Most NetWorker administrators with even a passing familiarity of mminfo will be aware of the “savetime” field, which reports when a saveset was created (i.e., when the backup was taken).
There are however some other fields that also provide additional date/time details about savesets, and knowing about them can be a real boon. Here’s a quick summary of the important date/time fields that provide information about savesets:
- savetime – The time/date, on the client of the backup.
- sscreate – The time/date on the server of the backup.
- ssinsert – The time/date on the server of the last time the saveset was inserted into the media database.
- sscomp – The time/date that the backup completed*.
- ssaccess – The date/time that the backup was last accessed for backup or recovery purposes**.
Now, remembering that we can append, in the report specifications, a field length to any field, we can get some very useful information out of the media database for savesets. For instance, to see when the backups started and stopped for a volume, you might run:
[root@nox ~]# mminfo -q "volume=ISO_Archive.001" -r "name, savetime(23),sscomp(23)" name date time ss completed /d/03/share-a/ISO 05/06/2009 08:38:40 AM 05/06/2009 12:34:18 PM
So, not only do we have the date, but also the time of both the start and the finish of the backup.
To compare the client savetime with the server savetime, we’d use the sscreate field:
[root@nox ~]# mminfo -q "volume=ISO_Archive.001" -r "name, savetime(23),sscreate(23)" name date time ss created /d/03/share-a/ISO 05/06/2009 08:38:40 AM 05/06/2009 08:38:42 AM
Note in this second there was a 2 second skew between the backup server and the client at the time the backup was run.
I’ll leave ssinsert as an exercise to the reader – if you’ve got any recently scanned in savesets, give it a try and compare it against the output from sscreate and savetime.
However, moving on to the last field I mentioned, ssaccess, we get some very interesting results. Let’s see the output from:
[root@nox ~]# mminfo -q "volume=ISO_Archive.001,name=/d/03/share-a/ISO" -r "name, savetime(23),ssaccess(23)" name date time ss access /d/03/share-a/ISO 05/06/2009 08:38:40 AM 05/06/2009 08:42:25 AM /d/03/share-a/ISO 05/06/2009 08:38:40 AM 05/06/2009 08:43:31 AM /d/03/share-a/ISO 05/06/2009 08:38:40 AM 05/06/2009 08:46:00 AM /d/03/share-a/ISO 05/06/2009 08:38:40 AM 05/06/2009 08:48:12 AM /d/03/share-a/ISO 05/06/2009 08:38:40 AM 05/06/2009 08:49:04 AM /d/03/share-a/ISO 05/06/2009 08:38:40 AM 05/06/2009 08:49:55 AM /d/03/share-a/ISO 05/06/2009 08:38:40 AM 05/06/2009 08:54:10 AM (snip)
Now, if you’ve been following the thread, the above doesn’t immediately appear to make sense. On that volume there’s only one saveset, so why are we suddenly getting entries for what appears to be multiple savesets? Well, they’re not multiple savesets – let’s try it again with SSID, rather than name:
[root@nox ~]# mminfo -q "volume=ISO_Archive.001,name=/d/03/share-a/ISO" -r "ssid, savetime(23),ssaccess(23)" ssid date time ss access 67158002 05/06/2009 08:38:40 AM 05/06/2009 08:42:25 AM 67158002 05/06/2009 08:38:40 AM 05/06/2009 08:43:31 AM 67158002 05/06/2009 08:38:40 AM 05/06/2009 08:46:00 AM 67158002 05/06/2009 08:38:40 AM 05/06/2009 08:48:12 AM 67158002 05/06/2009 08:38:40 AM 05/06/2009 08:49:04 AM 67158002 05/06/2009 08:38:40 AM 05/06/2009 08:49:55 AM 67158002 05/06/2009 08:38:40 AM 05/06/2009 08:54:10 AM (snip)
An astute reader may think I’ve got some problem with my media database at this point – only one instance of a saveset can ever appear on the same volume, so the above looks like it simply shouldn’t happen.
Here’s where it gets really interesting though. NetWorker writes savesets in fragments, and each fragment of the saveset is generated and may be accessed separately – therefore, mminfo is reporting the access time for each fragment of the saveset. We can fully see this by expanding what we’re asking mminfo to report – including fragsize, mediafile and mediarec.
[root@nox 02]# mminfo -q "volume=ISO_Archive.001" -r "savetime(23),ssaccess(23), fragsize,mediafile,mediarec" date time ss access size file rec 05/06/2009 08:38:40 AM 05/06/2009 08:42:25 AM 1040 MB 2 0 05/06/2009 08:38:40 AM 05/06/2009 08:43:31 AM 1040 MB 3 0 05/06/2009 08:38:40 AM 05/06/2009 08:46:00 AM 1040 MB 4 0 05/06/2009 08:38:40 AM 05/06/2009 08:48:12 AM 1040 MB 5 0 05/06/2009 08:38:40 AM 05/06/2009 08:49:04 AM 1040 MB 6 0 05/06/2009 08:38:40 AM 05/06/2009 08:49:55 AM 1040 MB 7 0
Now, the man page for mminfo says that the ssaccess time is updated for both backup and recovery operations, but despite various recovery tests I can’t yet get it to update. Despite this however, this is still useful – it allows us to tell how long each fragment took to backup, which lets us interrogate, at a later point, whether there were any pauses of significant delays in the data stream.
Regardless of the little discrepancy with ssaccess, you can see that there’s a great set of options available to retrieve additional date/time related details about savesets using mminfo.
(I’ve currently got a case open with EMC to determine whether ssaccess should be updated on recovery attempts, or whether the documentation has an error. I’ll update this posting once I find out.)
—
* The man page for mminfo does not document whether this is server time or client time. I assume, given that savetime is client time, that sscomp is also client time.
** The man page for mminfo does not document whether this is server time or client time. I assume that it’s in server time.