I'm not sure how widely this command is used, but I thought I'd give it a try and see if the network resiliency would work here as well.
FIRST-
I set up a network share as the destination of one of the mirror files (which the GUI nicely warns is not recommended as soon as \\ is typed into the destination field) and disconnected my network cable before starting the backup.
The backup Service appears to not have used the resiliency logic at this point. Instead it waiting about 4 minutes and then gave the following warning 3 times:
6/18/2009 2:19:50 PM: Warning 200:
Warning 480: Failed to create output folder: \\server\is\DWolford\SQLBackups\Database\SQL2005\.
At that point, the backup job gave up on the Network MirrorFile location and proceeded with backing up to two local destinations.
I also had a COPYTO command on there with the network destination. That one definitely used the resiliency logic and attempted 3 times before giving up..
SECOND-
This time I ran the same Script, but did not unplug my network cable until 3 seconds after starting it.
This time, it appears the network resiliency worked great.
The job sat there during the retry attempts, and the backup continued on as soon as I plugged in the network cable again.
The following messages were logged for the MirrorFile:
6/18/2009 3:40:16 PM: Warning 210: Thread 1 warning:
WriteFile failed for file: \\Server\is\DWolford\SQLBackups\Database\SQL2005\DeviceMonitor_FULL_20090618_153710.sqb at position: 2098176
6/18/2009 3:37:31 PM WriteFile failed for file: \\server\is\DWolford\SQLBackups\Database\SQL2005\DeviceMonitor_FULL_20090618_153710.sqb (The specified network name is no longer available.
)
6/18/2009 3:37:31 PM CloseTargetFile.FlushFileBuffers error: The specified network name is no longer available.
6/18/2009 3:37:51 PM Re-attempt: 1
6/18/2009 3:37:57 PM ReopenTargetFile.CreateFile error: The network path was not found.
Eventually, I plugged the cable back in, and the job completed successfully.
I did notice that the logged warnings for the MirrorFile location were duplicated in every test I did, so there is a minor issue in the log reporting. (I'll e-mail a couple examples to
backup.prerelease@red-gate.com )
Overall, it worked great. Very nice.
Thanks,
Dan W
FIRST-
I set up a network share as the destination of one of the mirror files (which the GUI nicely warns is not recommended as soon as \\ is typed into the destination field) and disconnected my network cable before starting the backup.
The backup Service appears to not have used the resiliency logic at this point. Instead it waiting about 4 minutes and then gave the following warning 3 times:
6/18/2009 2:19:50 PM: Warning 200:
Warning 480: Failed to create output folder: \\server\is\DWolford\SQLBackups\Database\SQL2005\.
At that point, the backup job gave up on the Network MirrorFile location and proceeded with backing up to two local destinations.
I also had a COPYTO command on there with the network destination. That one definitely used the resiliency logic and attempted 3 times before giving up..
SECOND-
This time I ran the same Script, but did not unplug my network cable until 3 seconds after starting it.
This time, it appears the network resiliency worked great.
The job sat there during the retry attempts, and the backup continued on as soon as I plugged in the network cable again.
The following messages were logged for the MirrorFile:
6/18/2009 3:40:16 PM: Warning 210: Thread 1 warning:
WriteFile failed for file: \\Server\is\DWolford\SQLBackups\Database\SQL2005\DeviceMonitor_FULL_20090618_153710.sqb at position: 2098176
6/18/2009 3:37:31 PM WriteFile failed for file: \\server\is\DWolford\SQLBackups\Database\SQL2005\DeviceMonitor_FULL_20090618_153710.sqb (The specified network name is no longer available.
)
6/18/2009 3:37:31 PM CloseTargetFile.FlushFileBuffers error: The specified network name is no longer available.
6/18/2009 3:37:51 PM Re-attempt: 1
6/18/2009 3:37:57 PM ReopenTargetFile.CreateFile error: The network path was not found.
Eventually, I plugged the cable back in, and the job completed successfully.
I did notice that the logged warnings for the MirrorFile location were duplicated in every test I did, so there is a minor issue in the log reporting. (I'll e-mail a couple examples to backup.prerelease@red-gate.com )
Overall, it worked great. Very nice.
Thanks,
Dan W