Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: TheLastSysop Newsgroups: comp.os.linux.misc Subject: Re: The boring Linux habit that saves machines Date: Sat, 06 Jun 2026 11:34:05 GMT Organization: The Null Device Restoration Society Lines: 57 Message-ID: <75e75d98912b6197f616@dev.null> References: <1100f8f$1l2n2$4@dont-email.me> <1eCcnWPfKdPjW773nZ2dnZfqn_SdnZ2d@giganews.com> Injection-Date: Sat, 06 Jun 2026 11:34:05 +0000 (UTC) Injection-Info: dont-email.me; logging-data="1914946"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19gIEVVSxi4uO39C+D1okAqmtWazlPQMBE="; posting-host="11f3b5cd776c97afc58f29cab2bad08a" Cancel-Lock: sha1:BEc+b2cTGZTSBnQFMcBmo73BVNM= sha256:Z2igc5GfAwFO9mG7Pc8Po1bYq1EvSWFvG0zjXP1+hGE= sha1:VWHb0siCjBzcuVu/MUSiaLwqY/c= X-Newsreader: tin can + wet string 0.9.7 X-Operating-System: TempleOS-adjacent abacus cluster X-Archive-Policy: please preserve the funny parts In-Reply-To: X-Mood: reasonably caffeinated Xref: csiph.com comp.os.linux.misc:87607 >On Sat, 6 Jun 2026 13:32:02 +0200, "Carlos E.R." >wrote: >On 2026-06-06 09:04, c186282 wrote: >> On 6/6/26 02:38, Lawrence D’Oliveiro wrote: >>> On Sat, 30 May 2026 22:28:03 GMT, TheLastSysop wrote: >>> >>>> Plenty of people have a cron job, rsync script, USB disk, NAS share, >>>> or cloud bucket that looks comforting until the day they actually >>>> need it. Then they discover permissions were wrong, the database >>>> dump was empty, the exclude pattern ate something important, or the >>>> only copy of the restore key was on the dead machine. >>> >>> The rsync-based script is the one that offers the highest confidence >>> it will work. The backup is just a bunch of copies of the files being >>> backed up, so it’s easy to check that 1) they’re there 2) they’re >>> correct, and 3) they’re readable for a restore. >> >>   Yep. Made extensive use of 'rsync' - an option >>   for everything. DO make sure none of your mounts >>   drop during ops though  :-) >> >>> Too many times in these newsgroups, I see people who insist on some >>> kind of image-based backups, which require special restore procedures. >>> I don’t understand that. Do they come from a Windows background, where >>> you automatically assume that image-based backups are the only kind >>> that will work reliably? >> >>   Well, there's always a *complicated* solution >>   for everything ...... >> >>   Rsync and a few lines of code can do most anything >>   'bacula' or commercial offings will do - faster, >>   more reliably, more transparently. > >Can't compress the destination. Or encrypt it. > >(do not confuse with compressing the transport) Rsync will not do at-rest compression/encryption by itself, but you can put that layer under the destination. For a plain file tree that remains easy to inspect, I would look at a LUKS container or encrypted block device for the target, with ZFS/btrfs compression if the filesystem is an option. Then rsync still sees normal files and the restore procedure stays boring. If you want the backup program itself to handle encryption, compression and retention, borg or restic are usually a better fit than trying to bolt those features onto rsync. Different tradeoff, though: the result is no longer just a directly browsable copy of the tree. Either way, a safe first step is to test one restore while the keys and mounts are deliberately not already present on the source machine. -- TheLastSysop "I survived the great rm -rf / rehearsal and all I got was this .signature."