The only reason to run a “weekly” Synth Full would be if you’re copying off to tape on a weekly basis.  If you’re only copying a monthly Full to tape, I would go with a “monthly” Synth Full.  In a dedupe world, you only have 1 cycle on disk anyways.  Running frequent Fulls/Synth Fulls is wasted cycles as they don’t really gain you anything other than bloating your DDBs.

For restores coming from disk, there’s NO penalty for using monthly Fulls instead of weekly.  Commvault will only grab the latest versions of files for the restore.  It doesn’t process ALL of the jobs and apply them in sequential order like a classic tape restore.

Thanks,
Scott
 

interesting… I have a few more questions if that’s ok:

for “In a dedupe world, you only have 1 cycle on disk anyways”: so this means essentially no disk space savings if the change is made (as long as we are using DDB’s, which we are), which sounds like ‘syn fulls’ are basically just.. err…. like special save points for internal referencing (like a checkpoint to go back to when doing restores?)?  I always thought of them as “another rolled up copy” = more space used up.

for: “other than bloating your DDBs”.  Any idea how to roughly guessestimate the bloat (or the savings if syn full methods were changed)? like ‘yeah if you do 1 syn full and have “X GB”, then if you do 4 syn fulls you likely have “X GB * 4” or something?  This is interesting to me as we have several DDB’s and some are very big (relative to our DDB drive size) and I need to seal all of them to free up some “referenced data” on a mount point. so if there were a way to shrink them first, before sealing that would be nice, to conserve DDB disk sealing overhead.

#1

Synth Fulls create a logical checkpoint of what a Full would look like at a given PIT.  This is useful for creating a “Full” copy for tape, or for closing a “cycle” for data aging purposes.  Note: The SF job itself does not protect anything since it’s purely a logical operation.  It’s the Incr job before and/or after the SF job which actually protects data.  (Or if you run a traditional Full job.)

Incr jobs = typically consume storage (new/unique data)
Full jobs = can consume some storage (the new/unique data)
Synth Full jobs = do not consume any new storage (purely logical) 

Incr jobs only update the DDB for the new unique blocks, so little DDB impact.
Full/Synth Full jobs update every block in the DDB, so a much larger DDB impact.

#2

I have no idea how to guesstime how much DDB space a Full/Synth Full job might create.

Thanks,
Scott
 

Thanks!