NetWorker: How to Configure Data Domain Snapshots

Summary

NetWorker using Data Domain for its storage is a time-tested solution which provides a maximum of speed, storage efficiency, and protection. One feature which Administrators may choose to implement is snapshot technology. Snapshots effectively provide a protected secondary copy of all files in a mtree so that Administrators have a backup in the event of unwanted deletion of data. As an example, an accidental relabel of a valid NetWorker Data Domain volume immediately removes all save set files on that volume. From a snapshot, the Administrator can safely recover the data without a full file system rollback.

Responsibilities 

NetWorker software does not have any access or visibility to snapshots - they are entirely configured and managed on the Data Domain. The following details concern how to set this up, and how it can be useful to recover from data loss scenarios, as well as its impacts on Data Domain capacity and cleaning.

Impacts

• Snapshots consume negligible amounts of space, but while they exist, they prevent space reclamation for production data which have been deleted normally.
•  This guarantees that at least some data naturally expired and deleted by NetWorker will persist beyond at least one garbage collection. For example, a snapshot with a retention of a single day causes the data deleted on the final day before garbage collection to persist (in the snapshot) beyond that cleaning cycle.
• mtree replication replicates snapshots as well. Because the replica or destination may also be configured for snapshots, replicas use a prefix of REPL-MTREE.
• Some processes such as mtree replication may lead to soft locks on the snapshot, preventing deletion during garbage collection. Snapshots must be considered when investigating space issues, and considered generally during sizing.

Considerations

• Because snapshots are mtree based, organize NetWorker volumes in separate mtrees if volumes require different snapshot policies. For example, one mtree may have no snapshots, as it is considered noncritical, and accidental deletion is not considered catastrophic. A second mtree might be considered critical, and the extra protection snapshots provide being worth the overhead.
• Snapshot retention will prolong the normal duration data consumes space - even after its standard copy is expired, deleted, and cleaned up. Retention considerations should involve the determination of how many days the protection of a snapshot are required. For example, the default 14-day snapshot retention delays the reclamation of the data by two cleaning cycles. Shorter retention periods, such as 3 days, may provide enough protection to recover from unexpected deletion issues on a Friday undetected until Monday, and will delay space reclamation for the last three days of backups by one cleaning cycle.
• Individual files may be recovered, but not deleted from each snapshot subfolder. Snapshots may be expired manually in order to reclaim space at need, but only for the entire snapshot. This effectively means at the snapshot level - all data in the mtree expires together for space reclaim purposes. For this reason, having each mtree have its saveset data with similar NetWorker retentions would be useful.

Configuration

•  After consideration of all the above, to create a snapshot schedule named Daily-0800 on a mtree named networker, at 08:00 AM, to be retained 7 days, which creates snapshots named for the year-month-day they are taken:

snapshot schedule create Daily-0800 mtrees /data/col1/networker time 08:00 retention 7days snap-name-pattern Daily-0800-2026-05-23

• To list all snapshots:

snapshot list mtree *

• To manually expire snapshot 'Daily-0800_2026-05-23', so that garbage collection removes it:

snapshot expire Daily-0800_2026-05-23 mtree /data/col1/networker

• To recover volume path 'volume1' from the snapshot Daily-0800_2026-05-23, first create a recovery mtree, and then fastcopy the data there:

mtree create /data/col1/networker-recovery

filesys fastcopy source /data/col1/networker/.snapshot/Daily-0800_2026-05-23/volume1 destination /data/col1/networker-recovery/volume1

• At this point, you can create a NetWorker device for the new mtree/path and recover from there. Conversely, you can fastcopy to the original location, although this is discouraged as incorrect commands could lead to overwritten data.

For more information, see Knowledge Article Data Domain: How to Use Snapshots to Prevent Data Deletion