When a copy across the network (LAN or WAN) is interrupted, the server side (where the copy is being stored) cleans. This is not convenient in all cases. Suppose I am copying a 200 GB virtual disk and it is interrupted at 70%. When I copy the VM again, being that the cleaning removed all the blocks from the incomplete disk, I must copy them all again.
It would be very useful to enable an option such as --no-clean that leaves the blocks in the .blocklist file. You should also enable a repair option such as --clean-no-mapped to erase those blocks (which do not belong to any .map)
If you are backing up (--backup action) across an unstable IP link you don't have to worry about the connection dropping. The --backup action has been designed to be resilient under the most terrible circumstances. You won't be able to rely on the broken backup attempt (you should clean that folder from the remote repository), but next successful attempt will be O.K.
If you are using the --replica action on a 200GB disk and your connection drops at 70% you should use Rsync instead or just use the --backup action and then rebuild the VM on the target system, Rsync as well as --backup action are more oriented towards reliability in unstable scenarios than (c)XSIBackup-DC's --replica method is.
We will improve (c)XSIBackup-DC as time passes and we will most probably add a retake broken transfer option from the previous block, but by now you need a reliable TCP link to transfer big files.