Backup Exec 2014 Backup-to-Dedupe Duplicate-to-Tape

[sgoldman79]

Some other questions have touched on this topic but they all seem to be just a little different than my scenario. The issue I seem to be having is the following.

I have a single Windows Server 2008 R2 server with Backup Exec 2014. I am not using CASO with a MMS. I run incrementals throughout the week and then a full backup to our dedupe storage on a SAN. I then run a duplicate of the previous Full backup job (not using scheduled option for duplicate job) to duplicate to tape for off-site storage. The intention is to retain two weeks of data on-site and more off-site. However, I see instances where, if the duplicate to tape job failes, the previous Full backup is no longer on the dedupe storage. This means we have to do the entire full backup over again and then duplicate to tape.

In addition, this concerns me because I wonder if all the other jobs we write to tape in this manner are also getting removed from dedupe storage after the job either completes successfully or fails. It concerns me because we want to retain some of those on-site.

Is this by design? Is there a way around this?

[pkh]

The backup sets in your dedup folder is managed by DLM. See this blog and my article below https://www-secure.symantec.com/connect/blogs/data-lifecycle-management-be-2012 https://www-secure.symantec.com/connect/articles/when-backup-sets-are-deleted-under-dlm Whether the backup set is duplicated to tape or not does not matter, you need to set the retention period in your job appropriately. You can also right-click on the backup set and extend their retention period

[sgoldman79]

Thank you for your response. However, I already am using DLM as set by the retention policies I have on each backup job. I have a 2 week retention on our full backup-to-dedupe disk jobs. I have seen this just be ignored.

I believe there is a bug in BE 2014 and even a Hotfix that addresses it. This bug has to do with deleting expired jobs that still have dependencies but I'm wondering if it can effect non-expired jobs as well.

[LegAEI]

Are you using a linked duplicate job or a scheduled duplicate job?

Did you try running a sheduled duplicate instead of linked?

Are you verifying the backup before or after the duplicate (or during)?

Just some quick things that have tanked my backups in the past.

[sgoldman79]

I was told once by Symantec support that I should be running linked jobs when possible so these are ALL linked jobs, not scheduled.

I haven't tried to run them as scheduled due to the above stated reason.

I am verifying both the full dedupe backup and then the duplicate dedupt-to-tape jobs.

[LegAEI]

When you run verification jobs (or if) is entirely up to you. The linked verification process just makes it easier to schedule instead of having to calculate when to run it, you can break these operations out as separate jobs that are managed by the same job or create completely new jobs to run on schedules that you determine.

I know it sounds like a lot of work timing everything out with the backups, but its something you can do yourself to fine tune your backup window.

[pkh]

In this case, you should log a support case for Symantec to look at your problem.

[maurijo]

But that will not help his problem about the retention being ignored.

I would open a case with Symantec and ask the engineer the same questions...

[sgoldman79]

Thank you for your advice. I have opened a support case with Symantec.