{"id":4672,"date":"2013-01-07T17:10:44","date_gmt":"2013-01-07T07:10:44","guid":{"rendered":"http:\/\/nsrd.info\/blog\/?p=4672"},"modified":"2018-12-11T14:28:33","modified_gmt":"2018-12-11T04:28:33","slug":"best-pool-content","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2013\/01\/07\/best-pool-content\/","title":{"rendered":"Best Practice \u2013\u00a0Pool content"},"content":{"rendered":"

\"Tape<\/a><\/p>\n

NB: Don’t forget to fill in the NetWorker Usage Survey<\/a>, if you haven’t already done so. It’s open until 31 January 2013.<\/p>\n

NetWorker has a bunch of predefined pools that come in the bootstrap configuration: Default, Default Clone, Offsite, Archive, etc. For the purposes of best practices, I’d suggest these pools should be used for reference purposes only: there are better and more logical ways to separate data than the predefined pools.<\/p>\n

Generally speaking, pools should separate data by common features, so as to make backup management more straight forward. For this reason, I recommend pool content breakdown by:<\/p>\n

    \n
  1. Backup frequency \/ retention<\/li>\n
  2. Intended location of media<\/li>\n
  3. Other logical breakdowns (only if required).<\/li>\n<\/ol>\n

    Using this layout, I typically end up with pools such as the following:<\/p>\n

      \n
    1. Daily Onsite<\/li>\n
    2. Daily Offsite<\/li>\n
    3. Monthly Onsite<\/li>\n
    4. Monthly Offsite<\/li>\n
    5. Yearly Onsite<\/li>\n
    6. Yearly Offsite<\/li>\n<\/ol>\n

      The “Daily”, “Monthly” and “Yearly” in the pool titles refer to the frequency<\/em> at which the backups going to those pools are performed. On that front, I try to align naming conventions to suit backup frequency. Therefore I’ll have “Daily X” schedules, a “Daily” policy, “Daily X” groups, and on on.<\/p>\n

      The “other logical breakdowns” refers to introducing additional separation points, if required<\/em>, that are consistent. For example, if dealing with a backup environment that features both encrypted-at-rest and unencrypted-at-rest data that is required to be stored on separate media, you might end up with say:<\/p>\n

        \n
      1. Daily Onsite Secure<\/li>\n
      2. Daily Offsite Secure<\/li>\n
      3. Daily Onsite Insecure<\/li>\n
      4. Daily Offsite Insecure<\/li>\n<\/ol>\n

        Alternatively, if it is necessary to send all Oracle data to one particular type of media, you might end up with:<\/p>\n

          \n
        1. Daily Onsite<\/li>\n
        2. Daily Onsite Oracle<\/li>\n
        3. Daily Offsite<\/li>\n
        4. Daily Office Oracle<\/li>\n<\/ol>\n

          The advantages of this style of pool layout are fairly obvious:<\/p>\n

            \n
          1. Data stored by the same backup frequency\/retention is likely to expire at a broadly similar time \u2013 if configured correctly it’ll avoid situations where you have media ready to recycle except<\/em> for one or two savesets that have vastly longer retention times;<\/li>\n
          2. Data that needs to be physically separated is<\/em>;<\/li>\n
          3. The layout still has flexibility in terms of additional layers of separation.<\/li>\n<\/ol>\n

            There are undoubtedly other ways of configuring pools within NetWorker for data separation, but in my opinion, this represents a best practice approach most likely to allow for a flexible, logical and functionally useful setup.<\/p>\n

            PS: Don’t forget to fill in the NetWorker Usage Survey<\/a>, if you haven’t already done so. It’s open until 31 January 2013.<\/p>\n","protected":false},"excerpt":{"rendered":"

            NB: Don’t forget to fill in the NetWorker Usage Survey, if you haven’t already done so. It’s open until 31 January…<\/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":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[1133],"tags":[1136,694,1135,750,1134],"class_list":["post-4672","post","type-post","status-publish","format-standard","hentry","category-best-practice","tag-data-separation","tag-offsite","tag-onsite","tag-pool","tag-pools"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-1dm","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/4672","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=4672"}],"version-history":[{"count":14,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/4672\/revisions"}],"predecessor-version":[{"id":7471,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/4672\/revisions\/7471"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=4672"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=4672"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=4672"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}