{"id":9839,"date":"2020-12-18T09:48:37","date_gmt":"2020-12-17T23:48:37","guid":{"rendered":"https:\/\/nsrd.info\/blog\/?p=9839"},"modified":"2020-12-18T09:48:40","modified_gmt":"2020-12-17T23:48:40","slug":"basics-networker-aftd-on-nas","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2020\/12\/18\/basics-networker-aftd-on-nas\/","title":{"rendered":"Basics \u2013 NetWorker AFTD on NAS"},"content":{"rendered":"\n

Someone recently asked me about using NetWorker to backup to a NAS, and how easy it would be to then enable the NAS for client direct access. I kind of umm’d and ahh’d about it at the time because I recalled some very early<\/em> attempts to configure that when Client Direct just came out and I didn’t do such a successful job at configuring it.<\/p>\n\n\n\n

The universe likes to teach me lessons though, so due to some hardware changes in my lab I decided to completely rebuild my NetWorker server. It was also an opportunity for me to reconsider how I was presenting storage to the backup server. Now while I’d obviously like something along the lines of a DD3300 or DD6900 as my home lab backup storage, that’s not something I can arrange. So instead I use a few half-TB DDVEs for deduplication related tests, and NAS storage for the day to day bigger tests.<\/p>\n\n\n\n

So since I was going to rebuild the backup server, and in light of the recent question, I thought it was a perfect time to revisit NAS AFTD Client Direct. And I’m glad I did.<\/p>\n\n\n\n

\"\"<\/a>
Starting the New Device Wizard<\/strong><\/figcaption><\/figure>\n\n\n\n

You start, as always, by using the New Device Wizard.<\/p>\n\n\n\n

\"\"<\/a>
Selecting an Advanced File Type Device<\/strong><\/figcaption><\/figure>\n\n\n\n

Once the wizard starts, you choose an Advanced File Type Device (AFTD) and click Next<\/strong> to continue.<\/p>\n\n\n\n

\"\"<\/a>
Configured a NAS Target for AFTD<\/strong><\/figcaption><\/figure>\n\n\n\n

Here’s where it gets fun! In the past when I’ve used NAS as a target for AFTDs, I’ve gone through the process of configuring my \/etc\/fstab on the Linux server to automatically mount the NAS share(s), then I’d create the AFTD as a local device, pointing to the assigned OS mount-point.<\/p>\n\n\n\n

In this case, I used the NAS functionality to create the device, clicking the checkbox “[X] Device storage is remote from this Storage Node”<\/strong>. This prompts the NMC wizard to instead get you to enter the network path<\/em> for the share in the form of NAS_Server:\/path\/to\/access<\/em>, which for me was the NAS server chulak<\/em> with an access path of \/volume1\/Backup01<\/em>. <\/p>\n\n\n\n

Since you’re talking to a NAS server, you’ll likely need to provide authenticated access to it, which I did via the Username\/Password field.<\/p>\n\n\n\n

After that, it’s your standard disk-based device setup routine: you’ll be prompted to create a folder and select it as the device root, then label a volume for the device into an appropriate pool. I won’t bore you with those details. But below is an example of the created device:<\/p>\n\n\n\n

\"\"<\/a>
Device Properties for AFTD on NAS<\/strong><\/figcaption><\/figure>\n\n\n\n

As you can see, the device access information points to the NAS share, and folder I’ve created under it.<\/p>\n\n\n\n

With this configuration in place, I don’t have the NAS target present as an OS-visible mount-point. Though having created and labelled the device, I can see the files if I browse on the NAS itself:<\/p>\n\n\n\n

\"\"<\/a>
Browsing the NAS File Storage<\/strong><\/figcaption><\/figure>\n\n\n\n

So, what’s the advantage of this? Well, other than keeping the backup storage away from operating system mount-points (always a good thing from a cyber resilience perspective!), it also makes client direct a doddle. In particular, it means that clients that can also access the NAS share using the same connection details as provided in the device wizard won’t send their data through a storage node.<\/p>\n\n\n\n

If I’d persisted in mounting the NAS storage locally to the backup server and making a locally configured AFTD, the data\/communication paths would have looked like this:<\/p>\n\n\n\n

\"\"<\/a>
Data Transfer via NAS-based AFTD Mounted Direct on Backup Server<\/strong><\/figcaption><\/figure>\n\n\n\n

It works, but as you can see, the backup server or storage node becomes a nexus point for the data transfers \u2013\u00a0you’re doing the infamous 2-step transfer, adding performance boundaries on the overall configuration.<\/p>\n\n\n\n

In the new configuration I went with, I get all the benefits of Client Direct, which means a data path that looks like the following:<\/p>\n\n\n\n

\"\"<\/a>
Data Transfer via NAS-based AFTD Configured as a NAS Device<\/strong><\/figcaption><\/figure>\n\n\n\n

So, to answer the question someone asked me a couple of weeks ago, “How easy is it to configure Client Direct with NAS Devices?”, I’ll retract my “Umm, ahh” answer and replace it with “Very easy indeed!” And it’s a pertinent reminder to always be willing to review how you’ve got your environment configured in case there’s scope for optimisation.<\/p>\n","protected":false},"excerpt":{"rendered":"

Someone recently asked me about using NetWorker to backup to a NAS, and how easy it would be to then…<\/p>\n","protected":false},"author":1,"featured_media":9840,"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,6,16],"tags":[104,617],"class_list":["post-9839","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-architecture","category-basics","category-networker","tag-aftd","tag-nas"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2020\/12\/bigStock-Network-Transfers.jpg","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-2yH","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/9839","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=9839"}],"version-history":[{"count":5,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/9839\/revisions"}],"predecessor-version":[{"id":9854,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/9839\/revisions\/9854"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media\/9840"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=9839"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=9839"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=9839"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}