11-16-2009 10:10 PM
11-16-2009 10:22 PM
11-17-2009 02:24 AM
11-17-2009 03:50 AM
11-17-2009 04:32 AM
The baseline is only used once by the first synthetic - subsequent synthetics must have access to the last syntehtic and cannot use the baseline - the normal configuration is do all Baseline , Synthetic and Incremental backups to disk locations and then add a duplication template for the synthetic to write that data to tape. It is possible to do synthetics to tape - but you will need multiple tape devices so it gets a bit more complicated.
The 2 options you discuss are not correct the options actually are
1) Write full synthetic (on whatever frequency you like) - if you want a daily single tape for restore then this will have to be every night, however, how many companies keep their daily backups for extended periods - usually weekly and montly backups are kept which would be when you run your synthetic
2) Keep incrementals since last synthetic and last synthetic available (forget about the baseline as this is ONLY needed until the first synthetic is run as each synthetic becomes the beginning of the next synthetic. Note: If you need to restore from prior to last synthetic then yes you will need earlier data sets but as per point one most companies keep the weekly or monthly sets to cover this instead of keeping all the dailies.
Also the benefits of synthetic are strongly environmental - in some environments your backup window might end up needing to be longer so there will be no benefit - in others it shortens it considerably as such always recommend doing some tests against you backup windows for synthetic vs traditional options. (Full, Incremental/Differentail etc)
11-17-2009 06:13 PM
11-18-2009 04:11 AM
If you put any part of the previous required backups on a tape then that tape must be accessible at the same time as another tape to write to.
Because you can only have one synthetic template and that template therefore can only be sent to one target device - you have a choice between writing all synthetic jobs to a B2D - or writing all synthetioc jobs to a library with more than one drive in it.
Best suggestion is
Write the basline and the synthetics into one B2D folder (and using 1 media set)
Write the Incrementals into another B2D folder (can be sthe same media set or a different one)
Make the Overwrite protection settings on the media set used by the baseline and synthetics backups such that The baseline and synthetic backups cannot be overwritten by the next synthetic (and cannot be appended to), but can ONLY be overwritten by the synthetic after. This will result in the equivalent of 2 full backups being stored on your disk with the earliest of the two being overwritten. There is no way to get round the 2 fulls's requirement as you always have to have the previous full (which is either a baseline or a synthetic) to base the next synthetic on - so at the end of the next synthetic this will always leave you with 2 present,. BTW a duplicate job does not maintain the indexing requirements needed to run a Synthetic job based on the data in the duplicate - as such you cannot use a duplicate job as part of the sequence - it can only be used as a method of writing the same data to a different media.
The suggestion that says you can run another base line if you want, just means that you end up running a full backup to replace a synthetic backup and apart from affecting your backup window is not going to change the basic way that synthetic backups work, It just puts you back to step 1 in my original order of how the process works. So yes the syhthetic prcoess does not care whether it is a NEW baseline or a the LAST synthetic in order to run. I agree you could set this to overwrite a previous synthetic - but this would be a useless idea as you might as well just run a standard full and incremental setup and not run synthetics at all if you are going to run a Baseline every week.
Oh and I have tested synthetic backups and found that in my environment the indexing makes the incremental jobs actually take longer than a full - so no I don't run it myself any longer and hence my comments that the process is heaviliy linked to the environent being backed up and should be tested before a decision about a final solution is made.
11-18-2009 09:09 PM
11-19-2009 01:37 AM