{"id":2025,"date":"2010-03-24T17:25:14","date_gmt":"2010-03-24T07:25:14","guid":{"rendered":"http:\/\/nsrd.info\/blog\/?p=2025"},"modified":"2018-12-11T18:50:43","modified_gmt":"2018-12-11T08:50:43","slug":"barcode-categories-issues","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2010\/03\/24\/barcode-categories-issues\/","title":{"rendered":"Barcode categories create issues"},"content":{"rendered":"<p>Some sites get quite particular about their volume barcodes when it comes to physical media. This means you&#8217;ll see barcodes such as:<\/p>\n<ul>\n<li>Bxxxxxx \u2013 Byyyyyy \u2013 Backup volumes<\/li>\n<li>Cxxxxxx \u2013 Cyyyyyy \u2013 Clone volumes<\/li>\n<\/ul>\n<p>I would call this bad barcode label practices, and advise that it should be avoided wherever possible.<\/p>\n<p>There&#8217;s a very simple reason for this: the 3am reason.<\/p>\n<p>Put yourself in this scenario: at 3am you get an automated notification that \u2013 due to some backup blow-out, or operators not loading tapes (it really doesn&#8217;t matter) \u2013 the system has run out of backup media. All B* volumes in the library are full.<\/p>\n<p>On the other hand, there&#8217;s a bunch of C* volumes in the library that are sitting there empty \u2013 tantalisingly empty, in fact.<\/p>\n<p>There&#8217;s two options \u2013 get up, get suitably clothed for the trip into work, drive\/train\/whatever into work to load tapes yourself, or relabel some of those empty C* volumes to be in the appropriate <em>Backup<\/em> rather than <em>Backup Clone<\/em> pool.<\/p>\n<p>Unless there&#8217;s severe punishments for doing so, I&#8217;m betting 99.999% of backup administrators will choose the latter, not the former option. After all, it&#8217;s the difference between being able to go back to sleep within 10 minutes or maybe not at all.<\/p>\n<p>However, this decision will then cascade through to having other repercussions. One of the following factors will likely come into play:<\/p>\n<ul>\n<li>If operators beat you in the next day, they&#8217;ll possibly ship <em>backup<\/em> as well as <em>clone<\/em> media off-site, by virtue of the volumes all starting with C*. (Even if you send them an email, they may do the tape shipping before they get to the email.)<\/li>\n<li>If you choose to manually separate out the backup and the clone media, and keep the appropriate backup media in the library even though the barcode designates that it should be clone, you&#8217;ll create an ongoing management overhead that just asks for trouble and headaches.<\/li>\n<li>If you choose to manually stage the backup data on the C* volumes to freshly loaded B* volumes, you&#8217;ve just added a bunch of work to your (likely already busy) schedule.<\/li>\n<\/ul>\n<p>None of these scenarios &#8220;work&#8221; from a business perspective \u2013 they&#8217;re not suitable use of your time, either personally or for the business either.<\/p>\n<p>There&#8217;s a solution to this: <em>stop treating the barcode as a definition of the data<\/em>.<\/p>\n<p>Using different barcodes for different categories is also the start of a slippery slope. Temptation can then start to have each pool represented by its own set of barcodes, or a global prefix for the company, etc. Pretty soon you can be left in a state where anyone with suitable familiarity with your IT can make a reasonable stab at knowing what sort of backup may be on any individual tape. I&#8217;ve seen this happen in many sites.<\/p>\n<p>Security through obfuscation is usually never enough by itself, but it&#8217;s always a good starting point.<\/p>\n<p>So there&#8217;s four key reasons why I would go so far as to say that barcode categories are <em>bad design<\/em>:<\/p>\n<ol>\n<li>They create issues when you run out of media with one type of barcode, but you have spare media using another type of barcode.<\/li>\n<li>They encourage you to think of the barcode as defining content on the tape. You should be relying on the media database for that.<\/li>\n<li>It decreases the security of the backup media by allowing someone to make fewer guesses to determine what might be on which tape.<\/li>\n<li>Sooner or later some event will break the &#8220;rule&#8221;, and then you&#8217;ll be stuck with operational practices that no longer align with reality.<\/li>\n<\/ol>\n<p>If you&#8217;re currently using barcode categories, I&#8217;d invite you to step back and consider how you could use the media database to avoid the necessity. If you&#8217;ve got pressure to <em>use<\/em> barcode categories, I&#8217;d suggest you strongly argue against it using the above four issues.<\/p>\n<p>Ultimately, barcodes should exist for one reason \u2013 to allow a robot to readily move media from slots to drives, in and out of the library, etc. They&#8217;re not there to provide information to humans as to what is on the tape \u2013 and nor should they be munged to provide such information. That&#8217;s the job of the backup software \u2013 something NetWorker does quite well.<\/p>\n<p><strong><em>[Edit, 2010-03-25]<\/em><\/strong><\/p>\n<p>See Ted&#8217;s comment below about using barcode categories to differentiate per-product media in a shared (virtualised) tape library arrangement. When running with partitioned\/virtualised library environments with shared physical storage between multiple backup products, that&#8217;s of course a good reason to have some barcode level differentiation &#8211; so that upon import rules can be defined to allocate media to the appropriate backup product.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Some sites get quite particular about their volume barcodes when it comes to physical media. This means you&#8217;ll see barcodes&hellip;<\/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":[3,5,16],"tags":[158,202,581],"class_list":["post-2025","post","type-post","status-publish","format-standard","hentry","category-architecture","category-backup-theory","category-networker","tag-barcodes","tag-categories","tag-media-database"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-wF","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/2025","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=2025"}],"version-history":[{"count":1,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/2025\/revisions"}],"predecessor-version":[{"id":7566,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/2025\/revisions\/7566"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=2025"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=2025"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=2025"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}