Between the Boost libraries included in NetWorker 8.2, and the in-flight encryption functionality added in Data Domain OS 5.5, it’s now possible to configure Boost-encrypted backups – and there’ll be quite a few sites with rigorous security requirements for which that’s a highly desirable function.
But it’s important to keep in mind that there are some architectural considerations to consider in this scenario, and the most important ones are about when the backup is encrypted.
Currently in NetWorker 8.2, there are no options for controlling the selection of in-flight encryption. This is done entirely at the Data Domain by configuring client groups. In essence, you can configure collections of clients at the Data Domain to either have encryption of either:
- none
- medium
- high
This is accomplished through using the command:
# ddboost clients add client-list [encryption-strength {medium|high}]
and:
# ddboost clients modify client-list [encryption-strength {none|medium|high}]
The astute reader will immediately identify the key restrictions this places: because all the control is being done from the Data Domain, it applies only to client backups that interface directly with the Data Domain.
For conventional backups, this means that Boost in-flight encryption will only apply to client-direct backups, i.e.:
In this scenario, with data flowing directly between the NetWorker client and the Data Domain server, in-flight encryption is available. However, when a storage node is inserted into the data flow, that changes:
In this scenario, the traffic sent between the client and the storage node does not utilise the Boost libraries, and thus flows unencrypted. The data is subsequently encrypted in transit between the storage node and the Data Domain, but by this point an organisation requiring in-flight encryption of backup traffic is already likely remiss in its obligations.
There are other scenarios where in-flight encryption is feasible:
- VBA with ‘hotadd’ transport mode – this connects the ESX datastores directly to the VBA appliance (or its proxies) for the purposes of backup, keeping the initial data traffic within primary storage. The traffic sent from the VBA appliance or proxies, utilising Boost, gets encrypted as required. However, those Data Domain ddboost commands for enabling encryption will apply to the VBA appliance and its proxies – not individual virtual machines. Thus, encryption will be for all virtual machines backed up by the appliances (or none), and nothing in-between.
- VADP on an 8.2 storage node using ‘SAN’, ‘hotadd’ or ‘NBDSSL’ transport modes:
- ‘SAN’ transport mode is for physical storage nodes where the ESX LUNs are fibre-channel connected to the storage node; thus, data transport to the VADP proxy will be over fibre-channel, and the IP traffic will be encrypted via Boost between the storage node and the Data Domain;
- ‘hotadd’ – same as VBA;
- ‘NBDSSL’ – in this mode, the data is sent from the ESX server to the VADP proxy via IP, but in encrypted traffic; Boost level encryption subsequently takes over for transmission from the VADP proxy to the Data Domain.
- An up-to-date Data Domain Boost plugin (e.g., Oracle RMAN Plugin for Data Domain) – though technically, this is fully outside of NetWorker.
Boost based in-flight encryption is a great addition in a NetWorker environment, but it’s important to keep in mind the restrictions regarding when it will apply.