we are trying to get the Networker Backup for a comparably large Windows Server 2012 VM working but it always fails after roughly two days because it took roughly two days, at least that is what I am getting from the logs:
94694:save: The backup of save set 'K:\' succeeded.
138851:save: 'winhost.bla.local:WINDOWS ROLES AND FEATURES:\' is being reset/promoted to level 'Full' as no backup is found.
174908:save: Saving the backup data in the pool 'cfd09bck_all'.
175297:save: Unable to set up the direct save with server 'nwserver.bla.local': Automatically cancelling the save request. 'save' was unable to start the active session in 170971 seconds. The elapsed time is over a day. This may be due to the date/time being set incorrectly on the client..
90095:save: Cannot open save session with 'nwserver.bla.local': Automatically cancelling the save request. 'save' was unable to start the active session in 170971 seconds. The elapsed time is over a day. This may be due to the date/time being set incorrectly on the client.
90123:save: VSS save walkers: the backup of save set 'WINDOWS ROLES AND FEATURES:\' failed.
Backup is done via the Networker Windows Client to a DataDomain.
Question: Is it possible to disable the check for time consistency for one specific client/policy/workflow so we can get our initial backup done? What is BCP for a backup job that takes more than one day?
There are a couple of common things that could cause this error. The most likely one for you is the second one.
1. The client and server times are not synchronized. Please verify that they are exactly the same. It is recommended to configure NTP server on client and NetWorker server to match the time.
2. The other thing that could cause this is a Microsoft issue where they want your Disaster Recovery to complete within 24 hours of the start of your backup (The time on your error log is seconds = hours). The way to work around this is to create a separate save set for Disaster Recovery so it will run independent of your main save set.
Check both of these things; let me know the outcome and we will go from there.
NTP is working fine on both Ends, so that can be ruled out in this case. Would you mind elaborating on your second point? I would be especially curious about how this would be a Microsoft issue and what the BCP for a case, where your save set for DR simply takes more than a day for the Initial backup, would be.
Thanks for taking the time answering here
Since the "DISASTER_RECOVERY" is just sitting in waiting to run for more that 24hrs it is doing this.
What I am trying to understand is sine you are using DD as the back end device, even though the first backups fail for :WINDOWS ROLES AND FEATURES:\ it should complete much faster in the second attempt as the dedup would kick in. Can you check if client direct is working for the new machine that you are trying to backup. Also, try increasing your client parallelism to a number equal to the number of partitions on this systems and see if that helps.
I could be wrong about this being a Microsoft requirement, it could be in the NetWorker code as 24 hours is a long timeout, and if a mmd process is not being assigned in that time then it figures something is wrong and the backup is not completing correctly so it terminates it.
So I would run the DR backup separate for the first run and if subsequent runs get failed for the same reason I would do the following KBA, of course set it to the length of time that it takes for the backup to complete.
You can adjust this setting by following the below KBA:
If your backup server is Windows, to achieve the same thing, just:create an environment variable on the NetWorker server:
1. Windows Key > Right-click on This PC and select Properties
2. Click on Advanced system settings on the left
3. Select Environment Variables
Hi crazyrov and Julian,
going the route of skipping the DR backup for the first run and about 27 hours in so far. Gonna report back when it is done which should be tomorrow.
Thanks again for your help
Skipping the windows DR part let the backup complete without errors. Since this is an acceptable solution for us there is no need to dig any further right now. Thank you for pointing me in the right direction.
That's great, if you don;t mind please mark this answered.
I would also still do DR backups just separately.
Have a great day.
Good Morning I'm with the same error as you my schedule is right with NTP information Could you please explain to me how you solved this problem? Thank you