NetWorker Blog

Commentary from a long term NetWorker consultant and Backup Theorist

  • This blog has moved!

    This blog has now moved to Please jump across to the new site for the latest articles (and all old archived articles).



  • Enterprise Systems Backup and Recovery

    If you find this blog interesting, and either have an interest in or work in data protection/backup and recovery environments, you should check out my book, Enterprise Systems Backup and Recovery: A Corporate Insurance Policy. Designed for system administrators and managers alike, it focuses on features, policies, procedures and the human element to ensuring that your company has a suitable and working backup system rather than just a bunch of copies made by unrelated software, hardware and processes.
  • This blog has moved!

    This blog has now moved to Please jump across to the new site for the latest articles (and all old archived articles).



  • Twitter

    Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Basics – Using datazone encryption with NetWorker

Posted by Preston on 2009-03-22

I’m not fond of software encryption (or compression, for that matter). Particularly in a 24×7 enterprise environment, clients (i.e., production servers) have better things to be doing than doing on-the-fly software encryption or compression. In these environments, hardware encryption routers should be the product of choice for achieving totally secure backups. Such devices also have advantages in terms of key management – much more flexible, scalable and appropriate for role based data access.

That being said, in smaller environments, or environments where servers are relatively idle overnight, NetWorker’s datazone encryption can be sufficient to achieve a reasonable modicum of backup protection with minimum effort – and most importantly, cost.

To get started using NetWorker datazone encryption, you first need to assign a pass phrase. This is done in the NetWorker server properties (typically accessed within NMC):

datazone-encryptionWith the pass phrase in place, you can then configure directives within NetWorker to make use of AES 256 bit encryption. However! As soon as you turn encryption on, you lose all potential for hardware based compression for your media. Why? Quite simply, compression is about finding patterns in data and reducing all the matching patterns to a single reference point; however, encryption is all about eliminating patterns, making the data appear completely random.

Thus, if you want to still get some measure of compression, you should, when using this method, employ software based compression in your directive as well.

Thus, a base directive might look like the following:

<< / >>
+compressasm: .
+aes: .

This will apply compression first to all files encountered, then once the file has been compressed, it will be encrypted. A side benefit of this is that by compressing first, you reduce the amount of data to be encrypted*.

So long as the datazone pass phrase is stored in the server, encryption will occur, and no password will be required to recover the data. Remember, this style of encryption, using a single pass-phrase, isn’t about being able to restrict whom within the datazone can recover the data, but instead it’s about keeping the data stored on-tape (which is potentially off-site, or otherwise at higher risk of theft), from being recovered.

[Edit, 2009-08-15]

It’s been pointed out to me that you can’t compress + encrypt at the client side. Indeed, I’ve now found the part in the administration guide that explicitly says this. What is extremely disappointing about this is that NetWorker actually doesn’t warn you that it’s not going to compress + encrypt! To me, that’s a security issue.

So, for the examples above, forget about enabling client side compression as well as encryption – you can have one or the other, but not both.

* In the same way that ice-cream that’s 99% fat free, but 87% sugar is a “benefit”.


4 Responses to “Basics – Using datazone encryption with NetWorker”

  1. Andy said

    I wonder if you could clarify something for me?

    When you say “As soon as you turn encryption on, you lose all potential for hardware based compression for your media” do you mean just adding the pass phrase will impact all clients or only those where the AES directive is in use?

    Let’s say I have a data zone on which I have been relying on hardware compression by default at the tape device level. I add a “remote” dedicated storage node (that writes to it’s own NAS device). I want that data to be encrypted in case that NAS device goes walk-about. If I configure the server with a pass phrase and I configure the new client for the storage node with the AES directive but I leave all my other clients as they were – no AES directive, will I lose the compression I was getting before the pass phrase was configured or will I only not get compression for the new storage node?

    I thought it was only the s/w compression that was not compatible with encryption. Won’t the compression that is done between device driver and device still take place?

    • Preston said

      Hi Andy,

      It’s when you start actually using the AES directive – not just when you add the pass-phrase. It affects all forms of compression, both software and hardware.

      Logically it’s quite simple – compression is about finding repeated patterns in the data and reducing them to a minimum number referencing the same ‘chunk’. Encryption on the other hand is about finding repeated patterns in the data and scrambling them.

      Therefore, if you compress first (via software compression), then encrypt, you at least get a smaller data stream that is being scrambled by the encryption algorithm. However, if you encrypt first, you’re left with a datastream which is almost entirely, if not completely random/scrambled, and has no patterns that are susceptible to compression.

      It’s not to say there’s a limited chance that a tiny amount of compression might still happen on an encrypted data stream, but I’d suggest it’s no more than something that you’d get on compressing an encoded video file or a (only mildly compressed) zip file – e.g., maybe 1%.

      With your example above, with having a datazone passphrase set, but only using the AES directive on a particular host, only that host would ‘lose’ data compressibility. Other hosts that are not being encrypted should continue to have their data compressed as per normal.



  2. Jens Rohde said

    Hi Preston,

    Do you know how EMC has implemented this encryption. Do the generate a shared key, that is downloaded to the client on first backup or do they (I hope not!) store the passphrase in one of the local ressource files on the client?


    PS: Thank’s for some good interesting reading :)

    • Preston said

      Hi Jens,

      (FYI, don’t forget that the article is incorrect in advising to use a combination of aes and compressasm in the directive – only one or the other can be used.)

      The datazone passphrase used for encryption is stored on the NetWorker server, encrypted, and to my knowledge is shared encrypted with the client – i.e., it’s neither stored unencrypted nor passed unencrypted between services.


Sorry, the comment form is closed at this time.

%d bloggers like this: