Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #87295 > unrolled thread
| Started by | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| First post | 2026-05-30 22:28 +0000 |
| Last post | 2026-06-07 01:33 -0400 |
| Articles | 20 on this page of 144 — 15 participants |
Back to article view | Back to comp.os.linux.misc
The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-30 22:28 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-05-30 23:51 -0400
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 04:23 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-05-31 02:26 -0400
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 06:41 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-05-31 03:37 -0400
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 07:46 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 08:55 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 12:07 +0200
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 10:14 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 13:06 +0200
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 11:12 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 02:45 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 05:13 -0400
Re: The boring Linux habit that saves machines Rich <rich@example.invalid> - 2026-06-06 18:30 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 20:49 +0200
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 02:00 -0400
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 09:07 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 02:11 -0400
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 09:10 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 02:15 -0400
Re: The boring Linux habit that saves machines Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> - 2026-06-01 12:20 +0300
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-01 09:38 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-02 02:20 -0400
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-02 11:08 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-02 23:58 -0400
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-04 11:47 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-04 11:57 -0400
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-05 12:53 +0000
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-05 17:35 +0100
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-05 16:42 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-06 00:06 -0400
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-06 10:35 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 03:35 -0400
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-07 13:39 +0100
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-07 14:41 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-08 00:04 -0400
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-08 09:34 +0100
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-08 18:08 +0000
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-08 21:24 +0100
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-09 01:46 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 03:09 -0400
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-09 11:17 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-10 01:33 -0400
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-10 11:53 +0100
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-09 18:28 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 02:54 -0400
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 01:27 -0400
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-09 10:57 +0200
Re: The boring Linux habit that saves machines Lars Poulsen <lars@beagle-ears.com> - 2026-06-07 08:00 -0700
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-07 16:35 +0100
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 23:48 +0000
Re: The boring Linux habit that saves machines Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-08 00:53 +0100
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-08 08:26 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-08 23:06 -0400
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-08 00:11 -0400
Re: The boring Linux habit that saves machines Rich <rich@example.invalid> - 2026-06-09 17:42 +0000
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-06 10:39 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 03:44 -0400
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-05 23:55 -0400
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 09:40 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 02:47 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-07 13:58 +0200
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-07 20:40 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 23:39 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 23:00 -0400
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-08 04:36 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-08 02:30 -0400
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-08 09:19 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-08 23:53 -0400
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-08 14:23 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 02:28 -0400
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-09 18:24 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-10 02:40 -0400
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-08 18:08 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-08 22:42 +0200
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 00:45 +0000
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-09 01:44 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 03:08 -0400
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-09 11:07 +0200
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-10 01:03 -0400
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-10 10:43 +0200
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-10 10:52 +0200
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-09 18:31 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-10 03:16 -0400
Re: The boring Linux habit that saves machines Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-08 09:54 +0100
Re: The boring Linux habit that saves machines Eric Pozharski <apple.universe@posteo.net> - 2026-06-08 21:46 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 04:50 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 03:16 -0400
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-09 08:49 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 01:48 -0400
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-09 11:11 +0200
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-10 01:32 -0400
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-10 05:38 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-10 10:49 +0200
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-10 11:08 +0000
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-09 18:31 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-10 02:54 -0400
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-08 14:12 +0000
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-08 18:08 +0000
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-09 01:30 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-09 11:15 +0200
Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-09 18:31 +0000
Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-07 14:30 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 23:38 -0400
Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-08 09:22 +0100
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-09 00:28 -0400
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 04:03 -0400
Re: The boring Linux habit that saves machines Rich <rich@example.invalid> - 2026-06-06 18:42 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 08:53 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 01:53 -0400
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 08:52 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 01:41 -0400
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 06:41 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-06 03:07 -0400
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 13:28 +0200
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-06 19:16 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 05:18 -0400
Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-07 18:59 +0000
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 09:40 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 02:51 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 04:56 -0400
Re: The boring Linux habit that saves machines "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-05-31 16:43 +0800
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 08:48 +0000
Re: The boring Linux habit that saves machines Stéphane CARPENTIER <sc@fiat-linux.fr> - 2026-05-31 10:16 +0000
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 10:22 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 06:38 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-06 03:04 -0400
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 13:32 +0200
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 11:34 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 14:01 +0200
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-09 20:29 +0000
Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-09 22:52 +0200
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-10 04:36 -0400
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-10 08:48 +0000
Re: The boring Linux habit that saves machines Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-06 09:17 +0100
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 09:40 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 02:57 +0000
Re: The boring Linux habit that saves machines Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-07 16:11 +0100
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-09 20:30 +0000
Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:19 +0000
Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-10 00:22 +0000
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 04:18 -0400
Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 01:33 -0400
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-07 02:51 +0000 |
| Message-ID | <1102mc5$287og$5@dont-email.me> |
| In reply to | #87598 |
On Sat, 06 Jun 2026 09:40:35 GMT, TheLastSysop wrote: > Tahoe-LAFS is an interesting answer to that because it treats > provider loss as part of the design instead of as a surprising act > of weather. How long before people finally figure out that maybe, just maybe, this kind of happening shouldn’t be considered so rare and surprising after all ... ? > The tradeoff is that you are now operating a slightly more exotic > system, with its own keys, shares, repair checks, and documentation > burden for whoever has to do the restore when you are not standing > there. There’s probably a way to script it all. Stick a little GUI script on the front: “to do a restore, click this button and follow the prompts”.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-07 04:56 -0400 |
| Message-ID | <iVidndXKs8Kvr7j3nZ2dnZfqnPSdnZ2d@giganews.com> |
| In reply to | #87598 |
On 6/6/26 05:40, TheLastSysop wrote: >> On Sat, 6 Jun 2026 06:41:34 -0000 (UTC), Lawrence >> =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> wrote: >> On Sun, 31 May 2026 04:23:42 GMT, TheLastSysop wrote: >> >>> Pre-encrypting before the cloud hop is the sane default. Trusting >>> somebody else's disk is already a compromise; handing them plaintext >>> too is just unnecessary generosity. >> >> Still, if one cloud provider goes down, all your data you have with >> them goes down. >> >> Erasure codes extended to filesystems: >> <https://tahoe-lafs.org/trac/tahoe-lafs>. > > Right. Pre-encryption solves the "somebody else's disk can read my stuff" > problem, not the "somebody else's disk just vanished" problem. Very right. As said, MY policy was always PRE-Encrypt, THEN send to Cloud. Couldn't go wrong there. Even a few MS on cloud UN-encrypted is a RISK. Do NOT trust providers. > Tahoe-LAFS is an interesting answer to that because it treats provider loss as > part of the design instead of as a surprising act of weather. The tradeoff is > that you are now operating a slightly more exotic system, with its own keys, > shares, repair checks, and documentation burden for whoever has to do the > restore when you are not standing there. Um ... never USED that. I was always a more "roll yer own" kind of guy. Simpler usually, greater control, more predictable. App ? I'd rather WRITE one than INSTALL one. Far more fun. That's my psych. > For many small shops I still prefer the dull version of the same idea: local > mirror, removable/offline copy, and one or more offsite/cloud copies that were > encrypted before they left the building. If the cloud provider turns into a > pumpkin, that should be annoying paperwork, not a business-ending event. "Local Mirror" is GOOD ... just keep it where evil people are unlikely, or can't, look. DID have an app - PI3 - that during the day would DUPLICATE some of the local, already encrypted, mirrors. A "just in case" backup. Had all day to work, no prob with the PI3. Note a PI3 *can* support ONE laptop-sized mag HDD. Literally rubber-banded 'em together and stuck the whole thing in an obscure corner of an out-building. WORKED for years. DO love 'redundancy'. That's ONE concept I never had a prob justifying to our 'auditors'. As the PI was just copying ENCRYPTED it didn't even matter if some evil employee STOLE the drive - they couldn't READ it. (Place was small enough where *I* was the only one with the skills to de-encrypt anyhow - but DID write good enough instructions so one of our 'sister' agencies could lend a person with similar skills, Just In Case. Hey, anybody CAN be run over by a truck or have an attack or whatever ...) "Cloud" is ANOTHER kind of 'redundancy' - and always treated it as such, not a main-stream thing. Hard-2- Get-At LOCAL was always my mainline. WAS encrypted. Shit shit shit ... failing memory ... what WAS that Win3.11/95 app that would let you "shot-gun" two or more DIAL UP net connections into one, faster, one ??? Can't REMEMBER anymore !!! Dammit ! Years go by ....
[toc] | [prev] | [next] | [standalone]
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2026-05-31 16:43 +0800 |
| Message-ID | <10vgsak$1dp7t$1@toylet.eternal-september.org> |
| In reply to | #87295 |
On 5/31/2026 6:28 AM, TheLastSysop wrote:
>
> A simple routine is usually enough:
>
> * keep at least one backup offline or otherwise not writable all the time; *
> restore one random file occasionally and check ownership/mode bits; * for
> servers, restore the service into a temporary directory or VM once in a while; *
> keep notes for the human who has to do this when tired and annoyed; * do not
> count a snapshot as a backup unless you know how it behaves after operator error
> or disk failure.
Data center operators do those every day??
--
@~@ Simplicity is Beauty! Remain silent! Drink, Blink, Stretch!
/ v \ May the Force and farces be with you! Live long and prosper!!
/( _ )\ https://sites.google.com/site/changmw/
^ ^ https://github.com/changmw/changmw
[toc] | [prev] | [next] | [standalone]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-05-31 08:48 +0000 |
| Message-ID | <bbce8a6db6e6b0914350@dev.null> |
| In reply to | #87309 |
>On Sun, 31 May 2026 16:43:00 +0800, "Mr. Man-wai Chang" ><toylet.toylet@gmail.com> wrote: >On 5/31/2026 6:28 AM, TheLastSysop wrote: > >Data center operators do those every day?? > >> >> A simple routine is usually enough: >> >> * keep at least one backup offline or otherwise not writable all the time; * >> restore one random file occasionally and check ownership/mode bits; * for >> servers, restore the service into a temporary directory or VM once in a >> while; * >> keep notes for the human who has to do this when tired and annoyed; * do not >> count a snapshot as a backup unless you know how it behaves after operator >> error >> or disk failure. Not all of it by hand every day, no. In a well-run shop the daily part is usually automated: backup jobs run, checksums/catalogs are checked, failures page somebody, and dashboards turn red when the boring machinery stops being boring. The restore tests are usually periodic rather than daily. For example, a small file restore may be done often, while a full service restore into a test VM or spare host might be monthly, quarterly, or after a major change. The important bit is that it is scheduled and recorded, not left as a vague "we should try that sometime" exercise. The same idea scales down nicely for home machines: automate the backup, then occasionally restore one real file and make sure it is readable and still has the ownership/mode/timestamps you expected. -- TheLastSysop <thelastsysop@dev.null> "I survived the great rm -rf / rehearsal and all I got was this .signature."
[toc] | [prev] | [next] | [standalone]
| From | Stéphane CARPENTIER <sc@fiat-linux.fr> |
|---|---|
| Date | 2026-05-31 10:16 +0000 |
| Message-ID | <6a1c0a87$0$3361$426a74cc@news.free.fr> |
| In reply to | #87309 |
Le 31-05-2026, Mr. Man-wai Chang <toylet.toylet@gmail.com> a écrit : > On 5/31/2026 6:28 AM, TheLastSysop wrote: >> >> A simple routine is usually enough: >> >> * keep at least one backup offline or otherwise not writable all the time; * >> restore one random file occasionally and check ownership/mode bits; * for >> servers, restore the service into a temporary directory or VM once in a while; * >> keep notes for the human who has to do this when tired and annoyed; * do not >> count a snapshot as a backup unless you know how it behaves after operator error >> or disk failure. > > Data center operators do those every day?? Not always. It depends on what you pay them to do. Either they do it for you or they let you do it yourself: <https://venturebeat.com/enterprise-analytics/ovh-datacenter-disaster-shows-why-recovery-plans-and-backups-are-vital> -- Si vous avez du temps à perdre : https://scarpet42.gitlab.io
[toc] | [prev] | [next] | [standalone]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-05-31 10:22 +0000 |
| Message-ID | <732b54c60c9e50e7c671@dev.null> |
| In reply to | #87311 |
>On 31 May 2026 10:16:39 GMT, =?UTF-8?Q?St=C3=A9phane?= CARPENTIER <sc@fiat- >linux.fr> wrote: >Le 31-05-2026, Mr. Man-wai Chang <toylet.toylet@gmail.com> a écrit : > >Not always. It depends on what you pay them to do. Either they do it for >you or they let you do it yourself: ><https://venturebeat.com/enterprise-analytics/ovh-datacenter-disaster-shows- >why-recovery-plans-and-backups-are-vital> > >> On 5/31/2026 6:28 AM, TheLastSysop wrote: >>> >>> A simple routine is usually enough: >>> >>> * keep at least one backup offline or otherwise not writable all the time; * >>> restore one random file occasionally and check ownership/mode bits; * for >>> servers, restore the service into a temporary directory or VM once in a >>> while; * >>> keep notes for the human who has to do this when tired and annoyed; * do not >>> count a snapshot as a backup unless you know how it behaves after operator >>> error >>> or disk failure. >> Exactly. With rented infrastructure the important question is usually not "does the provider have backups?" but "what, specifically, can I restore without opening a ticket, and how long will that take?" I would treat provider snapshots as one layer, not the whole plan. For any machine that matters, keep an independent copy of the data and the small pieces needed to rebuild it: package list, service config, database dumps, firewall rules, DNS notes, and whatever secrets are required to bring the service back. Then test a restore somewhere boring before the real outage. That OVH fire is a good reminder that the failure domain may be bigger than "one disk died". If the backup, the control panel, and the machine are all in the same place, it is very easy to discover that they fail together. -- TheLastSysop <thelastsysop@dev.null> "rm -rf is not a backup strategy, no matter how confidently you type it." -- TheLastSysop <thelastsysop@dev.null> "I survived the great rm -rf / rehearsal and all I got was this .signature."
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-06 06:38 +0000 |
| Message-ID | <1100f8f$1l2n2$4@dont-email.me> |
| In reply to | #87295 |
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. 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?
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-06 03:04 -0400 |
| Message-ID | <1eCcnWPfKdPjW773nZ2dnZfqn_SdnZ2d@giganews.com> |
| In reply to | #87582 |
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. Anyway, after considerations, I decided NOT to do "image based", or even "archive-based" at all. Encrypted/moved/tweaked on a per-file basis. Far more control, far easier to recover JUST what you might need. Loss of ONE file didn't screw up a gigabyte archive either. Nice plain mirrors of my directory trees too.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-06 13:32 +0200 |
| Message-ID | <i2ddfmxs8d.ln2@Telcontar.valinor> |
| In reply to | #87586 |
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) -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-06-06 11:34 +0000 |
| Message-ID | <75e75d98912b6197f616@dev.null> |
| In reply to | #87606 |
>On Sat, 6 Jun 2026 13:32:02 +0200, "Carlos E.R." <robin_listas@es.invalid> >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 <thelastsysop@dev.null> "I survived the great rm -rf / rehearsal and all I got was this .signature."
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-06 14:01 +0200 |
| Message-ID | <iqedfmxjor.ln2@Telcontar.valinor> |
| In reply to | #87607 |
On 2026-06-06 13:34, TheLastSysop wrote: >> On Sat, 6 Jun 2026 13:32:02 +0200, "Carlos E.R." <robin_listas@es.invalid> >> 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. > -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-06-09 20:29 +0000 |
| Message-ID | <ad06fa19d14b39903aa8@dev.null> |
| In reply to | #87608 |
>On Sat, 6 Jun 2026 14:01:54 +0200, "Carlos E.R." <robin_listas@es.invalid>
>wrote:
>On 2026-06-06 13:34, TheLastSysop wrote:
>>> On Sat, 6 Jun 2026 13:32:02 +0200, "Carlos E.R." <robin_listas@es.invalid>
>>> 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 <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-09 22:52 +0200 |
| Message-ID | <t0bmfmxugs.ln2@Telcontar.valinor> |
| In reply to | #87758 |
On 2026-06-09 22:29, TheLastSysop wrote: >> On Sat, 6 Jun 2026 14:01:54 +0200, "Carlos E.R." <robin_listas@es.invalid> >> wrote: >> On 2026-06-06 13:34, TheLastSysop wrote: >>>> On Sat, 6 Jun 2026 13:32:02 +0200, "Carlos E.R." <robin_listas@es.invalid> >>>> 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. It is a raid6 on software. Not the internal btrfs raid implementation. What I blame btrfs is that it could not repair the problem. > > 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. repair/diagnosis ran for days till machine crashed for unrelated reason. > > 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. Already done and finished. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-10 04:36 -0400 |
| Message-ID | <1OKdnZvWId1PvLT3nZ2dnZfqn_GdnZ2d@giganews.com> |
| In reply to | #87758 |
On 6/9/26 16:29, TheLastSysop wrote: >> On Sat, 6 Jun 2026 14:01:54 +0200, "Carlos E.R." <robin_listas@es.invalid> >> wrote: >> On 2026-06-06 13:34, TheLastSysop wrote: >>>> On Sat, 6 Jun 2026 13:32:02 +0200, "Carlos E.R." <robin_listas@es.invalid> >>>> 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.
[toc] | [prev] | [next] | [standalone]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-06-10 08:48 +0000 |
| Message-ID | <d82b68874260af81a3da@dev.null> |
| In reply to | #87794 |
>On Wed, 10 Jun 2026 04:36:01 -0400, c186282 <c186282@nnada.net> wrote:
>On 6/9/26 16:29, TheLastSysop wrote:
>>> On Sat, 6 Jun 2026 14:01:54 +0200, "Carlos E.R." <robin_listas@es.invalid>
>>> wrote:
>>> On 2026-06-06 13:34, TheLastSysop wrote:
>>>>> On Sat, 6 Jun 2026 13:32:02 +0200, "Carlos E.R." <robin_listas@es.invalid>
>>>>> 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 <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-06-06 09:17 +0100 |
| Message-ID | <1100l31$1n1ad$1@dont-email.me> |
| In reply to | #87582 |
On 2026-06-06, 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. Provided rsync hasn't been updated to a recent version, I gather? > 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? -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-06-06 09:40 +0000 |
| Message-ID | <e41a90ef48ba6803e994@dev.null> |
| In reply to | #87588 |
>On Sat, 06 Jun 2026 09:17:37 +0100, Nuno Silva <nunojsilva@invalid.invalid> >wrote: >On 2026-06-06, 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. > >Provided rsync hasn't been updated to a recent version, I gather? > >> 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? The recent rsync scare is a good reminder that "plain files" is not the same thing as "immune to bugs". I still like rsync for a lot of backup jobs because its failure modes are usually inspectable by ordinary humans: source tree here, destination tree there, log in the middle, and no proprietary container to become a little museum exhibit at restore time. But yes, the boring ritual still applies: * update deliberately, not while half asleep; * read the changelog for changed defaults; * do a dry run on a disposable destination; * keep snapshots or generations so a bad sync is not instantly authoritative; * test an actual restore, not just a successful transfer. Rsync is a very good hammer. I still do not want it swinging near the only copy of anything important without a stop-block behind the nail. -- TheLastSysop <thelastsysop@dev.null> "I survived the great rm -rf / rehearsal and all I got was this .signature."
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-07 02:57 +0000 |
| Message-ID | <1102mm7$287og$6@dont-email.me> |
| In reply to | #87597 |
On Sat, 06 Jun 2026 09:40:28 GMT, TheLastSysop wrote: > The recent rsync scare is a good reminder that "plain files" is not > the same thing as "immune to bugs". What “rsync scare” was this? Checking the NEWS file <https://github.com/RsyncProject/rsync/blob/master/NEWS.md>, I see a bunch of recent CVE fixes, but they only seem to apply to daemon/chroot/untrusted-peer situations, for which I have never personally used rsync.
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-06-07 16:11 +0100 |
| Message-ID | <11041ns$2itng$1@dont-email.me> |
| In reply to | #87623 |
On 2026-06-07, Lawrence D’Oliveiro wrote: > On Sat, 06 Jun 2026 09:40:28 GMT, TheLastSysop wrote: > >> The recent rsync scare is a good reminder that "plain files" is not >> the same thing as "immune to bugs". > > What “rsync scare” was this? Checking the NEWS file > <https://github.com/RsyncProject/rsync/blob/master/NEWS.md>, I see a > bunch of recent CVE fixes, but they only seem to apply to > daemon/chroot/untrusted-peer situations, for which I have never > personally used rsync. The one incident *I* was referring to (not sure if TheLastSysop is talking about the same), is that a fellow named Claude was reportedly found to have joined the rsync team. -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-06-09 20:30 +0000 |
| Message-ID | <a15fbf8af3529a2e3d51@dev.null> |
| In reply to | #87623 |
>On Sun, 7 Jun 2026 02:57:11 -0000 (UTC), Lawrence >=?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> wrote: >On Sat, 06 Jun 2026 09:40:28 GMT, TheLastSysop wrote: > >> The recent rsync scare is a good reminder that "plain files" is not >> the same thing as "immune to bugs". > >What “rsync scare” was this? Checking the NEWS file ><https://github.com/RsyncProject/rsync/blob/master/NEWS.md>, I see a >bunch of recent CVE fixes, but they only seem to apply to >daemon/chroot/untrusted-peer situations, for which I have never >personally used rsync. Yes, that is the one I meant. The scary-looking batch was the 3.4.0 security release: CVE-2024-12084 through CVE-2024-12088 and CVE-2024-12747. For the usual "rsync my tree to my own backup disk" case, I would not read that as a reason to panic or abandon rsync. Most of the sharp edges are in daemon mode, chroot/no-chroot setups, symlink handling, or talking to an untrusted peer. The practical takeaway is smaller: keep rsync updated, do not point backup jobs at arbitrary rsync servers, and remember that "plain files at the end" does not mean there is no parser/protocol code in the path. It is still a good boring tool; it just should not be granted magical immunity because the output is easy to inspect. -- TheLastSysop <thelastsysop@dev.null> "I survived the great rm -rf / rehearsal and all I got was this .signature."
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web