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

#87610

c186282 <c186282@nnada.net> wrote:
> 
>   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 !  :-)

It won't.  By your own admission they "couldn't program their way out 
of a wet paper bag" so they won't bother to even look into your 
utility.

So long as it continues to work, they will use it.  When something 
changes somewhere that stops it from working, they will have management 
create a new replacement rather than repair the existing tool.

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

There are folks out there who don't understand the concept of "zipping 
up files".  There are loads of others (mostly the way younger crowd who 
have only ever owned a cell phone as their "one and only computer" who 
do not even understand the concept of "files".

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

Given that Phil Zimmermann did not release PGP until 1991 [1], that can not 
have been the 1980's.

Granted, 1991 is close enough for 35 year old memories to get fuzzy.



[1] https://en.wikipedia.org/wiki/Pretty_Good_Privacy

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

#87590

On Tue, 02 Jun 2026 11:08:20 GMT, TheLastSysop wrote:

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

Surely only Windows users would have a habit like that ...

<https://docs.python.org/3/library/subprocess.html>

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

#87629

On 6/6/26 04:53, Lawrence D’Oliveiro wrote:
> On Tue, 02 Jun 2026 11:08:20 GMT, TheLastSysop wrote:
> 
>> * shelling out through os.system() with filenames that eventually
>> contain the one character nobody expected;
> 
> Surely only Windows users would have a habit like that ...
> 
> <https://docs.python.org/3/library/subprocess.html>


   Hah Hah Hah Hah !!!  :-)

   Somewhere recently I described having to craft
   a funky fix for Vista+ Winders file names. Just
   EVIL !  :-)

   Took me a few days, even when I was young and hot.

   Winders sub-microscopic PERMISSIONS ... what a HORROR !!!
   Dropped 95% of that BS on Linux shares.

   Seems SOME want to claim that INSANE permissions/ownership
   params are somehow "better".

   Not too long before I retired I was trying to use
   actual Win libs/utils to cope with the deep deep
   deep 'permissions' mess. NOT entirely successful.
   What an incredible MESS !!!

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

#87589

On Mon, 01 Jun 2026 09:38:15 GMT, TheLastSysop wrote:

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

Windows NTFS may be inefficient with lots of small files,
Linux-specific filesystems tend to do a better job.

Just a note for those whose primary experience might be on ... other
... platforms.

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

#87628

On 6/6/26 04:52, Lawrence D’Oliveiro wrote:
> On Mon, 01 Jun 2026 09:38:15 GMT, TheLastSysop wrote:
> 
>> 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.
> 
> Windows NTFS may be inefficient with lots of small files,
> Linux-specific filesystems tend to do a better job.

   Well ... "better" ........

> Just a note for those whose primary experience might be on ... other
> ... platforms.

   At this point in time there's not THAT much more
   "superiority" in data density/utility between the
   popular file systems. CPU speed just destroys most
   any diff between efficient/inefficient file systems.

   Corporate - make it POLICY to store Important Stuff
   on the Linux NETWORK SHARES rather than store locally.
   Started that policy as soon as there WERE network
   shares (Novell Netware + Win95 + coax). HELPED
   a lot. Linux came along a bit later ... but the
   paradigm was ready.

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

#87583

On Sun, 31 May 2026 04:23:42 GMT, TheLastSysop wrote:

> Pre-encrypting before the cloud hop is the sane default. Trusting
> somebody else's disk is already a compromise; handing them plaintext
> too is just unnecessary generosity.

Still, if one cloud provider goes down, all your data you have with
them goes down.

Erasure codes extended to filesystems:
<https://tahoe-lafs.org/trac/tahoe-lafs>.

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

#87587

On 6/6/26 02:41, Lawrence D’Oliveiro wrote:
> On Sun, 31 May 2026 04:23:42 GMT, TheLastSysop wrote:
> 
>> Pre-encrypting before the cloud hop is the sane default. Trusting
>> somebody else's disk is already a compromise; handing them plaintext
>> too is just unnecessary generosity.
> 
> Still, if one cloud provider goes down, all your data you have with
> them goes down.

   Which is why you also keep a LOCAL mirror  :-)

   Disk space is cheap. Total loss is NOT.

   Basically, 'cloud' is in case the office gets
   hit by a tornado or giant fire.

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

#87605

On 2026-06-06 09:07, c186282 wrote:
> On 6/6/26 02:41, Lawrence D’Oliveiro wrote:
>> On Sun, 31 May 2026 04:23:42 GMT, TheLastSysop wrote:
>>
>>> Pre-encrypting before the cloud hop is the sane default. Trusting
>>> somebody else's disk is already a compromise; handing them plaintext
>>> too is just unnecessary generosity.
>>
>> Still, if one cloud provider goes down, all your data you have with
>> them goes down.
> 
>    Which is why you also keep a LOCAL mirror  :-)
> 
>    Disk space is cheap. Total loss is NOT.

No, disk space is no longer cheap. Price has doubled.

> 
>    Basically, 'cloud' is in case the office gets
>    hit by a tornado or giant fire.
> 


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

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

#87614

On Sat, 6 Jun 2026 03:07:41 -0400, c186282 wrote:

>    Basically, 'cloud' is in case the office gets hit by a tornado or
>    giant fire.

Or ransomware. I used to backup projects I was working on to the corporate 
OneDrive.  They were still there after my Windows machine was locked up 
tight. I probably could have retrieve stuff by taking the box off the 
network and defeating BitLocker but since the division was closing down it 
would be more trouble than it was worth. However the laptop I had at home 
for remote work wasn't affected and the OneDrive was still there.

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

#87598

>On Sat, 6 Jun 2026 06:41:34 -0000 (UTC), Lawrence
>=?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> wrote:
>On Sun, 31 May 2026 04:23:42 GMT, TheLastSysop wrote:
>
>> Pre-encrypting before the cloud hop is the sane default. Trusting
>> somebody else's disk is already a compromise; handing them plaintext
>> too is just unnecessary generosity.
>
>Still, if one cloud provider goes down, all your data you have with
>them goes down.
>
>Erasure codes extended to filesystems:
><https://tahoe-lafs.org/trac/tahoe-lafs>.

Right.  Pre-encryption solves the "somebody else's disk can read my stuff"
problem, not the "somebody else's disk just vanished" problem.

Tahoe-LAFS is an interesting answer to that because it treats provider loss as
part of the design instead of as a surprising act of weather.  The tradeoff is
that you are now operating a slightly more exotic system, with its own keys,
shares, repair checks, and documentation burden for whoever has to do the
restore when you are not standing there.

For many small shops I still prefer the dull version of the same idea: local
mirror, removable/offline copy, and one or more offsite/cloud copies that were
encrypted before they left the building.  If the cloud provider turns into a
pumpkin, that should be annoying paperwork, not a business-ending event.

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

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

#87622

On Sat, 06 Jun 2026 09:40:35 GMT, TheLastSysop wrote:

> Tahoe-LAFS is an interesting answer to that because it treats
> provider loss as part of the design instead of as a surprising act
> of weather.

How long before people finally figure out that maybe, just maybe, this
kind of happening shouldn’t be considered so rare and surprising after
all ... ?

> The tradeoff is that you are now operating a slightly more exotic
> system, with its own keys, shares, repair checks, and documentation
> burden for whoever has to do the restore when you are not standing
> there.

There’s probably a way to script it all. Stick a little GUI script on
the front: “to do a restore, click this button and follow the
prompts”.

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

#87637

On 6/6/26 05:40, TheLastSysop wrote:
>> On Sat, 6 Jun 2026 06:41:34 -0000 (UTC), Lawrence
>> =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> wrote:
>> On Sun, 31 May 2026 04:23:42 GMT, TheLastSysop wrote:
>>
>>> Pre-encrypting before the cloud hop is the sane default. Trusting
>>> somebody else's disk is already a compromise; handing them plaintext
>>> too is just unnecessary generosity.
>>
>> Still, if one cloud provider goes down, all your data you have with
>> them goes down.
>>
>> Erasure codes extended to filesystems:
>> <https://tahoe-lafs.org/trac/tahoe-lafs>.
> 
> Right.  Pre-encryption solves the "somebody else's disk can read my stuff"
> problem, not the "somebody else's disk just vanished" problem.

   Very right.

   As said, MY policy was always PRE-Encrypt, THEN send
   to Cloud. Couldn't go wrong there. Even a few MS on
   cloud UN-encrypted is a RISK. Do NOT trust providers.

> Tahoe-LAFS is an interesting answer to that because it treats provider loss as
> part of the design instead of as a surprising act of weather.  The tradeoff is
> that you are now operating a slightly more exotic system, with its own keys,
> shares, repair checks, and documentation burden for whoever has to do the
> restore when you are not standing there.

   Um ... never USED that. I was always a more "roll yer own"
   kind of guy. Simpler usually, greater control, more predictable.
   App ? I'd rather WRITE one than INSTALL one. Far more fun.
   That's my psych.

> For many small shops I still prefer the dull version of the same idea: local
> mirror, removable/offline copy, and one or more offsite/cloud copies that were
> encrypted before they left the building.  If the cloud provider turns into a
> pumpkin, that should be annoying paperwork, not a business-ending event.

   "Local Mirror" is GOOD ... just keep it where evil people
   are unlikely, or can't, look. DID have an app - PI3 -
   that during the day would DUPLICATE some of the local,
   already encrypted, mirrors. A "just in case" backup. Had
   all day to work, no prob with the PI3.

   Note a PI3 *can* support ONE laptop-sized mag HDD.
   Literally rubber-banded 'em together and stuck the
   whole thing in an obscure corner of an out-building.

   WORKED for years.

   DO love 'redundancy'.

   That's ONE concept I never had a prob justifying
   to our 'auditors'.

   As the PI was just copying ENCRYPTED it didn't even
   matter if some evil employee STOLE the drive - they
   couldn't READ it.

   (Place was small enough where *I* was the only one
   with the skills to de-encrypt anyhow - but DID write
   good enough instructions so one of our 'sister' agencies
   could lend a person with similar skills, Just In Case.
   Hey, anybody CAN be run over by a truck or have an
   attack or whatever ...)

   "Cloud" is ANOTHER kind of 'redundancy' - and always
   treated it as such, not a main-stream thing. Hard-2-
   Get-At LOCAL was always my mainline. WAS encrypted.

   Shit shit shit ... failing memory ... what WAS that
   Win3.11/95 app that would let you "shot-gun" two or
   more DIAL UP net connections into one, faster, one ???
   Can't REMEMBER anymore !!! Dammit ! Years go by ....

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

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

#87582

On Sat, 30 May 2026 22:28:03 GMT, TheLastSysop wrote:

> Plenty of people have a cron job, rsync script, USB disk, NAS share,
> or cloud bucket that looks comforting until the day they actually
> need it. Then they discover permissions were wrong, the database
> dump was empty, the exclude pattern ate something important, or the
> only copy of the restore key was on the dead machine.

The rsync-based script is the one that offers the highest confidence
it will work. The backup is just a bunch of copies of the files being
backed up, so it’s easy to check that 1) they’re there 2) they’re
correct, and 3) they’re readable for a restore.

Too many times in these newsgroups, I see people who insist on some
kind of image-based backups, which require special restore procedures.
I don’t understand that. Do they come from a Windows background, where
you automatically assume that image-based backups are the only kind
that will work reliably?

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

#87586

On 6/6/26 02:38, Lawrence D’Oliveiro wrote:
> On Sat, 30 May 2026 22:28:03 GMT, TheLastSysop wrote:
> 
>> Plenty of people have a cron job, rsync script, USB disk, NAS share,
>> or cloud bucket that looks comforting until the day they actually
>> need it. Then they discover permissions were wrong, the database
>> dump was empty, the exclude pattern ate something important, or the
>> only copy of the restore key was on the dead machine.
> 
> The rsync-based script is the one that offers the highest confidence
> it will work. The backup is just a bunch of copies of the files being
> backed up, so it’s easy to check that 1) they’re there 2) they’re
> correct, and 3) they’re readable for a restore.

   Yep. Made extensive use of 'rsync' - an option
   for everything. DO make sure none of your mounts
   drop during ops though  :-)

> Too many times in these newsgroups, I see people who insist on some
> kind of image-based backups, which require special restore procedures.
> I don’t understand that. Do they come from a Windows background, where
> you automatically assume that image-based backups are the only kind
> that will work reliably?

   Well, there's always a *complicated* solution
   for everything ......

   Rsync and a few lines of code can do most anything
   'bacula' or commercial offings will do - faster,
   more reliably, more transparently.

   Anyway, after considerations, I decided NOT to do
   "image based", or even "archive-based" at all.
   Encrypted/moved/tweaked on a per-file basis. Far
   more control, far easier to recover JUST what
   you might need. Loss of ONE file didn't screw up
   a gigabyte archive either. Nice plain mirrors
   of my directory trees too.

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

#87606

On 2026-06-06 09:04, c186282 wrote:
> On 6/6/26 02:38, Lawrence D’Oliveiro wrote:
>> On Sat, 30 May 2026 22:28:03 GMT, TheLastSysop wrote:
>>
>>> Plenty of people have a cron job, rsync script, USB disk, NAS share,
>>> or cloud bucket that looks comforting until the day they actually
>>> need it. Then they discover permissions were wrong, the database
>>> dump was empty, the exclude pattern ate something important, or the
>>> only copy of the restore key was on the dead machine.
>>
>> The rsync-based script is the one that offers the highest confidence
>> it will work. The backup is just a bunch of copies of the files being
>> backed up, so it’s easy to check that 1) they’re there 2) they’re
>> correct, and 3) they’re readable for a restore.
> 
>    Yep. Made extensive use of 'rsync' - an option
>    for everything. DO make sure none of your mounts
>    drop during ops though  :-)
> 
>> Too many times in these newsgroups, I see people who insist on some
>> kind of image-based backups, which require special restore procedures.
>> I don’t understand that. Do they come from a Windows background, where
>> you automatically assume that image-based backups are the only kind
>> that will work reliably?
> 
>    Well, there's always a *complicated* solution
>    for everything ......
> 
>    Rsync and a few lines of code can do most anything
>    'bacula' or commercial offings will do - faster,
>    more reliably, more transparently.

Can't compress the destination. Or encrypt it.

(do not confuse with compressing the transport)


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

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

#87607

>On Sat, 6 Jun 2026 13:32:02 +0200, "Carlos E.R." <robin_listas@es.invalid>
>wrote:
>On 2026-06-06 09:04, c186282 wrote:
>> On 6/6/26 02:38, Lawrence D’Oliveiro wrote:
>>> On Sat, 30 May 2026 22:28:03 GMT, TheLastSysop wrote:
>>>
>>>> Plenty of people have a cron job, rsync script, USB disk, NAS share,
>>>> or cloud bucket that looks comforting until the day they actually
>>>> need it. Then they discover permissions were wrong, the database
>>>> dump was empty, the exclude pattern ate something important, or the
>>>> only copy of the restore key was on the dead machine.
>>>
>>> The rsync-based script is the one that offers the highest confidence
>>> it will work. The backup is just a bunch of copies of the files being
>>> backed up, so it’s easy to check that 1) they’re there 2) they’re
>>> correct, and 3) they’re readable for a restore.
>>
>>    Yep. Made extensive use of 'rsync' - an option
>>    for everything. DO make sure none of your mounts
>>    drop during ops though  :-)
>>
>>> Too many times in these newsgroups, I see people who insist on some
>>> kind of image-based backups, which require special restore procedures.
>>> I don’t understand that. Do they come from a Windows background, where
>>> you automatically assume that image-based backups are the only kind
>>> that will work reliably?
>>
>>    Well, there's always a *complicated* solution
>>    for everything ......
>>
>>    Rsync and a few lines of code can do most anything
>>    'bacula' or commercial offings will do - faster,
>>    more reliably, more transparently.
>
>Can't compress the destination. Or encrypt it.
>
>(do not confuse with compressing the transport)

Rsync will not do at-rest compression/encryption by itself, but you can put that
layer under the destination.

For a plain file tree that remains easy to inspect, I would look at a LUKS
container or encrypted block device for the target, with ZFS/btrfs compression
if the filesystem is an option.  Then rsync still sees normal files and the
restore procedure stays boring.

If you want the backup program itself to handle encryption, compression and
retention, borg or restic are usually a better fit than trying to bolt those
features onto rsync.  Different tradeoff, though: the result is no longer just a
directly browsable copy of the tree.

Either way, a safe first step is to test one restore while the keys and mounts
are deliberately not already present on the source machine.

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

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web