10-30-2014 07:17 AM
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.
Solved! Go to Solution.
11-13-2014 01:56 AM
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.
10-30-2014 07:25 AM
...have you tried to recreate the job?
Thanks!
10-30-2014 08:02 AM
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.
11-02-2014 12:37 AM
***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.
11-02-2014 01:06 AM
11-02-2014 01:10 AM
@pkh
AOF was already on.
11-02-2014 07:22 PM
Was this backup also successful if you ran it manually ? Is the manual backup of the server ALWAYS successful when the scheduled backup fails ?
11-02-2014 07:59 PM
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.
11-02-2014 11:57 PM
@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.
11-03-2014 02:05 AM
Have you tried to split this backup job ? One job with AOFO on for file data and the other job without AOFO for SQL ?
11-03-2014 03:07 AM
11-04-2014 11:48 PM
***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.
11-10-2014 12:15 AM
***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.
11-10-2014 12:57 AM
Would recommend to either log a formal support case or enable debugging via SGmon to figure out why the scheduled backup is failing.
11-10-2014 01:33 AM
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.
11-10-2014 02:07 AM
@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.
11-10-2014 02:19 AM
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.
11-13-2014 01:56 AM
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.
11-14-2014 01:29 AM
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.