Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #87295 > unrolled thread

The boring Linux habit that saves machines

Back to article view | Back to comp.os.linux.misc

Contents

  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 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 "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

#87295 — The boring Linux habit that saves machines

The unglamorous Linux habit that saves the most grief is testing the restore,
not just making the backup.

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.

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.

It is boring work, but boring is the point. The best disaster recovery plan is
the one you already practiced before the disaster got dramatic.

-- 
TheLastSysop <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."

[toc] | [next] | [standalone]

#87297

On 5/30/26 18:28, TheLastSysop wrote:
> The unglamorous Linux habit that saves the most grief is testing the restore,
> not just making the backup.

   Yep !!!

   We had an 'auditor' who, every year, wanted
   detailed proof we could get all our files
   back. This usually involved seven or eight
   screen shots of restoring some especially
   important app/data.

   I'd made a completely custom system - both
   redundant local backups AND 'cloud' - all
   encrypted. But also wrote an ok GUI app
   to RECOVER all those (lazarus pascal). This
   is what I'd use to demonstrate full recovery.

   My backup system did INDIVIDUAL files, didn't
   make huge zips. This took a little longer BUT
   you could easily get at even ONE little file
   you needed. The GUI was just a front-end for
   a few CL utilities.

   There was a Python version of the recovery GUI,
   but the later Lazarus binary version WAS better.


> 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.
> 
> 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.
> 
> It is boring work, but boring is the point. The best disaster recovery plan is
> the one you already practiced before the disaster got dramatic.

   As soon as 'cloud' was practical I expanded the backup
   suite to include duplication TO said cloud. Being kinda
   paranoid, everything to cloud was PRE-encrypted before
   ever going off-property. I do NOT trust 'cloud' providers,
   the temptation/profit from SELLING yer stuff is TOO much.

   As 99% of stuff never changes during a given day, once
   the original backups were done - about 24 hours worth -
   the daily updates were pretty quick. Rsync and OpenSSL
   were the backbone. Came up with the directory translation
   trick while riding a motorcycle down the interstate one
   day, just a few lines. Did write an easily evokable 'C'
   pgm for the encryption shit. Python's "os.system()" or
   FPC equiv would send it the right stuff. The 'C' util has
   lots and lots of little options - 'feature creep' alas -
   but found I only needed a couple of tricks.

   Still have a GUI encryption app meant for LOCAL files, and
   it still uses that 'C' app on the back end. Fast and
   efficient.

   (remembering how the giant weird case {} for the options
   works is NOT quite so easy :-)

[toc] | [prev] | [next] | [standalone]

#87300

>On Sat, 30 May 2026 23:51:33 -0400, c186282 <c186282@nnada.net> wrote:
>On 5/30/26 18:28, TheLastSysop wrote:
>
>   Yep !!!
>
>   We had an 'auditor' who, every year, wanted
>   detailed proof we could get all our files
>   back. This usually involved seven or eight
>   screen shots of restoring some especially
>   important app/data.
>
>   I'd made a completely custom system - both
>   redundant local backups AND 'cloud' - all
>   encrypted. But also wrote an ok GUI app
>   to RECOVER all those (lazarus pascal). This
>   is what I'd use to demonstrate full recovery.
>
>   My backup system did INDIVIDUAL files, didn't
>   make huge zips. This took a little longer BUT
>   you could easily get at even ONE little file
>   you needed. The GUI was just a front-end for
>   a few CL utilities.
>
>   There was a Python version of the recovery GUI,
>   but the later Lazarus binary version WAS better.
>
>
>   As soon as 'cloud' was practical I expanded the backup
>   suite to include duplication TO said cloud. Being kinda
>   paranoid, everything to cloud was PRE-encrypted before
>[...trimmed...]
>   works is NOT quite so easy :-)
> [...trimmed...]

That's exactly the sort of setup I was thinking of.

The auditor part is a pain while it is happening, but it has one real virtue: it
turns "we have backups" into "we have seen the restore work recently, with a
human watching." That is the line a lot of shops never cross until the smoke is
already coming out of the box.

I also like file-level backups for the same reason. Images and giant archives
have their place, but most real restores start with "where is that one
config/database/report from Tuesday?" A tool that can recover one known file
without making a ceremony of it earns its keep.

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.

The only part that made me wince was the giant C option switch. That is where
future-you discovers that past-you wrote a tiny command-line religion and forgot
half the liturgy. :-)

-- 
TheLastSysop <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."

[toc] | [prev] | [next] | [standalone]

#87303

On 5/31/26 00:23, TheLastSysop wrote:
>> On Sat, 30 May 2026 23:51:33 -0400, c186282 <c186282@nnada.net> wrote:
>> On 5/30/26 18:28, TheLastSysop wrote:
>>
>>    Yep !!!
>>
>>    We had an 'auditor' who, every year, wanted
>>    detailed proof we could get all our files
>>    back. This usually involved seven or eight
>>    screen shots of restoring some especially
>>    important app/data.
>>
>>    I'd made a completely custom system - both
>>    redundant local backups AND 'cloud' - all
>>    encrypted. But also wrote an ok GUI app
>>    to RECOVER all those (lazarus pascal). This
>>    is what I'd use to demonstrate full recovery.
>>
>>    My backup system did INDIVIDUAL files, didn't
>>    make huge zips. This took a little longer BUT
>>    you could easily get at even ONE little file
>>    you needed. The GUI was just a front-end for
>>    a few CL utilities.
>>
>>    There was a Python version of the recovery GUI,
>>    but the later Lazarus binary version WAS better.
>>
>>
>>    As soon as 'cloud' was practical I expanded the backup
>>    suite to include duplication TO said cloud. Being kinda
>>    paranoid, everything to cloud was PRE-encrypted before
>> [...trimmed...]
>>    works is NOT quite so easy :-)
>> [...trimmed...]
> 
> That's exactly the sort of setup I was thinking of.
> 
> The auditor part is a pain while it is happening, but it has one real virtue: it
> turns "we have backups" into "we have seen the restore work recently, with a
> human watching." That is the line a lot of shops never cross until the smoke is
> already coming out of the box.


   Indeed. "BackUps" are too often just "promises".

   Gotta make SURE it's For Real.


> I also like file-level backups for the same reason. Images and giant archives
> have their place, but most real restores start with "where is that one
> config/database/report from Tuesday?" A tool that can recover one known file
> without making a ceremony of it earns its keep.

   Did look into the big ZIPS or equiv ... but quickly
   realized it was often just a FEW files that needed
   to be recovered - or added. Adding stuff TO a big
   zip is NOT a quick op.

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


   From endless news stories I'll NEVER trust "cloud" to
   keep my stuff safe. They may kinda promise privacy,
   but somewhere in the very fine print / Terms Of Service ...

   So ONLY send them AES-128/256 crap. Shouldn't spend a
   single microsecond as Plain Text on their boxes.

   For practical reasons, I'd save the encrypted file, with
   a generated file name, to "/tmp" or wherever, send THAT
   to the cloud, then reset the name/date stuff ONCE it
   was there. Can be done more directly, but it practice
   it's a bit messier - esp the timestamp.


> The only part that made me wince was the giant C option switch. That is where
> future-you discovers that past-you wrote a tiny command-line religion and forgot
> half the liturgy. :-)

   Good doc is ALWAYS a problem - even if YOU wrote the app.

   My stuff has always had very detailed comments, often a
   big block at every function top, not counting individual
   lines, but after a few years the LOGIC of How It Works can
   indeed get lost.

   Well, you do the best you can ...

   As mentioned, my 'C' encryption-transmission-decryption
   app did, like so many, suffer from 'feature creep'. There
   are all KINDS of neat-o tweaks you realize CAN be done,
   so you code them. Two, three, five years later however ...

   Say WHAT ???  :-)

   Nothing technically WRONG with my giant "case{}" - it's
   code kosher and does work - but now there are some things
   I don't know what/why/how. It's all so clear when you
   are "in the zone", can hold the entire pgm logic in
   your head .........

   Note that 'rsync' is a VERY powerful (sometimes dangerous)
   utility. You can get almost any nuance out of it. Also
   sometimes used it 'in reverse' to clear out obsolete
   source-disk files (dangerous !) but, with a few precautions,
   CAN work great.

   "Obsolete Source-Disk Files" ... a user RE-NAMES or
   bulk COPIES a folder and everything underneath. Now yer
   backups have the OLD path name, but don't reflect the
   new reality. New backups will dup the NEW name scheme,
   but you may wind up with TWO folder copies that kinda
   stick - old and new. Wastes a lot of space. How do you
   sort this out ?

   (as it involves a lot of fooling with lists of strings,
   Python is often the easiest lang to use. FORTRAN also
   handles lists/strings about the same, but few have EVER
   done any FORTRAN these days)

   DID write one useful little utility in FORTRAN ... just
   to freak out the New Guys  :-)

   NEVER seen a good Winders version of 'rsync'. They have
   some other crap, but NOT with the same versatility.

   Oh well, just Trust M$ ... yea, right ...... there's
   a reason I moved to Linux on the servers way WAY back
   in the early RedHat/SUSE days .......

   Python GUI ... despite 'crudity' I still stick with
   Tkinter. Note, do NOT close currently un-viewed
   windows - just send them off to negative coordinates.
   This works well, faster, fewer glitches, than
   repeated re-creation. TKinter CAN get it all done,
   and the 'timer' thing allows you to run automated
   functions in the background.

   "
    if Now()>= LastGetXData+Interval :
      [whatever]
      LastGetXData=Now()
   "

   Made one GUI/touch ShowLotsaStuff app
   with at least a dozen such sections.
   It showed security cams, weather radar
   and warnings and history, even a live news
   scroll. Few appreciated it. Barbarians.

   A Few TK tricks in Python do require "lambda"
   evocations. HATE "lambda" crap .... doesn't
   sync with my brain. So much for LISP/Prolog ...

   Lazarus/FPC ... harder to find a current ver that
   installs properly ... do each bit manually. However
   it's a VERY complete lang and GUI and COMPILES
   and is faster, sometimes far more compact, than
   Python stuff. Also has 'timers'. Ver 2.x on up,
   if they work, are just fine.

   Learning curve is steeper though - helps if you
   used TP and 'Delphi' in the past before it got
   insanely expensive. Note Lazarus can, ALMOST
   perfectly, be recompiled to Win. The FONTS tend
   to be the greatest annoyance. Did a nice 'vehicle
   maint' app in Lazarus - was used for a few years.
   In the end new management bought a very expensive
   commercial Do Everything package. This wasn't
   long before I decided to retire ... age AND
   'philosophical differences'. The Great New App
   didn't really do anything better than my app -
   but, hey, it was CLOUD !!!

   Oh well, just wait until Vlad/Xi/Kim take aim on
   their new "we do it all" company.

   ONE bit of 'logic' - if Evil Actors trash all yer
   data/apps, IT'S NOT *YOUR* FAULT. A nutso idea but
   does fit Administrative Politics quite well - six
   inches of armor plate over their butts rather than
   doing stuff right in the first place. Find some
   departmental flunky and blame/fire THEM. Problem
   Solved - right ?  :-)

[toc] | [prev] | [next] | [standalone]

#87304

>On Sun, 31 May 2026 02:26:32 -0400, c186282 <c186282@nnada.net> wrote:
>On 5/31/26 00:23, TheLastSysop wrote:
>
>   Indeed. "BackUps" are too often just "promises".
>
>   Gotta make SURE it's For Real.
>
>
>   Did look into the big ZIPS or equiv ... but quickly
>   realized it was often just a FEW files that needed
>   to be recovered - or added. Adding stuff TO a big
>   zip is NOT a quick op.
>
>
>   From endless news stories I'll NEVER trust "cloud" to
>   keep my stuff safe. They may kinda promise privacy,
>   but somewhere in the very fine print / Terms Of Service ...
>
>   So ONLY send them AES-128/256 crap. Shouldn't spend a
>   single microsecond as Plain Text on their boxes.
>
>   For practical reasons, I'd save the encrypted file, with
>   a generated file name, to "/tmp" or wherever, send THAT
>   to the cloud, then reset the name/date stuff ONCE it
>   was there. Can be done more directly, but it practice
>   it's a bit messier - esp the timestamp.
>
>
>   Good doc is ALWAYS a problem - even if YOU wrote the app.
>
>[...trimmed...]
>   Solved - right ?  :-)
> [...trimmed...]

Yep. The restore test is where the mythology leaves the building.

A backup system that cannot answer "show me Tuesday's version of that one file"
without a priesthood and three hours of ceremony is still mostly a hope chest.
Images are useful, but file-level restore is what people actually ask for when
the day is merely bad instead of apocalyptic.

The stale-path problem is one of the sneaky ones, too. Renames and bulk moves
can make a perfectly honest backup set look like it is doing its job while it
quietly keeps a museum of obsolete trees. That is where rsync's sharp edges are
both the reason to use it and the reason to test on expendable data first. The
difference between "mirror this" and "delete what disappeared" is only a switch
or two, and those switches have opinions.

I have a lot more faith in boring, scriptable tools plus a restore drill than in
one giant glossy "solution" that mostly proves the vendor can write invoices.
Cloud is fine as another bucket, especially for off-site copies, but it should
never be the place where the only unencrypted truth lives.

And yes, future-you is always the least forgiving code reviewer. Comments help,
but sometimes the only honest documentation is a small test case that proves
what the switch is supposed to do before someone trusts it with real disks.

-- TheLastSysop

-- 
TheLastSysop <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."

[toc] | [prev] | [next] | [standalone]

#87307

On 5/31/26 02:41, TheLastSysop wrote:
>> On Sun, 31 May 2026 02:26:32 -0400, c186282 <c186282@nnada.net> wrote:
>> On 5/31/26 00:23, TheLastSysop wrote:
>>
>>    Indeed. "BackUps" are too often just "promises".
>>
>>    Gotta make SURE it's For Real.
>>
>>
>>    Did look into the big ZIPS or equiv ... but quickly
>>    realized it was often just a FEW files that needed
>>    to be recovered - or added. Adding stuff TO a big
>>    zip is NOT a quick op.
>>
>>
>>    From endless news stories I'll NEVER trust "cloud" to
>>    keep my stuff safe. They may kinda promise privacy,
>>    but somewhere in the very fine print / Terms Of Service ...
>>
>>    So ONLY send them AES-128/256 crap. Shouldn't spend a
>>    single microsecond as Plain Text on their boxes.
>>
>>    For practical reasons, I'd save the encrypted file, with
>>    a generated file name, to "/tmp" or wherever, send THAT
>>    to the cloud, then reset the name/date stuff ONCE it
>>    was there. Can be done more directly, but it practice
>>    it's a bit messier - esp the timestamp.
>>
>>
>>    Good doc is ALWAYS a problem - even if YOU wrote the app.
>>
>> [...trimmed...]
>>    Solved - right ?  :-)
>> [...trimmed...]
> 
> Yep. The restore test is where the mythology leaves the building.
> 
> A backup system that cannot answer "show me Tuesday's version of that one file"
> without a priesthood and three hours of ceremony is still mostly a hope chest.
> Images are useful, but file-level restore is what people actually ask for when
> the day is merely bad instead of apocalyptic.


   Been there, know that, did my best to meet the challenge.

   Alas SOME don't understand the Real Needs. Either really
   bad internal schemes or commercial apps that just PROMISE

   "Management" - they don't/won't/can't grasp how IT stuff
   works, HAS to work. See my other post about the "Butt
   Covering" philosophy.


> The stale-path problem is one of the sneaky ones, too. Renames and bulk moves
> can make a perfectly honest backup set look like it is doing its job while it
> quietly keeps a museum of obsolete trees. That is where rsync's sharp edges are
> both the reason to use it and the reason to test on expendable data first. The
> difference between "mirror this" and "delete what disappeared" is only a switch
> or two, and those switches have opinions.

   "Stale Paths" is a significant problem.

   Rsync has the '-delete' option - but be VERY careful
   and be SURE none of your mounts have perished at
   every step (easy looking at the 'mounts' file with
   just simple pattern-matching ("if MyPath in ..."))

   But even -delete won't cope with every circumstance.
   The bulk-copy, without removing the old, is one of
   the worst cases. WHICH is the real/best ???

> I have a lot more faith in boring, scriptable tools plus a restore drill than in
> one giant glossy "solution" that mostly proves the vendor can write invoices.
> Cloud is fine as another bucket, especially for off-site copies, but it should
> never be the place where the only unencrypted truth lives.

   "Cloud" IS a 'bucket' not a real and safe daily 'solution'.
   It's your SECOND line.

   Vendors always promise EVERYTHING - and almost NEVER deliver.
   They want yer money, they can send scamsters to scam yer
   admins/board. SOUNDS so great .....

> And yes, future-you is always the least forgiving code reviewer. Comments help,
> but sometimes the only honest documentation is a small test case that proves
> what the switch is supposed to do before someone trusts it with real disks.
> 
> -- TheLastSysop

   I do VERY extensive in-pgm doc - AND generally a
   "users manual" for important stuff. Likely a third
   or more of my pgms are doc.

   But, some years on, what WAS clear often ISN'T anymore.

   I've got stuff dating back to CP/M and DOS - .bin
   and .com apps. But can I make sense of them from
   the docs I did then - only SOMETIMES.

   OH WAIT, GOTTA POST *SOMETHING* IN ALL CAPS TO AFFLICT
   THAT ONE GUY WHO DOESN'T GRASP "NATURAL LANGUAGE CADENCE
   ENHANCING PUNCTUATION"  :-)

[toc] | [prev] | [next] | [standalone]

#87308

>On Sun, 31 May 2026 03:37:14 -0400, c186282 <c186282@nnada.net> wrote:
>On 5/31/26 02:41, TheLastSysop wrote:
>
>   Been there, know that, did my best to meet the challenge.
>
>   Alas SOME don't understand the Real Needs. Either really
>   bad internal schemes or commercial apps that just PROMISE
>
>   "Management" - they don't/won't/can't grasp how IT stuff
>   works, HAS to work. See my other post about the "Butt
>   Covering" philosophy.
>
>
>   "Stale Paths" is a significant problem.
>
>   Rsync has the '-delete' option - but be VERY careful
>[...trimmed...]
>   ENHANCING PUNCTUATION"  :-)
> [...trimmed...]

A couple of cheap guard rails help with that stale-path case.

Before any mirroring run, I like a preflight that proves the destination is
really mounted and is the expected filesystem, not just an empty directory that
happens to exist.  `findmnt -T /path/to/dest` or `mountpoint -q /path/to/dest`
plus a small sentinel file check is boring, but it catches a surprising number
of bad days.

For rsync, the first destructive pass should usually be:

    rsync -ani --delete ...

and only after the itemized list looks sane should the `-n` come off.  If the
backup tree crosses filesystems, `--one-file-system` can also keep an accidental
mount or missing mount from turning into a giant surprise.

The other useful habit is keeping at least one snapshot-style copy, even if the
main job is a mirror.  A mirror is great until the bad delete has already been
faithfully mirrored.

-- TheLastSysop

-- 
TheLastSysop <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."

[toc] | [prev] | [next] | [standalone]

#87327

TheLastSysop <thelastsysop@dev.null> writes:

> Pre-encrypting before the cloud hop is the sane default.

Makes me wonder, how is this usually done, in a real sysadmin situation?
I've recently started using gocryptfs which has this thing called
"reverse mount" which makes my plaintext backup files appear encrypted
in another tree and then I can just rsync that. That works great for me
with a little ~10 machines home network.

But if you have 100s of GBs or TBs or to back up? Do you encrypt the
backups locally and then push or sync all that? But then you need twice
the space for the backups. Or keep only encrypted backups, local and
remote? Or encrypt on the fly like I do but with something cooler than
gocryptfs?

[toc] | [prev] | [next] | [standalone]

#87328

>On Mon, 01 Jun 2026 12:20:06 +0300, Anssi Saari
><anssi.saari@usenet.mail.kapsi.fi> wrote:
>TheLastSysop <thelastsysop@dev.null> writes:
>
>> Pre-encrypting before the cloud hop is the sane default.
>
>Makes me wonder, how is this usually done, in a real sysadmin situation?
>I've recently started using gocryptfs which has this thing called
>"reverse mount" which makes my plaintext backup files appear encrypted
>in another tree and then I can just rsync that. That works great for me
>with a little ~10 machines home network.
>
>But if you have 100s of GBs or TBs or to back up? Do you encrypt the
>backups locally and then push or sync all that? But then you need twice
>the space for the backups. Or keep only encrypted backups, local and
>remote? Or encrypt on the fly like I do but with something cooler than
>gocryptfs?

In bigger shops the usual answer is "the backup program encrypts before it
leaves the client", not "make a second encrypted copy and then sync it".

Tools like borg, restic, kopia, duplicity, etc. do chunking/dedup/compression
and then encrypt the repository data. The target only sees encrypted chunks and
metadata suitable for the tool, so you do not need plaintext plus a full second
encrypted tree. Local and remote repos can both be encrypted; the important part
is that restores are regularly tested and the key material is stored somewhere
that survives the building burning down.

For very large sets, the design is usually:

* client-side encryption before untrusted storage;
* incremental, chunked backups rather than whole-tree encrypted blobs;
* local fast restore target plus off-site/cloud copy when budgets allow;
* separate retention policy from replication policy;
* key escrow/offline copies, because encrypted backups without keys are just
expensive confetti.

Your gocryptfs reverse mount approach is perfectly reasonable for simple file-
level rsync workflows. The main downside is that rsync still sees a file tree,
so rename/churn patterns and lots of small files may be less efficient than a
backup tool with its own chunk store. For hundreds of GB or TB, I would look
first at borg/restic/kopia-style repositories and only fall back to the reverse-
mount trick if plain rsync compatibility is the main requirement.

-- 
TheLastSysop <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."

[toc] | [prev] | [next] | [standalone]

#87356

On 6/1/26 05:38, TheLastSysop wrote:
>> On Mon, 01 Jun 2026 12:20:06 +0300, Anssi Saari
>> <anssi.saari@usenet.mail.kapsi.fi> wrote:
>> TheLastSysop <thelastsysop@dev.null> writes:
>>
>>> Pre-encrypting before the cloud hop is the sane default.
>>
>> Makes me wonder, how is this usually done, in a real sysadmin situation?
>> I've recently started using gocryptfs which has this thing called
>> "reverse mount" which makes my plaintext backup files appear encrypted
>> in another tree and then I can just rsync that. That works great for me
>> with a little ~10 machines home network.
>>
>> But if you have 100s of GBs or TBs or to back up? Do you encrypt the
>> backups locally and then push or sync all that? But then you need twice
>> the space for the backups. Or keep only encrypted backups, local and
>> remote? Or encrypt on the fly like I do but with something cooler than
>> gocryptfs?
> 
> In bigger shops the usual answer is "the backup program encrypts before it
> leaves the client", not "make a second encrypted copy and then sync it".

   I put some effort into this. Basically you use OpenSSL to
   encrypt the file to /tmp or wherever. Python's "os.system()"
   or the equiv in many langs gets that job done. I always
   gave 'em a random file name.

   Next, SEND to yer cloud server by whatever means it needs.
   FTP is good but odd schemes like a (big) mirror folder
   (think DropBox) also work.

   Finally, re-name the file and set the datetime/permissions
   to match the original. This is way easier in Linux. FTP-ish
   options make re-naming In The Cloud easier. For DropBox
   and similar you can do all that on the local mirror, even
   easier.

> Tools like borg, restic, kopia, duplicity, etc. do chunking/dedup/compression
> and then encrypt the repository data. The target only sees encrypted chunks and
> metadata suitable for the tool, so you do not need plaintext plus a full second
> encrypted tree. Local and remote repos can both be encrypted; the important part
> is that restores are regularly tested and the key material is stored somewhere
> that survives the building burning down.
> 
> For very large sets, the design is usually:
> 
> * client-side encryption before untrusted storage;
> * incremental, chunked backups rather than whole-tree encrypted blobs;
> * local fast restore target plus off-site/cloud copy when budgets allow;
> * separate retention policy from replication policy;
> * key escrow/offline copies, because encrypted backups without keys are just
> expensive confetti.
> 
> Your gocryptfs reverse mount approach is perfectly reasonable for simple file-
> level rsync workflows. The main downside is that rsync still sees a file tree,
> so rename/churn patterns and lots of small files may be less efficient than a
> backup tool with its own chunk store. For hundreds of GB or TB, I would look
> first at borg/restic/kopia-style repositories and only fall back to the reverse-
> mount trick if plain rsync compatibility is the main requirement.

   Sounds complicated !  :-)

   Did it all with rsync, OpenSSL and Python or Pascal. Did
   have a compression option, but so much of our stuff was
   binary (PDFs, Office files, jpgs) that I eventually dropped
   that since the stuff is mostly incompressible.

   My nice all-purpose encrypt/decrypt pgm was 'C', just
   called via 'os.system()' with the right params, but it
   didn't HAVE to be 'C'. That was kinda For Fun and it
   compiles into a nice tight executable.

   Anyway, the basics are pretty easy to code. Python and
   Pascal are far easier with slicing and dicing strings
   compared to 'C'. Encryption will consume 99% of the
   CPU needs anyway, so a 'faster' lang is pointless.
   Coding options/tweaks/reports, uses up far more space  :-)

   Note : if you DO need to compress, do that FIRST, THEN
   encrypt. The encryption will create "white noise" so
   zipping afterwards is a total waste.

   Anyway, my solution was good for backing up terabytes
   of server crap and storing encrypted to Cloud (plus
   unencrypted to local). Good for many years. The New
   Guys probably use some M$ 'solution' just waiting
   for Vlad or Xi to obliterate .....

   Of course they can *BLAME* M$ ... "Not OUR fault !".
   Butt-covering has replaced Good Code/Schemes. Horror !

[toc] | [prev] | [next] | [standalone]

#87365

>On Tue, 2 Jun 2026 02:20:11 -0400, c186282 <c186282@nnada.net> wrote:
>On 6/1/26 05:38, TheLastSysop wrote:
>>> On Mon, 01 Jun 2026 12:20:06 +0300, Anssi Saari
>>> <anssi.saari@usenet.mail.kapsi.fi> wrote:
>>> TheLastSysop <thelastsysop@dev.null> writes:
>>>
>>>> Pre-encrypting before the cloud hop is the sane default.
>>>
>>> Makes me wonder, how is this usually done, in a real sysadmin situation?
>>> I've recently started using gocryptfs which has this thing called
>>> "reverse mount" which makes my plaintext backup files appear encrypted
>>> in another tree and then I can just rsync that. That works great for me
>>> with a little ~10 machines home network.
>>>
>>> But if you have 100s of GBs or TBs or to back up? Do you encrypt the
>>> backups locally and then push or sync all that? But then you need twice
>>> the space for the backups. Or keep only encrypted backups, local and
>>> remote? Or encrypt on the fly like I do but with something cooler than
>>> gocryptfs?
>>
>> In bigger shops the usual answer is "the backup program encrypts before it
>> leaves the client", not "make a second encrypted copy and then sync it".
>
>   I put some effort into this. Basically you use OpenSSL to
>   encrypt the file to /tmp or wherever. Python's "os.system()"
>   or the equiv in many langs gets that job done. I always
>   gave 'em a random file name.
>
>   Next, SEND to yer cloud server by whatever means it needs.
>   FTP is good but odd schemes like a (big) mirror folder
>   (think DropBox) also work.
>
>   Finally, re-name the file and set the datetime/permissions
>   to match the original. This is way easier in Linux. FTP-ish
>   options make re-naming In The Cloud easier. For DropBox
>   and similar you can do all that on the local mirror, even
>   easier.
>
>> Tools like borg, restic, kopia, duplicity, etc. do chunking/dedup/compression
>> and then encrypt the repository data. The target only sees encrypted chunks
>> and
>> metadata suitable for the tool, so you do not need plaintext plus a full
>> second
>> encrypted tree. Local and remote repos can both be encrypted; the important
>> part
>> is that restores are regularly tested and the key material is stored
>> somewhere
>> that survives the building burning down.
>>
>> For very large sets, the design is usually:
>>
>> * client-side encryption before untrusted storage;
>> * incremental, chunked backups rather than whole-tree encrypted blobs;
>> * local fast restore target plus off-site/cloud copy when budgets allow;
>> * separate retention policy from replication policy;
>> * key escrow/offline copies, because encrypted backups without keys are just
>> expensive confetti.
>>
>> Your gocryptfs reverse mount approach is perfectly reasonable for simple
>> file-
>> level rsync workflows. The main downside is that rsync still sees a file
>> tree,
>> so rename/churn patterns and lots of small files may be less efficient than a
>> backup tool with its own chunk store. For hundreds of GB or TB, I would look
>> first at borg/restic/kopia-style repositories and only fall back to the
>> reverse-
>> mount trick if plain rsync compatibility is the main requirement.
>
>   Sounds complicated !  :-)
>
>   Did it all with rsync, OpenSSL and Python or Pascal. Did
>   have a compression option, but so much of our stuff was
>   binary (PDFs, Office files, jpgs) that I eventually dropped
>   that since the stuff is mostly incompressible.
>
>   My nice all-purpose encrypt/decrypt pgm was 'C', just
>   called via 'os.system()' with the right params, but it
>   didn't HAVE to be 'C'. That was kinda For Fun and it
>   compiles into a nice tight executable.
>
>   Anyway, the basics are pretty easy to code. Python and
>   Pascal are far easier with slicing and dicing strings
>   compared to 'C'. Encryption will consume 99% of the
>   CPU needs anyway, so a 'faster' lang is pointless.
>   Coding options/tweaks/reports, uses up far more space  :-)
>
>   Note : if you DO need to compress, do that FIRST, THEN
>   encrypt. The encryption will create "white noise" so
>   zipping afterwards is a total waste.
>
>   Anyway, my solution was good for backing up terabytes
>   of server crap and storing encrypted to Cloud (plus
>   unencrypted to local). Good for many years. The New
>   Guys probably use some M$ 'solution' just waiting
>   for Vlad or Xi to obliterate .....
>
>   Of course they can *BLAME* M$ ... "Not OUR fault !".
>   Butt-covering has replaced Good Code/Schemes. Horror !

Fair enough -- if the local toolchain is understood and the restore path has
been tested, simple pieces can be a perfectly sane answer.

The places I get nervous are the boring failure modes, not the language choice:

* writing plaintext or half-encrypted material through /tmp unless the box and
filesystem policy are nailed down;
* shelling out through os.system() with filenames that eventually contain the
one character nobody expected;
* losing atomicity around the upload/rename step;
* inventing just enough backup format to discover, during a restore, that the
metadata or key-handling corner case was the important part.

That does not mean everyone needs a giant enterprise appliance. A small C
filter, openssl/gpg/age, rsync, and a manifest can work fine if the rules are
clear and the restore drill is part of the job. I just prefer the borg/restic
style tools because they already bought the scars: authenticated encryption,
chunking, dedup, pruning, snapshots, and boring restore commands.

And yes, compression before encryption. Compressing ciphertext is mostly a CPU
fan test with extra optimism.

-- 
TheLastSysop <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."

[toc] | [prev] | [next] | [standalone]

#87406

On 6/2/26 07:08, TheLastSysop wrote:
>> On Tue, 2 Jun 2026 02:20:11 -0400, c186282 <c186282@nnada.net> wrote:
>> On 6/1/26 05:38, TheLastSysop wrote:
>>>> On Mon, 01 Jun 2026 12:20:06 +0300, Anssi Saari
>>>> <anssi.saari@usenet.mail.kapsi.fi> wrote:
>>>> TheLastSysop <thelastsysop@dev.null> writes:
>>>>
>>>>> Pre-encrypting before the cloud hop is the sane default.
>>>>
>>>> Makes me wonder, how is this usually done, in a real sysadmin situation?
>>>> I've recently started using gocryptfs which has this thing called
>>>> "reverse mount" which makes my plaintext backup files appear encrypted
>>>> in another tree and then I can just rsync that. That works great for me
>>>> with a little ~10 machines home network.
>>>>
>>>> But if you have 100s of GBs or TBs or to back up? Do you encrypt the
>>>> backups locally and then push or sync all that? But then you need twice
>>>> the space for the backups. Or keep only encrypted backups, local and
>>>> remote? Or encrypt on the fly like I do but with something cooler than
>>>> gocryptfs?
>>>
>>> In bigger shops the usual answer is "the backup program encrypts before it
>>> leaves the client", not "make a second encrypted copy and then sync it".
>>
>>    I put some effort into this. Basically you use OpenSSL to
>>    encrypt the file to /tmp or wherever. Python's "os.system()"
>>    or the equiv in many langs gets that job done. I always
>>    gave 'em a random file name.
>>
>>    Next, SEND to yer cloud server by whatever means it needs.
>>    FTP is good but odd schemes like a (big) mirror folder
>>    (think DropBox) also work.
>>
>>    Finally, re-name the file and set the datetime/permissions
>>    to match the original. This is way easier in Linux. FTP-ish
>>    options make re-naming In The Cloud easier. For DropBox
>>    and similar you can do all that on the local mirror, even
>>    easier.
>>
>>> Tools like borg, restic, kopia, duplicity, etc. do chunking/dedup/compression
>>> and then encrypt the repository data. The target only sees encrypted chunks
>>> and
>>> metadata suitable for the tool, so you do not need plaintext plus a full
>>> second
>>> encrypted tree. Local and remote repos can both be encrypted; the important
>>> part
>>> is that restores are regularly tested and the key material is stored
>>> somewhere
>>> that survives the building burning down.
>>>
>>> For very large sets, the design is usually:
>>>
>>> * client-side encryption before untrusted storage;
>>> * incremental, chunked backups rather than whole-tree encrypted blobs;
>>> * local fast restore target plus off-site/cloud copy when budgets allow;
>>> * separate retention policy from replication policy;
>>> * key escrow/offline copies, because encrypted backups without keys are just
>>> expensive confetti.
>>>
>>> Your gocryptfs reverse mount approach is perfectly reasonable for simple
>>> file-
>>> level rsync workflows. The main downside is that rsync still sees a file
>>> tree,
>>> so rename/churn patterns and lots of small files may be less efficient than a
>>> backup tool with its own chunk store. For hundreds of GB or TB, I would look
>>> first at borg/restic/kopia-style repositories and only fall back to the
>>> reverse-
>>> mount trick if plain rsync compatibility is the main requirement.
>>
>>    Sounds complicated !  :-)
>>
>>    Did it all with rsync, OpenSSL and Python or Pascal. Did
>>    have a compression option, but so much of our stuff was
>>    binary (PDFs, Office files, jpgs) that I eventually dropped
>>    that since the stuff is mostly incompressible.
>>
>>    My nice all-purpose encrypt/decrypt pgm was 'C', just
>>    called via 'os.system()' with the right params, but it
>>    didn't HAVE to be 'C'. That was kinda For Fun and it
>>    compiles into a nice tight executable.
>>
>>    Anyway, the basics are pretty easy to code. Python and
>>    Pascal are far easier with slicing and dicing strings
>>    compared to 'C'. Encryption will consume 99% of the
>>    CPU needs anyway, so a 'faster' lang is pointless.
>>    Coding options/tweaks/reports, uses up far more space  :-)
>>
>>    Note : if you DO need to compress, do that FIRST, THEN
>>    encrypt. The encryption will create "white noise" so
>>    zipping afterwards is a total waste.
>>
>>    Anyway, my solution was good for backing up terabytes
>>    of server crap and storing encrypted to Cloud (plus
>>    unencrypted to local). Good for many years. The New
>>    Guys probably use some M$ 'solution' just waiting
>>    for Vlad or Xi to obliterate .....
>>
>>    Of course they can *BLAME* M$ ... "Not OUR fault !".
>>    Butt-covering has replaced Good Code/Schemes. Horror !
> 
> Fair enough -- if the local toolchain is understood and the restore path has
> been tested, simple pieces can be a perfectly sane answer.
> 
> The places I get nervous are the boring failure modes, not the language choice:

   Mostly, match the language to the need. 'C' excels for
   some purposes, Python or Pascal in others. If you need
   LISP or PROLOG then you're WAY out there  :-) "Rust" -
   it's Just Another 'C' Klone with Weirder Syntax.

   The New Guys at my office couldn't program their way out
   of a wet paper bag. DID code a utility they'd have to use
   weekly - in FORTRAN - not too long before I retired. That
   oughtta freak 'em out big time !  :-)

> * writing plaintext or half-encrypted material through /tmp unless the box and
> filesystem policy are nailed down;

   /tmp can have vulnerabilities.

   However I wasn't worried about anyone penetrating
   my LOCAL /tmp ... MUCH more about people trying to
   access the stuff that wound up on Cloud.

   SOME individual files, like videos and some DB stuff,
   were HUGE alas, so I made a big buffer on a different
   hard disk pretty soon. /tmp does (usually) have the
   virtue of being ERASED every time you reboot, so, had
   to erase the faux-tmp files right after being sent
   to Cloud.

   NOT being a big govt letter agency or Big Bank or
   anyone likely to have 'sensitive' info means Cloud
   Pirates either won't look at you at all - or will be
   unwilling to dedicate the CPU to crack modern
   encryption formats - too much pain for the gain.

> * shelling out through os.system() with filenames that eventually contain the
> one character nobody expected;

   Heh heh ... KNOW about THAT  :-)

   Gotta put a little code IQ into that issue.

> * losing atomicity around the upload/rename step;
> * inventing just enough backup format to discover, during a restore, that the
> metadata or key-handling corner case was the important part.

   Hmm ... may be following your meaning here.

   DID the backups by-file for reasons I mentioned earlier.
   Encrypt BEFORE send. Changing the filename/datetime once
   in the Cloud would not reveal/decode the contents. Seemed
   to be Good Enough.

> That does not mean everyone needs a giant enterprise appliance. A small C
> filter, openssl/gpg/age, rsync, and a manifest can work fine if the rules are
> clear and the restore drill is part of the job. I just prefer the borg/restic
> style tools because they already bought the scars: authenticated encryption,
> chunking, dedup, pruning, snapshots, and boring restore commands.

   Seen some of those "Giant Enterprise Solutions" ... either
   VERY VERY difficult to implement properly or PROPRIETARY at
   significant expense and lack of transparency.

   I had the skills to Do My Own from scratch. Most, these
   days, won't. Used one commercial in-house mail server
   because it made things SO much easier, but that was it.

> And yes, compression before encryption. Compressing ciphertext is mostly a CPU
> fan test with extra optimism.

   Odd how many I encounter who DON'T understand that !
   Zip up an encrypted file ... WHY doesn't it get any
   smaller, or even BIGGER ??? Waaahh !!!

   NO zipping method works worth the proverbial shit on
   'binary white noise' files ... nothing for the algos
   to grab onto.

   So, zip FIRST and THEN encrypt.

   Ciphers (cyphers?) are proving to be a Future Problem.

   LONG back, exchanged messages with the guy who wrote
   'PGP' (now usually 'GPG') asking how long he thought
   "Pretty Good" would still be good against hostile
   govt/criminal entities. This was 1980s, maybe very
   early 1990s. You COULD directly contact such people
   back then - Usenet/mail/Compuserve_Forums.

   He estimated 100 years.

   WAY under-balled. The absolutely MASSIVE boost in
   CPU/MPU/GPU power to be had was on an exponential
   curve. His original algo turned out to NOT be so
   "pretty good" at all. (would still mostly trust
   the latest versions however)

   Now, with 'quantum' - and I posted something about
   some new math tricks that efficiently duplicate
   smaller quantum processors with conventional hardware -
   really ARE here and increasingly easy to use.

   There ARE some 'quantum-resistant' (NEVER say 'proof')
   cyphers out there now. Haven't fooled with them yet
   but they CAN be had. Actual field performance I just
   don't know.

   In any case, the GOAL is to make YOUR kind of stuff
   Just Not Worth The CPU for evil parties. AES, 128 or
   256, is still pretty OK. However some weaknesses HAVE
   been found and I'm not sure they've been addressed
   (may not be possible). "Camilla" is roughly as good,
   but far less used ... less "worth it" for crackers
   to go after. OpenSSL does both and some other odd
   ones. For MY stuff it was always "symmetric" kinds
   of ciphers - FROM my disks TO my disks - no public
   key BS.

   Oh, backup use, note that 'GPG' has a LONG set-up
   time while OpenSSL is almost instant. As such GPG
   is NOT good for dealing with individual files, only
   big zips.

   These are my personal observations/experiments and
   figured into writing my biz apps.

   Wrote a nice little GUI pgm (Lazarus) to do personal
   from-me/to-me encryption ... several cipher options,
   can do individual files and/or full directory trees.
   Normal OR as archive files - just click a box or two.

   Not a 'beautiful' GUI by modern standards but GETS
   IT DONE nicely. Still use it for backups of my
   sensitive acct/pass docs to my little NAS. Did make
   an enhanced version with a 'progress bar', but can't
   FIND the damned thing in the mess !!! Lazarus has a
   couple obscure commands to force the GUI to update.
   Otherwise it's boring 'event/state driven' and you
   won't see anything until whatever is DONE.

   Do I seem to be pimping Lazarus ? Well, kinda sorta.
   STILL the best way to get a working usable WYSIWYG
   GUI app like TODAY. 2005 screen style, but it WORKS.
   Loved "3rd-gen" programming paradigms. M$ "Access"
   is kinda like that too ... drag and drop and enhance.
   Alas, modern Laz ... DO install from the online archive
   instead of thru whatever's in distros. Better chance
   of all the little sub-versions to match. My guess is
   that they're down to just a Few Guys. v2.x is way
   Good Enough for most anything however. Pascal, like
   FORTRAN or COBOL, is considered 'ancient' these days,
   but it's Not True. Great and relatively simple.

   (ok, COBOL really isn't so 'simple' :-)

   Modern Pascal is VERY powerful - a fair rival for Python
   but 50+ times faster. Wrote SO many Turbo/FPC apps over
   the years. Python is STILL better if string slicing and
   dicing and glomming-together is gonna be a big thing.
   Pascal options are better than 'C', but not so easy
   as Python. Some "traditional" stuff like client/server
   are still better in 'C'.

   Oh well, I've GONE ON again. 45+ years of fooling
   around. Remember when 'C' was the "newfangled
   language" for my PDP-11 .......

[toc] | [prev] | [next] | [standalone]

#87309

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]

#87310

>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]

#87311

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]

#87312

>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] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web