Remove destination folder if it exists

[eugene-bright]

After the server had been restored from backup snapshot numbering was reset. Thus new snapshots has the same path as those are stored on the backup server but at the same time has different UUID. Buttersink tries to create directories that are exists already causing an error.

    ERROR:buttersink.py[275]: ERROR: Path /var/backups/myhost/rootfs/1/snapshot exists, can't receive 508f9147-20fc-4b4c-9d23-ea622fd2c230.                                                                             
Traceback (most recent call last):
  File "/root/buttersink/buttersink.py", line 257, in main
    diff.sendTo(dest, chunkSize=args.part_size << 20)
  File "/root/buttersink/Store.py", line 346, in sendTo
    receiveContext = dest.receive(self, paths)
  File "/root/buttersink/ButterStore.py", line 179, in receive
    "Path %s exists, can't receive %s" % (path, diff.toUUID)

Is it safe to silently delete destination folders if they exist already? I would like to start discussion here.

[AmesCornish]

Btrfs has a concept of an "original UUID" when using send and receive. Unfortunately, if you sent the received snapshot again, the "original UUID" changes, so neither Buttersink nor btrfs itself can tell that the final snapshot is the same as the original. I think this may be what happened to you.... btrfs thinks "snapshot" on the restore and "snapshot" on the backup are different snapshots, and is refusing to copy over.

The good news is that if you use Buttersink to transfer the snapshot, it will retain the original "orginal UUID", and future syncs should work as expected.

[eugene-bright]

I treated source system in the such way so all it's UUIDs changed. But at the same time new snapshots got the same paths used before (and are present on backup server). That's the problem source I think. Buttersink do transfer to destination folder that is already occupied by unrelated snapshot. What is the best approach for this situation? Should we silently replace target or do we need to wait before user intervention?

[AmesCornish]

We should not silently replace possibly critical data. I think users should manually delete the data they've decided is duplicate. It might be nice to have buttersink, or a separate tool, allow you to fix-up the "original UUIDs", though it would be a dangerous tool.

[eugene-bright]

I agree.