Interesting thread - I will be required to regularly verify my backups, is
there any way to automate the 'checking' of backups in nbu?

-----Original Message-----
From: Wayne T. Smith [mailto:WTSmith AT maine DOT edu]
Sent: Tuesday, February 11, 2003 11:34 AM
To: Veritas Netbackup mailing list
Subject: Re: [Veritas-bu] Verifying backups....restores?


Gravizi, Thomas wrote, in part:
 > I am inquiring of what different organizations are doing to verify
 > that their backups are successful.  We perform restores for many
 > different policies that we have, so those aren't the issue.  It?s the
 > backups of the information we do not restore, or have not restored.
 > Do some people perform restores of random files every so often to
 > verify their backups are good?  Would a verify in the backup be
 > sufficient determining the backup was good?  What are some of your
 > thoughts and ideas?  Are there any good procedures out there?

This could be a good thread, even if some info is reposted from the
past.  I, too, invite people to comment here!

I'm used to having reliable equipment, so I don't spend much time on 
verifying that NBU doesn't drop a bit here or there.  What I do try to 
do is a little training and support of my data owners.

Rule 1 - If it isn't backed up, it must not be important to the 
organization.  My NBU clients receive high-level reports on backups via 
e-mail and they are able to get them, and detailed level (error) 
reports, via the web.

I encourage them to aim for status code 0, periodically investigate 
status code 1, and investigate any other status code asap.

Rule 1a - You can never have too many backups.

RAID/mirroring, rsync, outside-of-NBU automatic or manual backups, 
record keeping, and having a  person to backup your knowledge can all 
have their place.

Rule 1b - Just because a backup job continues to run successfully, 
doesn't mean all of your data is being backed up.

Think about your data. Look at your excludes and includes. Periodicaly 
invoke the Backup/Restore GUI and study the tree of backed up folders 
and files.  We once had a backup job that specified the file systems to 
backup.  A year later, they added a drive to support a new application. 
A year later I received a frantic call because the new drive had failed 
and the data owner couldn't get the restore to work.  It didn't work 
because the data was never backed up.

"ALL_LOCAL_DRIVES" is your friend!

(One of the things I like about Tivoli's ITSM product is that there is a 
view much like the NBU backup tree that indicates, for a policy, whether 
each item will or will not be backed up by automatic backup jobs).

Rule 2 - If you can't restore it (in reasonable time), a backup is 
worthless.

I encourage my data owners to periodically try simple and 
complex/complete restores of information they may one day need.  The 
former gets them familiar with the software and gives them another look 
at their data; the latter frequently shows them limitations or 
procedural problems better found in testing than when you need the data 
to return to production *now*!

Just a few thoughts ... I'm interested in yours!   cheers, wayne
-- 

Wayne T. Smith -- WTSmith AT Maine DOT edu
University of Maine System -- UNET -- Systems Software Analyst

_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu