Background: We are taking weekly synthetic fulls (daily incrementals) and only writing the “last full of the month” to tapes.
Question: If we moved to *not* doing weekly syn fulls and chose something else like bi-monthly or 1 Syn full/month, all other things being the equal (like our retention and tape writing stays the same), are there any benefits to storage on disk or “possible issues to consider”?
Comments: I bet “restoring something is likely to take longer as it may have to reconcile many more incrementals” but I’m mostly hoping that less syn fulls - less data stored on local storage, but I’m not sure if this is true. I can’t think of any other possible issues other than if you have corrupt/bad incrementals (for whatever reason), that would be much more of an issue than always having a weekly full to compensate, if a restore was needed.
Best answer by Scott Moseman
#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.
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.
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.
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.
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.