How to check or verify backup?

[Ted Flanders]

I keep hearing, "check your backup" or "verify your backup". What is the best way to do this? I do a bulog, but I am sure that is not enough. Thanks!

[f. halili]

if it is a backup via tar I use:
#tar tvf /dev/rmt/0m


-fnhalili

[Mark Vollmers]

I use SAM to set up an automated backup to run. As far as verifing that the backup occured, I get cron e-mail that lists the errors I got (if a file was open and could not be backed up). Also, I can look at the log (/var/sam/log/br_index.full), which is a complete list of all the files backed up. It tends to be a large file, since it contains everything. At least it lets me know that everything was done, though.

[Patrick Wallek]

The best way to check your backup is to actually use it to restore a file. You can delete something non-critical and restore it, or pick a file and restore to a location other than its original location. Checking for errors is good, but if you can't actually restore a file, then your backup is useless.

[James R. Ferguson · Accepted solution]

Hi Ted:

For 'fbackup' you can use 'frecover' without actually recovering files to verify your backup. The '-N' option for 'frecover' from the man pages specifies:

/begin_quote/

-N (no recovery) Prevent frecover from actually recovering any files onto disk, but read the backup as if it was, in fact, recovering the data from the backup, producing the same output that it would on a normal recovery. This option is useful for verifying backup media contents in terms of validity (block checksum errors are reported), and contents (a listing of files can be produced by using the -N and -v options together). Note that the listing of files produced with the -N and -v options requires the reading of the entire backup, but is therefore a more
accurate reflection of the backup's contents than the index stored at the beginning of the backup (which was created at the start of the backup session, and is not changed during the course of the backup).

/end_quote/

...JRF...

[Manuel P. Ron]

To verify backup:
frecover -xNv

To list the fiels on the tape:
frecover -I "index_file"

More information is in Chapter 9 Backing up and Restoring Data in the book "HP-UX System Administration Task." (Part. no. B2355-90079)

[Paula J Frazer-Campbell]

Hi Ted

The only true way to check you backup is to do a full recovery from the backup media, not something that we normally can do.

While backups are important, some are "Mission Critical" and so MUST be tested fully. Your company like mine will probable complain that you require downtime on the servers to test, but will understand when they realise the implications of a failed recovery procedure.

Once this test has been carried out we then have to rely on backup logs to confirm the validity of our backups.

In fbackup you can also define an error file to be executed upon error condition ( Mail to , write to log , page etc).

By using the command :-

mt -f /dev/rmt/xmn status
(HPUX 11.00 and above) it is possible to remotely check if the write protect tab is on on your destination backup tape.

Also as James has said a test recovery can be run by using the ?N option in fbackup, this has two problems the first being that you can be testing against a ?moving? database and so errors will be reported and the second is on a busy server extra loading will occur during the verification run.

Just a few ideas.


Paula

[Celso Medina Kern]

Hi,

You don?t need to do a real restore to verify a backup. You need to read data from the media, not writting it to any mass storage.
CPIO
cpio -it
TAR
tar -t
FBACKUP
use flag -N
OMNIBACK
use verify option from media pool management edit menu.
DD
dd if=/dev/ of=/dev/null

If the command returns an i/o error, you?ve got a bad backup.

Good backups!

[HSW Support]

One method I use is to create a small file as part of the backup script (in our case just the output of the date command). The backup list is sorted so that this file resides on the end of the tape. Following the backup write phase a restore is performed on this file and compared to a copy made earlier. If the 2 files match, backup is assumed ok. (cpio used for backups)

Mike

[William E. Sisson, Jr.]

Tapes can and do go bad. That being said, my experience has been that bad backups are more often the result of bad procedures than bad tapes. You have got to verify your procedures first and foremost. The ultimate test of your procedures (assuming you have the hardware) is to clone another system using your backups. Once you've done this you probably will feel pretty confident in your ability to restore.

If your data is really critical, consider redundant backups, because ocassionally tapes will go bad on the shelf, even after you verify them. Mission Critical systems should definitely have some element of redundancy (RAID/Mirror/clone..) for storage.
Bill

[John Bolene]

We use ignite make_recovery for most backups.
The tapes are created, then get loaded to our test servers.

What? You say that you don't have crash and burn lab servers? We have 2 C110, a K something, and an N something to play with in the lab. We normally load all new patches to them first and test if all the stuff works, sometimes it does not. After the patches are tested, they go to production servers. More make_recoverys are done and these are then loaded back to the lab servers.