{"id":9232,"date":"2020-01-20T12:48:56","date_gmt":"2020-01-20T02:48:56","guid":{"rendered":"https:\/\/nsrd.info\/blog\/?p=9232"},"modified":"2020-01-20T12:49:02","modified_gmt":"2020-01-20T02:49:02","slug":"basics-networker-compressed-recoveries","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2020\/01\/20\/basics-networker-compressed-recoveries\/","title":{"rendered":"Basics \u2013\u00a0NetWorker Compressed Recoveries"},"content":{"rendered":"\n

While Data Domain compressed restores had been available in the NMDA and NMM modules for a while, NetWorker 19.1 introduced recovery compression for most other backups. (VMware virtual machine recoveries \u2013 i.e., via vProxy\/NVP, are a notable exception. But you can get even higher speed recoveries of these backups through instant access<\/em> and changed-block-tracking<\/em>.)<\/p>\n\n\n\n

I did a post some time ago showing the impacts of compressed recovery for an Oracle database using the NetWorker 18.1 NMDA plugin<\/strong><\/a>, but I wanted to show how it can make a speedup in other recoveries, too.<\/p>\n\n\n\n

The great thing about NetWorker\/Data Domain compressed recoveries is that they’re enabled by default<\/em>. It’s only if you want to disable<\/em> them that you have to take any action. (You create a file called disable_compressed_restore<\/em> in the \/nsr\/debug<\/em> directory \u2013 or appropriate equivalent directory on Windows.)<\/p>\n\n\n\n

So I figured I’d have a look at two different compressed recovery scenarios. The first instance was to recover a Synology NAS share in my lab that is about 99.9% populated with PDFs. As you’d know, PDFs don’t necessarily yield themselves to a lot of extra compression, so they’re a good “line in the sand”.<\/p>\n\n\n\n

Here’s the recovery:<\/p>\n\n\n\n

\"\"
NetWorker Restore of PDF-Populated NAS Share<\/figcaption><\/figure>\n\n\n\n

So that was the restore of the PDF populated NAS share, but how do I see what sort of compression I got during the restore? To do that, I had also logged onto the Data Domain system console to run the following command, starting it just before the recovery:<\/p>\n\n\n\n

sysadmin@neutronium# ddboost stats show interval 1<\/strong><\/pre>\n\n\n\n
That command gives me details of Data Domain boost connections running on the Data Domain, with details of the number of connections, size of data sent, etc. Here’s what I got for the duration of the recovery:<\/p>\n\n\n\n
\"\"
ddboost stats show interval 1 \u2013 Showing compressed recovery<\/figcaption><\/figure>\n\n\n\n
Well there’s definitely compression happening during the recovery, where possible. For instance, the highlighted line shows a recovery read<\/em> of 100MB\/s, but only 85MB\/s sent.<\/p>\n\n\n\n
But can we show better than that? Well, my lab only uses 0.5TB DDVEs, so it’s not as if I have huge chunks of data flowing to them, but it occurred to me to use my savekvm<\/a><\/strong><\/span>1<\/sup><\/a><\/span> script then subsequently test out recovery of a KVM virtual machine.<\/p>\n\n\n\n
So having done a backup of a CentOS 7 KVM virtual machine, I first checked the mminfo output:<\/p>\n\n\n\n
\"\"
mminfo output for savekvm backup<\/figcaption><\/figure>\n\n\n\n
So the virtual machine disks are about 5.5GB. The NetWorker recovery of just the disks themselves ran as follows:<\/p>\n\n\n\n
\"\"
NetWorker Recovery from savekvm Backup<\/figcaption><\/figure>\n\n\n\n
The Data Domain Boost stats though showed a substantial improvement in recovery performance as a result of automatic compression:<\/p>\n\n\n\n
\"\"
ddboost show stats interval 1 \u2013 During KVM Recovery<\/figcaption><\/figure>\n\n\n\n
Here we see a substantial improvement. At times the recovery process reduced the data that needed to be sent from the Data Domain by more than 12x, and overall the recovery sent 4.87x less<\/em> data as a result of compression.<\/p>\n\n\n\n
Where this is important is obvious: backup speed is important, but so too is recovery speed. If you need to recover a 2TB filesystem, would you rather stream 2TB across your network, or 410.68GB? (That’s using the 4.87x reduction result above.) Sure, on a 10Gbit network, in theory you can transmit 2TB of data in 26 minutes and 40 seconds, but 411GB would only take you 5 minutes and 28 seconds. Perhaps even more importantly, 411GB over a 1Gbit network will take you almost 55 minutes, but 2TB over a 1Gbit network is going to take you almost 4.5 hours.<\/p>\n\n\n\n
And the best thing about NetWorker\/Data Domain compressed recoveries is that they’re on by default so long as you’ve got NetWorker 19.1+ and DDOS 6.0.0.30 or higher.<\/p>\n","protected":false},"excerpt":{"rendered":"
While Data Domain compressed restores had been available in the NMDA and NMM modules for a while, NetWorker 19.1 introduced…<\/p>\n","protected":false},"author":1,"featured_media":9233,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_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},"jetpack_post_was_ever_published":false},"categories":[1181,16,19],"tags":[242,1215],"class_list":["post-9232","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-data-domain-2","category-networker","category-recovery","tag-compression","tag-restore"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t