Verifying data on volume

It depends on what you mean under verify.

If you wish to verify what data is saved you can check index database with nsrinfo command. For example, from media database obtain nsavetime for given client and ssid and then feed it to nsrinfo and you will see what data is there.

If you wish to check integrity of the data on the volume itself you could clone the volume or run bogus scanner command (-n option).

Most common method is still by checking the logs and writing custom script where in report you see number of files and data volume. Experienced admin usually will notice if figures are not right and logs itself should be enough to see if something happen or not (however, that won't save you from nasty things like bad media).

It is a little unclear what you mean by verify - it could mean (1) look at what savesets Networker believes are on the tape, or you could mean (2) that you wish to check what contents are actually on the tape.

(1) The easiest way would be to check in the GUI and see what savesets are on the volume - you can also use mminfo -q volume=volumename to verify the contents (as per the media database).

(2) To verify the contents of the tape you will need to mount the tape and run the scanner command on it.

The correct answer to this query depends on what you need the information for and how you intend to act upon it!

regards

David

The "acid" test is to do an actual restore. Use a redirected restore to a test folder.

Thanks for all of the information. Our database routinely becomes corrupt so all of these options will help in determining actual data from the nights jobs.

If your database becomes corrupted by default (!?) then I would rather focus on solving that first (assuming you are talking about NetWorker database - otherwise ignore this post).

put them in the following order....1 being the best method....

1. Restore from the tape.....

2. Clone the tape.....

3. Use Scanner on the tape....

Restoring data for test is more than verifying. What is always recommended is that once per month there is random data selected and restored from production system to DR. This is approach usually taken in enterprise environment and it does give good overview of required actions and workflow when real restore would be required. This kind of approach that I would recommend anyone to use.

One thing we all failed to add was that in restore GUI you can run verify, but that one will only compare file types, modification times, sizes, and content. It does not verify other attributes, such as read only or hidden. Most of backup admins won't use that as they will probably script a solution via nsrinfo and some other tools on the local system.

this verifies your DR functionality works, and that you can restore from the volume.

As you had stated in your first response to his question, if the verification was to validate the data on the volume then a proper restore would be your first option.

I don't agree. If my single backup (eg. file server) is some 2TB big I have to plan restore of those 2TB at certain point of time and at certain place. During that period, give that backup went to tape, I will "loose" tape drive(s) and volumes. While this may not be your problem at all (it really depends on environment), cloning would be muc better option as I would be able to script smater way of cloning plus I would validate backup. The "loss" of drives/volumes is still present here (thus, having backup to disk, cloning after and finally staging after certain period is prefered way).

If your backup volume is small or critical data that needs 100% to be verified is small that restore might be your option. However, imagine a bigger volume - restore can't be optimal anymore way of doing verify. Still, if being sure you have data secured is an issue cloning would be something that would address both things: verification of original volume and extra copy.

One thing that still remains an issue is data volume verification after certain time - for example you wish to test if your volumes are still able to do the restores. Today I believe data retention which is acceptable per tape type we usually see is 5-7 years (despite, some people like to believe tapes can be used to keep data "forever"). For such tests you would have 2 kind of verifications: one - verifying conditions of tape vaulting and second where you would run random test to your DR location.