[dead]
An almost perfect rsync over SSH backup script
41–50 of 130 posts
Re: An almost perfect rsync over SSH backup script
#42The first two lines of the script are already wrong; #!/bin/bash Should be: #!/usr/bin/env bash set -euo pipefail That’s table stakes for any bash script. With the first piece, exit on error, being critically important.
Agreed on fail on error, but the first one is needlessly pedantic.
Find me a single Linux distro where bash, if installed, is not available in /bin
Re: An almost perfect rsync over SSH backup script
#43Earlier quoted context omitted.
Yep. We use rsnapshot with btrfs snapshots on Debian / Ubuntu. You can set up multiple generations easily. Efficient storage using hard links. Very reliable.
AFAIK the crucial part of this, is rsync's `--link-dest=DIR` parameter, which hard-links an unmodified file to the respective place in "DIR", rather than making a copy.
The docs for my version of rsnapshot say not to use '--link-dest' if GNU cp is available, because the script will use 'cp -l' instead when copying "daily-1" to "daily-0" (for example). This is before it will overwrite "daily-0" with new files via rsync.
Re: An almost perfect rsync over SSH backup script
#44Earlier quoted context omitted.
Yep. We use rsnapshot with btrfs snapshots on Debian / Ubuntu. You can set up multiple generations easily. Efficient storage using hard links. Very reliable.
Could you elaborate on where the btrfs snapshots come into play? I use rsnapshot on a plain ext4 fs and it’s pretty slow (lots of small files).
The snapshots don't help with the speed.
Instead, they make sure the files aren't changing / being deleted between when the rsync starts and finishes.
Re: An almost perfect rsync over SSH backup script
#45rsnapshot[1] is what I used on FreeBSD with a snapshot. It is like a well-tested version of the author's rsync and ssh blog post. I have a blog post here[2] describing my setup. It saved my bacon multiple times. Also, rsnapshot works in pull mode, so no client is needed on my Linux/macOS desktop or server except ssh and rsync. [1] https://github.com/rsnapshot/rsnapshot [2] https://www.cyberciti.biz/faq/howto-install-…
Tangential question: I've been using rsnapshot to backup a remote machine to my local NAS for a while now. My impression is that even for an incremental backup, everything that I want to have backed up is transferred over the wire, and it is determined locally what actually needs to be written to disk, and what can be hardlinked from a previous backup. Is there a way to configure rsnapshot so that it only transfers t…
That is the default. rsnapshot uses rsync between local and remote, and rsync uses delta encoding algo so it is speedy. You may need to tune your ssh, networking stack and rsync.
Re: An almost perfect rsync over SSH backup script
#46I've been doing rsync-based backups of close to a thousand systems for ~20 years, most notably for a long time I backed up the python.org infrastructure, and I have quite a few thoughts on this. I also have a battle-tested rsync wrapper that I'll point to below.
- Backups should be automatic, only requiring attention when it is needed. This script philosophy seems to be "Just do your best, mail a log file, and rely on the user to figure out if something didn't work". Even for home backups, this is just wrong.
- As an example of the above: This script notes that it fails if a backup takes more than 24 hours.
- The "look for other rsyncs running" part of the code is an odd way of approaching locking, but for a single personal "push" backup I guess it is ok.
I've got an rsync wrapper that has been battle tested over a couple decades and hundreds of servers here: https://github.com/linsomniac/tummy-backup/blob/master/sbin/...
Features of it are:
- As the filename implies, the goal is to rsync to a zfs destination, and it will take a zfs snapshot as part of this. It is easy to customize to another backup destination, I've had people report they have customized it for their own laptop backups, for example to an rsync.net destination.
- It goes out of its way to detect when rsync has failed and log that.
- It does do "inplace" rsyncs, which dramatically save space if you have large files that get appended to (logfiles, ZODB databases).
- This is part of a larger system that manages the rsyncs of multiple systems, both local and remote. Things like alerting are done if a backup of a system has failed consistently for many days.
- In the case that there are no failures, there is no e-mail sent, meaning the user only gets actionable e-mails.
The hardlink trick only works for fairly small data sets. Issues include: Managing hard links takes a lot of overhead, especially on spinning discs. Large files being appended to use a ton of space (a 4GB file with 1K appended every day uses 128GB to store 14 dailies, 6 weeklies, and 12 monthlies). ZFS is a pretty good destination for rsync, as similar snapshots will use 4GB to store.
Re: An almost perfect rsync over SSH backup script
#47I didn't read the whole article but the reason I like rsync is that I get files on a normal filesystem. I don't need any special backup software to read or access the files.
I totally agree. Do not underestimate the obstacle a family member will face when he needs to open a borg or restic repository to access a backup of your family photos.
I use restic for most of my backups but hand-written rsync on an external drive with ntfs for the stuff that would be important to my family.
Re: An almost perfect rsync over SSH backup script
#48Earlier quoted context omitted.
Make sure your borg repos are copying properly and in full! I had a horrible realisation that my borg backups were timing out on the offiste copy, meaning the resulting offsite backup I had was non-existent. The heartbreaking error message Inconsistency detected. Please run "borg check [repository]" - although likely this is "beyond repair" Course following the 3-2-1 rule you're probably good, but aye I'm treating bo…
This is why you gotta test your backups too
Can Borg do this? Like, something you can set up to run once a month or so?
Re: An almost perfect rsync over SSH backup script
#49[deleted]
Re: An almost perfect rsync over SSH backup script
#50The first two lines of the script are already wrong; #!/bin/bash Should be: #!/usr/bin/env bash set -euo pipefail That’s table stakes for any bash script. With the first piece, exit on error, being critically important.
Agreed on fail on error, but the first one is needlessly pedantic. Find me a single Linux distro where bash, if installed, is not available in /bin
I'd argue it's easier to find a distro without /usr/bin/env.