[clug] Story: Fijian Resort complex loses a single disk: business process stops for 1-2 days

[Alex Satrapa]

On 26 Jul 2014, at 23:48, Scott Ferguson <scott.ferguson.clug at gmail.com> wrote:

> Again - that verifies the backup, not the reliablity. Counting the
> bottles you store on the nature strip isn't laying down a cellar for
> your future ;p

So how do you verify the media when the media is, say, a USB hard drive?

> You snip out all of my original post bar the sentence about verifying
> the backup medium then state that you compare the backup to the
> original. Why?  (I also note that you could/should have checked the
> backup by using rsync with the checksum option - cp is a dangerous way
> to do backups)

Here is how you check the backup to verify that it’s working:
1) Keep MD5 sums
2) Check the backup against the MD5 sums

Nothing in there about cp. I use Time Machine which is basically doing the same thing as “rsync snapshot” backups. It copies-by-reference the entire file system then hard copies the files that have changed.

> The discussion (see OP) is about a failure of a backup system. One of
> the most common is media failure due to a failure to practise BMP and
> actually prove the reliability of the medium (damaged array *and* pp
> backup plan didn't backup critical data).

How does one verify the media more cheaply than checksumming the content? I don’t want an estimate along the lines of, “oh, this disk is mostly working”.

How does one verify the backup plan is working, other than doing a full or partial restore of data?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.samba.org/pipermail/linux/attachments/20140727/43d58c5c/attachment.pgp>