Forum Discussion

Kevin_O_Connor's avatar
12 years ago
Solved

Remote Site backups with Encryption

Hi,

 

We have a requirement to backup a set of servers in remote sites and we've tested a backup solution outlined below which works pretty well but I know it'll only be a matter of time before someone asks about encryption.

  • Backing up to MSDP on the server locally and using SLP to replicate the images to a media server in our Datacentre.
  • The Master server is Windows 2008 as are the remote servers, all running 7.5.0.6. Flat file backups, no DB's.

 

So I'm right in saying, if we wanted to enable Encryption before the data was sent up to the DC

  1. We'd need to disable Accelerator and Client Side Dedupe.
  2. We'd need to rethink the MSDP and use Basic Disk.

In other words it would mean a complete redesign of the solution ?

Is there anything I'm missing ? We need to be able to backup these servers while reducing the amount of data transferred across the line because unfortunately the line used is sometimes only a 2MB line (currently works though).

 

Any suggestions welcome.

Thanks

Kevin

  • I think it is th eother way - once the storage server is setup then everything gets encrypted If you dont want one client to be encrypted then set its LOCAL_SETTINGS to 1 so that it does not have to obey the storage server and that client then has the choice of whether to use encryption or not

8 Replies

  • I will double check but i am pretty sure that MSDP uses its own internal encryption when sending data for deuplication / replication - which means when you do exactly what you do the data is actually encrypted during SLP duplication / AIR replication.

    This is inbuilt and not something you can configure yourself

    I will dig out the relevant part in the docs and post it up when i can

    Hope this helps

  • Here you go  - sure there is more somewhere but hopefully this is enough to make life easy for you - from the NBU De-Dupe Guide:

    About MSDP encryption
    NetBackup provides encryption for the deduplicated data. It is separate from and
    different than NetBackup policy-based encryption. By default, deduplication
    encryption is disabled.
    Symantec recommends that you use deduplication encryption.
    The following is the behavior for the encryption that occurs during the deduplication
    process:
    ■ If you enable encryption on a client that deduplicates its own data, the client
    encrypts the data before it sends it to the storage server. The data remains
    encrypted on the storage.
    Data also is transferred from the client over a Secure Sockets Layer to the server
    regardless of whether or not the data is encrypted. Therefore, data transfer from
    the clients that do not deduplicate their own data is also protected.
    ■ If you enable encryption on a load balancing server, the load balancing server
    encrypts the data. It remains encrypted on storage.
    ■ If you enable encryption on the storage server, the storage server encrypts the
    data. It remains encrypted on storage. If the data is already encrypted, the
    storage server does not encrypt it.
    Deduplication uses the Blowfish algorithm for encryption.
    Note: Do not enable encryption by selecting the Encryption setting on the Attributes
    tab of the Policy dialog box. If you do, NetBackup encrypts the data before it reaches
    the deduplication plug-in that deduplicates it. Consequently, deduplication rates
    are very low. Also, NetBackup does not use the Deduplication Multi-Threaded Agent
    if policy-based encryption is enabled.

    Then read the section entitled Enabling MSDP encryption

    You may need to check this all out in an AIR system but i am guessing that all de-dupe uses the same keys? (I will see what i can find out)

  • I still have the feeling that it does some level of encryption by default but cannot locate the docs now surprise

    I will keep digging but I think it all has a common key anyway so AIR should be OK.

    A test system would be ideal so that you can confirm it all first.

    If i stumble across what i am looking for i will post it for you

  • I've been reading up on it and it looks like it's disabled by default, I've never touched either of the two config files on the media/clients servers before and it hasn't been enabled there either.

     

    I'm a little confused though after reading the documents, there looks to be two methods  of enabling encryption, a catch all effect by changing a setting on the media server so any clients will be encrypted or on a per client basis.

     

    Two questions though.

    1. If we use the catch all method do we still have the same config control by changing the pd.conf file on the clients as well?
    2. As we're doing client side dedupe before backing up to the MSDP on a media server which method is the better option ?
  • I think the guide is a little confusing  (the 7.5 and 7.6guide) but it says:

    Ensure that the LOCAL_SETTINGS parameter is set to 1.
    If LOCAL_SETTINGS is 0 (zero) and the ENCRYPTION setting on the storage server
    is 0, the client setting does not override the server setting. Consequently, the
    data is not encrypted on the client host.

    Which means that the storage server must be enabled for encryption to allow a client to encrypt as the client will not override it - which when read the otherway around must mean that if the server does it you could deselect it on individual clients

    Does that make sense!!

  • Okay, my head's still going around in circles smiley

     

    So if I modify the pd.conf and contentrouter.cfg files on the media server it will process the encryption of any client it backs up but in turn the client needs the LOCAL_SETTINGS value set to 1 as well otherwise the client is excluded ?

  • I think it is th eother way - once the storage server is setup then everything gets encrypted If you dont want one client to be encrypted then set its LOCAL_SETTINGS to 1 so that it does not have to obey the storage server and that client then has the choice of whether to use encryption or not