May 30, 2012 at 1:32 pm
We are running SQL Server 2005, SP3. I am running a backup across the network. This process has been working just fine for years. This past weekend the system went down because an Air Conditioner Issue. Since this AC Issue, I have been receiving the "64(The specified network name is no longer available.)" Error on my backup jobs. It appears the backup job completes successfully. I have verified the backup by running the following command:
-----------------------------------------------------------------------
--Verify the Backup is formatted correctly and accessible.
-----------------------------------------------------------------------
--You can also run a statement that will check the integrity of
--a database backup. It doesn't check the integrity of the data
--within a backup, but it does verify that the backup is formatted
--correctly and accessible.
-----------------------------------------------------------------------
RESTORE VERIFYONLY FROM DISK = 'Point to backup file.bak'
1) What could be causing this error? Everything I have read is pointing to a hardware or network issue.
2) Are there any other SQL Commands which can be used to verify the backup file?
Complete error message is below:
Back Up Database (Full) (bbdb2\blackboard) Backup Database on Local server connection
Databases: bb_bb60,bb_bb60_stats,bbadmin,cms,cms_doc
Type: Full
Append existing
Task start: 2012-05-30T04:30:13.
Task end: 2012-05-30T04:47:01.
Failed:(-1073548784) Executing the query "BACKUP DATABASE [bb_bb60] TO DISK = N'\\\\ctcstore\\sqlb2d\\blackboarddb\\Full\\bb_bb60\\bb_bb60_backup_201205300430.bak' WITH NOFORMAT, NOINIT, NAME = N'bb_bb60_backup_20120530043013', SKIP, REWIND, NOUNLOAD, STATS = 10 " failed with the following error: "A nonrecoverable I/O error occurred on file "\\\\ctcstore\\sqlb2d\\blackboarddb\\Full\\bb_bb60\\bb_bb60_backup_201205300430.bak:" 64(The specified network name is no longer available.).
BACKUP DATABASE is terminating abnormally.
10 percent processed.
20 percent processed.
30 percent processed.
40 percent processed.
50 percent processed.
60 percent processed.
70 percent processed.
80 percent processed.
90 percent processed.
Processed 1486968 pages for database 'bb_bb60', file 'bb_bb60_data' on file 1.
100 percent processed.
Processed 446 pages for database 'bb_bb60', file 'bb_bb60_log' on file 1.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
Thanks in advance, Kevin
June 4, 2012 at 11:04 pm
You need to be aware that running a restore verifyonly does not actually confirm you have a good backup, you can only do that with a full database restore.
I'm also unsure why you are using NOINIT and NOFORMAT with your backups. You could be appending to an already formatted file, one that has problems, which is causing your verify to fail. I recommend always using FORMAT, INIT on backups.
June 7, 2012 at 9:20 pm
Kevin,
How big is your DB? I had same issue trying to backup TB DB. Eventually did local backup and then copied file to network storage
July 5, 2012 at 6:37 am
Nicholas Cain (6/4/2012)
You need to be aware that running a restore verifyonly does not actually confirm you have a good backup, you can only do that with a full database restore.I'm also unsure why you are using NOINIT and NOFORMAT with your backups. You could be appending to an already formatted file, one that has problems, which is causing your verify to fail. I recommend always using FORMAT, INIT on backups.
Thanks Nicholas. I am writing to a new backup device each time by using a datetime stamp as part of my backup file name (_201205300430.bak). So, I did not think I need to use INIT and FORMAT. I found out from our network group that the problem is because of a battery issue with the disk caching system.
Kevin
July 5, 2012 at 6:39 am
Yuri55 (6/7/2012)
Kevin,How big is your DB? I had same issue trying to backup TB DB. Eventually did local backup and then copied file to network storage
One database is 12 GBs and the other is 23 GBs. Not too large. I found out from our network group that the problem is because of a battery issue with the disk caching system.
Thanks, Kevin
July 6, 2012 at 6:34 am
Why are you not using WITH CHECKSUM?
Viewing 6 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply