Veritas-bu

[Veritas-bu] Verifying backups....restores?

2003-02-11 15:28:45
Subject: [Veritas-bu] Verifying backups....restores?
From: jmcdon23 AT csc.com DOT au (jmcdon23 AT csc.com DOT au)
Date: Wed, 12 Feb 2003 07:28:45 +1100
Hi

More thoughts
1. Check your service level agreement/objectives.  Are they written with
restores in mind?
2. Check for backup window over-runs.  Is the backup void because an app
was started while the backup was running?  That states the obvious but I
have seen it happen many times.
3. To save time record all client requested restores use that a test. Get
agreement that frequent client restores fulfil the requirement data
restoration testing.

Regards
Jim McDonald

----------------------------------------------------------------------------------------

This email, including any attachments, is intended only for use by the
addressee(s) and may contain confidential and/or personal information and
may also be the subject of legal privilege. Any personal information
contained in this email is not to be used or disclosed for any purpose
other than the purpose for which you have received it. If you are not the
intended recipient, you must not disclose or use the information contained
in it. In this case, please let me know by return email, delete the message
permanently from your system and destroy any copies.
----------------------------------------------------------------------------------------





"Wayne T. Smith" <WTSmith AT maine DOT edu>@mailman.eng.auburn.edu on 12/02/2003
03:34:25 AM

Sent by:    veritas-bu-admin AT mailman.eng.auburn DOT edu


To:    Veritas Netbackup mailing list <veritas-bu AT mailman.eng.auburn DOT edu>
cc:
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