There’s currently a bug within NetWorker whereby if you’re using a 32-bit Windows client that has a filesystem large enough such that the savesets generated are larger than 2TB, you’ll get a massively truncated size reported in the savegroup completion. In fact, for a 2,510 GB saveset, the savegroup completion report will look like this:
Start time: Sat Nov 14 17:42:52 2009 End time: Sun Nov 15 06:58:57 2009 --- Successful Save Sets --- * cyclops:Probe savefs cyclops: succeeded. * cyclops:C:\bigasms 66135:(pid 3308): NSR directive file (C:\bigasms\nsr.dir) parsed cyclops: C:\bigasms level=full, 1742 MB 13:15:56 255 files trash.pmdg.lab: index:cyclops level=full, 31 KB 00:00:00 7 files trash.pmdg.lab: bootstrap level=full, 213 KB 00:00:00 198 files
However, when checked through NMC, nsrwatch or mminfo, you’ll find that that the correct size for the saveset is actually shown:
[root@trash ~]# mminfo volume client date size level name XFS.002 cyclops 11/14/2009 2510 GB full C:\bigasms XFS.002.RO cyclops 11/14/2009 2510 GB full C:\bigasms
The reporting doesn’t affect recoverability, but if you’re reviewing savegroup completion reports the data sizes will likely (a) be a cause for concern or (b) affect any auto parsing that you’re doing of the savegroup completion report.
I’ve managed to secure a fix for 7.4.4 for this, with requests in to get it ported to 7.5.1 as well, and to get it integrated into the main trees for permanent inclusion upon the next service packs, etc. If you’ve been putting up with this problem for a while or have just noticed it and want it fixed, the escalation patch number was NW110493.
(It’s possible that this problem affects more than just 32-bit Windows clients – i.e,. it could affect other 32-bit clients as well. I’d be interested in knowing if someone has spotted it on another operating system. I’d test, but my lab environment is currently otherwise occupied and generating 2+TB of data, even at 90MB/s, is a wee bit long.)
