Following a recent discussion I\u2019ve been having on the NetWorker Mailing List, I thought I should put a few details down about clone IDs.<\/p>\n
If you don\u2019t clone your backups (and if you don\u2019t: why not?<\/em>), you may not have really encountered clone IDs very much. They\u2019re the shadowy twin of the saveset ID, and serve a fairly important purpose.<\/p>\n From hereon in, I\u2019ll use the following nomenclature:<\/p>\n \u201cSSID\u201d is pretty much the standard NetWorker terminology for saveset ID, but usually clone ID is just written as \u201cclone ID\u201d or \u201cclone-id\u201d, etc., which gets a bit tiresome after a while.<\/p>\n Every saveset in NetWorker is tagged with a unique SSID. However, every copy of a saveset is tagged with the same SSID, but a different CLID.<\/p>\n You can see this when you ask mminfo to show both:<\/p>\n (If you must know, being a fan of Doctor Who, all my Time Machine drives are called \u201cTARDIS\u201d \u2013 and no, I don\u2019t backup my Time Machine copies with NetWorker, it would be a truly arduous and wasteful thing to do; I use my Time Machine drives for other database dumps from my Macs.)<\/em><\/p>\n In this case we\u2019re not only seeing the SSID and CLID, but also a special instance of the SSID\/CLID combination \u2013 that which is assigned for disk backup units. In the above example, you\u2019ll note that the CLID associated with the read-only (.RO) version of the disk backup unit is exactly one less than the CLID associated with the read-write version of the disk backup unit. This is done by NetWorker for a very specific reason.<\/p>\n So, you might wonder then what the purpose of the CLID is, since we use the SSID to identify an individual saveset, right?<\/p>\n I had hunted for ages for a really good analogy on SSID\/CLIDs, and stupidly the most obvious one never occurred to me. One of the NetWorker Mailing List\u2019s most helpful posters, Davina Treiber, posted the (in retrospect) obvious and smartest analogy I\u2019ve seen – comparing savesets to books in a library. To paraphrase, while a library may have multiple copies of the same book (with each copy having the same ISBN – after all, it\u2019s the same book), they will obviously need to keep track of the individual copies of the book to know who has which copy, how many copies they have left, etc. Thus, the library would assign an individual copy number to each instance of the book they have, even if they only have one instance.<\/p>\n This, quite simply, is the purpose of the CLID \u2013 to identify individual instances of a single saveset. This means that you can, for example, do any of the following (and more!):<\/p>\n In particular, in the final example, if you know that a particular tape is bad, and you want to delete that tape, you only want NetWorker to delete reference to the saveset instances on that tape \u2013 you wouldn\u2019t want to also delete reference to perfectly good copies sitting on other tapes. Thus you would refer to SSID\/CLID.<\/p>\n I\u2019ve not been using the terminology SSID\/CLID randomly. When working with NetWorker in a situation where you either want to, or must specify a specific instance of a saveset, you literally use that in the command. E.g.,:<\/p>\n Would clone the saveset 3962821973 to the \u201cDaily Clone\u201d pool, using the saveset instance (CLID) 1228135764.<\/p>\n The same command could be specified as:<\/p>\n However, this would mean that NetWorker would pick which instance of the saveset to read from in order to clone the nominated saveset. The same thing happens when NetWorker is asked to perform a recovery in standard situations (i.e., non-SSID based recoveries).<\/p>\n So, how does NetWorker pick which instance of a saveset should be used to facilitate a recovery? The algorithm used goes a little like this:<\/p>\n The first point may not immediately make sense. Most available? If you say, have 2 copies on tape, and one tape is in a library, but the other is physically mounted in a tape drive, and is not in use, that tape in the drive will be used.<\/p>\n For the second point, consider disk backup units – adv_file type devices. In this case, both the RW and the RO \u201cversion\u201d of the saveset (remembering, there\u2019s only one real physical copy on disk, NetWorker just mungs some details to make it appear to the media database that there\u2019s 2 copies) are equally online – they\u2019re both mounted disk volumes. So, to prevent recoveries automatically running from the RW \u201cversion\u201d of the saveset on disk, when the instances are setup, the \u201cversion\u201d on the RO portion of the disk backup unit is assigned a CLID one less than the CLID of the \u201cversion\u201d on the RW device.<\/p>\n Thus, we get \u201cguaranteed\u201d recovery\/reading from the RO version of the disk backup unit. In normal circumstances, that is. (You can still force recovery\/reading from the RW version if you so desire.)<\/p>\n In the final point, if all copies are equally offline, NetWorker previously just requested the copy with the lowest CLID. This works well in a tape only environment – i.e.:<\/p>\n In this scenario, NetWorker would ask for the \u2018original\u2019 by virtue of it having the lowest CLID. However, the CLID is only generated when the saveset is cloned. Thus, consider the backup to disk scenario:<\/p>\n This created a problem \u2013 in this scenario, if you went to do a recovery after staging, then NetWorker would (annoyingly for many!) request the clone version of the saveset. This either meant requesting it to be pulled back from the offsite location, or doing a SSID\/CLID recovery or marking the clone SSID\/CLID as suspect or mounting the \u201coriginal\u201d. However you looked at it, it was a lot of work that you really shouldn\u2019t have needed to do.<\/p>\n NetWorker 7.3.x however introduced the notion of an offsite flag; this isn\u2019t the same as setting the volume location to offsite however. It\u2019s literally a new flag:<\/p>\n Would mark the volume 800841 in the media database as not being onsite \u2013 I.e., having a less desirable<\/em> availability for recovery\/read operations.<\/p>\n The net result is that in this situation, even if the offsite clone has a lower CLID, if it is flagged as offsite, but there\u2019s a clone with a higher CLID not flagged as offsite, NetWorker will bypass that normal \u201cuse the lowest CLID\u201d preference to instead request the onsite copy.<\/p>\n It would certainly be preferable however if a future version of NetWorker could have read priority established as a flag for pools; that way, rather than having to bugger around with the offsite flag (which, incidentally, can only be set\/cleared from the command line, and can\u2019t be queried!), an administrator could nominate \u201cThis pool has highest recovery priority, whereas this pool has lower recovery priority\u201d. That way, NetWorker would pick the lowest CLID in the highest recovery priority pool.<\/p>\n (I wait, and hope.)<\/p>\n","protected":false},"excerpt":{"rendered":" Following a recent discussion I\u2019ve been having on the NetWorker Mailing List, I thought I should put a few details…<\/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":[16,20],"tags":[1249,1252,856,1253],"class_list":["post-12","post","type-post","status-publish","format-standard","hentry","category-networker","category-scripting","tag-networker","tag-recovery","tag-saveset","tag-scripting"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-c","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/12","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=12"}],"version-history":[{"count":1,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/12\/revisions"}],"predecessor-version":[{"id":7702,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/12\/revisions\/7702"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=12"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=12"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=12"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
[root@nox ~]# mminfo -q \"savetime>=18 hours ago,pool=Staging,client=archon,\nname=\/Volumes\/TARDIS\" -r volume,ssid,cloneid,nsavetime<\/pre>\n
volume ssid clone id save time<\/pre>\n
Staging-01 3962821973 1228135765 1228135764<\/pre>\n
Staging-01.RO 3962821973 1228135764 1228135764<\/pre>\n
\n
# nsrclone -b \u201cDaily Clone\u201d -S 3962821973\/1228135764<\/pre>\n
# nsrclone -b \u201cDaily Clone\u201d -S 3962821973<\/pre>\n
\n
\n
\n
# nsrmm -o offsite 800841<\/pre>\n