Duplicate Backup set policies and schedules

[Steve_Taylor_3]

Not sure if this is possible, but here it goes:

I back up about 20 servers each weekend with full backups. I've tried using policies to create duplicate backup sets for offsite storage for DR purposes with the following results:

Policy templates I have many polices controlling agent usage, but this is a good example:

Full: every week
Diff: Daily
Offsite: Duplicate of Full

Policy attempt 1: Run duplicates according to policy rules
Rules: after Full completes, start Offsite to duplicate backup sets
Result: Works OK, but My duplicate backups start running as soon as the full completes, so my Full's end up getting queued waiting for devices to become available that are in use by the duplicates. Even worse, If a duplicate job grabs one of my 2 tape drives, it never gets the chance to complete because I get a full occupying the 2nd drive.
-----------------------------------------------------------------------------------------------
Policy attempt 2: Run duplicates according to schedule
Conceptually this works great, however our retention schedule ensures that I have a couple of weeks worth of data. This means that I may have 2 (or even 3) Full backup sets. Each time my duplicate jobs run, it backs up all 3 full backup sets. I only want the most recent backup set. There doesn't seem to be a policy rule that governs this.

As a result of these scheduling problems, our backups currently require significant manual intervention and this is no good. I'm about to submit a request to Symantec's tech support, but I'm sick of their hold music and was hoping I could get an answer quicker this way.

Thanks!

Steve

[perry_baker]

You do describe something that can be challenging...both options have drawbacks just as you described.

The first scenario you describe is typical; you will need enough devices available to accomplish the end goal, otherwise you end up with what you are encountering.

The second scenario can probably be adjusted to accomplish what you want. The way the duplicates decide what sets need to be duplicated is based on the backup job that is to be duplicated and how many times it has run since the last duplicate job completed successfully. Key word: successfully. So if a duplicate job runs but does not successfully complete a duplicate backup set then the backup set will stay in the list of backup sets that need to be duplicated. Only after the duplicate has completed successfully will it be removed from the list.

So if your duplicate is set to duplicate backup sets in a Full Backup and that Full Backup runs three times before the duplicate job runs, the duplicate job will want to 'duplicate' the backup sets in all three Full Backups.

If you schedule the duplicate job to run after the Full Backup but before the next Full Backup, then you should be able to achieve your goal. But remember the requirement that the duplicate job must be successful in order for that specific backup set to be removed from the list of backup sets to duplicate.