Can anyone help me explain this? I keep finding backup jobs where the "backup size" is larger than the "data size" (see highlighted numbers at bottom).
I found this thread indicating it could be a cluster size issue. It's hard to imagine because the size difference seems pretty extreme. But the repository is a Data Domain so I wouldn't be surprised at the weirdness. vmware-vsphere-f24/backup-size-larger-t ... 83945.html
Is this a forever incremental backup chain? Do you have scheduled regular full backups?
In case it's a forever incremental backup chain, the Full Backup File won't get smaller. It may have blocks stored inside that file which already doesn't exist anymore. Maybe you had once connected some huge disks to it?
Ok that was simple, thanks. They are forever forward and needed compacted. That leads to a question, what is best practice for a dedup appliance like a Data Domain? Should I do periodic synthetic fulls, active fulls, or schedule a compact operation? Because as soon as I turned on the compact operation and ran the jobs again we lost about half of the DD's reduction. Is that just temporary or should I do fulls instead?
With a Data Domain (or any dedup appliance) you should be doing at least weekly synth fulls.
depending on the size of the VM's you could do an active full then on a monthly basis.
Mark is correct.
Please schedule weekly synthetic full backups if you use the Data Domain over DDBoost.
Because as soon as I turned on the compact operation and ran the jobs again we lost about half of the DD's reduction. Is that just temporary or should I do fulls instead?
DD reduction is calculated by pre-compression and post-compression size of your backups.
You had a file with a lot of zeroed data. 17 Terabyte. 17 Terabyte of empty blocks can be stored as a single block on the Data Domain. I assume your high reduction comes from that.
Now with the empty blocks gone from the backup file, the compression rate is a lot smaller.