Comments
5 comments
-
The copy operations are currently queued only for transaction log backups. This was done to make log shipping more reliable.
You've made a good point re the need to also queue the copy operations of other types of backups. No, it isn't difficult to do, just that they felt it wasn't needed at this point.
Thanks. -
I agree with Dan. I'd love to let the copy to a newtork drive be queued so my backups complete first. To me having my initial backup is more important that having the backup copied out to my DR site. If 1 database gets hung up because my DR site is unavailable it will hold up all the other databases backups. I'd love to see this included or as an option for the user to decide if they want fulls and diffs queued as well.
-
Guys,
There seem to be two ways of looking at this:
1 - Backup my databases to local HDD then copy to LAN\WAN location
2 - Backup my databases to LAN\WAN location
in scenario 1, you have your backups done and the copy may or may not retry if the network is present.
in scenario 2, you are backing up databases to a network location, if the job encounters a network problem then moving to the next database will just find the same problem.
Possibly what you are suggesting is an option to flip from one option to the other if a network issue arises. I.E. backup to DR site but if the network drops backup locally?
Personally I have got around this with two jobs in version 5; 1 does the local backup on a given schedule and the other does the DR backup on another schedule. If either fail I know I have the other should I need to restore. -
Yes, there are certainly many ways to work around the issue, and if I had such a tight backup window as I described above, I would probably create a seperate job as well. One would just do local backups, and the other would do the copy. However, in the context of providing feedback for the network resiliency feature, it'd be nice to see a queuing option and be able to have the solution all bundled up.
-
It would be good to also see how well the job progressed before the network problems or better still until it gave up/ran out of re-tries.
If the job was to backup 5 databases to DR and it got 1,2+3 done, had problems in no4 but then gave up trying during the backup of no5 then this detail would only be found via the DR file share and checking each folder's contents. This may be in the SQL job output but getting it into the SQL Backup interface would be preferrable.
Jonathan
Add comment
Please sign in to leave a comment.
I like the resiliency, but I wish it had been built to queue up the failed network copy operation until after all of the backups have completed. From my testing, I've gathered that a single database will be worked on until it is done with everything, and then the next. In case of resiliency, and depending on what settings were chosen, that means the backup operation could sit for a very long time before finally failing and moving on to the next database. In many environments, there may be pretty tight time constraints on the backup window available. In those places, it is more important to get the local backup done as quickly as possible, and then focus on the network operations.
Of course, if the point is just to cover network blips, then the way it is will do great, but if there is potential for a destination share to not be available for an hour or two, then queueing the copy and allowing the backups to complete first becomes much more important.
Wow, that book :P being said, I also get that you are basically submitting a single backup command to SQL Server with all of the parameters packaged together, so breaking that apart might be a challenge.
Dan W