| 1 |
On Sun, Oct 24, 2021 at 10:48 AM Helmut Jarausch <jarausch@××××××.be> wrote: |
| 2 |
> |
| 3 |
> Finally I have come up with the following shell script for backing up |
| 4 |
> my /home directory, |
| 5 |
> comments are more than welcome, of course. |
| 6 |
> (/HBackUp contains a BTRFS file system) |
| 7 |
> |
| 8 |
|
| 9 |
Is /home on btrfs? If not then something like this is probably your |
| 10 |
best bet (not sure if existing tools work, and I didn't carefully |
| 11 |
check your script for any missed error handling). |
| 12 |
|
| 13 |
If /home is on btrfs, just on a different filesystem, then you're |
| 14 |
probably much better off using something based on send/receive. This |
| 15 |
can let you very efficiently transfer snapshots incrementally and |
| 16 |
preserve COW between the copies (that is, unchanged data is |
| 17 |
deduplicated). While rsync is very efficient for network transfer or |
| 18 |
amount of data written, in order to detect changes it has to read all |
| 19 |
the inodes in both copies of the data. If you don't trust mtime in |
| 20 |
either copy then you have to further read all the data itself. That |
| 21 |
is a lot of read IO and CPU on both ends, though if they're on |
| 22 |
different hosts the network traffic is very efficient. |
| 23 |
|
| 24 |
Btrfs send/receive can determine what has changed between two |
| 25 |
snapshots very efficiently, as snapshots are b-trees that are |
| 26 |
cross-linked where there are no changes, so you only have to descend |
| 27 |
and then transfer branches that actually contain changes (similar to |
| 28 |
git). If only one file changes between snapshots the number of reads |
| 29 |
to find it scales logarithmically with the amount of metadata, while |
| 30 |
rsync scales linearly as it has to read all of it. Also, with btrfs |
| 31 |
the incremental change set can be prepared without any reference to |
| 32 |
the target (since both copies are on the source), so latency isn't a |
| 33 |
factor at all. You can just dump the incremental backups to serial |
| 34 |
files if you prefer, though that requires keeping them all as with |
| 35 |
normal incremental backups. If you receive them into a btrfs |
| 36 |
filesystem then you only need to retain one snapshot in common between |
| 37 |
the source and target to allow future incrementals. |
| 38 |
|
| 39 |
I think there are tools out there which already implement this for |
| 40 |
btrfs. I know such tools exist for zfs and I use one myself. I never |
| 41 |
used this with btrfs as it was immature at the time I switched over. |
| 42 |
|
| 43 |
-- |
| 44 |
Rich |
Archives