I have a weekly full backup to disk and after that a duplication to tape. Last week the duplication to tape failed and I didn't care. This week the duplication fails with the error 0xe0009444 "Catalog query failed".
Looking at the job log I can see that the duplication want's to duplicate the whole selection twice. This is not possible because the last weeks backup set is already deleted. i think this is the issue described here http://www.symantec.com/business/support/index?page=content&id=TECH43264
In BE2010 it was possible to open the selection list of the duplicate job and delete the "<catalog not found> entries" manually. This is not possible anymore in BE2012 but the issue seems to be the same.
In my opinion the new "intelligent" media management should be intelligent enough to handle these problems but it seems it is not. What can I do now to get the duplication back running?
No, it is not. The setup is the following:
Full backup - Running every Saturday at 11:00 pm - to disk - kept for 1 Week
Differential - Running every Monday to Friday at 11:00 pm - to disk - kept for 1 Week
Weekly - Running every Sunday at 04:00 am - to tape - Source: Full Backup
Daily - Running every Tuesday to Saturday at 04:00 am - to tape - Source: Differential Backup
The weekly duplication is the one that fails because it want's to duplicate the backup set from a week ago which is not existing anymore.
I am backing up several servers to disk which are then duplicated to tape. I thought it would be best to have the backup job run first and then have all duplication jobs run later to minimize the interference between those jobs. Setting the duplication jobs to run right after the backup would mean that backup of some servers and duplication would run at the same.
Do you think that would be better?
If i understand correctly when the Sunday duplication runs it attempts to duplicate the previous weeks backup as well as the one that preceeded it "which has expired and been overwritten".
If this is the case under your source selection instead of Full under selected backups but most recent full backup should prevent BE from looking for the week prior.
If i have misunderstood the issue please clarify for me
@Donald: You are right. In this case the "most recent full" option would solve this problem. But today I'm running into the same with the differential backups.
Las week the daily duplication of the differental backups failed on some days. Today BE want's to duplicate these backup sets as well as the one from the backup to night. This is failing with the very same reason. The sets from last week don't exist anymore. And here is no option 'just all missing differential since the last full backup" or so and no way to clean up the selection list of the duplicate job.
@pkh: Yes and no. I admit running the duplicate right after the backup job can help solve the problem if it is only a timing issue. But if the duplication fails and the backup set on disk is cleaned up before you get it back running you always get the issue that there is something in the selection list of the duplication job that is not existing anymore.
And if you want to do two duplication jobs of one backup like I do (for internal and external storage) running the jobs right after each other isn't a usefull thing. Best here is to do it step by step (e.g 1:00 am backup, 10 am duplication 1, 4 pm duplication 2)
For the differential backups perhaps you should consider having them duplicate immediately after the the disk backup to remedy this issue. As far as interfering with other jobs that are dependent on the disk where the backups are being stored you can increase the number of concurrent write sessions allowed to run at a time to 2 or 3 to accommodate.
What you describe is a known issue with BE2012 SP1a+ that my site faces regularly.
We have been instructed by the Advanced (BackLine) team to use the workarounds described by pkh and Donald if they work.
When those work-arounds dont' work, then we have been instructed to re-create the backup (which removes all dependencies for the duplicates and starts over).
After recreating the backup, we then go in to our B2D storage and manually prune the backup sets that are no longer useful if they still hang after their expiration dates.
It certainly is NOT pretty at this point, but at least Symantec engineering has acknowledged that they are aware of the problem and are moving toward a solution in a future version...
PS - I WON'T change my duplicates to run immediately (I don't have the backup window time, nor do I have the money to purchase double the number of tape drives)...
I have faced similar situation in my environment.
My duplicate backup job to disk was successful...but it's duplicated to tape was failing sins past few weeks.
So, I found (Duplicate to tape) backup job failed due to it has executed before it sourced backup job (Duplicate to disk).
So its corresponding catalog information of the source media not found.
Then to resolve the issue, I select the option 'Duplicate data immediately after the source task completes' from backup job properties of (Duplicate to tape).
After above changes my (Duplicate to tape) backup job got executed immediately after completion of its source backup job (Duplicate to disk), and it has completed successfully without any error.