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: Tue, 09 Jun 2026 20:29:59 GMT Organization: The Null Device Restoration Society Lines: 90 Message-ID: References: <1100f8f$1l2n2$4@dont-email.me> <1eCcnWPfKdPjW773nZ2dnZfqn_SdnZ2d@giganews.com> <75e75d98912b6197f616@dev.null> Injection-Date: Tue, 09 Jun 2026 20:30:00 +0000 (UTC) Injection-Info: dont-email.me; logging-data="318593"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX196PhLdtSFn5nw59iUSNsi/yh7AyoEL/p0="; posting-host="bd7980419cd1ebcd04c76ba0dd9d173e" Cancel-Lock: sha1:UTWPdxX//vF8c7AqvfJPu+QN8jU= sha256:UMIrC7FlPiZJgFZ9+JKT4afaBrwGbFr6oSKopd52ZRw= sha1:3dNgjb491REMGlCQaofdiBRGTRE= X-Newsreader: tin can + wet string 0.9.7 X-Archive-Policy: please preserve the funny parts X-Operating-System: TempleOS-adjacent abacus cluster In-Reply-To: X-Mood: reasonably caffeinated Xref: csiph.com comp.os.linux.misc:87758 >On Sat, 6 Jun 2026 14:01:54 +0200, "Carlos E.R." >wrote: >On 2026-06-06 13:34, TheLastSysop wrote: >>> 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. > >I do that already. > >Problem: I got btrfs corruption of one file, read error. I don't trust it. > >I am at this moment reformatting my main backup destination to XFS. > >> >> 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. >> That read error is the bit I would chase before blaming btrfs alone. XFS is a perfectly reasonable backup target, but a new filesystem will not fix a marginal disk, cable, USB bridge, SATA port, RAM problem, or power issue. A safe first pass is to look at the boring evidence: dmesg -T | egrep -i 'btrfs|i/o error|ata|usb|reset|medium error' smartctl -x /dev/WHATEVER smartctl -t long /dev/WHATEVER If the old filesystem is still readable enough, `btrfs scrub status -d` can also tell you whether this was a single bad extent or part of a larger pattern. For a backup destination, I would also keep at least one other independent copy until the replacement target has survived a full write, readback, and some time powered on. The most annoying backup failure is the one that moves with the enclosure and then wears a different filesystem hat. -- TheLastSysop "I survived the great rm -rf / rehearsal and all I got was this .signature."