cancel
Showing results for 
Search instead for 
Did you mean: 

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.

ComdaIT
Level 3

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.

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

ComdaIT
Level 3

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. 

View solution in original post

18 REPLIES 18

CraigV
Level 6
Partner    VIP    Accredited

...have you tried to recreate the job?

Thanks!

ComdaIT
Level 3

Hi @CraigV,

It's a freshly installed backup server, all of the job within it are also new and not imported from the old server. 

But I did as you suggested and i'm waiting for the scheduale to kick in, i'll keep you posted. 

Many thanks,

Nadav. 

 

 

ComdaIT
Level 3

***update***

The job ran as schedualed on Thursday, but again - if failed:

WARNING: "CCSRV\CCSSQL\CCSuiteDB" is a corrupt file. This file cannot verify.

WARNING: "CCSRV\CCSSQL\CCSWEB.ReportServices" is a corrupt file. This file cannot verify.

Any other suggestions? 

Thanks,

Nadav.

 

pkh
Moderator
Moderator
   VIP    Certified
Did you turn on AOF in your job? If not, do so

ComdaIT
Level 3

@pkh

AOF was already on.

VJware
Level 6
Employee Accredited Certified

Was this backup also successful if you ran it manually ?  Is the manual backup of the server ALWAYS successful when the scheduled backup fails ?

pkh
Moderator
Moderator
   VIP    Certified

Did you install an Agent for Applications and Database licence on the media server to backup the SQL on this server?  If not, then you should exclude the SQL directory from the backup.  Without an Agent for Applications and Database licence on the media server, you cannot backup SQL databases.  Backing up the .mdf and .ldf files would not work.

ComdaIT
Level 3

@VJware : the backup is always succesful when I choose manual backup: "Ran next backup now"

 

@pkh: my backup server includes the mentioned license. Other SQL servers are backing up with any problems. I don't want to exclude the mentioned files because their are a core part of the server, plus as said before when I ran it manualy the backup was succesful. 

 

Thanks,

Nadav. 

 

VJware
Level 6
Employee Accredited Certified

Have you tried to split this backup job ? One job with AOFO on for file data and the other job without AOFO for SQL ?

pkh
Moderator
Moderator
   VIP    Certified
If you have not enabled Shadow Copies in that machine, do so and remove any disk limit. If you don't know how to enable Shadow Copy, search the Microsoft site

ComdaIT
Level 3

***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
Level 3

***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
Level 6
Employee Accredited Certified

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

maurijo
Level 6
Partner Accredited

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
Level 3

@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
Level 6
Partner Accredited

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
Level 3

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. 

View solution in original post

maurijo
Level 6
Partner Accredited

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.