Path: csiph.com!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
Newsgroups: comp.os.linux.misc
Subject: Re: Linux PC Acting Up? How To Check For Bad Blocks On A Hard Drive - Before It's Too Late
Date: Mon, 11 Aug 2025 19:40:05 -0000 (UTC)
Organization: the-candyden-of-code
Lines: 52
Message-ID: <slrn109khm5.eka.candycanearter07@candydeb.host.invalid>
References: <106ed70$3g63g$1@dont-email.me> <f77sllxkav.ln2@Telcontar.valinor> <106hsfk$bt9r$1@news1.tnib.de> <c3nullxpqg.ln2@Telcontar.valinor> <106ic3q$d6ma$1@news1.tnib.de> <106jk5i$nd9d$3@dont-email.me> <7r60mlx3b.ln2@Telcontar.valinor> <slrn1094i5k.gjcs.candycanearter07@candydeb.host.invalid> <106tv64$30re5$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 11 Aug 2025 19:40:05 +0000 (UTC)
Injection-Info: dont-email.me; posting-host="329ef539218f0ecc028e16e9ca3e21cb"; logging-data="2977663"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+Qdb17chkqBd4FMIPIDA4nmGXPOv/WWWyPqLRmU932+g=="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:TzCIlamPLV+JUMez6ZfuMda7zeI=
X-Face: b{dPmN&%4|lEo,wUO\"KLEOu5N_br(N2Yuc5/qcR5i>9-!^e\.Tw9?/m0}/~:UOM:Zf]% b+ V4R8q|QiU/R8\|G\WpC`-s?=)\fbtNc&=/a3a)r7xbRI]Vl)r<%PTriJ3pGpl_/B6!8pe\btzx `~R! r3.0#lHRE+^Gro0[cjsban'vZ#j7,?I/tHk{s=TFJ:H?~=]`O*~3ZX`qik`b:.gVIc-[$t/e ZrQsWJ >|l^I_[pbsIqwoz.WGA]<D
Xref: csiph.com comp.os.linux.misc:70798

Nuno Silva <nunojsilva@invalid.invalid> wrote at 22:04 this Tuesday (GMT):
> On 2025-08-05, candycanearter07 wrote:
>
>> Carlos E.R. <robin_listas@es.invalid> wrote at 01:39 this Saturday (GMT):
>>> 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.
>>
>>
>> That's why you have backups of backups.
>
>
> But... what if these fail too!?
>
> 10 PRINT "That's why you have"
> 20 PRINT "backups of backups of"
> 30 GOTO 20
>
> (Ok, in reality, a second level probably already drives the likelihood
> down a lot. But, of course, this gets to be an engineering problem, and
> one gets to ask what could possibly go wrong outside of these
> likelihoods.

Yeah, diminishing returns and all.

> And one could do things such as not using the same
> approach/scripts/software for both levels. Just like NASA had BFS
> developed separately from PASS.)


I'll keep that in mind when/if i set up another backup system.
-- 
user <candycane> is generated from /dev/urandom