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: Wed, 10 Jun 2026 08:48:35 GMT Organization: The Null Device Restoration Society Lines: 142 Message-ID: References: <1100f8f$1l2n2$4@dont-email.me> <1eCcnWPfKdPjW773nZ2dnZfqn_SdnZ2d@giganews.com> <75e75d98912b6197f616@dev.null> <1OKdnZvWId1PvLT3nZ2dnZfqn_GdnZ2d@giganews.com> Injection-Date: Wed, 10 Jun 2026 08:48:36 +0000 (UTC) Injection-Info: dont-email.me; logging-data="663076"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19jdgukH5jCjnRKqjuwoZkB7Km+AkTrGgg="; posting-host="4a3ff1ddd4520e0e3b411fbbfc126362" Cancel-Lock: sha1:SbzVq6A0f4CD/dmAiyNlksHYr2E= sha256:M1g2uPJzeQ5gsbMEKuXxkbTyirPZ3TNvdlOaHsENVAs= sha1:G30SPM523UyuE4s12nJw7rvuTKU= X-Archive-Policy: please preserve the funny parts X-Newsreader: tin can + wet string 0.9.7 X-Mood: reasonably caffeinated In-Reply-To: <1OKdnZvWId1PvLT3nZ2dnZfqn_GdnZ2d@giganews.com> X-Operating-System: TempleOS-adjacent abacus cluster Xref: csiph.com comp.os.linux.misc:87796 >On Wed, 10 Jun 2026 04:36:01 -0400, c186282 wrote: >On 6/9/26 16:29, TheLastSysop wrote: >>> 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. > > If using USB drives there are many little ways > things can go wrong. It's MORE often the actual > drive, not the particular file system used. > > BTRFS/XFS ... have really had no issues with them. > XFS is still good for large backup drives. BTRFS > seems like over-kill. TREND towards EXT4 on > everything though - most tools. > > Anyway, most ALL current Linux filesystems are Very > Good. Bizarre probs - look to the hardware. > > I made a little home NAS ... all USB drives in > a 4-unit enclosure. It's pretty damned good. > FAN died, replaced with a bigger/noisier one, > but all in all can't complain. DID find a bit > of obscure code for resetting the entire USB > bus - as if everything was newly plugged in. > Run THAT just after boot. Settles things. > > Smartctl ... used to use that a lot with mag drives, > automated scripts + email reports. Sometimes FOUND > stuff too. However mag drives are not as common > anymore, all SSDs. However, BIG, it's still mags. > > IF in your budget, DO look into the Sinology > dedicated NAS units. One caution on the USB-bus reset trick: I would only do that before any of those filesystems are mounted, or after they have been cleanly unmounted. Resetting a bus with mounted backup disks on it is a fine way to turn a minor USB weirdness into a filesystem problem. For a little USB NAS, the boring parts I would check first are: * a powered enclosure/hub with enough margin at spin-up * stable mounts by filesystem UUID or label, not /dev/sdX names * dmesg for UAS resets, link flaps, and power errors * smartctl -x on each disk, if the bridge passes SMART through * a periodic full readback or scrub, not just a successful write If the bridge is one of the flaky UAS ones, trying the usb-storage quirk for that device can sometimes make it less exciting. Slower is better than randomly disappearing in the middle of a backup. -- TheLastSysop "I survived the great rm -rf / rehearsal and all I got was this .signature."