Forum Discussion

Chase_Drouillar's avatar
13 years ago

V-79-57344-33994 - The data being read from the media is inconsistent. BE2012

This is an error that I encountered every now and again in backup exec 2010, and, in that version, it was easy enough to fix. If the error showed up on a normal B2D job, then all I'd have to do would be to rerun that job, and it'd be fine. That still applies in 2012. However, the issue is that with the Duplicate jobs, this error was caused by corrupt or incomplete backups in the duplicate selection list (ones that showed up with a red X in a circle on their icons). In backup exec 2010, I could simply right-click the duplicate job that failed, click "edit selection list", and uncheck the corrupted selections. Of course, if I did not do this, the job would simply continue to try over and over again to duplicate those back selections, failing repeatedly. In backup exec 2012, the "Edit selection list" option does not exist, or at least not from the right-click menu. Because of this, when I get media inconsistent errors, I have no way to remove the corrupt backup from the to-be-duplicated list, which is a major problem.

Does anyone know of a way to view the backups that a duplicate job is preparing to duplicate and change them? If not, does anyone know a way to fix this problem in 2012?

  • There's no exclusion option specficially for the duplicate job. Also, from my understanding of it, the exclusion option bound to the entire job as a whole, via the selection list, only excludes files/directories. What I would need to exclude here would be a faulty B2D######## media, which I don't believe is possible.

  • To edit a selection list in Backup Exec 2012, you simply need to double-click the servername. This will open a page showing all the scheduled backups for that server.

    Then, just right click on the job or policy you with to review/modify and edit it.

    On the left-hand side you should see two buttons the left button allows you to modify the selection list.

     

    Regards,

     

  • That's the backup selection list, not the duplicate selection list. The list I'm talking about is the list of B2D Media (aka Backup Sets, Aka .bkf files) that a duplicate job has queued to duplicate the next time it runs.

    I even said that it was the list where you would find <Catalog Not Found> Errors back in 2010, to be perfectly clear as to what list I was referring to. I would certainly hope you wouldn't find <Catalog Not Found> errors in the backup selection list.

    EDIT: I actually didn't say that in this post, I said it in the idea post about this, whoops.

    Again, the list I'm talking about is this:

    When a duplicate job is coupled with normal full and incremental backups, the duplicate job must then duplicate said full and incremental backup media that is created from those full and incremental backup jobs. Once the jobs run, they are put into a list for the duplicate job to duplicate the next time it runs. This is the list that I would need to edit.

  • So there is no way to edit that list, then? The only way to get rid of this error is to completely delete the duplicate job and re-create it, thus losing the duplication of every single backup since the error occured? 

    If that's the case, doesn't that seem to be just a little bit problematic? There was a way, as I pointed out, to fix this issue with minimal data loss in Backup Exec 2010, why on earth would that method be removed?

  • We are still searching for an answer - please see my enhancement request on the community site: https://www-secure.symantec.com/connect/ideas/be-2012-enhancement-duplicate-recovery-chain-option

    This option would require that the duplicate process and their associated selections be enhanced to ensure a consistent recovery chain like with Full, Incremental, and Differential backups in BE2012.

     

    Workaround: In the meantime, we are manually monitoring the status of failed duplicates and re-scheduling a full backup to run on any server which experiences failed duplicates.  If we run another full, it seems to reset the ability of the next duplicate to run properly.

    We also do a manual duplicate to tape whenever we encounter these failures.

    Since implementing this strategy we have lowered the incidence of failed duplicates significantly (because we catch them on the first failure) and increased the number of B2D files that we have duplicated (because we are manually doing the duplicate).  This has come at the cost of much additional manual review and rerun time (on the order of 1-2 person-hours/day increase)...