Backup/Restore scenario

Hi,
I'm confused about the role of tLogs in a restore scenario. Imagine the
following:
Database running 24/7 with a lot of user activity. All backups at midnight
Fri - Full backup
Mon - tLog backup
Tue - tLog backup
Wed - tLog backup
Thurs - tLog backup
Imagine the server blows up one Thursday morning.
Q1. If I restore the full backup from the previous Friday, and then the
tLogs for Mon, Tue, Wed, does that mean I've got everything except the last
few user updates early Thursday morning?
Q2. What if the developers had added a new table on Tuesday? Would this new
table exist in the restored version?
--
Gerry HickmanQ1 - When you apply the transaction log backups you will have all the
modifications that have happened up to the point of the most recent
transaction log that you applied.
Q2 - Yes, the table that is created on Tuesday will be capured within
Tuesday night's t-log backup. It will be "created" when you restore that
log backup.
If you have "lots" of user activity as you say you might want to issue
transaction log backups more often than once per day.
--
Keith Kratochvil
"Gerry Hickman" <gerry1uk@.netscape.net> wrote in message
news:u6ZvvygPGHA.3164@.TK2MSFTNGP11.phx.gbl...
> Hi,
> I'm confused about the role of tLogs in a restore scenario. Imagine the
> following:
> Database running 24/7 with a lot of user activity. All backups at midnight
> Fri - Full backup
> Mon - tLog backup
> Tue - tLog backup
> Wed - tLog backup
> Thurs - tLog backup
> Imagine the server blows up one Thursday morning.
> Q1. If I restore the full backup from the previous Friday, and then the
> tLogs for Mon, Tue, Wed, does that mean I've got everything except the
> last
> few user updates early Thursday morning?
> Q2. What if the developers had added a new table on Tuesday? Would this
> new
> table exist in the restored version?
> --
> Gerry Hickman
>|||Hi Keith,
Thanks, this is very helpful and this was how I originally understood it
would work, but recently I wasn't sure. It's interesting the new table
gets carried over.
I have another question now!
If the tLogs are storing all the changes since the last backup, do they
get "emptied" next time you do a full backup?
As I understand it, you can choose to "truncate" the log as part of the
backup procedure, but I currently DON'T have this checked, so how do I
know my full backup really is "full" and will my tLogs keep growing
forever? All my backup settings are on the defaults. Can you advise the
correct backup settings to use for our simple setup?
(Point taken about doing full backup each day instead of each week)
Keith Kratochvil wrote:
> Q1 - When you apply the transaction log backups you will have all the
> modifications that have happened up to the point of the most recent
> transaction log that you applied.
> Q2 - Yes, the table that is created on Tuesday will be capured within
> Tuesday night's t-log backup. It will be "created" when you restore that
> log backup.
>
> If you have "lots" of user activity as you say you might want to issue
> transaction log backups more often than once per day.
>
Gerry Hickman (London UK)|||Gerry Hickman wrote:
> Hi Keith,
> Thanks, this is very helpful and this was how I originally understood it
> would work, but recently I wasn't sure. It's interesting the new table
> gets carried over.
> I have another question now!
> If the tLogs are storing all the changes since the last backup, do they
> get "emptied" next time you do a full backup?
> As I understand it, you can choose to "truncate" the log as part of the
> backup procedure, but I currently DON'T have this checked, so how do I
> know my full backup really is "full" and will my tLogs keep growing
> forever? All my backup settings are on the defaults. Can you advise the
> correct backup settings to use for our simple setup?
> (Point taken about doing full backup each day instead of each week)
> Keith Kratochvil wrote:
>> Q1 - When you apply the transaction log backups you will have all the
>> modifications that have happened up to the point of the most recent
>> transaction log that you applied.
>> Q2 - Yes, the table that is created on Tuesday will be capured within
>> Tuesday night's t-log backup. It will be "created" when you restore
>> that log backup.
>>
>> If you have "lots" of user activity as you say you might want to issue
>> transaction log backups more often than once per day.
>
Hi Gary
The FULL backup will not do anything to the logfiles. It's only a log
backup that will "touch" the logfile (Actually a FULL backup will take a
little part of the logfile, but that's only what it needs to be able to
perform a RESTORE).
When you do a log backup, it will mark the transactions that it has
backed up and the space can then be reused (TRUNCATE). Now the space can
be reused by new transactions, so your physical logfile doesn't need to
grow to contain the transactions.
Try to look up "Transaction Log Backups" in Books On Line. That chapter
gives a fairly good description of how it works.
Regards
Steen

Backup/Restore scenario

Hi,
I'm confused about the role of tLogs in a restore scenario. Imagine the
following:
Database running 24/7 with a lot of user activity. All backups at midnight
Fri - Full backup
Mon - tLog backup
Tue - tLog backup
Wed - tLog backup
Thurs - tLog backup
Imagine the server blows up one Thursday morning.
Q1. If I restore the full backup from the previous Friday, and then the
tLogs for Mon, Tue, Wed, does that mean I've got everything except the last
few user updates early Thursday morning?
Q2. What if the developers had added a new table on Tuesday? Would this new
table exist in the restored version?
Gerry Hickman
Q1 - When you apply the transaction log backups you will have all the
modifications that have happened up to the point of the most recent
transaction log that you applied.
Q2 - Yes, the table that is created on Tuesday will be capured within
Tuesday night's t-log backup. It will be "created" when you restore that
log backup.
If you have "lots" of user activity as you say you might want to issue
transaction log backups more often than once per day.
Keith Kratochvil
"Gerry Hickman" <gerry1uk@.netscape.net> wrote in message
news:u6ZvvygPGHA.3164@.TK2MSFTNGP11.phx.gbl...
> Hi,
> I'm confused about the role of tLogs in a restore scenario. Imagine the
> following:
> Database running 24/7 with a lot of user activity. All backups at midnight
> Fri - Full backup
> Mon - tLog backup
> Tue - tLog backup
> Wed - tLog backup
> Thurs - tLog backup
> Imagine the server blows up one Thursday morning.
> Q1. If I restore the full backup from the previous Friday, and then the
> tLogs for Mon, Tue, Wed, does that mean I've got everything except the
> last
> few user updates early Thursday morning?
> Q2. What if the developers had added a new table on Tuesday? Would this
> new
> table exist in the restored version?
> --
> Gerry Hickman
>
|||Hi Keith,
Thanks, this is very helpful and this was how I originally understood it
would work, but recently I wasn't sure. It's interesting the new table
gets carried over.
I have another question now!
If the tLogs are storing all the changes since the last backup, do they
get "emptied" next time you do a full backup?
As I understand it, you can choose to "truncate" the log as part of the
backup procedure, but I currently DON'T have this checked, so how do I
know my full backup really is "full" and will my tLogs keep growing
forever? All my backup settings are on the defaults. Can you advise the
correct backup settings to use for our simple setup?
(Point taken about doing full backup each day instead of each week)
Keith Kratochvil wrote:
> Q1 - When you apply the transaction log backups you will have all the
> modifications that have happened up to the point of the most recent
> transaction log that you applied.
> Q2 - Yes, the table that is created on Tuesday will be capured within
> Tuesday night's t-log backup. It will be "created" when you restore that
> log backup.
>
> If you have "lots" of user activity as you say you might want to issue
> transaction log backups more often than once per day.
>
Gerry Hickman (London UK)
|||Gerry Hickman wrote:
> Hi Keith,
> Thanks, this is very helpful and this was how I originally understood it
> would work, but recently I wasn't sure. It's interesting the new table
> gets carried over.
> I have another question now!
> If the tLogs are storing all the changes since the last backup, do they
> get "emptied" next time you do a full backup?
> As I understand it, you can choose to "truncate" the log as part of the
> backup procedure, but I currently DON'T have this checked, so how do I
> know my full backup really is "full" and will my tLogs keep growing
> forever? All my backup settings are on the defaults. Can you advise the
> correct backup settings to use for our simple setup?
> (Point taken about doing full backup each day instead of each week)
> Keith Kratochvil wrote:
>
Hi Gary
The FULL backup will not do anything to the logfiles. It's only a log
backup that will "touch" the logfile (Actually a FULL backup will take a
little part of the logfile, but that's only what it needs to be able to
perform a RESTORE).
When you do a log backup, it will mark the transactions that it has
backed up and the space can then be reused (TRUNCATE). Now the space can
be reused by new transactions, so your physical logfile doesn't need to
grow to contain the transactions.
Try to look up "Transaction Log Backups" in Books On Line. That chapter
gives a fairly good description of how it works.
Regards
Steen

Backup/Restore scenario

Hi,
I'm confused about the role of tLogs in a restore scenario. Imagine the
following:
Database running 24/7 with a lot of user activity. All backups at midnight
Fri - Full backup
Mon - tLog backup
Tue - tLog backup
Wed - tLog backup
Thurs - tLog backup
Imagine the server blows up one Thursday morning.
Q1. If I restore the full backup from the previous Friday, and then the
tLogs for Mon, Tue, Wed, does that mean I've got everything except the last
few user updates early Thursday morning?
Q2. What if the developers had added a new table on Tuesday? Would this new
table exist in the restored version?
Gerry HickmanQ1 - When you apply the transaction log backups you will have all the
modifications that have happened up to the point of the most recent
transaction log that you applied.
Q2 - Yes, the table that is created on Tuesday will be capured within
Tuesday night's t-log backup. It will be "created" when you restore that
log backup.
If you have "lots" of user activity as you say you might want to issue
transaction log backups more often than once per day.
Keith Kratochvil
"Gerry Hickman" <gerry1uk@.netscape.net> wrote in message
news:u6ZvvygPGHA.3164@.TK2MSFTNGP11.phx.gbl...
> Hi,
> I'm confused about the role of tLogs in a restore scenario. Imagine the
> following:
> Database running 24/7 with a lot of user activity. All backups at midnight
> Fri - Full backup
> Mon - tLog backup
> Tue - tLog backup
> Wed - tLog backup
> Thurs - tLog backup
> Imagine the server blows up one Thursday morning.
> Q1. If I restore the full backup from the previous Friday, and then the
> tLogs for Mon, Tue, Wed, does that mean I've got everything except the
> last
> few user updates early Thursday morning?
> Q2. What if the developers had added a new table on Tuesday? Would this
> new
> table exist in the restored version?
> --
> Gerry Hickman
>|||Hi Keith,
Thanks, this is very helpful and this was how I originally understood it
would work, but recently I wasn't sure. It's interesting the new table
gets carried over.
I have another question now!
If the tLogs are storing all the changes since the last backup, do they
get "emptied" next time you do a full backup?
As I understand it, you can choose to "truncate" the log as part of the
backup procedure, but I currently DON'T have this checked, so how do I
know my full backup really is "full" and will my tLogs keep growing
forever? All my backup settings are on the defaults. Can you advise the
correct backup settings to use for our simple setup?
(Point taken about doing full backup each day instead of each week)
Keith Kratochvil wrote:
> Q1 - When you apply the transaction log backups you will have all the
> modifications that have happened up to the point of the most recent
> transaction log that you applied.
> Q2 - Yes, the table that is created on Tuesday will be capured within
> Tuesday night's t-log backup. It will be "created" when you restore that
> log backup.
>
> If you have "lots" of user activity as you say you might want to issue
> transaction log backups more often than once per day.
>
Gerry Hickman (London UK)|||Gerry Hickman wrote:
> Hi Keith,
> Thanks, this is very helpful and this was how I originally understood it
> would work, but recently I wasn't sure. It's interesting the new table
> gets carried over.
> I have another question now!
> If the tLogs are storing all the changes since the last backup, do they
> get "emptied" next time you do a full backup?
> As I understand it, you can choose to "truncate" the log as part of the
> backup procedure, but I currently DON'T have this checked, so how do I
> know my full backup really is "full" and will my tLogs keep growing
> forever? All my backup settings are on the defaults. Can you advise the
> correct backup settings to use for our simple setup?
> (Point taken about doing full backup each day instead of each week)
> Keith Kratochvil wrote:
>
Hi Gary
The FULL backup will not do anything to the logfiles. It's only a log
backup that will "touch" the logfile (Actually a FULL backup will take a
little part of the logfile, but that's only what it needs to be able to
perform a RESTORE).
When you do a log backup, it will mark the transactions that it has
backed up and the space can then be reused (TRUNCATE). Now the space can
be reused by new transactions, so your physical logfile doesn't need to
grow to contain the transactions.
Try to look up "Transaction Log Backups" in Books On Line. That chapter
gives a fairly good description of how it works.
Regards
Steen

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?
PaulIt 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...
> > 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
>
>|||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...
> > 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
>
>|||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

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