2- From <http://nsrd.info/blog/tag/data-domain/>
NetWorker 8.0 software allows “Client direct” backups to Advanced File Type Devices (AFTDs) or Data Domain (DD) Boost backup devices. Previously, no client backups could be written directly to AFTD devices and only the NetWorker Backup Server, Storage Nodes and specific database backup Modules could write directly to DD Boost devices. The ability for client backup data to bypass the Storage Node and write directly over the IP network to Data Domain eliminates the Storage Node as a bottleneck during backups.
A major benefit of DD Boost devices is the use of NetWorker Clone Controlled Replication, allowing the creation of NetWorker Clone jobs to automatically replicate backups to a remote Data Domain. Because this process is initiated and managed by NetWorker, the backup application is fully aware of the replica backup copy which can easily be used to recover from. An additional benefit of NetWorker being aware of remote backup replicas is that Cloning to tape for long term retention can be done either at the source or target site.
Client direct is a (relatively) new feature, introduced in the 8.x series, (8.0 to be exact) which allows for a client to communicate directly with the backup device rather than going through a storage node.
This obviously requires the client to have access to the backup device, and only happens when you’re backing up to Data Domain Boost or an Advanced File Type Device (AFTD). (Direct access to tape drives – physical or virtual – comes in library or dynamic drive sharing.)
The real power of this feature happens when you’re using Data Domain within your environment though. When Data Domain Boost compatibility was first introduced in NetWorker, it was on the basis of a very traditional storage node model, i.e.:
As a starting point with Data Domain Boost, the NetWorker storage node software was updated to support deduplication offloading, referred to as “distributed segment processing”. That’s where the storage node communicated with the Data Domain and determined what client data it was receiving actually needed to be sent across to the Data Domain. (This came in for NetWorker 7.6 SP1, where support for Data Domain Boost devices was added.)
· By distributing the deduplication processing, higher ingest rates could be achieved. (Though it should be noted that Data Domain is no slouch when it comes to ingest speed. But next to recoverability, speed is always important in a backup and recovery environment.)
· Less data would be sent across the network; while the client data would sent to the storage node, the storage node would not have to send as much data across to the Data Domain. (Which, of course, also helps backup speeds.)
However, the Boost distributed segment processing functionality introduced into NetWorker Storage Nodes was just the beginning. When NetWorker 8.0 introduced the “Client Direct” feature, this was combined with pushing the Boost functionality for distributed segment processing out from the storage nodes to the clients. The net result was a substantial change:
· Best practice for AFTDs is to create one per pool on a storage node and not to place more than one on a file system. The AFTD should be the only thing on the file system.
· When savesets are staged off of the Data Domain system, space is not available for subsequent backups until the next time the cleaning process runs. Best practice is to run cleaning weekly.
· Note: Using Advanced File Type Devices is very different from using VTLs and requires an understanding of the benefits and limitations before deployment. Briefly, AFTD can simultaneously receive many save sessions. They can simultaneously handle many recover sessions. However, only one clone can be performed at a time, so ensure that a single stream can deliver the performance needed to clone data before growing an AFTD too large.
· In NAS environments, the NetWorker Advanced File Type Device accepts concurrent streams, writing them into separate files in the directory structure of the AFTD. This makes it possible for the deduplication intelligence to find and remove common data, thus achieving optimal deduplication performance.