{"id":1402,"date":"2009-12-04T07:15:56","date_gmt":"2009-12-03T21:15:56","guid":{"rendered":"http:\/\/nsrd.wordpress.com\/?p=1402"},"modified":"2018-12-12T15:14:15","modified_gmt":"2018-12-12T05:14:15","slug":"validcopies-hazardous-sanity","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2009\/12\/04\/validcopies-hazardous-sanity\/","title":{"rendered":"Validcopies hazardous to your sanity"},"content":{"rendered":"

While much of NetWorker 7.6’s enhancements have been surrounding updates to virtualisation or (urgh) cloud, there remains a bunch of smaller updates that are of interest.<\/p>\n

One of those new features is the validcopies<\/em> flag, something I unfortunately failed to check out in beta testing. It looks like it could use some more work, but the theory<\/em> is a good one. The idea behind validcopies<\/em> is that we can use it in VTL style situations to determine not only whether we’ve got an appropriate number of copies, but they’re also valid<\/em> \u2013 i.e., they’re usable by NetWorker for recovery purposes.<\/p>\n

It’s a shame it’s too buggy to be used.<\/p>\n

Here’s an example where I backup to an ADV_FILE type device:<\/p>\n

[root@tara ~]# save -b Default -e \"+3 weeks\" -LL -q \/usr\/share\n57777:save:Multiple client instances of tara.pmdg.lab, using the first entry\nsave: \/usr\/share  1244 MB 00:03:23  87843 files\ncompleted savetime=1259366579\n\n[root@tara ~]# mminfo -q \"name=\/usr\/share,validcopies>1\"\n volume        client       date      size   level  name\nDefault.001    tara.pmdg.lab 11\/28\/2009 1244 MB manual \/usr\/share\nDefault.001.RO tara.pmdg.lab 11\/28\/2009 1244 MB manual \/usr\/share\n\n[root@tara ~]# mminfo -q \"name=\/usr\/share,validcopies>1\" -r validcopies\n6095:mminfo: no matches found for the query\n\n[root@tara ~]# mminfo -q \"name=\/usr\/share,validcopies>1\"\n volume        client       date      size   level  name\nDefault.001    tara.pmdg.lab 11\/28\/2009 1244 MB manual \/usr\/share\nDefault.001.RO tara.pmdg.lab 11\/28\/2009 1244 MB manual \/usr\/share\n\n[root@tara ~]# mminfo -q \"name=\/usr\/share,validcopies>1\" -r validcopies\n6095:mminfo: no matches found for the query\n\n[root@tara ~]# mminfo -q \"name=\/usr\/share,validcopies>1\" -r validcopies,copies\n validcopies copies\n 2     2\n 2     2<\/pre>\n
I have a few problems with the above output, and am working through the bugs in validcopies with EMC. Let’s look at each of those items and see what I’m concerned about:<\/p>\n
    \n
  1. We don’t have more than one valid copy just because it’s sitting on an ADV_FILE device. If the purpose of the “validcopies” flag is to count the number of unique recoverable copies, we do not have 2 copies<\/em> for each instance on ADV_FILE. There should be some logic there to not count copies on ADV_FILE devices twice for valid<\/em> copy counts.<\/li>\n
  2. As you can see from the last two commands, the results found<\/em> differ depending on report options. This is inappropriate, to say the least. We’re getting no validcopies reported at all if we only look for validcopies, or 2 validcopies reported if we search for both validcopies and copies.<\/li>\n<\/ol>\n
    Verdict from the above:<\/p>\n
      \n
    • Don’t use validcopies for disk backup units.<\/li>\n
    • Don’t report on validcopies only, or you’ll skew your results.<\/li>\n<\/ul>\n
      Let’s move on to VTLs though – we’ll clone the saveset I just generated to the ADV_FILE type over to the VTL:<\/p>\n
      [root@tara ~]# mminfo -q \"volume=Default.001.RO\" -r ssid,cloneid\n ssid         clone id\n4279265459  1259366578\n\n[root@tara ~]# nsrclone -b \"Big Clone\" -v -S 4279265459\/1259366578\n5874:nsrclone: Automatically copying save sets(s) to other volume(s)\n6216:nsrclone:\nStarting cloning operation...\nNov 28 11:29:42 tara logger: NetWorker media: (waiting) Waiting for 1 writable volume(s)\nto backup pool 'Big Clone' tape(s) or disk(s) on tara.pmdg.lab\n5884:nsrclone: Successfully cloned all requested save sets\n5886:nsrclone: Clones were written to the following volume(s):\n BIG998S3\n\n[root@tara ~]# mminfo -q \"ssid=4279265459\" -r validcopies\n 0\n\n[root@tara ~]# mminfo -q \"ssid=4279265459\" -r copies,validcopies\n copies validcopies\n 3          3\n 3          3\n 3          3<\/pre>\n
      In the above instance, if we query just by the saveset ID for the number of valid copies, NetWorker happily tells us “0”. If we query for copies and validcopies, we get 3 of each.<\/p>\n
      So, what does this say to me? Steer away from ‘validcopies’ until it’s fixed.<\/em><\/strong><\/p>\n
      (On a side note, why does the offsite<\/strong><\/em> parameter remain Write Only? We can’t query it through mminfo, and I’ve had an RFE in since the day the offsite<\/em> option was introduced into nsrmm. Why this is “hard” or taking so long is beyond me.)<\/p>\n","protected":false},"excerpt":{"rendered":"
      While much of NetWorker 7.6’s enhancements have been surrounding updates to virtualisation or (urgh) cloud, there remains a bunch of…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_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}},"categories":[11,16,20],"tags":[256,594,694,1068],"class_list":["post-1402","post","type-post","status-publish","format-standard","hentry","category-features","category-networker","category-scripting","tag-copies","tag-mminfo","tag-offsite","tag-validcopies"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-mC","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/1402","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/comments?post=1402"}],"version-history":[{"count":1,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/1402\/revisions"}],"predecessor-version":[{"id":7587,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/1402\/revisions\/7587"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=1402"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=1402"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=1402"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}