use an existing subvolume as source for further incremental backups

[dkebler]

I have an existing (large >500gb) subvolume on a remote machine with a nearly identical subvolume locally. I want to use that remote subvolume as the "source" snapshot for a btrbk run so it won't have to "resend" then entire 500gb.

Is there a way to "initialize" the backup against an existing subvolume?

Sorry to use your issue tracker for a question. If you enable discussions for the repo I would have been happy to use that instead.

[dkebler]

I'm guessing I need to change the "Received UUID" of the remote subvolume in order to fool btrbk into thinking that snapshot is already on the remote and thus only do "incremental". Only I'm not sure if that is possible. Someone else already has this same question but no one answered the post.

https://unix.stackexchange.com/questions/681639/is-there-any-native-tools-to-modify-uuid-and-received-uuid-of-a-btrfs-subvolume

[dkebler]

I think that actually worked using the set_received_uuid.py

on the target machine I made a snapshot of the subvolume on the remote formally created by btrbk into the folder of the the new btrbk conf target. Then used that python script (on target machine) to set the same received id as the original target subvolume snapshot. Then doing a dryrun btrbk shows that only incremental snapshots are needed (yea).

...trying a run now. Guess we'll see if it ended up really transfering as an incremental.

So don't know if this is something that can/should be incorporated into btrbk but might be a nice "feature".

[dkebler]

yea given how long this is taking I'm assuming that although it recognized the existing remote snapshot as one on which it could do an incremental it wasn't able to use the files therein as is (maybe it just decided the modified timestamp is not the same, not sure how btrbk compares to rsync in this regard). So maybe there is more to this than just setting the subvolume receive id. Oh well I'll just let it finish and then my issue will be moot.