{"id":9811,"date":"2020-12-07T05:28:10","date_gmt":"2020-12-06T19:28:10","guid":{"rendered":"https:\/\/nsrd.info\/blog\/?p=9811"},"modified":"2020-12-07T05:28:12","modified_gmt":"2020-12-06T19:28:12","slug":"networker-volume-move","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2020\/12\/07\/networker-volume-move\/","title":{"rendered":"NetWorker Volume Move"},"content":{"rendered":"\n

Introduced at the same time as NetWorker 19.4, the NetWorker Volume Move system allows you to migrate a backup volume from one NetWorker server to another.<\/p>\n\n\n\n

The focus for the v1 release is to allow volumes on Data Domains to be relocated from one server to another. Moving a volume is a somewhat complex task. A volume has some media details associated with it, and then it has a number of savesets on it. Each saveset though is associated with a client \u2013 savesets do not exist in a vacuum, after all.<\/p>\n\n\n\n

So how does the NetWorker volume move operation work? A little like this:<\/p>\n\n\n\n

\"\"
NetWorker Volume Move Sequence<\/em><\/strong><\/figcaption><\/figure>\n\n\n\n

You have two systems involved in the volume move operation: the source NetWorker server and the target NetWorker server. As you might imagine, you start at the source server by preparing and exporting the volume that you want to move. This creates a volume bootstrap<\/em> that the target NetWorker server can ingest (avoiding the need to scan the volume on the target). The volume bootstrap contains all the details required: client file indices, client RAP records, etc. Also involved, as you may imagine, is making the volume off-line and read-only on the source system.<\/p>\n\n\n\n

The target NetWorker server then gets involved, with an analysis of the bootstrap data (for example, to look for client ID clashes, etc.), and then an import from the bootstrap of all the good stuff: media database entries, client file indices, and the client resource configuration. (Note that policies\/workflows\/etc. don’t get moved \u2013 the client ends up on the target NetWorker server configured, but not a member of any group\/policy. You’ll have to do that part in your completion activities.)<\/p>\n\n\n\n

Then at the end, once you’re satisfied the volume move has completed successfully, there’s a little cleanup on both sides. (For example: you’d delete the media database entries for the volume on the source NetWorker server.)<\/p>\n\n\n\n

You can find the documentation and binaries for NetWorker Volume Move from the NetWorker product landing page, here<\/a><\/strong>. In terms of compatibility: while the target<\/em> NetWorker server needs to be 19.4 (or higher), the source NetWorker server can be 18.x onwards \u2013 so it’s not as if you have to start this process by ensuring both servers are running exactly the same version.<\/p>\n\n\n\n

It’s worth keeping in mind that the volume move<\/em> function enables a variety of operational options. Clearly the first scenario is literally to move a volume from one server to another, viz.:<\/p>\n\n\n\n

\"\"
Volume Move: Moving a volume from one NetWorker server to another<\/em><\/strong><\/figcaption><\/figure>\n\n\n\n

In the scenario above, you’ve got a NetWorker server A \u2013 but you move a volume such that one volume remains on server A, and the volume you moved ends up on another NetWorker host, server B.<\/p>\n\n\n\n

But if you can move volumes, including all the client details, you can achieve a whole lot more. In fact, there are three distinct additional scenarios this opens up to NetWorker administrators.<\/p>\n\n\n\n

\"\"
Volume Move: Server Migration<\/em><\/strong><\/figcaption><\/figure>\n\n\n\n

You can use the volume move function to achieve a NetWorker server migration. That is, move all<\/em> of the volumes from server A to a new NetWorker server, B. It’s not to say this is the only way you’d do a NetWorker server migration, but it is a new option that is potentially available to you.<\/p>\n\n\n\n

\"\"
Volume Move: Server Partitioning<\/em><\/strong><\/figcaption><\/figure>\n\n\n\n

You can also use the volume move function to split or partition a single NetWorker server into two more NetWorker servers. This could be useful in situations where you need to say, spin off a dedicated NetWorker server for a subset of the business that’s being sold, or where a new operational requirement has been introduced. You might even do it in a situation where you want to keep upgrading part of your NetWorker environment, but you have some older clients that can no longer be upgraded: rather than to hold the entire environment back, you could partition it.<\/p>\n\n\n\n

\"\"
Volume Move: Server Consolidation<\/em><\/strong><\/figcaption><\/figure>\n\n\n\n

Conversely, as shown in the above, you might end up in a situation where you have multiple NetWorker servers that you want to bring together \u2013 e.g., two operating entities within the company merge their backup resources, or you acquire another company also running NetWorker.<\/p>\n\n\n\n

The NetWorker volume move function adds a great set of options for operating on your NetWorker environment(s), and I’d encourage you to keep it in mind as a potential solution for any of the above situations. As always \u2013 make sure you read the documentation first!<\/p>\n","protected":false},"excerpt":{"rendered":"

Introduced at the same time as NetWorker 19.4, the NetWorker Volume Move system allows you to migrate a backup volume…<\/p>\n","protected":false},"author":1,"featured_media":9813,"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":[1181,16],"tags":[275,1249,1590,1591,1092],"class_list":["post-9811","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-data-domain-2","category-networker","tag-data-domain","tag-networker","tag-server-migration","tag-server-split","tag-volume"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2020\/12\/bigStock-Movers.jpg","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-2yf","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/9811","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=9811"}],"version-history":[{"count":5,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/9811\/revisions"}],"predecessor-version":[{"id":9822,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/9811\/revisions\/9822"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media\/9813"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=9811"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=9811"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=9811"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}