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

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

Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late

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

Contents

  Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-31 00:26 +0000
    Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late c186282 <c186282@nnada.net> - 2025-07-30 23:02 -0400
    Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late "Carlos E.R." <robin_listas@es.invalid> - 2025-07-31 15:21 +0200
      Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late The Natural Philosopher <tnp@invalid.invalid> - 2025-07-31 14:39 +0100
      Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-01 01:08 +0000
        Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late "Carlos E.R." <robin_listas@es.invalid> - 2025-08-01 14:03 +0200
      Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-08-01 10:05 +0200
        Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late "Carlos E.R." <robin_listas@es.invalid> - 2025-08-01 14:04 +0200
          Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-08-01 14:31 +0200
            Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late "Carlos E.R." <robin_listas@es.invalid> - 2025-08-01 14:40 +0200
              Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-08-01 18:16 +0200
            Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-08-01 19:29 +0000
              Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late c186282 <c186282@nnada.net> - 2025-08-02 02:15 -0400
              Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-08-02 10:05 +0200
            Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-01 23:55 +0000
              Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late "Carlos E.R." <robin_listas@es.invalid> - 2025-08-02 03:39 +0200
                Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-02 03:24 +0000
                  Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late c186282 <c186282@nnada.net> - 2025-08-02 02:04 -0400
                  Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late "Carlos E.R." <robin_listas@es.invalid> - 2025-08-02 13:59 +0200
                Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late c186282 <c186282@nnada.net> - 2025-08-02 03:03 -0400
                Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-08-05 19:20 +0000
                  Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late Nuno Silva <nunojsilva@invalid.invalid> - 2025-08-05 23:04 +0100
                    Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late c186282 <c186282@nnada.net> - 2025-08-05 19:54 -0400
                      Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late rbowman <bowman@montana.com> - 2025-08-06 06:37 +0000
                        Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late c186282 <c186282@nnada.net> - 2025-08-06 04:03 -0400
                          Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late not@telling.you.invalid (Computer Nerd Kev) - 2025-08-07 07:14 +1000
                            Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late c186282 <c186282@nnada.net> - 2025-08-06 22:16 -0400
                              Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late Richard Kettlewell <invalid@invalid.invalid> - 2025-08-07 18:20 +0100
                                Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late The Natural Philosopher <tnp@invalid.invalid> - 2025-08-07 18:22 +0100
                              Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late not@telling.you.invalid (Computer Nerd Kev) - 2025-08-08 09:10 +1000
                        Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2025-08-06 07:39 -0700
                    Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-08-11 19:40 +0000
              Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-08-02 10:07 +0200
                Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-02 23:32 +0000
                  Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late c186282 <c186282@nnada.net> - 2025-08-02 21:36 -0400

Page 1 of 2  [1] 2  Next page →

#70174 — Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late

This article
<https://www.zdnet.com/article/linux-pc-acting-up-how-to-check-for-bad-blocks-on-a-hard-drive-before-its-too-late/>
is, I would say, more of a starting point for thinking about the
issue, rather than the final word on what to do.

I used to use the badblocks utility a lot, too. However, the last I
checked, it had limitations on the size of disks it could cope with --
a 12-terabyte drive was beyond its capabilities. So I had to write my
own disk-scanning utility <https://gitlab.com/ldo/scan_disks/>. (I
don’t bother much with SMART -- I think it’s mostly a waste of time.)

Frankly, I would not like to continue using a disk that had bad blocks
on it. I did sort-of try that once -- I had a 3-terabyte drive that
developed errors within the warranty period. Before taking it back to
the shop, I wrote zeroes over the whole drive, and as a result of
that, the bad blocks disappeared. And the shop couldn’t find anything
wrong with it, so they refused a warranty return.

That drive did last a few more years in my backup machine, before
developing more bad sectors, after which I retired it.

[toc] | [next] | [standalone]

#70175

On 7/30/25 8:26 PM, Lawrence D'Oliveiro wrote:
> This article
> <https://www.zdnet.com/article/linux-pc-acting-up-how-to-check-for-bad-blocks-on-a-hard-drive-before-its-too-late/>
> is, I would say, more of a starting point for thinking about the
> issue, rather than the final word on what to do.
> 
> I used to use the badblocks utility a lot, too. However, the last I
> checked, it had limitations on the size of disks it could cope with --
> a 12-terabyte drive was beyond its capabilities. So I had to write my
> own disk-scanning utility <https://gitlab.com/ldo/scan_disks/>. (I
> don’t bother much with SMART -- I think it’s mostly a waste of time.)
> 
> Frankly, I would not like to continue using a disk that had bad blocks
> on it. I did sort-of try that once -- I had a 3-terabyte drive that
> developed errors within the warranty period. Before taking it back to
> the shop, I wrote zeroes over the whole drive, and as a result of
> that, the bad blocks disappeared. And the shop couldn’t find anything
> wrong with it, so they refused a warranty return.
> 
> That drive did last a few more years in my backup machine, before
> developing more bad sectors, after which I retired it.

   I don't have a good answer for you. A lot of the
   old Linux disk-check utilities were writ in the
   Bad Old Days of sub-terabyte, maybe sub-gigabyte,
   HDDs. If you can still get them, they're mostly
   just useless now.

   Choices are re-writing/re-compiling them ... no minor
   task ... or kinda writing your own from scratch.

   Figuring out how some programmer from decades ago
   was thinking can be just *horrible* - and not too
   many added good notes to the source code.

   A few years ago I wrote a whole-disk reader in 'C'.
   (also a Pascal/Delphi version but it CALLED some of
   the 'C' stuff). Had to deal with BIG offsets ... which
   meant 64/128 bit math types and less-known variants
   of 'seek()' and related. I did make it work. Kinda
   looked like a nice 'ghex'-ish display.

   Thing is, you COULD expand on that to do read/write
   probes of any sectors. How many patterns you think
   you need to try on each sector - up to you.

   In short it CAN be done - but by YOU. 1990 utilities
   aren't gonna cut it.

   Best compromise - the built-in capabilities in most
   SATA/related drives. "S.M.A.R.T./smartctl" can do
   this - but expect it to take 24 hours on large disks.
   Just install the 'smartmontools' pkg. I *think* Gnome
   has a GUI for them.

   Dunno if 'badblocks' can do huge disks.

   FIXING/relocating bad blocks ... a whole new challenge !

   Some stuff just ain't so easy.

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

#70192

On 2025-07-31 02:26, Lawrence D'Oliveiro wrote:
> This article
> <https://www.zdnet.com/article/linux-pc-acting-up-how-to-check-for-bad-blocks-on-a-hard-drive-before-its-too-late/>
> is, I would say, more of a starting point for thinking about the
> issue, rather than the final word on what to do.
> 
> I used to use the badblocks utility a lot, too. However, the last I
> checked, it had limitations on the size of disks it could cope with --
> a 12-terabyte drive was beyond its capabilities. So I had to write my
> own disk-scanning utility <https://gitlab.com/ldo/scan_disks/>. (I
> don’t bother much with SMART -- I think it’s mostly a waste of time.)
> 
> Frankly, I would not like to continue using a disk that had bad blocks
> on it. I did sort-of try that once -- I had a 3-terabyte drive that
> developed errors within the warranty period. Before taking it back to
> the shop, I wrote zeroes over the whole drive, and as a result of
> that, the bad blocks disappeared. And the shop couldn’t find anything
> wrong with it, so they refused a warranty return.

This is one of the SMART features.
Even showing the bad blocks is not enough to get a refund/return.

> 
> That drive did last a few more years in my backup machine, before
> developing more bad sectors, after which I retired it.

I have a dead Seagate 3TB disk, lost all the data inside.

-- 
Cheers, Carlos.

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

#70193

On 31/07/2025 14:21, Carlos E.R. wrote:
> On 2025-07-31 02:26, Lawrence D'Oliveiro wrote:
>> This article
>> <https://www.zdnet.com/article/linux-pc-acting-up-how-to-check-for-bad-blocks-on-a-hard-drive-before-its-too-late/>
>> is, I would say, more of a starting point for thinking about the
>> issue, rather than the final word on what to do.
>>
>> I used to use the badblocks utility a lot, too. However, the last I
>> checked, it had limitations on the size of disks it could cope with --
>> a 12-terabyte drive was beyond its capabilities. So I had to write my
>> own disk-scanning utility <https://gitlab.com/ldo/scan_disks/>. (I
>> don’t bother much with SMART -- I think it’s mostly a waste of time.)
>>
>> Frankly, I would not like to continue using a disk that had bad blocks
>> on it. I did sort-of try that once -- I had a 3-terabyte drive that
>> developed errors within the warranty period. Before taking it back to
>> the shop, I wrote zeroes over the whole drive, and as a result of
>> that, the bad blocks disappeared. And the shop couldn’t find anything
>> wrong with it, so they refused a warranty return.
> 
> This is one of the SMART features.
> Even showing the bad blocks is not enough to get a refund/return.
> 
I got a replacement SSD under SMART  info - the vendor checked it and 
said 'yup. that's fucked' and gave me another one.
We are good friends


>>
>> That drive did last a few more years in my backup machine, before
>> developing more bad sectors, after which I retired it.
> 
> I have a dead Seagate 3TB disk, lost all the data inside.
> 
If something other than a sector goes bad you are in real trouble.
We did manage to swap circuit boards on a drive once and get the data off it


-- 
Religion is regarded by the common people as true, by the wise as 
foolish, and by the rulers as useful.

(Seneca the Younger, 65 AD)

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

#70209

On Thu, 31 Jul 2025 15:21:19 +0200, Carlos E.R. wrote:

> I have a dead Seagate 3TB disk, lost all the data inside.

This is why I have a backup machine.

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

#70226

On 2025-08-01 03:08, Lawrence D'Oliveiro wrote:
> On Thu, 31 Jul 2025 15:21:19 +0200, Carlos E.R. wrote:
> 
>> I have a dead Seagate 3TB disk, lost all the data inside.
> 
> This is why I have a backup machine.

Yes, I do, but the files there were not that important (movies), and I 
had no space for them. 3TB was my biggest disk at the time.

-- 
Cheers, Carlos.

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

#70220

"Carlos E.R." <robin_listas@es.invalid> wrote:
>I have a dead Seagate 3TB disk, lost all the data inside.

Probably a decade old?

Greetings
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

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

#70227

On 2025-08-01 10:05, Marc Haber wrote:
> "Carlos E.R." <robin_listas@es.invalid> wrote:
>> I have a dead Seagate 3TB disk, lost all the data inside.
> 
> Probably a decade old?

Probably. I think that model was infamous.

-- 
Cheers, Carlos.

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

#70228

"Carlos E.R." <robin_listas@es.invalid> wrote:
>On 2025-08-01 10:05, Marc Haber wrote:
>> "Carlos E.R." <robin_listas@es.invalid> wrote:
>>> I have a dead Seagate 3TB disk, lost all the data inside.
>> 
>> Probably a decade old?
>
>Probably. I think that model was infamous.

I apologize. I thought that we were talking about practical relevant
cases.

I lost 540 MB from a failed Fujitsu drive in 1998 and found out the
backup was invalid the hard way.

-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

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

#70229

On 2025-08-01 14:31, Marc Haber wrote:
> "Carlos E.R." <robin_listas@es.invalid> wrote:
>> On 2025-08-01 10:05, Marc Haber wrote:
>>> "Carlos E.R." <robin_listas@es.invalid> wrote:
>>>> I have a dead Seagate 3TB disk, lost all the data inside.
>>>
>>> Probably a decade old?
>>
>> Probably. I think that model was infamous.
> 
> I apologize. I thought that we were talking about practical relevant
> cases.

I think that Seagate model had many disk failing early. Defective model. 
But as mine was working fine, I continued using it, till one day it 
failed completely. Probably a pcb replacement would work, but that's not 
something I can do.

> 
> I lost 540 MB from a failed Fujitsu drive in 1998 and found out the
> backup was invalid the hard way.
> 


-- 
Cheers, Carlos.

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

#70230

"Carlos E.R." <robin_listas@es.invalid> wrote:
>I think that Seagate model had many disk failing early. Defective model. 
>But as mine was working fine, I continued using it, till one day it 
>failed completely. Probably a pcb replacement would work, but that's not 
>something I can do.

No backup, no mercy.

Greetings
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

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

#70237

Le 01-08-2025, Marc Haber <mh+usenetspam1118@zugschl.us> a écrit :
>
> I lost 540 MB from a failed Fujitsu drive in 1998 and found out the
> backup was invalid the hard way.

When a backup is never tested, it's called a Schrödinger's backup.

-- 
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

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

#70249

On 8/1/25 3:29 PM, Stéphane CARPENTIER wrote:
> Le 01-08-2025, Marc Haber <mh+usenetspam1118@zugschl.us> a écrit :
>>
>> I lost 540 MB from a failed Fujitsu drive in 1998 and found out the
>> backup was invalid the hard way.
> 
> When a backup is never tested, it's called a Schrödinger's backup.

   Hey, I *like* that term !!!  :-)

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

#70254

Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:
>Le 01-08-2025, Marc Haber <mh+usenetspam1118@zugschl.us> a écrit :
>> I lost 540 MB from a failed Fujitsu drive in 1998 and found out the
>> backup was invalid the hard way.
>
>When a backup is never tested, it's called a Schrödinger's backup.

Right. Back then, verifying a backup meant having spare hardware. You
didn't have that in the 1990ies typical small company. Today you can
restore in another VM and verify the backup there. That was simply not
realistic 30 years ago.

That was when I was still using windows. The backup software used back
then had a GUI. You included the root, and then excluded by clicking
in the tree. So I thought. What I didn't know that with the first
"exclude" click, the software built a (static!) list of all files to
back up. And didn't maintain it. So all files that were created after
that first "exclude" click never found their way into a backup.

And, "verify backup" didn't uncover this, since of course all files
that were backed up could be read back and verified just fine. Just
the ones that never got backed up of course didn't cause an error.

The "correct" way would have been to not use the GUI but instead write
the paths to exclude with wildcards into a text file.

I still consider this what we would call today an UX nightmare and
blame the software vendor. 30 years later, I still consider this
implementation one of the most diabolic footguns that I ever
encountered.

Of course, with 30 years of more experience, one could have tried a
data only restore to a different part of the directory tree, but as a
junior sysadmin making some extra money on the side of college, that
didnt occur to me back then. One of the more painful lessons of a life
in IT.

Greetings
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

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

#70242

On Fri, 01 Aug 2025 14:31:54 +0200, Marc Haber wrote:

> I lost 540 MB from a failed Fujitsu drive in 1998 and found out the
> backup was invalid the hard way.

My backups are done with rsync, or script wrappers around rsync. They are 
effectively mirror filesystems, not in any special “backup” format. These 
are the easiest to verify, and restoration can be done with the same file-
manipulation commands I use every day.

In particular, that means that, in a moment of crisis (which is what 
happens when you find you’ve lost data), I am doing the restoration using 
familiar commands with which I am (hopefully) less likely to make 
mistakes.

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

#70245

On 2025-08-02 01:55, Lawrence D'Oliveiro wrote:
> On Fri, 01 Aug 2025 14:31:54 +0200, Marc Haber wrote:
> 
>> I lost 540 MB from a failed Fujitsu drive in 1998 and found out the
>> backup was invalid the hard way.
> 
> My backups are done with rsync, or script wrappers around rsync. They are
> effectively mirror filesystems, not in any special “backup” format. These
> are the easiest to verify, and restoration can be done with the same file-
> manipulation commands I use every day.
> 
> In particular, that means that, in a moment of crisis (which is what
> happens when you find you’ve lost data), I am doing the restoration using
> familiar commands with which I am (hopefully) less likely to make
> mistakes.

Once an rsync backup deleted the original.

I was using the --delete parameter, which is intended to delete files 
that are gone from the source, and delete them in the destination (when 
you overwrite a backup). Unfortunately, the paths were messed up, and it 
deleted the files on the source of another different backup.

-- 
Cheers, Carlos.

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

#70246

On Sat, 2 Aug 2025 03:39:19 +0200, Carlos E.R. wrote:

> Once an rsync backup deleted the original.
> 
> I was using the --delete parameter, which is intended to delete files
> that are gone from the source, and delete them in the destination (when
> you overwrite a backup). Unfortunately, the paths were messed up, and it
> deleted the files on the source of another different backup.

A computer is a powerful tool. It will do exactly what you tell it to do, 
no more, no less.

Try --delete-after, which postpones all the deletions until after the new 
and updated files have been successfully copied -- and which doesn’t do 
any deletions at all, if there were errors in those copies.

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

#70248

On 8/1/25 11:24 PM, Lawrence D'Oliveiro wrote:
> On Sat, 2 Aug 2025 03:39:19 +0200, Carlos E.R. wrote:
> 
>> Once an rsync backup deleted the original.
>>
>> I was using the --delete parameter, which is intended to delete files
>> that are gone from the source, and delete them in the destination (when
>> you overwrite a backup). Unfortunately, the paths were messed up, and it
>> deleted the files on the source of another different backup.
> 
> A computer is a powerful tool. It will do exactly what you tell it to do,
> no more, no less.
> 
> Try --delete-after, which postpones all the deletions until after the new
> and updated files have been successfully copied -- and which doesn’t do
> any deletions at all, if there were errors in those copies.

   I had a similar gross fault with "-delete". The prob
   was that mounted shares CAN fail, and then the param
   sees an empty dir and dutifully deletes all the backups.
   Had one weird case with sort of reverse-update trick,
   where the SOURCE files got deleted instead of the backups.

   Fair fix ... look in /proc/mounts, quick pattern match,
   to see if you're still connected. "if '/my/whatever' in
   /proc/mounts then :"

   Next, subdivide the backup a bit - and do the above
   check before each segment. NEVER feel sure that
   mounts are gonna be perfectly solid.

   It's not 101% sure, but close enough for govt work.

   The "-delete" is ultra-valuable and you're probably
   going to HAVE to use it lest mass quantities of
   old junk accumulate. In an office environ where
   people keep creating/deleting/moving all the time
   that's a biggie. All you can do is make it safer,
   more sure.

   In my big backup pgm I also added a little "intelligence",
   a quick eval of what the size of the targets were LAST
   time -vs- THIS time. If TOO different it'd mail error
   messages and NOT proceed without manual intervention.

   Biz/corporate, good backups are IMPERATIVE ... and
   preferably local AND to 'cloud' (DO pre-encrypt !
   Don't BELIEVE cloud providers. Encrypt, send, re-name
   if needed, but never put a plain file on their systems
   for a millisecond)

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

#70258

On 2025-08-02 05:24, Lawrence D'Oliveiro wrote:
> On Sat, 2 Aug 2025 03:39:19 +0200, Carlos E.R. wrote:
> 
>> Once an rsync backup deleted the original.
>>
>> I was using the --delete parameter, which is intended to delete files
>> that are gone from the source, and delete them in the destination (when
>> you overwrite a backup). Unfortunately, the paths were messed up, and it
>> deleted the files on the source of another different backup.
> 
> A computer is a powerful tool. It will do exactly what you tell it to do,
> no more, no less.
> 
> Try --delete-after, which postpones all the deletions until after the new
> and updated files have been successfully copied -- and which doesn’t do
> any deletions at all, if there were errors in those copies.

Ah, interesting, thanks.

-- 
Cheers, Carlos.

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

#70253

On 8/1/25 9:39 PM, Carlos E.R. wrote:
> On 2025-08-02 01:55, Lawrence D'Oliveiro wrote:
>> On Fri, 01 Aug 2025 14:31:54 +0200, Marc Haber wrote:
>>
>>> I lost 540 MB from a failed Fujitsu drive in 1998 and found out the
>>> backup was invalid the hard way.
>>
>> My backups are done with rsync, or script wrappers around rsync. They are
>> effectively mirror filesystems, not in any special “backup” format. These
>> are the easiest to verify, and restoration can be done with the same 
>> file-
>> manipulation commands I use every day.
>>
>> In particular, that means that, in a moment of crisis (which is what
>> happens when you find you’ve lost data), I am doing the restoration using
>> familiar commands with which I am (hopefully) less likely to make
>> mistakes.
> 
> Once an rsync backup deleted the original.

   Had that happen once. It was a 'reverse' operation,
   a kind of clean-up, of the source folders. Alas
   a mount became un-mounted and ...

> I was using the --delete parameter, which is intended to delete files 
> that are gone from the source, and delete them in the destination (when 
> you overwrite a backup). Unfortunately, the paths were messed up, and it 
> deleted the files on the source of another different backup.
> 

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web