{"id":1322,"date":"2009-11-13T16:45:02","date_gmt":"2009-11-13T06:45:02","guid":{"rendered":"http:\/\/nsrd.wordpress.com\/?p=1322"},"modified":"2018-12-12T15:18:57","modified_gmt":"2018-12-12T05:18:57","slug":"manually-staging-dont-forget-the-clone-id","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2009\/11\/13\/manually-staging-dont-forget-the-clone-id\/","title":{"rendered":"Manually Staging? Don’t forget the Clone ID!"},"content":{"rendered":"

Something that continues to periodically come up is the need to remind people running manual staging to ensure they specify both the SSID and the Clone ID when they stage. I did some initial coverage of this when I first started the blog<\/a>, but I wanted to revisit and demonstrate exactly why<\/em> this is necessary.<\/p>\n

The short version of why is simple: If you stage by SSID alone, NetWorker will delete\/purge all instances of the saveset other than the one you just created<\/em>. This is Not A Good Thing for 99.999% of what we do within NetWorker.<\/p>\n

So to demonstrate, here’s a session where I:<\/p>\n

    \n
  1. Generate a backup<\/li>\n
  2. Clone the backup to tape<\/li>\n
  3. Stage the saveset only to tape<\/li>\n<\/ol>\n

    In between each step, I’ll run mminfo to get a dump of what the media database says about saveset availability.<\/p>\n

    Part 1 \u2013 Generate the Backup<\/h3>\n

    Here’s a very simple backup for the purposes of this demonstration, and the subsequent mminfo command to find out about the backup:<\/p>\n

    [root@tara ~]# save -b Default -LL -q \/etc\nsave: \/etc  106 MB 00:00:07   2122 files\ncompleted savetime=1258093549\n\n[root@tara ~]# mminfo -q \"client=tara.pmdg.lab,name=\/etc\" -r volume,ssid,cloneid,\nsavetime\n volume        ssid          clone id  date\nDefault.001    2600270829  1258093549 11\/13\/2009\nDefault.001.RO 2600270829  1258093548 11\/13\/2009<\/pre>\n
    There’s nothing out of the ordinary here, so we’ll move onto the next step.<\/p>\n
    Part 2 \u2013 Clone the Backup<\/h3>\n
    We’ll just do a manual clone to the Default Clone pool. Here we’ll specify the saveset ID alone, which is fine for cloning \u2013 but is often what leads people to being in the habit of not specifying a particular saveset instance. I’m using very small VTL tapes, so don’t be worried that in this case I’ve got a clone of \/etc spanning 3 volumes:<\/p>\n
    [root@tara ~]# nsrclone -b \"Default Clone\" -S 2600270829\n[root@tara ~]# mminfo -q \"client=tara.pmdg.lab,name=\/etc\" -r volume,ssid,cloneid,\nsavetime\n volume        ssid          clone id  date\n800843S3       2600270829  1258094164 11\/13\/2009\n800844S3       2600270829  1258094164 11\/13\/2009\n800845S3       2600270829  1258094164 11\/13\/2009\nDefault.001    2600270829  1258093549 11\/13\/2009\nDefault.001.RO 2600270829  1258093548 11\/13\/2009<\/pre>\n
    As you can see there, it’s all looking fairly ordinary at this point – nothing surprising is going on at all.<\/p>\n
    Part 3 \u2013 Stage by Saveset ID Only<\/h3>\n
    In this next step, I’m going to stage by saveset ID alone rather than specifying the saveset ID\/clone ID, which is the correct way of staging, so as to demonstrate what happens at the conclusion of the staging. I’ll be staging to a pool called “Big”:<\/p>\n
    [root@tara ~]# nsrstage -b Big -v -m -S 2600270829\nObtaining media database information on server tara.pmdg.lab\nParsing save set id(s)\nMigrating the following save sets (ids):\n 2600270829\n5874:nsrstage: Automatically copying save sets(s) to other volume(s)\n\nStarting migration operation...\nNov 13 17:34:00 tara logger: NetWorker media: (waiting) Waiting for 1 writable\nvolume(s) to backup pool 'Big' disk(s) or tape(s) on tara.pmdg.lab\n5884:nsrstage: Successfully cloned all requested save sets\n5886:nsrstage: Clones were written to the following volume(s):\n BIG991S3\n6359:nsrstage: Deleting the successfully cloned save set 2600270829\nSuccessfully deleted original clone 1258093548 of save set 2600270829\nfrom media database.\nSuccessfully deleted AFTD's companion clone 1258093549 of save set 2600270829\nfrom media database with 0 retries.\nSuccessfully deleted original clone 1258094164 of save set 2600270829\nfrom media database.\nRecovering space from volume 4294740163 failed with the error\n'Cannot access volume 800844S3, please mount the volume or verify its label.'.\nRefer to the NetWorker log for details.\n6330:nsrstage: Cannot access volume 800844S3, please mount the volume\nor verify its label.\nCompleted recover space operation for volume 4177299774\nRefer to the NetWorker log for any failures.\nRecovering space from volume 4277962971 failed with the error\n'Cannot access volume 800845S3, please mount the volume or verify its label.'.\nRefer to the NetWorker log for details.\n6330:nsrstage: Cannot access volume 800845S3, please mount the volume\nor verify its label.\nRecovering space from volume 16550059 failed with the error\n'Cannot access volume 800843S3, please mount the volume or verify its label.'.\nRefer to the NetWorker log for details.\n6330:nsrstage: Cannot access volume 800843S3, please mount the volume\nor verify its label.<\/pre>\n
    You’ll note there’s a bunch of output there about being unable to access the clone volumes the saveset was previously cloned to. When we then check mminfo, we see the consequences of the staging operation though:<\/p>\n
    [root@tara ~]# mminfo -q \"client=tara.pmdg.lab,name=\/etc\" -r volume,ssid,cloneid,\nsavetime\n volume        ssid          clone id  date\nBIG991S3       2600270829  1258095244 11\/13\/2009<\/pre>\n
    As you can see \u2013 no reference to the clone volumes at all!<\/p>\n
    Now, has the clone data been erased? No, but it has<\/em> been removed from the media database, meaning you’d have to manually scan the volumes back in order to be able to use them again. Worse, if those volumes only<\/em> contained clone data that was subsequently removed from the media database, they may become eligible for recycling and get re-used before you notice what has gone wrong!<\/p>\n
    Wrapping Up<\/h3>\n
    Hopefully the above session will have demonstrated the danger of staging by saveset ID alone. If instead of staging by saveset ID we staged by saveset ID and clone ID, we’d have had a much more desirable outcome. Here’s a (short) example of that:<\/p>\n
    [root@tara ~]# save -b Default -LL -q \/tmp\nsave: \/tmp  2352 KB 00:00:01     67 files\ncompleted savetime=1258094378\n[root@tara ~]# mminfo -q \"name=\/tmp\" -r volume,ssid,cloneid\n volume        ssid          clone id\nDefault.001    2583494442  1258094378\nDefault.001.RO 2583494442  1258094377\n[root@tara ~]# nsrclone -b \"Default Clone\" -S 2583494442\n\n[root@tara ~]# mminfo -q \"name=\/tmp\" -r volume,ssid,cloneid\n volume        ssid          clone id\n800845S3       2583494442  1258095244\nDefault.001    2583494442  1258094378\nDefault.001.RO 2583494442  1258094377\n[root@tara ~]# nsrstage -b Big -v -m -S 2583494442\/1258094377\nObtaining media database information on server tara.pmdg.lab\nParsing save set id(s)\nMigrating the following save sets (ids):\n 2583494442\n5874:nsrstage: Automatically copying save sets(s) to other volume(s)\n\nStarting migration operation...\n\n5886:nsrstage: Clones were written to the following volume(s):\n BIG991S3\n6359:nsrstage: Deleting the successfully cloned save set 2583494442\nSuccessfully deleted original clone 1258094377 of save set 2583494442 from\nmedia database.\nSuccessfully deleted AFTD's companion clone 1258094378 of save set 2583494442\nfrom media database with 0 retries.\nCompleted recover space operation for volume 4177299774\nRefer to the NetWorker log for any failures.\n\n[root@tara ~]# mminfo -q \"name=\/tmp\" -r volume,ssid,cloneid\n volume        ssid          clone id\n800845S3       2583494442  1258095244\nBIG991S3       2583494442  1258096324<\/pre>\n
    The recommendation that I always make is that you forget about using saveset IDs alone<\/em> unless you absolutely have to. Instead, get yourself into the habit of always specifying a particular instance<\/em> of a saveset ID via the “ssid\/cloneid” option. That way, if you do any manual staging, you won’t wipe out access to data!<\/p>\n","protected":false},"excerpt":{"rendered":"
    Something that continues to periodically come up is the need to remind people running manual staging to ensure they specify…<\/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":[6,16,20],"tags":[227,656,677,857,928,933],"class_list":["post-1322","post","type-post","status-publish","format-standard","hentry","category-basics","category-networker","category-scripting","tag-clone-id","tag-nsrclone","tag-nsrstage","tag-saveset-id","tag-ssid","tag-staging"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\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\n\t\t\n\t\t