We did something like this in the past, where we had a scheduled job that
created a file in a specific directory, we would then recover this directory
each month to verify that all the files had been backed up (the recovery part
wasn't automated, but that wouldn't be too difficult) ... but I have to say it
didn't make me feel any better about our backups. I mean I felt comfortable
that that directory was well protected, but the rest of the environment that
was a different story.
There are various checks/tests that can be done to verify the validity of a
backup, and depending on the size of your organisation those checks should be
owned / performed by different people, some of these are obvious and other
perhaps not - we don't necessarily do all of these, or if we do, do them very
well.
1. save set completion reports - is networker reporting that the backup
completed successfully.
2. save set size - does the size of the save set roughly match your expected
size of the dataset (this is difficult for incremental or differential
backups), but is a worthwhile check for full backups.
3. save set validity - can networker read the entire save set, I've never done
this, but I guess you could perform a save set recovery and re-direct to
/dev/nul.
The above three should all be owned by the data protection team, and probably
to some degree could be automated.
4. data set validity - and I guess this is the one that we are talking about
here, I really believe that this should be performed by the people who manage
the dataset - not the end users - but for example if we are talking about a
file server, then the people who manage that file server should be performing
this check, DBA's should be checking the validity of database backups, etc. As
the backup administrator I don't have a clue as to what the dataset should look
like, so verifying that the recovery looks correct is a little tricky.
Anyway just my 2c ... am sure that there are people out there who have
different thoughts around this, I'd be interested to hear them.
Mat.
-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of STANLEY R. HORWITZ
Sent: Saturday, 9 April 2011 2:22 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] Automated Restore tests in networker
Yes. Just a few weeks ago, one of the DBA people here restored an RMAN file
from LTO-3 tape. The resulting file would not import back into Oracle (on a
Windows 2003) server. We tried restoring a backup from another tape.
That one worked fine.
On 4/8/2011 8:52 AM, "dmitri" <networker-forum AT BACKUPCENTRAL DOT COM> wrote:
>[qoute]My idea is to set up a set of files on a given NetWorker client,
>then schedule a restore of those files via a script to the client, but
>to a different folder, then use a "diff" script to verify the restored
>and original files are the same.[/quote]
>
>While I can understand and appreciate some merits in running test
>restores, this got me thinking... Has anybody had a case when a
>restored file was any different then the source one? I've never seen this.
>As for the OP - yes, it can be easily achieved with "recover" command,
>scheduled in cron. All you need is read the manpage for it, very
>simple implementation.
>
>+----------------------------------------------------------------------
>|This was sent by xxxxxx AT zzzz DOT cc via Backup Central.
>|Forward SPAM to abuse AT backupcentral DOT com.
>+----------------------------------------------------------------------
>
>To sign off this list, send email to listserv AT listserv.temple DOT edu and
>type "signoff networker" in the body of the email. Please write to
>networker-request AT listserv.temple DOT edu if you have any problems with
>this list. You can access the archives at
>http://listserv.temple.edu/archives/networker.html or via RSS at
>http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or via RSS at
http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
********************************* DISCLAIMER
*********************************
The information contained in the above e-mail message or messages
(which includes any attachments) is confidential and may be legally
privileged. It is intended only for the use of the person or
entity to which it is addressed. If you are not the addressee any
form of disclosure, copying, modification, distribution or any
action taken or omitted in reliance on the information is
unauthorised. Opinions contained in the message(s) do not
necessarily reflect the opinions of the Queensland Government and
its authorities. If you received this communication in error,
please notify the sender immediately and delete it from your
computer system network.
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
