December 31, 2007 at 10:56 am
We recently started backing up a 40gb database to a network drive from SQL 2000. The "funny" thing about our problem is that it occurs every other time we do the backup. We receive operating system error 64 which indicates a possible network issue. So, 1 day the BU works and the next day it doesn't ; and so on and so on for several weeks. We have searched high and low for a resolution, cause, etc. Anyone out there have similar symptoms ? Any ideas ? We also suspect that perhaps this error is a "false" indication of another problem of some kind.
December 31, 2007 at 2:49 pm
When the backups do complete are they doing so in the time you'd expect? If you copy a large file from another workstation to the Windows 2003 server does it complete in the time you'd expect?
NIC drivers and switch settings are worth looking at. A duplex mismatch between the servers and the switches would cause slow performance and intermittent connectivity issues.
January 1, 2008 at 8:57 pm
The issue is that SQL backups are extremely intolerant of network delays. A file copy will retry itself, but because of the nature of getting the backups done quickly, it fails.
Back up locally and then copy remotely.
January 2, 2008 at 3:04 am
I have backed up across the network to make migration easier between versions - you just need to restore the backup on the new server and you're in business - but not with as much as 40 GB. I did make sure the servers were on the same switch and that the NICs and ports were correctly, manually, configured.
But you do say this happens every other time. Maybe there is a persistent file lock on the previous backup file (I doubt it), or maybe the time-out relates to the fact that there is an existing 'old' backup file. Is space tight on the target server? Is the backup job trying to delete, or to overwrite, or to append to the existing file - in other words, could the target server appear to be timing-out because it is busy with a file system operation? You could ensure that the existing backup file is renamed or deleted as a separate job before the backup starts.
January 3, 2008 at 10:35 am
We had it very often but now at rare moments. Suspects: some backup/replication software keeping the filesystem too busy causing a short network timeout.
Changes made from often to rare:
Updated windows 2003 to service pack 1 (fixing copying of large files)
Added more memory
Installed new hardwaredrivers (old ones had memory leaks).
Changed the timeframe of backupsoftware.
Previously we had to keep the networkspeed down to 100mb, now it is 1gb/s.
January 3, 2008 at 8:26 pm
Disk space might be an issue. Did you keep your backups for a certain period? If so, please check the disk space. The network drive needs to have at least 40 GB free space to complete your task.
January 8, 2008 at 6:13 am
Thanks to everyone for their comments on our issue ... This particular one seemed to be the solution, at least it seems to be. We noticed that when our BU canceled "every other time" that the destination server had deleted the day before's .BAK and created a new one. That + this response got us to thinking that maybe with everything else being executed on the destination server, that maybe it was taking too long to delete the previous day's BU before telling SQL on the source server that it was ready to start today's BU. So, we added a retry after 5 min to the SQL BU under the Advanced Tab of the Step properties box and we have not had a failure in 5 days now. Hope this solution may help others. The other important lesson we learned from this is that we have way too much going on at the same time on the destination server and we have designated a "traffic cop" to try to resolve some of the usage issues.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply