Forum Discussion

ComdaIT's avatar
ComdaIT
Level 3
10 years ago

V-79-57344-34108 - An unexpected error occurred when cleaning up snapshot volumes. Confirm that all snapped volumes are correctly resynchronized with the original volumes. *********** is a corrupt file. This file cannot verify.

Hi,

We use BackupExec 2012 SP4 to backup (with an agent installed) a 2008 r2 server that holds among other things a small sql (CCSSQL). 

The schedualed backup of the server usually fails with the response code: V-79-57344-34108, An unexpected error occurred when cleaning up snapshot volumes. Confirm that all snapped volumes are correctly resynchronized with the original volumes. 

But, whenever I choose to manually backup it, by clicking on 'Run next backup now', the job is always succesful. 

The job fails because it cannot verify a couple of files, but I have to backup them, they seem to be important. 

i've already tried all the the KB regarding code V-79-57344-34108 and non of them seem to apply to my problem.

Did any one encounter such a mystery? 

Many Thanks,

Nadav.

 

 

2012
Agents
Backing Up
Backup and Recovery
Backup Exec
Windows Server (2003-2008)
  • ComdaIT's avatar
    ComdaIT
    10 years ago

    Hi all,

    @maurijo : by "worse" I meant it didn't backup at all.

    eventually as I stated earlier, I did follow the advices here and splitted up the jobs to SQL only and Non-SQL jobs. Although it kept on failing, I decided to change the schedualed time of the non SQL files.

    Thus, the only sql job is set to run at 01:15 and with enough space in between the non sql job is set to 05:30. 

    For the past 2 days the 2 jobs were succesful with out my interference. 

    Thank you all for your suggestions. 

18 Replies

Sort By
Show More
  • ComdaIT's avatar
    ComdaIT
    Level 3
    10 years ago

    ***update*** 

    I've splited the job as @VJware suggested. 

    yesterday evening the job ran as schedualed: 

    1. the sub-job Only SQL was succesful

    2. the sub-job with only system state and drive C failed.

    i'll restart the server today maybe it will help for tonight's scheduale. 

     

  • ComdaIT's avatar
    ComdaIT
    Level 3
    10 years ago

    ***update***

    as explained earlier, i've splitted the job in to two sub-jobs. 

    the only sql job succeeds exvery evening, while the other one (file system) fails everytime. 

    I've change the AOFO from automaticaly to Microsoft Shadow Copy, since that is the only provider listed in "vssadmin lsit providers", but still with out any change. 

    the backup server claims some file are missing, but they're not.

  • VJware's avatar
    VJware
    Level 6
    10 years ago

    Would recommend to either log a formal support case or enable debugging via SGmon to figure out why the scheduled backup is failing.

  • maurijo's avatar
    maurijo
    Level 6
    10 years ago

    Pkh said to enable shadow copies. Did you do this and verified if there is enough free space on the disks to actually store a shadow copy ?

    Your writers are not in failed state ? Can you see them changing states when you run a backup ? Using vssadmin list writers command in cmd.

  • ComdaIT's avatar
    ComdaIT
    Level 3
    10 years ago

    @maurijo 

    I did to that, and it didnt change anything. it even made things worse. so I've changed it back to it's defualt state: disabled. Their is plenty of space on the server. 

    all of the list writers are in stable mode with no errors. 

  • maurijo's avatar
    maurijo
    Level 6
    10 years ago

    What do you mean by "it made things worse" ?

    I would recommend to log a support case. Or maybe one last thing, check out what happens in SGmon while the backup runs. It could give you more info and you will probably need this log anyway.

  • ComdaIT's avatar
    ComdaIT
    Level 3
    10 years ago

    Hi all,

    @maurijo : by "worse" I meant it didn't backup at all.

    eventually as I stated earlier, I did follow the advices here and splitted up the jobs to SQL only and Non-SQL jobs. Although it kept on failing, I decided to change the schedualed time of the non SQL files.

    Thus, the only sql job is set to run at 01:15 and with enough space in between the non sql job is set to 05:30. 

    For the past 2 days the 2 jobs were succesful with out my interference. 

    Thank you all for your suggestions. 

  • maurijo's avatar
    maurijo
    Level 6
    10 years ago

    So when you split them up you set them on the same time...? Then its because of VSS that it fails. You cannot query the same server's VSS writers twice at the same time...

     

    When you have different jobs targeting the same server and using VSS then you should always leave enough time in between.