search

digint / btrbk

Tool for creating snapshots and remote backups of btrfs subvolumes
https://digint.ch/btrbk/
GNU General Public License v3.0
1.69k stars 122 forks source link

questions about workflow #89

Open dimovnike opened 8 years ago

dimovnike commented 8 years ago

Hi, i want to make backups from btrfs/SSD to local btrfs/HDD and to remote raw server via SSH. Is this tool able to use a single btrfs send but simultaneously store both backups? Is it able to detect when btrfs receive failed on local HDD and invalidate the backup on remote server?

Another question: Is it possible to make an incremantal btrfs send /ssd | tee /tmp/tmpcopy | btrfs receive /hdd then check the resulting snapshots with rsync -n and only if is OK send the raw file /tmp/tmpcopy to remote SSH server?

Btw, are there other possibilities to send questions here? Thanks.

digint commented 8 years ago

I want to make backups from btrfs/SSD to local btrfs/HDD and to remote raw server via SSH. Is this tool able to use a single btrfs send but simultaneously store both backups? Is it able to detect when btrfs receive failed on local HDD and invalidate the backup on remote server?

No. btrbk does one send per specified target, so this would be two separate send-streams for your use case. These send-streams should be identical though, as they are created from a read-only snapshot. If a send-receive failed on your harddisk, an attempt will still be made on the remote raw target. btrbk only aborts subsequent backups on the same target (e.g. if you have multiple subvolumes).

Is it possible to make an incremantal btrfs send /ssd | tee /tmp/tmpcopy | btrfs receive /hdd then check the resulting snapshots with rsync -n and only if is OK send the raw file /tmp/tmpcopy to remote SSH server?

No. btrbk does not (yet) provide any check functionality. The only checking you get is the error output from btrfs receive, which is usually enough (for non-raw backups).

That said, I get the point you are making here, trying to get more certainty of the integrity of your raw backups. Your proposed btrfs send | tee tmpcopy | btrfs receive /integrity/check/disk approach would help, at least if you don't trust btrfs to create identical send-streams (which is kind of sane paranoia to have when it comes to your precious backups on a non-btrfs NAS).

I will take this into account when doing further work on btrbk raw-backups. I was also thinking of providing some raw-check functionality (btrfs-receive the full incremental raw backup chain to a integrity-check-subvolume), this will probably come if I find some time to implement it.