{"id":5075,"date":"2014-02-24T20:18:33","date_gmt":"2014-02-24T10:18:33","guid":{"rendered":"http:\/\/nsrd.info\/blog\/?p=5075"},"modified":"2014-02-24T20:18:33","modified_gmt":"2014-02-24T10:18:33","slug":"boost-daily-monthly-backups","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2014\/02\/24\/boost-daily-monthly-backups\/","title":{"rendered":"Data Domain Boost and Daily\/Monthly Backups"},"content":{"rendered":"

One question that comes up every now and then concerns having an optimal approach to Data Domain Boost devices in NetWorker when doing both daily and monthly backups.<\/p>\n

Under NetWorker 7.x and lower, when the disk backup architecture was considerably less capable (resulting in just one read nsrmmd and one write nsrmmd for each ADV_FILE or Data Domain device) it was invariably the case that you’d end up with quite a few devices, with typically no more than 4 as the target\/max sessions setting for each device.<\/p>\n

With NetWorker 8 having the capability of running multiple nsrmmds per device, the architectural reasons around splitting disk backup have diminished. For ADV_FILE devices, unless you’re using a\u00a0good<\/em> journaling filesystem that can recover quickly from a crash, you’re likely still going to need multiple filesystems to avoid the horror of a crash resulting in a 8+ hour filesystem check. (For example, on Linux I tend to use XFS as the filesystem for ADV_FILE devices for precisely this reason.)<\/p>\n

Data Domain is not the same as conventional ADV_FILE devices. Regardless of whether you allocate 1 or 20 devices in NetWorker from a Data Domain server, there’s no change in LUN mappings or background disk layouts. It’s all a single global storage pool. What I’m about to outline is what I’d call\u00a0an<\/em> optimal solution\u00a0for daily and monthly backups using boost. (As is always the case, you’ll find exceptions to every rule, and NetWorker lets you achieve the same result using a myriad of different techniques, so there are potentially other equally optimal<\/em>\u00a0solutions.)<\/p>\n

Pictorially, this will resemble the following:<\/p>\n

\"Optimal<\/a>
Optimal Dailies and Monthlies with Data Domain Boost<\/figcaption><\/figure>\n

The daily backups will be kept on disk for their entire lifetime, and the monthly backups will be kept on disk for a while, but cloned out to tape so that they can be removed from disk to preserve space over time.<\/p>\n

A common enough approach under NetWorker 7.6 and below was to have a bunch of devices defined at each site, half for daily backups and half for monthly backups,\u00a0before<\/em> any clone devices were factored into consideration.<\/p>\n

These days, between scheduled cloning policies and Data Domain boost, it can be a whole lot simpler.<\/p>\n

All the “Daily” groups and all the “Monthly” groups can write to the same backup device in each location. Standard group based cloning will be used to copy the backup data from one site to the other \u2013 NetWorker\/Boost controlled replication. (If you’re using NetWorker 8.1, you can even enable the option to have NetWorker trigger the cloning on a per\u00a0saveset<\/em> basis within the group, rather than waiting for each group to end before cloning is done.)<\/p>\n

If you only want the backups from the Monthly groups to stay on the disk devices for the same length of time as the Daily retention period, you’ve got a real winning situation \u2013 you can add an individual client to\u00a0both<\/em> the relevant Daily and<\/em> Monthly groups, with the client having the\u00a0daily<\/em> retention period assigned to it. If you want the backups from the Monthly groups to stay on disk, it’ll be best to keep two separate client definitions for each client \u2013 one with the daily retention period, and one with the\u00a0on-disk<\/em>\u00a0monthly retention period.<\/p>\n

Monthly backups would get cloned to tape using scheduled clone policies. For the backups that need to be transferred out to tape for longer-term retention, you make use of the option to set both\u00a0browse<\/em> and\u00a0retention<\/em> time for the cloned savesets. (You can obviously also make use of the\u00a0copies<\/em> option for scheduled cloning operations and generate two tape copies for when the disk copy expires.)<\/p>\n

In this scenario, the Monthly backups are written to disk with a shorter retention period, but cloned out to tape with the true long-term retention. This ensures that the disk backup capacity is managed automatically by NetWorker while long-term backups are stored for their required retention period.<\/p>\n

Back to the Data Domain configuration however, the overall disk backup configuration itself is quite straight forward: with multiple nsrmmd processes running per device, the same result is achieved with one Data Domain Boost device as would have been achieved with multiple Boost devices under 7.6.x and lower.<\/p>\n","protected":false},"excerpt":{"rendered":"

One question that comes up every now and then concerns having an optimal approach to Data Domain Boost devices in…<\/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":[3,5,16],"tags":[175,275,333],"class_list":["post-5075","post","type-post","status-publish","format-standard","hentry","category-architecture","category-backup-theory","category-networker","tag-boost","tag-data-domain","tag-disk-backup"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-1jR","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/5075","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=5075"}],"version-history":[{"count":8,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/5075\/revisions"}],"predecessor-version":[{"id":5084,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/5075\/revisions\/5084"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=5075"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=5075"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=5075"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}