Timeline for Linux backup utility for incremental backups
Current License: CC BY-SA 4.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 14, 2024 at 8:05 | comment | added | JoL |
@bit The significance of snapshots and reflinks are to pre-populate the directory you're rsyncing to with the previous backup, so that 1) rsync compares and only transfers the differences, and 2) you get a browsable directory that contains the whole backup, not just the difference. Like with the hardlinks created by the use of --link-dest, snapshots and reflinks don't take additional space on the disk for the data the backups have in common. Personally, I prefer btrfs snapshots because the FS provides a quicker way to report the changes between them than comparing each file.
|
|
| Sep 14, 2024 at 7:36 | comment | added | JoL |
@bit --link-dest is redundant when rsyncing to a snapshot you created with btrfs subvolume snapshot. The answer shows 3 different ways to do incremental backups with rsync. If you have a btrfs filesystem, you'd create the snapshot, then rsync without --link-dest. If you have an FS with reflink support, you'd do cp --reflink, then rsync without --link-dest. If you have neither type of FS, then you'd just do the rsync --link-dest.
|
|
| Sep 14, 2024 at 5:52 | comment | added | bit |
What is the significance of this step? If you use a filesystem with subvolumes like btrfs, you can also just snapshot from the previous backup before rsync'ing. Snapshots are instantaneous and don't take additional space[1].. And are you supposed to run rsync -va --link-dest after running the btrfs command?
|
|
| Sep 12, 2024 at 12:38 | comment | added | JoL |
@bit They're plain directories, so yes, they can be browsed. There's no need to mount. The btrfs subvolumes can be turned readonly with sudo btrfs property set $path_to_subvolume ro true. For the reflink and hardlink backup directories, you can use sudo mount -Br $path_to_subvolume{,} to mount them readonly. The {,} is just a brace-expansion trick to duplicate the argument. You're Bind mounting a directory onto itself in readonly mode.
|
|
| Sep 12, 2024 at 11:00 | comment | added | bit | Can you browse a backup made by rsync, e.g. by mounting it in readonly mode like restic does. | |
| Jun 7, 2021 at 16:27 | history | edited | JoL | CC BY-SA 4.0 |
added 63 characters in body
|
| Jun 11, 2020 at 14:16 | history | edited | CommunityBot |
Commonmark migration
|
|
| Feb 18, 2020 at 23:31 | history | edited | JoL | CC BY-SA 4.0 |
deleted 13 characters in body
|
| Feb 18, 2020 at 21:05 | comment | added | JoL | @user361323 I've edited the answer to expand on what I said in the comments. | |
| Feb 18, 2020 at 21:04 | history | edited | JoL | CC BY-SA 4.0 |
Added comparison with original tar proposal and instruction on how to get something similar.
|
| Feb 18, 2020 at 17:27 | comment | added | JoL |
@user361323 After considering that, if you really want each directory to only hold the new files, I suppose you can get that result by using rsync with hardlinks (with --link-dest) and then delete the hardlinks with something like find $new_backup -type f ! -links 1 -delete. If the advantage that you see on this is that you get an easy listing of the differences between versions (though you'd only see the additions and not deletions), consider that you can also get that listing by keeping logs of rsync's -i/--itemize-changes's output like I showed with tee.
|
|
| Feb 18, 2020 at 17:10 | comment | added | JoL | @user361323 This is versioning. With regards to used space and bandwidth, when you use hardlinks, reflinks, or snapshots, it doesn't really make a difference how often you make a backup. Each one will seem to contain the whole thing, but they'll share space of the common data and only transfer the new data. If a file, weighing 1GB, is present in 2 backups, you're still only using 1GB total, not 2GB. The advantages of doing it this way are 1) it's simpler to restore or browse, and 2) you have a natural way to encode file deletions, as opposed to when you do versions that only present new files. | |
| Feb 18, 2020 at 6:22 | comment | added | user361323 | But can you make a new backup for each iteration, with only the changes in? Because from what I read for rsync, when it backs up your files, it does so in the same place. What I need is something akin to versioning, where if I have it set up so that it backs up every 30m, after 3 hours I have 6 different backup files, each only containing the changes since the last full (master) backup. | |
| Feb 17, 2020 at 16:47 | history | edited | JoL | CC BY-SA 4.0 |
added 148 characters in body
|
| Feb 17, 2020 at 16:37 | history | edited | JoL | CC BY-SA 4.0 |
added 148 characters in body
|
| Feb 16, 2020 at 20:19 | comment | added | Angelo | rsync with link-dest is my preferred solution | |
| Feb 16, 2020 at 17:45 | history | edited | JoL | CC BY-SA 4.0 |
added 6 characters in body
|
| Feb 16, 2020 at 17:37 | history | edited | JoL | CC BY-SA 4.0 |
added 126 characters in body
|
| Feb 16, 2020 at 17:31 | history | edited | JoL | CC BY-SA 4.0 |
added 126 characters in body
|
| Feb 16, 2020 at 17:25 | history | answered | JoL | CC BY-SA 4.0 |