Hi,
I have been trying to set up log shipping on a database with a backup size of ~190MB. However, I have been getting two error messages as stated below during the initial backup of the DB before it is restored on the warm standby.
1st Error
-----
Windows was unable to save all of the data for the file \Device\LanmanRedirector\<<UNC Path>>. The data has been lost. This error may be caused by a failure of your computer hardware or network connection. Please try to save the file elsewhere.
2nd Error
----
Write on '<<UNC path>>' failed, status 64. See the Sql Server eror log for more details. BACKUP database is terminating abnormally.
Backing up the database out side of the logshipping set up runs fine if I use a mapped drive, but it fails again when I use a UNC path. All the permissions are correct (I have backed up a smaller DB to the UNC path which completes successfully) so I am a little stumped.
Any help would be greatly appreciated
Thanks
RichI think this is a caching issue - check to see if you have network redirector caching enabled. The following link shows you how to disable:
link (http://support.microsoft.com/default.aspx?scid=kb;en-us;Q163401)
The following is another link that might be helpful if the above information does not solve your problem:
link (http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q321733&)|||Thanks for coming back so quickly. I thought that the cache could be the problem but noticed from the link you sent that it was specific to NT. I forgot to mention in my initial post that I am running on Win 2k SP2 Adv. Server boxes. Could this still be a problem with the more recent OS?
The second link you mentioned relates to a very specific record in the event log. The error I am experiencing is almost identical to that mentioned in the KB article all exceppt for the final staus code. I do not have c0000022 in my event log. Am I correct in therefore assuming that the workaround will not make any difference.
I know this is just more questions, but I do not have access to the boxes for the next couple of days and am trying to workout the best approach so as to try to reolve the problem when I get on site as quickly as possible.
Cheers
Rich
Showing posts with label path. Show all posts
Showing posts with label path. Show all posts
Sunday, February 12, 2012
Backup to UNC path
I'm having a problem with a backup job.
15 or so databases are being backed up overnight to a remote server using UNC paths. All bar one database is being copied fine. The one that isn't is the largest at 8gb. The error in the log is OS error 64 (the network name could not be found).
Now I've got the customer looking into any reasons why their network may be interrupted overnight, but while googling around I saw someone mentioned that backing up to UNC with databases over 2gb can cause problems? Is there any truth in this?
I am inclined to reccomend the user backs up the database to a local drive and then sets up a scheduled task to copy it across, but I'm interested to see if this is a known issue.
Thanks.My own Opinion (MOO)
You should backup to the local drive, then copy the dump.
It'll be faster and safer...
MOO|||Once upon a time, in a galaxy far, far away ... oops, wrong place
I had that situation once. You could download a free copy of gzip and use that to compress the backup on the local machine before copying it across the network. I tried winzip, but it became unreliable after the database grew to over 4 GB. I **never** had a problem unzipping the database using gzip, and before I left that company, it had grown to over 17 GB.
I backed up the db to a backup device, zipped the file into a new file, and then copied the zipped file off server, where it was then picked up by the tape backup daily. Triple redundacy!!|||As I thought :)
btw does anyone know if sql 2005 will support native compression of backups?
Sage databases have a *lot* of padding. I've got a 1gb database that compressed down to 25mb with winrar, would be nice to have backups compressed right off the bat!|||backup to disk
use network backup to backup the backup file
saves you money so you dont have to buy the sql plugin for your backup software. and you get permenent backup devices which make restoring a whole lot easier.
backup database db1 to db1full
backup database db1 to db1diff with differential
backup log db1 to db1log
i know where all of my fulls, diffs and logs are without searching through hundreds of files in a dir.
convenient yes
does it compress well? not really.
15 or so databases are being backed up overnight to a remote server using UNC paths. All bar one database is being copied fine. The one that isn't is the largest at 8gb. The error in the log is OS error 64 (the network name could not be found).
Now I've got the customer looking into any reasons why their network may be interrupted overnight, but while googling around I saw someone mentioned that backing up to UNC with databases over 2gb can cause problems? Is there any truth in this?
I am inclined to reccomend the user backs up the database to a local drive and then sets up a scheduled task to copy it across, but I'm interested to see if this is a known issue.
Thanks.My own Opinion (MOO)
You should backup to the local drive, then copy the dump.
It'll be faster and safer...
MOO|||Once upon a time, in a galaxy far, far away ... oops, wrong place
I had that situation once. You could download a free copy of gzip and use that to compress the backup on the local machine before copying it across the network. I tried winzip, but it became unreliable after the database grew to over 4 GB. I **never** had a problem unzipping the database using gzip, and before I left that company, it had grown to over 17 GB.
I backed up the db to a backup device, zipped the file into a new file, and then copied the zipped file off server, where it was then picked up by the tape backup daily. Triple redundacy!!|||As I thought :)
btw does anyone know if sql 2005 will support native compression of backups?
Sage databases have a *lot* of padding. I've got a 1gb database that compressed down to 25mb with winrar, would be nice to have backups compressed right off the bat!|||backup to disk
use network backup to backup the backup file
saves you money so you dont have to buy the sql plugin for your backup software. and you get permenent backup devices which make restoring a whole lot easier.
backup database db1 to db1full
backup database db1 to db1diff with differential
backup log db1 to db1log
i know where all of my fulls, diffs and logs are without searching through hundreds of files in a dir.
convenient yes
does it compress well? not really.
Subscribe to:
Posts (Atom)