{"id":4602,"date":"2009-09-16T06:27:23","date_gmt":"2009-09-15T20:27:23","guid":{"rendered":"http:\/\/nsrd.wordpress.com\/?p=803"},"modified":"2018-12-12T15:40:39","modified_gmt":"2018-12-12T05:40:39","slug":"7-procedural-obliations","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2009\/09\/16\/7-procedural-obliations\/","title":{"rendered":"The 7 procedural obligations of backup administrators"},"content":{"rendered":"<p>A while ago, I ran a post titled <a title=\"Ethical obligations of backup administrators\" href=\"https:\/\/nsrd.info\/blog\/2009\/03\/19\/ethical-obligations-of-backup-administrators\/\" target=\"_blank\">Ethical Obligations of Backup Administrators<\/a>. Following up from that now I want to talk about the <em>procedural<\/em> obligations implicit to working in the role of being a backup administrator.<\/p>\n<p>Now, to start with, if you think that the primary procedural obligation of a backup administrator is to ensure that the backups work or run, then you need to think more about the <em>end<\/em> obligation than the <em>start<\/em> obligation. (This is a primary topic of consideration in <a title=\"Enterprise Systems Backup and Recovery: A Corporate Insurance Policy\" href=\"http:\/\/www.amazon.com\/gp\/redirect.html?ie=UTF8&amp;location=http%3A%2F%2Fwww.amazon.com%2FEnterprise-Systems-Backup-Recovery-Corporate%2Fdp%2F1420076396%3Fie%3DUTF8%26s%3Dbooks%26qid%3D1221104920%26sr%3D8-1&amp;tag=entesystbacka-20&amp;linkCode=ur2&amp;camp=1789&amp;creative=9325\" target=\"_blank\">my book<\/a>.)<\/p>\n<p>Before I set out the procedural obligations, I need to define <em>recoverable<\/em>. You may think this is a self-obvious definition \u2013 however, if it were, a lot of problems that regularly occur in backup systems wouldn&#8217;t happen at all. Thus, by <em>recoverable<\/em> I mean the following:<\/p>\n<ol>\n<li>The item that was backed up can be retrieved from the backup media.<\/li>\n<li>The item that is retrieved from the backup media is <em>usable<\/em> as a replacement to the data that was backed up.<\/li>\n<li>The item can be retrieved <em>within the required window<\/em>.<\/li>\n<\/ol>\n<p>A backup should not be deemed to be recoverable unless it meets all three of the above requirements. No ifs, no buts, no maybes. (Indeed, it&#8217;s worth noting that many &#8220;soft&#8221; recovery failures are caused by a failure to meet the third requirement \u2013 getting the data back <em>in time<\/em> is equally as important in mission critical systems as getting the data <em>back<\/em>.)<\/p>\n<p>Since most people work well with lists, I&#8217;ll define these procedural obligations as a list, ordered in priority starting at the highest:<\/p>\n<ol>\n<li><strong>To ensure that all required data is recoverable<\/strong>. By &#8220;data&#8221; I&#8217;m <em>not<\/em> just referring to raw data, but all items, files, information, databases, systems, etc., designated as requiring recovery.<\/li>\n<li><strong>To maintain a zero error policy<\/strong>. There is no such thing as 100% certainty, but the closest you can get to it is by maintaining a <a title=\"What is a zero error policy?\" href=\"https:\/\/nsrd.info\/blog\/2009\/08\/11\/what-is-a-zero-error-policy\/\" target=\"_blank\">zero error policy<\/a>. In essence, by maintaining a zero error policy, you become immediately aware of any issues that may compromise the above rule.<\/li>\n<li><strong>To maintain documentation for the environment<\/strong>. No system is complete without documentation. In particular, if someone with adequate skills cannot interact with it after reading the documentation, then the system is not documented and<em> is not a system<\/em>.<\/li>\n<li><strong>To maintain an issues register<\/strong>. This is somewhat implicit in the maintenance of a zero error policy, but it is worth remembering that not all issues in a backup system are to do with errors. Issues may be that department heads approve of, or insist on non-standard backups, or that a system went into production without adequate testing, etc.<\/li>\n<li><strong>To be across ongoing capacity management and forecasting requirements<\/strong>. A backup system can&#8217;t reliably work if it could halt due to capacity restraints at any random moment or minor data growth. Thus, the backup administrator must have a finger on the pulse of the capacity of the system.<\/li>\n<li><strong>To maintain reports<\/strong>. A backup system does not work in isolation, and thus a backup administrator must ensure that reports (both daily\/operational and long term\/management) are <em>accurate<\/em> and <em>timely<\/em>.<\/li>\n<li><strong>To document all data that is not required for recovery<\/strong>. There should be no &#8220;unknowns&#8221; in a backup <em>system<\/em>. Thus, any systems or data that are designated to <em>not<\/em> require recovery (e.g., QA systems) must be documented as such, and periodically rechecked to confirm this remains the case.<\/li>\n<\/ol>\n<p>As I said from the outset, many of these obligations are implicit to the role of being a backup administrator. However, for organisations wanting to formalise their processes and their role descriptions, thus achieving higher guarantees of reliability within their backup system, clearly documenting these obligations are vital.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>A while ago, I ran a post titled Ethical Obligations of Backup Administrators. Following up from that now I want&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":[5,10,16],"tags":[140,688,760,1112,1113],"class_list":["post-4602","post","type-post","status-publish","format-standard","hentry","category-backup-theory","category-ethics","category-networker","tag-backup-administrator","tag-obligations","tag-procedural","tag-work","tag-work-practices"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-1ce","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/4602","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=4602"}],"version-history":[{"count":1,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/4602\/revisions"}],"predecessor-version":[{"id":7614,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/4602\/revisions\/7614"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=4602"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=4602"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=4602"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}