Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An almost perfect rsync over SSH backup script

blog.zazu.berlin

Post reply on HN
Print view View original

61–70 of 130 posts

Re: An almost perfect rsync over SSH backup script

#61

Post by aborsy »

aedocw wrote: post #53
throwaway81523 wrote: post #3

Too complicated to even try to read. Rsync is great but I've switched to Borg for backups. Borg isn't perfect but it is a higher level approach to backups, as it were. Hetzner recently dropped the price of their Storage Box backup product to about 2 euro per TB per month, and Borg works nicely with it. Borg encrypts all the backup contents and conceals the metadata on the backup server, and yet you can (with the encr…

Fully agree, Borg is awesome. I wrote up how I'm using it here[1]. In short, borg backup to a local machine, and that machine uses rclone to copy the backups to an S3 bucket off-site. I've had multiple occasions to restore stuff successfully, and I never have to think about whether my data is retrievable. [1] https://opensource.com/article/17/10/backing-your-machines-b...

You need to run “Borg check” once in a while to check and fix backup integrity errors. S3 egress fees will kill you!

Re: An almost perfect rsync over SSH backup script

#63

Post by throwaway81523 »

pkulak wrote: post #48
klysm wrote: post #13

Earlier quoted context omitted.

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?

Borg has a command ("borg check") to test backup metadata. I'm not sure exactly what it does, but it is pretty slow, about 80 minutes to check a 1.6TB backup depending on how busy the backup server is. Another approach might be to mount the backup as a FUSE filesystem and monitor it with something like tripwire. I just thought of that a minute ago and haven't looked into it, so idk if it is workable. At the end of the day you have to occasionally do a full restore to another system, and test everything.

Re: An almost perfect rsync over SSH backup script

#64

Post by throwaway81523 »

sendfoods wrote: post #23
throwaway81523 wrote: post #3

Too complicated to even try to read. Rsync is great but I've switched to Borg for backups. Borg isn't perfect but it is a higher level approach to backups, as it were. Hetzner recently dropped the price of their Storage Box backup product to about 2 euro per TB per month, and Borg works nicely with it. Borg encrypts all the backup contents and conceals the metadata on the backup server, and yet you can (with the encr…

The cheapest I can find on https://www.hetzner.com/storage/storage-box is 3.49 Euro. I assume your talking about the bigger plans with price / TB?

Yes, the bigger ones are around 2 euro per TB. They also have Storage Share at around 3 euro/TB in the bigger sizes. Those have more features (they run nextcloud) and are themselves backed up several times a day.

Re: An almost perfect rsync over SSH backup script

#66

Post by wjnc »

camnora wrote: post #65

Does anyone have experience with Duplicati [1] or recommend it? I am tentatively looking to make the switch to something a little more sophisticated than manually tar-balling + rsyncing backups. [1] https://www.duplicati.com/

I’ve that in use on my personal pc (Ubuntu) for my personal files. Bringing in the pictures via Dropbox. It works flawlessly for about 1.5 yr and 150GB to Backblaze. What put me off initially is that the most important part of backups: testing the restore process was / is less documented. Got it tested by just using common sense and a fresh temporary install. (Any pointers to how to do automatic integrity tests greatly appreciated.)

Re: An almost perfect rsync over SSH backup script

#67

Post by jethro_tell »

senko wrote: post #42
koolba wrote: post #14

The 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

As a system eng for almost 15 years I've spent a good number of years handling deployments, dependancies, environment evaluations and all the little minutiae that's required to run large complex distributed systems at scale. This is fine to ignore if it's your personal box and no one else is working on it.

However I've seen it happen quite frequently in systems that were designed with container like 'chroot-lite' prod setups where the system bash and the deployed environment may contain different bash.

The different bash is the one that was tested in the test env with the automation. There may even be multiple different versions of an interpreter on the system with multiple app environments running.

This was a pretty common way to package apps before easy access to containers and container managers.

This is why we have industry best practices, so that people who don't understand why something exists can just follow the best practices and we don't all have to be experts in things outside of our direct field.

Re: An almost perfect rsync over SSH backup script

#68

Post by scottlamb »

tjoff wrote: post #31
branon wrote: post #21

Haven't read the page yet but the header image struck me as interesting. "Molex to SATA, lose all your data" was drilled into my head at an early job and appears to be what's depicted there. If your disks are set up in a similar way, you might have a very immediate need for a good backup script :)

That's a weird mantra, molex to sata is perfectly fine.

I'd never heard of it either but found this interesting youtube video: https://www.youtube.com/watch?v=fAyy_WOSdVc>.

tl;dw: many of these adapters are so poorly made they might catch on fire. They put the (insulated) wires in and then pour in something kind of like hot-melt glue around them (to hold them in place, and/or for extra insulation, not sure). Sometimes the wires are well separated within that medium, but sometimes they're touching, and possibly the wire's own insulation is melted by the glue. There also seems to be some contaminants in the glue, and possibly corrosion from the way it was soldered.

At the end, he shows a better kind where crimped wires are put into hard plastic channels, which reliably keeps them in place without the same risk of compromising their insulation.

Re: An almost perfect rsync over SSH backup script

#69

Post by aborsy »

camnora wrote: post #65

Does anyone have experience with Duplicati [1] or recommend it? I am tentatively looking to make the switch to something a little more sophisticated than manually tar-balling + rsyncing backups. [1] https://www.duplicati.com/

I haven’t used it, but the comments on Reddit indicate there are issues. You may easily find them.

Re: An almost perfect rsync over SSH backup script

#70

Post by scottlamb »

0xbadcafebee wrote: post #58
koolba wrote: post #14

The 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.

#!/usr/bin/env bash and set -u are always good ideas. There are cases where you don't want -e enabled, such as when you want to make sure your script makes the best attempt to continue operating even through unknown failures. Using pipefail makes it more likely your script will fail unexpectedly and without a known cause. You have to check PIPELINE to see which command in a string of pipes failed and then report on i…

> Using pipefail makes it more likely your script will fail unexpectedly and without a known cause. You have to check PIPELINE to see which command in a string of pipes failed and then report on it. This is often pointless, because usually just checking the output of the last pipe will tell you whether you got what you wanted.

Really? In this script's "ps aux | grep -c rsync" for example, if "ps" fails, you'll just get 0 without the grep failing.

(Speaking of that line: chasil's completely right that it's much better to use "flock" than "ps" for locking...)

Post reply on HN