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:<\/p>\n
Start time:\u00a0\u00a0 Sat Nov 14 17:42:52 2009\nEnd time:\u00a0\u00a0\u00a0\u00a0 Sun Nov 15 06:58:57 2009\n\n--- Successful Save Sets ---\n* cyclops:Probe savefs cyclops: succeeded.\n* cyclops:C:bigasms 66135:(pid 3308): NSR directive file (C:bigasmsnsr.dir) parsed\n\u00a0cyclops: C:bigasms\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 level=full,\u00a0\u00a0 1742 MB 13:15:56\u00a0\u00a0\u00a0 255 files\n\u00a0trash.pmdg.lab: index:cyclops\u00a0\u00a0\u00a0\u00a0 level=full,\u00a0\u00a0\u00a0\u00a0 31 KB 00:00:00\u00a0\u00a0\u00a0\u00a0\u00a0 7 files\n\u00a0trash.pmdg.lab: bootstrap\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 level=full,\u00a0\u00a0\u00a0 213 KB 00:00:00\u00a0\u00a0\u00a0 198 files<\/pre>\nHowever, when checked through NMC, nsrwatch or mminfo, you’ll find that that the correct size for the saveset is actually shown:<\/p>\n
[root@trash ~]# mminfo\n volume\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 client\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 date\u00a0\u00a0\u00a0\u00a0\u00a0 size\u00a0\u00a0 level\u00a0 name\nXFS.002\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 cyclops\u00a0\u00a0 11\/14\/2009 2510 GB\u00a0\u00a0 full\u00a0 C:bigasms\nXFS.002.RO\u00a0\u00a0\u00a0\u00a0 cyclops\u00a0\u00a0 11\/14\/2009 2510 GB\u00a0\u00a0 full\u00a0 C:bigasms<\/pre>\nThe 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.<\/p>\n
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.<\/p>\n
(It’s possible that this problem affects more than just 32-bit Windows clients \u2013 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.)<\/p>\n","protected":false},"excerpt":{"rendered":"
There’s currently a bug within NetWorker whereby if you’re using a 32-bit Windows client that has a filesystem large enough…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[11,16,27],"tags":[50,53,594,638,679,855,856,858],"class_list":["post-1769","post","type-post","status-publish","format-standard","hentry","category-features","category-networker","category-windows","tag-2tb","tag-32-bit","tag-mminfo","tag-nmc","tag-nsrwatch","tag-savegroup-completion","tag-saveset","tag-saveset-size"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t