Backup to NAS device fails under SQL2k5 X64...

Here is my scenario: we have SQL2K5 X64 running in VM (ESX server). When I
use T-SQL cmd "BACKUP DATABASE" landing on NAS device, if fails (after some
non-deterministic period of time) with the error
BackupMedium::ReportIoError: write failure on backup device
'\\sql-snap\data\BACKUP\sql_dev\ArchiveDB_20080409132735. bak'. Operating
system error 64(The specified network name is no longer available.).
The OS is Win2K3 SP2 X64; SQL2K5 is running at level 1399. I have tried this
on another box with OS patched to max/SQL2K5 at level 3215 with the same
results.
The really weird thing is if I run this exact scenario in the 32-bit
environment (VM/Win2K3/SQL2K5 @. level 3215), it works fine. So it's related
to the 64-bit environment. If I point the landing spot for the backup file to
locally attached storage (in a 64-bit VM environment), it works fine.
Has anybody seen this in their 64-bit environment? If so, what did you do to
get around this issue?
Paul
It doesn't sound like a SQL problem. Try copying a large file with xcopy or
explorer and see if the same thing happens.
Jason Massie
Web: http://statisticsio.com
RSS: http://feeds.feedburner.com/statisticsio
"psligar" <psligar@.discussions.microsoft.com> wrote in message
news:B7994C94-7224-4F34-82B2-37D8C7D84BB2@.microsoft.com...
> Here is my scenario: we have SQL2K5 X64 running in VM (ESX server). When I
> use T-SQL cmd "BACKUP DATABASE" landing on NAS device, if fails (after
> some
> non-deterministic period of time) with the error
> BackupMedium::ReportIoError: write failure on backup device
> '\\sql-snap\data\BACKUP\sql_dev\ArchiveDB_20080409132735. bak'. Operating
> system error 64(The specified network name is no longer available.).
> The OS is Win2K3 SP2 X64; SQL2K5 is running at level 1399. I have tried
> this
> on another box with OS patched to max/SQL2K5 at level 3215 with the same
> results.
> The really weird thing is if I run this exact scenario in the 32-bit
> environment (VM/Win2K3/SQL2K5 @. level 3215), it works fine. So it's
> related
> to the 64-bit environment. If I point the landing spot for the backup file
> to
> locally attached storage (in a 64-bit VM environment), it works fine.
> Has anybody seen this in their 64-bit environment? If so, what did you do
> to
> get around this issue?
> Paul
|||Does the NAS location your trying to write to exist?
'The specified network name is no longer available'
Can you map to the nas location via my computer? If yes to both, then make
sure the ID your using has access to the nas device (read,write, modify,
etc).
I currently have all my SQL2k5 servers backing up to a NAS and I ran into
something similiar and it was due to the Id I was using no longer had access
to the NAS device.
"psligar" <psligar@.discussions.microsoft.com> wrote in message
news:B7994C94-7224-4F34-82B2-37D8C7D84BB2@.microsoft.com...
> Here is my scenario: we have SQL2K5 X64 running in VM (ESX server). When I
> use T-SQL cmd "BACKUP DATABASE" landing on NAS device, if fails (after
> some
> non-deterministic period of time) with the error
> BackupMedium::ReportIoError: write failure on backup device
> '\\sql-snap\data\BACKUP\sql_dev\ArchiveDB_20080409132735. bak'. Operating
> system error 64(The specified network name is no longer available.).
> The OS is Win2K3 SP2 X64; SQL2K5 is running at level 1399. I have tried
> this
> on another box with OS patched to max/SQL2K5 at level 3215 with the same
> results.
> The really weird thing is if I run this exact scenario in the 32-bit
> environment (VM/Win2K3/SQL2K5 @. level 3215), it works fine. So it's
> related
> to the 64-bit environment. If I point the landing spot for the backup file
> to
> locally attached storage (in a 64-bit VM environment), it works fine.
> Has anybody seen this in their 64-bit environment? If so, what did you do
> to
> get around this issue?
> Paul
|||Jason:
Thanks for the reply. I should have included that info in my question - that
was our thinking, as well. Our first inclination was to think we had a 64-bit
network driver issue. However, we have copied (via XCOPY) large (~30 GB)
files continuously across the network to the device in question (from the
64-bit VM SQL machine) with no problems.
"Jason Massie" wrote:

> It doesn't sound like a SQL problem. Try copying a large file with xcopy or
> explorer and see if the same thing happens.
> --
> Jason Massie
> Web: http://statisticsio.com
> RSS: http://feeds.feedburner.com/statisticsio
> "psligar" <psligar@.discussions.microsoft.com> wrote in message
> news:B7994C94-7224-4F34-82B2-37D8C7D84BB2@.microsoft.com...
>
>
|||Mike:
Thanks for the reply. To answer your question, yes, the location exists - we
are backing up multiple SQL2K 32-bit servers to that location across the
network. Some of those machines are in the ESX environment, as well. I can
map a drive to the network share point on the NAS device from 64-bit VM's in
question. I can copy large files to that share (see my reply to Jason). The
issue in question only surfaces when I try to use the 'BACKUP DATABASE' T-SQL
cmd from within SQL2K5.
In reference to the UID issue you mention, at times, one or more databases
will successfully backup to this device, before it fails on a subsequent DB.
So I'm confident that the UID being used has access to the network share.
NOTE: It's the same UID that is being used by the 32-bit SQL boxes that do
not exhibit this problem.
If I had the hardware availability, I might try setting up a stand alone
64-bit test box (to eliminate the ESX part of this scenario). Unfortunately,
I don't have that option (currently).
Paul
"Mike" wrote:

> Does the NAS location your trying to write to exist?
> 'The specified network name is no longer available'
> Can you map to the nas location via my computer? If yes to both, then make
> sure the ID your using has access to the nas device (read,write, modify,
> etc).
> I currently have all my SQL2k5 servers backing up to a NAS and I ran into
> something similiar and it was due to the Id I was using no longer had access
> to the NAS device.
> "psligar" <psligar@.discussions.microsoft.com> wrote in message
> news:B7994C94-7224-4F34-82B2-37D8C7D84BB2@.microsoft.com...
>
>
|||And the saga continues:
I installed the MS tool NetMon version 3.1 'cause I wanted to see what was
going on vis-a-vis the network, and reran the backup job. Lo and behold, it
completed - 5 DB's backed up across the network to a NAS device - a total of
approximately 52 GB. I know that the NetMon tool loaded a packet capture
driver into the network stack - I'm just unsure what other changes it made.
"psligar" wrote:

> Here is my scenario: we have SQL2K5 X64 running in VM (ESX server). When I
> use T-SQL cmd "BACKUP DATABASE" landing on NAS device, if fails (after some
> non-deterministic period of time) with the error
> BackupMedium::ReportIoError: write failure on backup device
> '\\sql-snap\data\BACKUP\sql_dev\ArchiveDB_20080409132735. bak'. Operating
> system error 64(The specified network name is no longer available.).
> The OS is Win2K3 SP2 X64; SQL2K5 is running at level 1399. I have tried this
> on another box with OS patched to max/SQL2K5 at level 3215 with the same
> results.
> The really weird thing is if I run this exact scenario in the 32-bit
> environment (VM/Win2K3/SQL2K5 @. level 3215), it works fine. So it's related
> to the 64-bit environment. If I point the landing spot for the backup file to
> locally attached storage (in a 64-bit VM environment), it works fine.
> Has anybody seen this in their 64-bit environment? If so, what did you do to
> get around this issue?
> Paul