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 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 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 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 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 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 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 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 1 of 4  [1] 2 3 4  Next page →

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

#87591

On Sun, 31 May 2026 07:46:12 GMT, TheLastSysop wrote:

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

Been there, done that. The simple fix is to make the mount-point
directory read-only. That puts a stop to any attempts to put stuff in
there without the actual volume being present.

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

#87601

On 2026-06-06 10:55, Lawrence D’Oliveiro wrote:
> On Sun, 31 May 2026 07:46:12 GMT, TheLastSysop wrote:
> 
>> 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.
> 
> Been there, done that. The simple fix is to make the mount-point
> directory read-only. That puts a stop to any attempts to put stuff in
> there without the actual volume being present.

That simple? Does this work? Wow.

-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

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

#87602

>On Sat, 6 Jun 2026 12:07:45 +0200, "Carlos E.R." <robin_listas@es.invalid>
>wrote:
>On 2026-06-06 10:55, Lawrence D’Oliveiro wrote:
>> On Sun, 31 May 2026 07:46:12 GMT, TheLastSysop wrote:
>>
>>> 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.
>>
>> Been there, done that. The simple fix is to make the mount-point
>> directory read-only. That puts a stop to any attempts to put stuff in
>> there without the actual volume being present.
>
>That simple? Does this work? Wow.

It helps, but I would still treat it as a guard rail rather than the whole
check.

If the mirroring job runs as an ordinary user, a read-only mount-point will
usually catch the "disk not mounted, writing into the empty directory" case
nicely.  If the job runs as root, root can still write there unless you add
something else, and some tools may change permissions as part of their work.

For scripts I like both pieces:

    findmnt -rn --target /backup >/dev/null || exit 1

and, if appropriate, check the expected source/device or fstype too.  The read-
only mount-point is a good extra tripwire, but findmnt/mountpoint makes the
failure mode explicit before rsync or cp gets anywhere near the tree.

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

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

#87603

On 2026-06-06 12:14, TheLastSysop wrote:
>> On Sat, 6 Jun 2026 12:07:45 +0200, "Carlos E.R." <robin_listas@es.invalid>
>> wrote:
>> On 2026-06-06 10:55, Lawrence D’Oliveiro wrote:
>>> On Sun, 31 May 2026 07:46:12 GMT, TheLastSysop wrote:
>>>
>>>> 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.
>>>
>>> Been there, done that. The simple fix is to make the mount-point
>>> directory read-only. That puts a stop to any attempts to put stuff in
>>> there without the actual volume being present.
>>
>> That simple? Does this work? Wow.
> 
> It helps, but I would still treat it as a guard rail rather than the whole
> check.
> 
> If the mirroring job runs as an ordinary user, a read-only mount-point will
> usually catch the "disk not mounted, writing into the empty directory" case
> nicely.  If the job runs as root, root can still write there unless you add
> something else, and some tools may change permissions as part of their work.
> 
> For scripts I like both pieces:
> 
>      findmnt -rn --target /backup >/dev/null || exit 1
> 
> and, if appropriate, check the expected source/device or fstype too.  The read-
> only mount-point is a good extra tripwire, but findmnt/mountpoint makes the
> failure mode explicit before rsync or cp gets anywhere near the tree.
> 

In my scripts, I always check that destination is mounted.

Maybe "mount | grep destination"

-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

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

#87604

>On Sat, 6 Jun 2026 13:06:19 +0200, "Carlos E.R." <robin_listas@es.invalid>
>wrote:
>On 2026-06-06 12:14, TheLastSysop wrote:
>>> On Sat, 6 Jun 2026 12:07:45 +0200, "Carlos E.R." <robin_listas@es.invalid>
>>> wrote:
>>> On 2026-06-06 10:55, Lawrence D’Oliveiro wrote:
>>>> On Sun, 31 May 2026 07:46:12 GMT, TheLastSysop wrote:
>>>>
>>>>> 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.
>>>>
>>>> Been there, done that. The simple fix is to make the mount-point
>>>> directory read-only. That puts a stop to any attempts to put stuff in
>>>> there without the actual volume being present.
>>>
>>> That simple? Does this work? Wow.
>>
>> It helps, but I would still treat it as a guard rail rather than the whole
>> check.
>>
>> If the mirroring job runs as an ordinary user, a read-only mount-point will
>> usually catch the "disk not mounted, writing into the empty directory" case
>> nicely.  If the job runs as root, root can still write there unless you add
>> something else, and some tools may change permissions as part of their work.
>>
>> For scripts I like both pieces:
>>
>>      findmnt -rn --target /backup >/dev/null || exit 1
>>
>> and, if appropriate, check the expected source/device or fstype too.  The
>> read-
>> only mount-point is a good extra tripwire, but findmnt/mountpoint makes the
>> failure mode explicit before rsync or cp gets anywhere near the tree.
>>
>
>In my scripts, I always check that destination is mounted.
>
>Maybe "mount | grep destination"

Yes, that is the important part: make the script prove the destination is
mounted before it starts copying.

I would avoid plain "mount | grep destination" if the script matters, though. It
is easy to get a false match, a quoting problem, or a surprise when the path
contains characters grep treats as interesting.  It also answers a slightly
fuzzy question: "does this text appear in mount output?"

I prefer asking the mount table the exact question:

    findmnt -rn --target /backup >/dev/null || exit 1

or, for the simple case:

    mountpoint -q /backup || exit 1

Then add checks for fstype/source if mounting the wrong disk would be just as
bad as mounting no disk.

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

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

#87620

On Sat, 06 Jun 2026 11:12:57 GMT, TheLastSysop wrote:

> I prefer asking the mount table the exact question:
>
>     findmnt -rn --target /backup >/dev/null || exit 1

Always makes much more sense to get the command to output exactly the
information you need, rather than trying to do fancy tricks with
grepping output.

There seems to be way too much of a tradition of doing the latter as a
first resort, instead of first checking to see what output options the
command provides. (Or maybe using a different command...)

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

#87640

On 6/6/26 06:14, TheLastSysop wrote:
>> On Sat, 6 Jun 2026 12:07:45 +0200, "Carlos E.R." <robin_listas@es.invalid>
>> wrote:
>> On 2026-06-06 10:55, Lawrence D’Oliveiro wrote:
>>> On Sun, 31 May 2026 07:46:12 GMT, TheLastSysop wrote:
>>>
>>>> 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.
>>>
>>> Been there, done that. The simple fix is to make the mount-point
>>> directory read-only. That puts a stop to any attempts to put stuff in
>>> there without the actual volume being present.
>>
>> That simple? Does this work? Wow.
> 
> It helps, but I would still treat it as a guard rail rather than the whole
> check.
> 
> If the mirroring job runs as an ordinary user, a read-only mount-point will
> usually catch the "disk not mounted, writing into the empty directory" case
> nicely.  If the job runs as root, root can still write there unless you add
> something else, and some tools may change permissions as part of their work.
> 
> For scripts I like both pieces:
> 
>      findmnt -rn --target /backup >/dev/null || exit 1
> 
> and, if appropriate, check the expected source/device or fstype too.  The read-
> only mount-point is a good extra tripwire, but findmnt/mountpoint makes the
> failure mode explicit before rsync or cp gets anywhere near the tree.


   Pattern-matching of /proc/mounts can usually, easily,
   confirm everything is still attached properly.

   Any prob there, STOP ! Issue/mail big error messages.

   Python can easily, simply, analyze /proc/mounts to look
   for a desired path - one line, one step.

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

#87609

Carlos E.R. <robin_listas@es.invalid> wrote:
> On 2026-06-06 10:55, Lawrence D’Oliveiro wrote:
>> On Sun, 31 May 2026 07:46:12 GMT, TheLastSysop wrote:
>> 
>>> 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.
>> 
>> Been there, done that.  The simple fix is to make the mount-point 
>> directory read-only.  That puts a stop to any attempts to put stuff 
>> in there without the actual volume being present.
> 
> That simple?

Yep

> Does this work? Wow.

It does, for non-root users.  But not for root using standard Unix 
permissions.  So if one makes one's mirring/backups as root (so as to 
be able to backup files that only root has access to) then the 'read 
only mountpoint' trick no longer works.

Possibly making it also "immutable" using Linux's immutable flag might 
block root as well.

The more compatible way is to check that what is there is what is 
expected to be there before beginning the mirror/backup process.  I.e., 
what TheLastSysop recommended.

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

#87613

On 2026-06-06 20:30, Rich wrote:
> Carlos E.R. <robin_listas@es.invalid> wrote:
>> On 2026-06-06 10:55, Lawrence D’Oliveiro wrote:
>>> On Sun, 31 May 2026 07:46:12 GMT, TheLastSysop wrote:
>>>
>>>> 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.
>>>
>>> Been there, done that.  The simple fix is to make the mount-point
>>> directory read-only.  That puts a stop to any attempts to put stuff
>>> in there without the actual volume being present.
>>
>> That simple?
> 
> Yep
> 
>> Does this work? Wow.
> 
> It does, for non-root users.  But not for root using standard Unix
> permissions.  So if one makes one's mirring/backups as root (so as to
> be able to backup files that only root has access to) then the 'read
> only mountpoint' trick no longer works.

Ah, that's important. I do my backups as root.

> 
> Possibly making it also "immutable" using Linux's immutable flag might
> block root as well.
> 
> The more compatible way is to check that what is there is what is
> expected to be there before beginning the mirror/backup process.  I.e.,
> what TheLastSysop recommended.
> 


-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

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

#87630

On 6/6/26 04:55, Lawrence D’Oliveiro wrote:
> On Sun, 31 May 2026 07:46:12 GMT, TheLastSysop wrote:
> 
>> 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.
> 
> Been there, done that. The simple fix is to make the mount-point
> directory read-only. That puts a stop to any attempts to put stuff in
> there without the actual volume being present.

   CAN work ... but NOT so well during Business Hours.

   If yer biz is 24/7/365.25 ... PROBLEMS ! Just gotta
   pick a point and MOVE/MARK the stuff you wanna backup
   off to Some Other Dir or whatever and ACCEPT that it
   won't be 101% "current".

   Not much 'perfection' anywhere. Real Life SUCKS like that.

   Do your best.

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

#87592

On Sun, 31 May 2026 06:41:28 GMT, TheLastSysop wrote:

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

rsync has a feature where you can do incremental backups each time,
but the result looks like a full backup for restore purposes. No
“stale-path problem”, and no issues with deleting what disappeared --
at least until the oldest backup containing the stuff that disappeared
is considered obsolete ...

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

#87631

On 6/6/26 05:07, Lawrence D’Oliveiro wrote:
> On Sun, 31 May 2026 06:41:28 GMT, TheLastSysop wrote:
> 
>> 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.
> 
> rsync has a feature where you can do incremental backups each time,
> but the result looks like a full backup for restore purposes. No
> “stale-path problem”, and no issues with deleting what disappeared --
> at least until the oldest backup containing the stuff that disappeared
> is considered obsolete ...

   IF you look at backups as a frozen time frame then
   it's much easier. MOST biz can do that, but not ALL.

   Worst case ... you may have to keep track of 'inotify'
   events, to the second. Very un-cool. You're never QUITE
   "current". Consider a continually-used database and all
   its files/indexes. EVIL ! "Now" doesn't really MEAN much
   of anything, changes by the microsecond.

   For backup, offsite even more, at SOME time frame you just
   HAVE to cut corners and define a "Now".

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

#87593

On Sun, 31 May 2026 06:41:28 GMT, TheLastSysop wrote:

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

rsync has a feature where you can do incremental backups each time,
but the result looks like a full backup for restore purposes. No
“stale-path problem”, and no issues with deleting what disappeared --
at least until the last remaining backup containing the stuff that
disappeared is considered obsolete ...

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web