Snapshot Information for MTree: /data/col1/avamar-1477523534 mtree listĬhecking the smaller of the Mtrees shows what we expect to see snapshot list mtree /data/col1/avamar-1477523534 Use the mtree list command to show the Data Domain Mtree structure. These snapshots together were using around 16Tb of the available 67Tb of space on the Data Domain. When I checked out the snapshots on one of the Mtrees, I saw that there were 10 snapshots from almost a year ago. Had a customer who's replication Data Domain was significantly (20% more!) more utilized than the primary site, and also was completely full.
#Datadomain os 2017 free
Have a Data Domain that's full? Need to free up space so your backups continue to run? Check for old snapshots, expire them, then free up space with a file system cleaning. Now you can point your Veeam (or whatever) jobs to the new Data Domain with your historical data intact. Name Pre-Comp (GiB) Status User Report Physical Verify the storage unit with: ddboost storage-unit show Storage-unit "REPLICATED_MTREE" modified for user "ddboost". We see our replicated MTree directory REPLICATED_MTREE, and we'll now turn that into a DDBoost storage unit with: ddboost storage-unit modify REPLICATED_MTREE user ddboost RLGD : Retention-Lock Governance Disabled Data Domain won't let you create a new SU from the GUI from the replicated MTree so, you'll need to convert the replicated MTree to a DDBoost SU from the CLI: mtree list If you're migrating from one Data Domain to another and using a non-Avamar backup solution (Veeam, etc) and the built-in DD replication, you'll need to create a new storage unit post replication.