Basics – NetWorker Compressed Recoveries

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 – i.e., via vProxy/NVP, are a notable exception. But you can get even higher speed recoveries of these backups through instant access and changed-block-tracking.)

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

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

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”.

Here’s the recovery:

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:

sysadmin@neutronium# ddboost stats show interval 1

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:

Well there’s definitely compression happening during the recovery, where possible. For instance, the highlighted line shows a recovery read of 100MB/s, but only 85MB/s sent.

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¹ script then subsequently test out recovery of a KVM virtual machine.

So having done a backup of a CentOS 7 KVM virtual machine, I first checked the mminfo output:

So the virtual machine disks are about 5.5GB. The NetWorker recovery of just the disks themselves ran as follows:

The Data Domain Boost stats though showed a substantial improvement in recovery performance as a result of automatic compression:

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 data as a result of compression.

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.

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.

1. This highlighted there’s a bug in my savekvm script which doesn’t work unless it’s invoked with a virtual cluster name, which I’ll need to fix.