[clug] Story: Fijian Resort complex loses a single disk: business process stops for 1-2 days
grail at goldweb.com.au
Sat Jul 26 15:56:06 MDT 2014
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...
Size: 189 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the linux