Hi, everyday an automated backup is done of my content database and when i
checked today to ensure the job went thru, I realized it failed.
I get the error msg:
"A nonrecoverable I/O error occured on file
"\\tcl-fileserver3\backups\moss\daily"
The specified network name is no longer available. Error: 3013"
I created a new file and did a backup to that file
"\\tcl-fileserver3\backups\moss\testing" and the backup went thru fine. I
then renamed the original file and did a backup and that went thru......
Is it possible that a file name can be corrupted? The original backup path
was "\\tcl-fileserver3\backups\moss\daily" I renamed that file to:
"\\tcl-fileserver3\backups\moss\daily_testing" and the backup went thru
fine......
What could be the issue here?
When you say the remote server, you are referring to the server where i am
backing up the information to?
Also, I didn't change the time in the schedule, I just changed the name of
the file and it worked......
What could cause this?
"Des FitzGerald" wrote:
> Hi Shelly,
> I think this points to a problem with either the network connection at the
> scheduled time of the backup or to over processing on the remote network
> server you are sending the backup to at the time of the schedule.
> Could it be that this remote server is under heavy load during the backup?
> If so perhaps changing the time of the schedule if possible may help.
> Kind Regards,
> Des
>
> On 08/01/2008 16:09, in article
> ED8CA9B6-4896-4E15-BC4A-1DA86CDDCD03@.microsoft.com, "Shelley"
> <Shelley@.discussions.microsoft.com> wrote:
>
>
>
|||Hi, thanks so much for your help.
I renamed the file, but left the schedule the same and the backup went thru.
Still not sure what the exact problem was since this was the first time this
ever happened; have been doing the automated backups for about a month now.
Thanks again,
Shelley
"Des FitzGerald" wrote:
> The remote server is where you are backing up your database to - in this
> case \\tcl-fileserver
> I am thinking that this server was under load when your normal scheduled
> nightly execution took place and this may have caused the problem or perhaps
> there was an intermittent network problem at the time.
> Both these scenarios are possibilities as to why you have seen this issue,
> the file name may have become corrupt because of the I/O problems on the
> server, I would look at the time of the schedule and see if other heavy
> processing is occurring on your remote backup location and change the time
> if possible of the schedule so it executes when the server is under less
> strain.
> Alternatively if this happened only once out of 100 runs of the schedule it
> may just be bad luck and the schedule can remain. It would also be possible
> to write a check before starting the backup to make sure the file exists and
> can be reached and that all looks OK.
> Cheers,
> Des
> On 08/01/2008 16:31, in article
> 62B77DBE-316A-4C5F-AAAB-AD1B9E1AB994@.microsoft.com, "Shelley"
> <Shelley@.discussions.microsoft.com> wrote:
>
>
Showing posts with label ensure. Show all posts
Showing posts with label ensure. Show all posts
Tuesday, March 27, 2012
Backup failed - Error 3013
Hi, everyday an automated backup is done of my content database and when i
checked today to ensure the job went thru, I realized it failed.
I get the error msg:
"A nonrecoverable I/O error occured on file
"\\tcl-fileserver3\backups\moss\daily"
The specified network name is no longer available. Error: 3013"
I created a new file and did a backup to that file
"\\tcl-fileserver3\backups\moss\testing" and the backup went thru fine. I
then renamed the original file and did a backup and that went thru......
Is it possible that a file name can be corrupted? The original backup path
was "\\tcl-fileserver3\backups\moss\daily" I renamed that file to:
"\\tcl-fileserver3\backups\moss\daily_testing" and the backup went thru
fine......
What could be the issue here?Hi Shelly,
I think this points to a problem with either the network connection at the
scheduled time of the backup or to over processing on the remote network
server you are sending the backup to at the time of the schedule.
Could it be that this remote server is under heavy load during the backup?
If so perhaps changing the time of the schedule if possible may help.
Kind Regards,
Des
On 08/01/2008 16:09, in article
ED8CA9B6-4896-4E15-BC4A-1DA86CDDCD03@.microsoft.com, "Shelley"
<Shelley@.discussions.microsoft.com> wrote:
> Hi, everyday an automated backup is done of my content database and when i
> checked today to ensure the job went thru, I realized it failed.
> I get the error msg:
> "A nonrecoverable I/O error occured on file
> "\\tcl-fileserver3\backups\moss\daily"
> The specified network name is no longer available. Error: 3013"
> I created a new file and did a backup to that file
> "\\tcl-fileserver3\backups\moss\testing" and the backup went thru fine. I
> then renamed the original file and did a backup and that went thru......
> Is it possible that a file name can be corrupted? The original backup path
> was "\\tcl-fileserver3\backups\moss\daily" I renamed that file to:
> "\\tcl-fileserver3\backups\moss\daily_testing" and the backup went thru
> fine......
> What could be the issue here?|||When you say the remote server, you are referring to the server where i am
backing up the information to?
Also, I didn't change the time in the schedule, I just changed the name of
the file and it worked......
What could cause this?
"Des FitzGerald" wrote:
> Hi Shelly,
> I think this points to a problem with either the network connection at the
> scheduled time of the backup or to over processing on the remote network
> server you are sending the backup to at the time of the schedule.
> Could it be that this remote server is under heavy load during the backup?
> If so perhaps changing the time of the schedule if possible may help.
> Kind Regards,
> Des
>
> On 08/01/2008 16:09, in article
> ED8CA9B6-4896-4E15-BC4A-1DA86CDDCD03@.microsoft.com, "Shelley"
> <Shelley@.discussions.microsoft.com> wrote:
> > Hi, everyday an automated backup is done of my content database and when i
> > checked today to ensure the job went thru, I realized it failed.
> > I get the error msg:
> > "A nonrecoverable I/O error occured on file
> > "\\tcl-fileserver3\backups\moss\daily"
> > The specified network name is no longer available. Error: 3013"
> > I created a new file and did a backup to that file
> > "\\tcl-fileserver3\backups\moss\testing" and the backup went thru fine. I
> > then renamed the original file and did a backup and that went thru......
> > Is it possible that a file name can be corrupted? The original backup path
> > was "\\tcl-fileserver3\backups\moss\daily" I renamed that file to:
> > "\\tcl-fileserver3\backups\moss\daily_testing" and the backup went thru
> > fine......
> > What could be the issue here?
>
>
>|||The remote server is where you are backing up your database to - in this
case \\tcl-fileserver
I am thinking that this server was under load when your normal scheduled
nightly execution took place and this may have caused the problem or perhaps
there was an intermittent network problem at the time.
Both these scenarios are possibilities as to why you have seen this issue,
the file name may have become corrupt because of the I/O problems on the
server, I would look at the time of the schedule and see if other heavy
processing is occurring on your remote backup location and change the time
if possible of the schedule so it executes when the server is under less
strain.
Alternatively if this happened only once out of 100 runs of the schedule it
may just be bad luck and the schedule can remain. It would also be possible
to write a check before starting the backup to make sure the file exists and
can be reached and that all looks OK.
Cheers,
Des
On 08/01/2008 16:31, in article
62B77DBE-316A-4C5F-AAAB-AD1B9E1AB994@.microsoft.com, "Shelley"
<Shelley@.discussions.microsoft.com> wrote:
> When you say the remote server, you are referring to the server where i am
> backing up the information to?
> Also, I didn't change the time in the schedule, I just changed the name of
> the file and it worked......
> What could cause this?
> "Des FitzGerald" wrote:
>> Hi Shelly,
>> I think this points to a problem with either the network connection at the
>> scheduled time of the backup or to over processing on the remote network
>> server you are sending the backup to at the time of the schedule.
>> Could it be that this remote server is under heavy load during the backup?
>> If so perhaps changing the time of the schedule if possible may help.
>> Kind Regards,
>> Des
>>
>> On 08/01/2008 16:09, in article
>> ED8CA9B6-4896-4E15-BC4A-1DA86CDDCD03@.microsoft.com, "Shelley"
>> <Shelley@.discussions.microsoft.com> wrote:
>> Hi, everyday an automated backup is done of my content database and when i
>> checked today to ensure the job went thru, I realized it failed.
>> I get the error msg:
>> "A nonrecoverable I/O error occured on file
>> "\\tcl-fileserver3\backups\moss\daily"
>> The specified network name is no longer available. Error: 3013"
>> I created a new file and did a backup to that file
>> "\\tcl-fileserver3\backups\moss\testing" and the backup went thru fine. I
>> then renamed the original file and did a backup and that went thru......
>> Is it possible that a file name can be corrupted? The original backup path
>> was "\\tcl-fileserver3\backups\moss\daily" I renamed that file to:
>> "\\tcl-fileserver3\backups\moss\daily_testing" and the backup went thru
>> fine......
>> What could be the issue here?
>>
>>|||Hi, thanks so much for your help.
I renamed the file, but left the schedule the same and the backup went thru.
Still not sure what the exact problem was since this was the first time this
ever happened; have been doing the automated backups for about a month now.
Thanks again,
Shelley
"Des FitzGerald" wrote:
> The remote server is where you are backing up your database to - in this
> case \\tcl-fileserver
> I am thinking that this server was under load when your normal scheduled
> nightly execution took place and this may have caused the problem or perhaps
> there was an intermittent network problem at the time.
> Both these scenarios are possibilities as to why you have seen this issue,
> the file name may have become corrupt because of the I/O problems on the
> server, I would look at the time of the schedule and see if other heavy
> processing is occurring on your remote backup location and change the time
> if possible of the schedule so it executes when the server is under less
> strain.
> Alternatively if this happened only once out of 100 runs of the schedule it
> may just be bad luck and the schedule can remain. It would also be possible
> to write a check before starting the backup to make sure the file exists and
> can be reached and that all looks OK.
> Cheers,
> Des
> On 08/01/2008 16:31, in article
> 62B77DBE-316A-4C5F-AAAB-AD1B9E1AB994@.microsoft.com, "Shelley"
> <Shelley@.discussions.microsoft.com> wrote:
> > When you say the remote server, you are referring to the server where i am
> > backing up the information to?
> > Also, I didn't change the time in the schedule, I just changed the name of
> > the file and it worked......
> > What could cause this?
> >
> > "Des FitzGerald" wrote:
> >
> >> Hi Shelly,
> >>
> >> I think this points to a problem with either the network connection at the
> >> scheduled time of the backup or to over processing on the remote network
> >> server you are sending the backup to at the time of the schedule.
> >>
> >> Could it be that this remote server is under heavy load during the backup?
> >>
> >> If so perhaps changing the time of the schedule if possible may help.
> >>
> >> Kind Regards,
> >> Des
> >>
> >>
> >>
> >> On 08/01/2008 16:09, in article
> >> ED8CA9B6-4896-4E15-BC4A-1DA86CDDCD03@.microsoft.com, "Shelley"
> >> <Shelley@.discussions.microsoft.com> wrote:
> >>
> >> Hi, everyday an automated backup is done of my content database and when i
> >> checked today to ensure the job went thru, I realized it failed.
> >> I get the error msg:
> >> "A nonrecoverable I/O error occured on file
> >> "\\tcl-fileserver3\backups\moss\daily"
> >> The specified network name is no longer available. Error: 3013"
> >> I created a new file and did a backup to that file
> >> "\\tcl-fileserver3\backups\moss\testing" and the backup went thru fine. I
> >> then renamed the original file and did a backup and that went thru......
> >> Is it possible that a file name can be corrupted? The original backup path
> >> was "\\tcl-fileserver3\backups\moss\daily" I renamed that file to:
> >> "\\tcl-fileserver3\backups\moss\daily_testing" and the backup went thru
> >> fine......
> >> What could be the issue here?
> >>
> >>
> >>
> >>
> >>
>
>sql
checked today to ensure the job went thru, I realized it failed.
I get the error msg:
"A nonrecoverable I/O error occured on file
"\\tcl-fileserver3\backups\moss\daily"
The specified network name is no longer available. Error: 3013"
I created a new file and did a backup to that file
"\\tcl-fileserver3\backups\moss\testing" and the backup went thru fine. I
then renamed the original file and did a backup and that went thru......
Is it possible that a file name can be corrupted? The original backup path
was "\\tcl-fileserver3\backups\moss\daily" I renamed that file to:
"\\tcl-fileserver3\backups\moss\daily_testing" and the backup went thru
fine......
What could be the issue here?Hi Shelly,
I think this points to a problem with either the network connection at the
scheduled time of the backup or to over processing on the remote network
server you are sending the backup to at the time of the schedule.
Could it be that this remote server is under heavy load during the backup?
If so perhaps changing the time of the schedule if possible may help.
Kind Regards,
Des
On 08/01/2008 16:09, in article
ED8CA9B6-4896-4E15-BC4A-1DA86CDDCD03@.microsoft.com, "Shelley"
<Shelley@.discussions.microsoft.com> wrote:
> Hi, everyday an automated backup is done of my content database and when i
> checked today to ensure the job went thru, I realized it failed.
> I get the error msg:
> "A nonrecoverable I/O error occured on file
> "\\tcl-fileserver3\backups\moss\daily"
> The specified network name is no longer available. Error: 3013"
> I created a new file and did a backup to that file
> "\\tcl-fileserver3\backups\moss\testing" and the backup went thru fine. I
> then renamed the original file and did a backup and that went thru......
> Is it possible that a file name can be corrupted? The original backup path
> was "\\tcl-fileserver3\backups\moss\daily" I renamed that file to:
> "\\tcl-fileserver3\backups\moss\daily_testing" and the backup went thru
> fine......
> What could be the issue here?|||When you say the remote server, you are referring to the server where i am
backing up the information to?
Also, I didn't change the time in the schedule, I just changed the name of
the file and it worked......
What could cause this?
"Des FitzGerald" wrote:
> Hi Shelly,
> I think this points to a problem with either the network connection at the
> scheduled time of the backup or to over processing on the remote network
> server you are sending the backup to at the time of the schedule.
> Could it be that this remote server is under heavy load during the backup?
> If so perhaps changing the time of the schedule if possible may help.
> Kind Regards,
> Des
>
> On 08/01/2008 16:09, in article
> ED8CA9B6-4896-4E15-BC4A-1DA86CDDCD03@.microsoft.com, "Shelley"
> <Shelley@.discussions.microsoft.com> wrote:
> > Hi, everyday an automated backup is done of my content database and when i
> > checked today to ensure the job went thru, I realized it failed.
> > I get the error msg:
> > "A nonrecoverable I/O error occured on file
> > "\\tcl-fileserver3\backups\moss\daily"
> > The specified network name is no longer available. Error: 3013"
> > I created a new file and did a backup to that file
> > "\\tcl-fileserver3\backups\moss\testing" and the backup went thru fine. I
> > then renamed the original file and did a backup and that went thru......
> > Is it possible that a file name can be corrupted? The original backup path
> > was "\\tcl-fileserver3\backups\moss\daily" I renamed that file to:
> > "\\tcl-fileserver3\backups\moss\daily_testing" and the backup went thru
> > fine......
> > What could be the issue here?
>
>
>|||The remote server is where you are backing up your database to - in this
case \\tcl-fileserver
I am thinking that this server was under load when your normal scheduled
nightly execution took place and this may have caused the problem or perhaps
there was an intermittent network problem at the time.
Both these scenarios are possibilities as to why you have seen this issue,
the file name may have become corrupt because of the I/O problems on the
server, I would look at the time of the schedule and see if other heavy
processing is occurring on your remote backup location and change the time
if possible of the schedule so it executes when the server is under less
strain.
Alternatively if this happened only once out of 100 runs of the schedule it
may just be bad luck and the schedule can remain. It would also be possible
to write a check before starting the backup to make sure the file exists and
can be reached and that all looks OK.
Cheers,
Des
On 08/01/2008 16:31, in article
62B77DBE-316A-4C5F-AAAB-AD1B9E1AB994@.microsoft.com, "Shelley"
<Shelley@.discussions.microsoft.com> wrote:
> When you say the remote server, you are referring to the server where i am
> backing up the information to?
> Also, I didn't change the time in the schedule, I just changed the name of
> the file and it worked......
> What could cause this?
> "Des FitzGerald" wrote:
>> Hi Shelly,
>> I think this points to a problem with either the network connection at the
>> scheduled time of the backup or to over processing on the remote network
>> server you are sending the backup to at the time of the schedule.
>> Could it be that this remote server is under heavy load during the backup?
>> If so perhaps changing the time of the schedule if possible may help.
>> Kind Regards,
>> Des
>>
>> On 08/01/2008 16:09, in article
>> ED8CA9B6-4896-4E15-BC4A-1DA86CDDCD03@.microsoft.com, "Shelley"
>> <Shelley@.discussions.microsoft.com> wrote:
>> Hi, everyday an automated backup is done of my content database and when i
>> checked today to ensure the job went thru, I realized it failed.
>> I get the error msg:
>> "A nonrecoverable I/O error occured on file
>> "\\tcl-fileserver3\backups\moss\daily"
>> The specified network name is no longer available. Error: 3013"
>> I created a new file and did a backup to that file
>> "\\tcl-fileserver3\backups\moss\testing" and the backup went thru fine. I
>> then renamed the original file and did a backup and that went thru......
>> Is it possible that a file name can be corrupted? The original backup path
>> was "\\tcl-fileserver3\backups\moss\daily" I renamed that file to:
>> "\\tcl-fileserver3\backups\moss\daily_testing" and the backup went thru
>> fine......
>> What could be the issue here?
>>
>>|||Hi, thanks so much for your help.
I renamed the file, but left the schedule the same and the backup went thru.
Still not sure what the exact problem was since this was the first time this
ever happened; have been doing the automated backups for about a month now.
Thanks again,
Shelley
"Des FitzGerald" wrote:
> The remote server is where you are backing up your database to - in this
> case \\tcl-fileserver
> I am thinking that this server was under load when your normal scheduled
> nightly execution took place and this may have caused the problem or perhaps
> there was an intermittent network problem at the time.
> Both these scenarios are possibilities as to why you have seen this issue,
> the file name may have become corrupt because of the I/O problems on the
> server, I would look at the time of the schedule and see if other heavy
> processing is occurring on your remote backup location and change the time
> if possible of the schedule so it executes when the server is under less
> strain.
> Alternatively if this happened only once out of 100 runs of the schedule it
> may just be bad luck and the schedule can remain. It would also be possible
> to write a check before starting the backup to make sure the file exists and
> can be reached and that all looks OK.
> Cheers,
> Des
> On 08/01/2008 16:31, in article
> 62B77DBE-316A-4C5F-AAAB-AD1B9E1AB994@.microsoft.com, "Shelley"
> <Shelley@.discussions.microsoft.com> wrote:
> > When you say the remote server, you are referring to the server where i am
> > backing up the information to?
> > Also, I didn't change the time in the schedule, I just changed the name of
> > the file and it worked......
> > What could cause this?
> >
> > "Des FitzGerald" wrote:
> >
> >> Hi Shelly,
> >>
> >> I think this points to a problem with either the network connection at the
> >> scheduled time of the backup or to over processing on the remote network
> >> server you are sending the backup to at the time of the schedule.
> >>
> >> Could it be that this remote server is under heavy load during the backup?
> >>
> >> If so perhaps changing the time of the schedule if possible may help.
> >>
> >> Kind Regards,
> >> Des
> >>
> >>
> >>
> >> On 08/01/2008 16:09, in article
> >> ED8CA9B6-4896-4E15-BC4A-1DA86CDDCD03@.microsoft.com, "Shelley"
> >> <Shelley@.discussions.microsoft.com> wrote:
> >>
> >> Hi, everyday an automated backup is done of my content database and when i
> >> checked today to ensure the job went thru, I realized it failed.
> >> I get the error msg:
> >> "A nonrecoverable I/O error occured on file
> >> "\\tcl-fileserver3\backups\moss\daily"
> >> The specified network name is no longer available. Error: 3013"
> >> I created a new file and did a backup to that file
> >> "\\tcl-fileserver3\backups\moss\testing" and the backup went thru fine. I
> >> then renamed the original file and did a backup and that went thru......
> >> Is it possible that a file name can be corrupted? The original backup path
> >> was "\\tcl-fileserver3\backups\moss\daily" I renamed that file to:
> >> "\\tcl-fileserver3\backups\moss\daily_testing" and the backup went thru
> >> fine......
> >> What could be the issue here?
> >>
> >>
> >>
> >>
> >>
>
>sql
Thursday, February 16, 2012
Backup
I'm not sure if I'm doing this correctly to ensure recovery in case of a
disaster. I have a SQL 2000 Sp4 server, this server has not tape drive
attached to it. What I'm doing is during the night I run a backup through a
maintenance job in enterprise manager to the BACKUP directory in the SQL file
structure. On another server that has a tape drive I'm backing up this
BACKUP directory to tape. Should I be backing up anything else to ensure
disaster recovery.In summary, ensure that you are backing-up the system databases (there is an
option in the maintenance plan wizard to do this) as well as your user
databases. Make the maintenance plan for the system databases separate from
your plans for the user databases. Also ensure that if you are doing tran log
backups on the databases that have full recovery model, that you have the
backups for the simple model databases in a different plan or you will get an
error in the tran log backup job (even though the tran log backups will
succeed).
If you can backup to a remote server using UNC paths if your mssqlserver
service uses a service account (that has the necessary rights to the file
system on the remote server), that would be preferable. If you cannot
however, then your current backup strategy is adequate.
AndyP,
Sr. Database Administrator,
MCDBA 2003
"George Schneider" wrote:
> I'm not sure if I'm doing this correctly to ensure recovery in case of a
> disaster. I have a SQL 2000 Sp4 server, this server has not tape drive
> attached to it. What I'm doing is during the night I run a backup through a
> maintenance job in enterprise manager to the BACKUP directory in the SQL file
> structure. On another server that has a tape drive I'm backing up this
> BACKUP directory to tape. Should I be backing up anything else to ensure
> disaster recovery.
>|||I currently have all databses under on Maintenance plan. Why is it
neccessary to seperate the system and user db's into two?
"AndyP" wrote:
> In summary, ensure that you are backing-up the system databases (there is an
> option in the maintenance plan wizard to do this) as well as your user
> databases. Make the maintenance plan for the system databases separate from
> your plans for the user databases. Also ensure that if you are doing tran log
> backups on the databases that have full recovery model, that you have the
> backups for the simple model databases in a different plan or you will get an
> error in the tran log backup job (even though the tran log backups will
> succeed).
> If you can backup to a remote server using UNC paths if your mssqlserver
> service uses a service account (that has the necessary rights to the file
> system on the remote server), that would be preferable. If you cannot
> however, then your current backup strategy is adequate.
>
> --
> AndyP,
> Sr. Database Administrator,
> MCDBA 2003
>
> "George Schneider" wrote:
> > I'm not sure if I'm doing this correctly to ensure recovery in case of a
> > disaster. I have a SQL 2000 Sp4 server, this server has not tape drive
> > attached to it. What I'm doing is during the night I run a backup through a
> > maintenance job in enterprise manager to the BACKUP directory in the SQL file
> > structure. On another server that has a tape drive I'm backing up this
> > BACKUP directory to tape. Should I be backing up anything else to ensure
> > disaster recovery.
> >
> >|||Your plans will fail in an ungraceful manner if you have database in both full and simple recovery
mode and you try to do log backups in such a plan.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"George Schneider" <georgedschneider@.news.postalias> wrote in message
news:0C3B4830-8855-45BF-8CC4-84C27E5EF174@.microsoft.com...
>I currently have all databses under on Maintenance plan. Why is it
> neccessary to seperate the system and user db's into two?
> "AndyP" wrote:
>> In summary, ensure that you are backing-up the system databases (there is an
>> option in the maintenance plan wizard to do this) as well as your user
>> databases. Make the maintenance plan for the system databases separate from
>> your plans for the user databases. Also ensure that if you are doing tran log
>> backups on the databases that have full recovery model, that you have the
>> backups for the simple model databases in a different plan or you will get an
>> error in the tran log backup job (even though the tran log backups will
>> succeed).
>> If you can backup to a remote server using UNC paths if your mssqlserver
>> service uses a service account (that has the necessary rights to the file
>> system on the remote server), that would be preferable. If you cannot
>> however, then your current backup strategy is adequate.
>>
>> --
>> AndyP,
>> Sr. Database Administrator,
>> MCDBA 2003
>>
>> "George Schneider" wrote:
>> > I'm not sure if I'm doing this correctly to ensure recovery in case of a
>> > disaster. I have a SQL 2000 Sp4 server, this server has not tape drive
>> > attached to it. What I'm doing is during the night I run a backup through a
>> > maintenance job in enterprise manager to the BACKUP directory in the SQL file
>> > structure. On another server that has a tape drive I'm backing up this
>> > BACKUP directory to tape. Should I be backing up anything else to ensure
>> > disaster recovery.
>> >
>> >
disaster. I have a SQL 2000 Sp4 server, this server has not tape drive
attached to it. What I'm doing is during the night I run a backup through a
maintenance job in enterprise manager to the BACKUP directory in the SQL file
structure. On another server that has a tape drive I'm backing up this
BACKUP directory to tape. Should I be backing up anything else to ensure
disaster recovery.In summary, ensure that you are backing-up the system databases (there is an
option in the maintenance plan wizard to do this) as well as your user
databases. Make the maintenance plan for the system databases separate from
your plans for the user databases. Also ensure that if you are doing tran log
backups on the databases that have full recovery model, that you have the
backups for the simple model databases in a different plan or you will get an
error in the tran log backup job (even though the tran log backups will
succeed).
If you can backup to a remote server using UNC paths if your mssqlserver
service uses a service account (that has the necessary rights to the file
system on the remote server), that would be preferable. If you cannot
however, then your current backup strategy is adequate.
AndyP,
Sr. Database Administrator,
MCDBA 2003
"George Schneider" wrote:
> I'm not sure if I'm doing this correctly to ensure recovery in case of a
> disaster. I have a SQL 2000 Sp4 server, this server has not tape drive
> attached to it. What I'm doing is during the night I run a backup through a
> maintenance job in enterprise manager to the BACKUP directory in the SQL file
> structure. On another server that has a tape drive I'm backing up this
> BACKUP directory to tape. Should I be backing up anything else to ensure
> disaster recovery.
>|||I currently have all databses under on Maintenance plan. Why is it
neccessary to seperate the system and user db's into two?
"AndyP" wrote:
> In summary, ensure that you are backing-up the system databases (there is an
> option in the maintenance plan wizard to do this) as well as your user
> databases. Make the maintenance plan for the system databases separate from
> your plans for the user databases. Also ensure that if you are doing tran log
> backups on the databases that have full recovery model, that you have the
> backups for the simple model databases in a different plan or you will get an
> error in the tran log backup job (even though the tran log backups will
> succeed).
> If you can backup to a remote server using UNC paths if your mssqlserver
> service uses a service account (that has the necessary rights to the file
> system on the remote server), that would be preferable. If you cannot
> however, then your current backup strategy is adequate.
>
> --
> AndyP,
> Sr. Database Administrator,
> MCDBA 2003
>
> "George Schneider" wrote:
> > I'm not sure if I'm doing this correctly to ensure recovery in case of a
> > disaster. I have a SQL 2000 Sp4 server, this server has not tape drive
> > attached to it. What I'm doing is during the night I run a backup through a
> > maintenance job in enterprise manager to the BACKUP directory in the SQL file
> > structure. On another server that has a tape drive I'm backing up this
> > BACKUP directory to tape. Should I be backing up anything else to ensure
> > disaster recovery.
> >
> >|||Your plans will fail in an ungraceful manner if you have database in both full and simple recovery
mode and you try to do log backups in such a plan.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"George Schneider" <georgedschneider@.news.postalias> wrote in message
news:0C3B4830-8855-45BF-8CC4-84C27E5EF174@.microsoft.com...
>I currently have all databses under on Maintenance plan. Why is it
> neccessary to seperate the system and user db's into two?
> "AndyP" wrote:
>> In summary, ensure that you are backing-up the system databases (there is an
>> option in the maintenance plan wizard to do this) as well as your user
>> databases. Make the maintenance plan for the system databases separate from
>> your plans for the user databases. Also ensure that if you are doing tran log
>> backups on the databases that have full recovery model, that you have the
>> backups for the simple model databases in a different plan or you will get an
>> error in the tran log backup job (even though the tran log backups will
>> succeed).
>> If you can backup to a remote server using UNC paths if your mssqlserver
>> service uses a service account (that has the necessary rights to the file
>> system on the remote server), that would be preferable. If you cannot
>> however, then your current backup strategy is adequate.
>>
>> --
>> AndyP,
>> Sr. Database Administrator,
>> MCDBA 2003
>>
>> "George Schneider" wrote:
>> > I'm not sure if I'm doing this correctly to ensure recovery in case of a
>> > disaster. I have a SQL 2000 Sp4 server, this server has not tape drive
>> > attached to it. What I'm doing is during the night I run a backup through a
>> > maintenance job in enterprise manager to the BACKUP directory in the SQL file
>> > structure. On another server that has a tape drive I'm backing up this
>> > BACKUP directory to tape. Should I be backing up anything else to ensure
>> > disaster recovery.
>> >
>> >
Tuesday, February 14, 2012
Backup
I'm not sure if I'm doing this correctly to ensure recovery in case of a
disaster. I have a SQL 2000 Sp4 server, this server has not tape drive
attached to it. What I'm doing is during the night I run a backup through
a
maintenance job in enterprise manager to the BACKUP directory in the SQL fil
e
structure. On another server that has a tape drive I'm backing up this
BACKUP directory to tape. Should I be backing up anything else to ensure
disaster recovery.In summary, ensure that you are backing-up the system databases (there is an
option in the maintenance plan wizard to do this) as well as your user
databases. Make the maintenance plan for the system databases separate from
your plans for the user databases. Also ensure that if you are doing tran lo
g
backups on the databases that have full recovery model, that you have the
backups for the simple model databases in a different plan or you will get a
n
error in the tran log backup job (even though the tran log backups will
succeed).
If you can backup to a remote server using UNC paths if your mssqlserver
service uses a service account (that has the necessary rights to the file
system on the remote server), that would be preferable. If you cannot
however, then your current backup strategy is adequate.
AndyP,
Sr. Database Administrator,
MCDBA 2003
"George Schneider" wrote:
> I'm not sure if I'm doing this correctly to ensure recovery in case of a
> disaster. I have a SQL 2000 Sp4 server, this server has not tape drive
> attached to it. What I'm doing is during the night I run a backup throug
h a
> maintenance job in enterprise manager to the BACKUP directory in the SQL f
ile
> structure. On another server that has a tape drive I'm backing up this
> BACKUP directory to tape. Should I be backing up anything else to ensure
> disaster recovery.
>|||I currently have all databses under on Maintenance plan. Why is it
neccessary to seperate the system and user db's into two?
"AndyP" wrote:
[vbcol=seagreen]
> In summary, ensure that you are backing-up the system databases (there is
an
> option in the maintenance plan wizard to do this) as well as your user
> databases. Make the maintenance plan for the system databases separate fro
m
> your plans for the user databases. Also ensure that if you are doing tran
log
> backups on the databases that have full recovery model, that you have the
> backups for the simple model databases in a different plan or you will get
an
> error in the tran log backup job (even though the tran log backups will
> succeed).
> If you can backup to a remote server using UNC paths if your mssqlserver
> service uses a service account (that has the necessary rights to the file
> system on the remote server), that would be preferable. If you cannot
> however, then your current backup strategy is adequate.
>
> --
> AndyP,
> Sr. Database Administrator,
> MCDBA 2003
>
> "George Schneider" wrote:
>|||Your plans will fail in an ungraceful manner if you have database in both fu
ll and simple recovery
mode and you try to do log backups in such a plan.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"George Schneider" <georgedschneider@.news.postalias> wrote in message
news:0C3B4830-8855-45BF-8CC4-84C27E5EF174@.microsoft.com...[vbcol=seagreen]
>I currently have all databses under on Maintenance plan. Why is it
> neccessary to seperate the system and user db's into two?
> "AndyP" wrote:
>
disaster. I have a SQL 2000 Sp4 server, this server has not tape drive
attached to it. What I'm doing is during the night I run a backup through
a
maintenance job in enterprise manager to the BACKUP directory in the SQL fil
e
structure. On another server that has a tape drive I'm backing up this
BACKUP directory to tape. Should I be backing up anything else to ensure
disaster recovery.In summary, ensure that you are backing-up the system databases (there is an
option in the maintenance plan wizard to do this) as well as your user
databases. Make the maintenance plan for the system databases separate from
your plans for the user databases. Also ensure that if you are doing tran lo
g
backups on the databases that have full recovery model, that you have the
backups for the simple model databases in a different plan or you will get a
n
error in the tran log backup job (even though the tran log backups will
succeed).
If you can backup to a remote server using UNC paths if your mssqlserver
service uses a service account (that has the necessary rights to the file
system on the remote server), that would be preferable. If you cannot
however, then your current backup strategy is adequate.
AndyP,
Sr. Database Administrator,
MCDBA 2003
"George Schneider" wrote:
> I'm not sure if I'm doing this correctly to ensure recovery in case of a
> disaster. I have a SQL 2000 Sp4 server, this server has not tape drive
> attached to it. What I'm doing is during the night I run a backup throug
h a
> maintenance job in enterprise manager to the BACKUP directory in the SQL f
ile
> structure. On another server that has a tape drive I'm backing up this
> BACKUP directory to tape. Should I be backing up anything else to ensure
> disaster recovery.
>|||I currently have all databses under on Maintenance plan. Why is it
neccessary to seperate the system and user db's into two?
"AndyP" wrote:
[vbcol=seagreen]
> In summary, ensure that you are backing-up the system databases (there is
an
> option in the maintenance plan wizard to do this) as well as your user
> databases. Make the maintenance plan for the system databases separate fro
m
> your plans for the user databases. Also ensure that if you are doing tran
log
> backups on the databases that have full recovery model, that you have the
> backups for the simple model databases in a different plan or you will get
an
> error in the tran log backup job (even though the tran log backups will
> succeed).
> If you can backup to a remote server using UNC paths if your mssqlserver
> service uses a service account (that has the necessary rights to the file
> system on the remote server), that would be preferable. If you cannot
> however, then your current backup strategy is adequate.
>
> --
> AndyP,
> Sr. Database Administrator,
> MCDBA 2003
>
> "George Schneider" wrote:
>|||Your plans will fail in an ungraceful manner if you have database in both fu
ll and simple recovery
mode and you try to do log backups in such a plan.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"George Schneider" <georgedschneider@.news.postalias> wrote in message
news:0C3B4830-8855-45BF-8CC4-84C27E5EF174@.microsoft.com...[vbcol=seagreen]
>I currently have all databses under on Maintenance plan. Why is it
> neccessary to seperate the system and user db's into two?
> "AndyP" wrote:
>
Backup
I'm not sure if I'm doing this correctly to ensure recovery in case of a
disaster. I have a SQL 2000 Sp4 server, this server has not tape drive
attached to it. What I'm doing is during the night I run a backup through a
maintenance job in enterprise manager to the BACKUP directory in the SQL file
structure. On another server that has a tape drive I'm backing up this
BACKUP directory to tape. Should I be backing up anything else to ensure
disaster recovery.
In summary, ensure that you are backing-up the system databases (there is an
option in the maintenance plan wizard to do this) as well as your user
databases. Make the maintenance plan for the system databases separate from
your plans for the user databases. Also ensure that if you are doing tran log
backups on the databases that have full recovery model, that you have the
backups for the simple model databases in a different plan or you will get an
error in the tran log backup job (even though the tran log backups will
succeed).
If you can backup to a remote server using UNC paths if your mssqlserver
service uses a service account (that has the necessary rights to the file
system on the remote server), that would be preferable. If you cannot
however, then your current backup strategy is adequate.
AndyP,
Sr. Database Administrator,
MCDBA 2003
"George Schneider" wrote:
> I'm not sure if I'm doing this correctly to ensure recovery in case of a
> disaster. I have a SQL 2000 Sp4 server, this server has not tape drive
> attached to it. What I'm doing is during the night I run a backup through a
> maintenance job in enterprise manager to the BACKUP directory in the SQL file
> structure. On another server that has a tape drive I'm backing up this
> BACKUP directory to tape. Should I be backing up anything else to ensure
> disaster recovery.
>
|||I currently have all databses under on Maintenance plan. Why is it
neccessary to seperate the system and user db's into two?
"AndyP" wrote:
[vbcol=seagreen]
> In summary, ensure that you are backing-up the system databases (there is an
> option in the maintenance plan wizard to do this) as well as your user
> databases. Make the maintenance plan for the system databases separate from
> your plans for the user databases. Also ensure that if you are doing tran log
> backups on the databases that have full recovery model, that you have the
> backups for the simple model databases in a different plan or you will get an
> error in the tran log backup job (even though the tran log backups will
> succeed).
> If you can backup to a remote server using UNC paths if your mssqlserver
> service uses a service account (that has the necessary rights to the file
> system on the remote server), that would be preferable. If you cannot
> however, then your current backup strategy is adequate.
>
> --
> AndyP,
> Sr. Database Administrator,
> MCDBA 2003
>
> "George Schneider" wrote:
|||Your plans will fail in an ungraceful manner if you have database in both full and simple recovery
mode and you try to do log backups in such a plan.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"George Schneider" <georgedschneider@.news.postalias> wrote in message
news:0C3B4830-8855-45BF-8CC4-84C27E5EF174@.microsoft.com...[vbcol=seagreen]
>I currently have all databses under on Maintenance plan. Why is it
> neccessary to seperate the system and user db's into two?
> "AndyP" wrote:
disaster. I have a SQL 2000 Sp4 server, this server has not tape drive
attached to it. What I'm doing is during the night I run a backup through a
maintenance job in enterprise manager to the BACKUP directory in the SQL file
structure. On another server that has a tape drive I'm backing up this
BACKUP directory to tape. Should I be backing up anything else to ensure
disaster recovery.
In summary, ensure that you are backing-up the system databases (there is an
option in the maintenance plan wizard to do this) as well as your user
databases. Make the maintenance plan for the system databases separate from
your plans for the user databases. Also ensure that if you are doing tran log
backups on the databases that have full recovery model, that you have the
backups for the simple model databases in a different plan or you will get an
error in the tran log backup job (even though the tran log backups will
succeed).
If you can backup to a remote server using UNC paths if your mssqlserver
service uses a service account (that has the necessary rights to the file
system on the remote server), that would be preferable. If you cannot
however, then your current backup strategy is adequate.
AndyP,
Sr. Database Administrator,
MCDBA 2003
"George Schneider" wrote:
> I'm not sure if I'm doing this correctly to ensure recovery in case of a
> disaster. I have a SQL 2000 Sp4 server, this server has not tape drive
> attached to it. What I'm doing is during the night I run a backup through a
> maintenance job in enterprise manager to the BACKUP directory in the SQL file
> structure. On another server that has a tape drive I'm backing up this
> BACKUP directory to tape. Should I be backing up anything else to ensure
> disaster recovery.
>
|||I currently have all databses under on Maintenance plan. Why is it
neccessary to seperate the system and user db's into two?
"AndyP" wrote:
[vbcol=seagreen]
> In summary, ensure that you are backing-up the system databases (there is an
> option in the maintenance plan wizard to do this) as well as your user
> databases. Make the maintenance plan for the system databases separate from
> your plans for the user databases. Also ensure that if you are doing tran log
> backups on the databases that have full recovery model, that you have the
> backups for the simple model databases in a different plan or you will get an
> error in the tran log backup job (even though the tran log backups will
> succeed).
> If you can backup to a remote server using UNC paths if your mssqlserver
> service uses a service account (that has the necessary rights to the file
> system on the remote server), that would be preferable. If you cannot
> however, then your current backup strategy is adequate.
>
> --
> AndyP,
> Sr. Database Administrator,
> MCDBA 2003
>
> "George Schneider" wrote:
|||Your plans will fail in an ungraceful manner if you have database in both full and simple recovery
mode and you try to do log backups in such a plan.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"George Schneider" <georgedschneider@.news.postalias> wrote in message
news:0C3B4830-8855-45BF-8CC4-84C27E5EF174@.microsoft.com...[vbcol=seagreen]
>I currently have all databses under on Maintenance plan. Why is it
> neccessary to seperate the system and user db's into two?
> "AndyP" wrote:
Subscribe to:
Posts (Atom)