Backup strategy

I have to build a backup method for my factory.
I have sql server 2000 and I have to save a DB that is used from 8.00
to 20.00.
Now I have a complete backup that run every night and a differential at
12.30 every day.
The complete have the name of the day, so I have seven different files
for every day of the week. Also the differential one.
I have not log backups.
So, if I'd like to make more backup in the working time (when users use
DB) I have to increase differential backups (with time of backup in the
name of file) or I have to add log backups?
If I make log backups, I have to create one day file (with no
overwrite) or I have to create in a day many files with day of week and
time of backup in the name of file?
In this scenario, I have to use NO_TRUNCATE or TRUNCATE for log
backups?
Thanks to all.If you don't want log backups then set the recovery model to simple - that
will truncate the log on every backup.
Include the date rather than the day in the backup files.
mydb_full_yyyymmdd_hhmmss.bak
mydb_diff_yyyymmdd_hhmmss.bak
If you want to include log backups then do the same
mydb_log_yyyymmdd_hhmmss.bak
You can now add diff backups whenever you wish.
From what you say you might want to consider log backups though.
Have a look at this sp
It will take full, diff and log backups for all databases on the server and
delete old files - you can control what it does from a table in the admin
database.
http://www.nigelrivett.net/SQLAdmin/BackupAllDatabases.html
There is also an sp there to do the restores including the log sequence and
latest full/diff.
"giminera@.libero.it" wrote:
> I have to build a backup method for my factory.
> I have sql server 2000 and I have to save a DB that is used from 8.00
> to 20.00.
> Now I have a complete backup that run every night and a differential at
> 12.30 every day.
> The complete have the name of the day, so I have seven different files
> for every day of the week. Also the differential one.
> I have not log backups.
> So, if I'd like to make more backup in the working time (when users use
> DB) I have to increase differential backups (with time of backup in the
> name of file) or I have to add log backups?
> If I make log backups, I have to create one day file (with no
> overwrite) or I have to create in a day many files with day of week and
> time of backup in the name of file?
> In this scenario, I have to use NO_TRUNCATE or TRUNCATE for log
> backups?
> Thanks to all.
>|||giminera@.libero.it wrote:
> I have to build a backup method for my factory.
> I have sql server 2000 and I have to save a DB that is used from 8.00
> to 20.00.
> Now I have a complete backup that run every night and a differential at
> 12.30 every day.
> The complete have the name of the day, so I have seven different files
> for every day of the week. Also the differential one.
> I have not log backups.
> So, if I'd like to make more backup in the working time (when users use
> DB) I have to increase differential backups (with time of backup in the
> name of file) or I have to add log backups?
> If I make log backups, I have to create one day file (with no
> overwrite) or I have to create in a day many files with day of week and
> time of backup in the name of file?
> In this scenario, I have to use NO_TRUNCATE or TRUNCATE for log
> backups?
> Thanks to all.
>
I have a script that you can schedule to run at frequent intervals (I
run it every 5 minutes) that will automatically handle full backups and
t-log backups for you, for all databases on the server.
http://realsqlguy.com/twiki/bin/view/RealSQLGuy/AutomaticBackupOfAllDatabases
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||A transaction log backup is actually recommended for your scenario.
Just a follow up question on this one. I have a full database backup and
log shipping configured. I want to include a differential backup so as to
make restoration a lot easy for the server since I am looking at around 50
databases on single server. Will the differential backup work with my
existing plan?
"Nigel Rivett" wrote:
> If you don't want log backups then set the recovery model to simple - that
> will truncate the log on every backup.
> Include the date rather than the day in the backup files.
> mydb_full_yyyymmdd_hhmmss.bak
> mydb_diff_yyyymmdd_hhmmss.bak
> If you want to include log backups then do the same
> mydb_log_yyyymmdd_hhmmss.bak
> You can now add diff backups whenever you wish.
> From what you say you might want to consider log backups though.
> Have a look at this sp
> It will take full, diff and log backups for all databases on the server and
> delete old files - you can control what it does from a table in the admin
> database.
> http://www.nigelrivett.net/SQLAdmin/BackupAllDatabases.html
> There is also an sp there to do the restores including the log sequence and
> latest full/diff.
>
>
>
> "giminera@.libero.it" wrote:
> > I have to build a backup method for my factory.
> > I have sql server 2000 and I have to save a DB that is used from 8.00
> > to 20.00.
> > Now I have a complete backup that run every night and a differential at
> > 12.30 every day.
> > The complete have the name of the day, so I have seven different files
> > for every day of the week. Also the differential one.
> > I have not log backups.
> > So, if I'd like to make more backup in the working time (when users use
> > DB) I have to increase differential backups (with time of backup in the
> > name of file) or I have to add log backups?
> > If I make log backups, I have to create one day file (with no
> > overwrite) or I have to create in a day many files with day of week and
> > time of backup in the name of file?
> > In this scenario, I have to use NO_TRUNCATE or TRUNCATE for log
> > backups?
> > Thanks to all.
> >
> >

Backup strategy

I have to build a backup method for my factory.
I have sql server 2000 and I have to save a DB that is used from 8.00
to 20.00.
Now I have a complete backup that run every night and a differential at
12.30 every day.
The complete have the name of the day, so I have seven different files
for every day of the week. Also the differential one.
I have not log backups.
So, if I'd like to make more backup in the working time (when users use
DB) I have to increase differential backups (with time of backup in the
name of file) or I have to add log backups?
If I make log backups, I have to create one day file (with no
overwrite) or I have to create in a day many files with day of week and
time of backup in the name of file?
In this scenario, I have to use NO_TRUNCATE or TRUNCATE for log
backups?
Thanks to all.If you don't want log backups then set the recovery model to simple - that
will truncate the log on every backup.
Include the date rather than the day in the backup files.
mydb_full_yyyymmdd_hhmmss.bak
mydb_diff_yyyymmdd_hhmmss.bak
If you want to include log backups then do the same
mydb_log_yyyymmdd_hhmmss.bak
You can now add diff backups whenever you wish.
From what you say you might want to consider log backups though.
Have a look at this sp
It will take full, diff and log backups for all databases on the server and
delete old files - you can control what it does from a table in the admin
database.
http://www.nigelrivett.net/SQLAdmin...lDatabases.html
There is also an sp there to do the restores including the log sequence and
latest full/diff.
"giminera@.libero.it" wrote:

> I have to build a backup method for my factory.
> I have sql server 2000 and I have to save a DB that is used from 8.00
> to 20.00.
> Now I have a complete backup that run every night and a differential at
> 12.30 every day.
> The complete have the name of the day, so I have seven different files
> for every day of the week. Also the differential one.
> I have not log backups.
> So, if I'd like to make more backup in the working time (when users use
> DB) I have to increase differential backups (with time of backup in the
> name of file) or I have to add log backups?
> If I make log backups, I have to create one day file (with no
> overwrite) or I have to create in a day many files with day of week and
> time of backup in the name of file?
> In this scenario, I have to use NO_TRUNCATE or TRUNCATE for log
> backups?
> Thanks to all.
>|||giminera@.libero.it wrote:
> I have to build a backup method for my factory.
> I have sql server 2000 and I have to save a DB that is used from 8.00
> to 20.00.
> Now I have a complete backup that run every night and a differential at
> 12.30 every day.
> The complete have the name of the day, so I have seven different files
> for every day of the week. Also the differential one.
> I have not log backups.
> So, if I'd like to make more backup in the working time (when users use
> DB) I have to increase differential backups (with time of backup in the
> name of file) or I have to add log backups?
> If I make log backups, I have to create one day file (with no
> overwrite) or I have to create in a day many files with day of week and
> time of backup in the name of file?
> In this scenario, I have to use NO_TRUNCATE or TRUNCATE for log
> backups?
> Thanks to all.
>
I have a script that you can schedule to run at frequent intervals (I
run it every 5 minutes) that will automatically handle full backups and
t-log backups for you, for all databases on the server.
http://realsqlguy.com/twiki/bin/vie...realsqlguy.com|||A transaction log backup is actually recommended for your scenario.
Just a follow up question on this one. I have a full database backup and
log shipping configured. I want to include a differential backup so as to
make restoration a lot easy for the server since I am looking at around 50
databases on single server. Will the differential backup work with my
existing plan?
"Nigel Rivett" wrote:
[vbcol=seagreen]
> If you don't want log backups then set the recovery model to simple - that
> will truncate the log on every backup.
> Include the date rather than the day in the backup files.
> mydb_full_yyyymmdd_hhmmss.bak
> mydb_diff_yyyymmdd_hhmmss.bak
> If you want to include log backups then do the same
> mydb_log_yyyymmdd_hhmmss.bak
> You can now add diff backups whenever you wish.
> From what you say you might want to consider log backups though.
> Have a look at this sp
> It will take full, diff and log backups for all databases on the server an
d
> delete old files - you can control what it does from a table in the admin
> database.
> http://www.nigelrivett.net/SQLAdmin...lDatabases.html
> There is also an sp there to do the restores including the log sequence an
d
> latest full/diff.
>
>
>
> "giminera@.libero.it" wrote:
>

Backup server

I currently have a main database server and want to implement a backup
server that replicates the data in my main server.
What is the best method of implementing this? I really don't know where to
start so even a pointer at some reading material would be helpful. Any
advice will be appreciated.
Hi
Look up Log Shipping and Replication in BOL (or the Microsoft web site).
Those are your 2 built-in options.
Regards
Mike
"Michael" wrote:

> I currently have a main database server and want to implement a backup
> server that replicates the data in my main server.
> What is the best method of implementing this? I really don't know where to
> start so even a pointer at some reading material would be helpful. Any
> advice will be appreciated.
>
>
|||That depends on if you want to copy all of the data or a subset of the data.
If you want all the data and system objects and your destination database
can go offline while the transaction logs are applied, and is read only,
then log shipping is for you.
If you want only a subset of the data and don't care about the system
objects (like permissions, etc), need continualy accessability of the
destination database, and want to be able to update the destination database
use replication. Note that if you are not careful the updates you make on
the destination database can disrupt the replication process, but you can
partition your data so it doesn't.
"Michael" <michael@.hello.com> wrote in message
news:356vljF4i904nU1@.individual.net...
>I currently have a main database server and want to implement a backup
>server that replicates the data in my main server.
> What is the best method of implementing this? I really don't know where to
> start so even a pointer at some reading material would be helpful. Any
> advice will be appreciated.
>

Backup server

I currently have a main database server and want to implement a backup
server that replicates the data in my main server.
What is the best method of implementing this? I really don't know where to
start so even a pointer at some reading material would be helpful. Any
advice will be appreciated.
Hi
Look up Log Shipping and Replication in BOL (or the Microsoft web site).
Those are your 2 built-in options.
Regards
Mike
"Michael" wrote:

> I currently have a main database server and want to implement a backup
> server that replicates the data in my main server.
> What is the best method of implementing this? I really don't know where to
> start so even a pointer at some reading material would be helpful. Any
> advice will be appreciated.
>
>
|||That depends on if you want to copy all of the data or a subset of the data.
If you want all the data and system objects and your destination database
can go offline while the transaction logs are applied, and is read only,
then log shipping is for you.
If you want only a subset of the data and don't care about the system
objects (like permissions, etc), need continualy accessability of the
destination database, and want to be able to update the destination database
use replication. Note that if you are not careful the updates you make on
the destination database can disrupt the replication process, but you can
partition your data so it doesn't.
"Michael" <michael@.hello.com> wrote in message
news:356vljF4i904nU1@.individual.net...
>I currently have a main database server and want to implement a backup
>server that replicates the data in my main server.
> What is the best method of implementing this? I really don't know where to
> start so even a pointer at some reading material would be helpful. Any
> advice will be appreciated.
>
sql

Backup server

I currently have a main database server and want to implement a backup
server that replicates the data in my main server.
What is the best method of implementing this? I really don't know where to
start so even a pointer at some reading material would be helpful. Any
advice will be appreciated.Hi
Look up Log Shipping and Replication in BOL (or the Microsoft web site).
Those are your 2 built-in options.
Regards
Mike
"Michael" wrote:
> I currently have a main database server and want to implement a backup
> server that replicates the data in my main server.
> What is the best method of implementing this? I really don't know where to
> start so even a pointer at some reading material would be helpful. Any
> advice will be appreciated.
>
>|||That depends on if you want to copy all of the data or a subset of the data.
If you want all the data and system objects and your destination database
can go offline while the transaction logs are applied, and is read only,
then log shipping is for you.
If you want only a subset of the data and don't care about the system
objects (like permissions, etc), need continualy accessability of the
destination database, and want to be able to update the destination database
use replication. Note that if you are not careful the updates you make on
the destination database can disrupt the replication process, but you can
partition your data so it doesn't.
"Michael" <michael@.hello.com> wrote in message
news:356vljF4i904nU1@.individual.net...
>I currently have a main database server and want to implement a backup
>server that replicates the data in my main server.
> What is the best method of implementing this? I really don't know where to
> start so even a pointer at some reading material would be helpful. Any
> advice will be appreciated.
>

Backup server

I currently have a main database server and want to implement a backup
server that replicates the data in my main server.
What is the best method of implementing this? I really don't know where to
start so even a pointer at some reading material would be helpful. Any
advice will be appreciated.Hi
Look up Log Shipping and Replication in BOL (or the Microsoft web site).
Those are your 2 built-in options.
Regards
Mike
"Michael" wrote:

> I currently have a main database server and want to implement a backup
> server that replicates the data in my main server.
> What is the best method of implementing this? I really don't know where to
> start so even a pointer at some reading material would be helpful. Any
> advice will be appreciated.
>
>|||That depends on if you want to copy all of the data or a subset of the data.
If you want all the data and system objects and your destination database
can go offline while the transaction logs are applied, and is read only,
then log shipping is for you.
If you want only a subset of the data and don't care about the system
objects (like permissions, etc), need continualy accessability of the
destination database, and want to be able to update the destination database
use replication. Note that if you are not careful the updates you make on
the destination database can disrupt the replication process, but you can
partition your data so it doesn't.
"Michael" <michael@.hello.com> wrote in message
news:356vljF4i904nU1@.individual.net...
>I currently have a main database server and want to implement a backup
>server that replicates the data in my main server.
> What is the best method of implementing this? I really don't know where to
> start so even a pointer at some reading material would be helpful. Any
> advice will be appreciated.
>

backup method question

hi
We are evaluating our backup plans. We currently do a live backup with a
backup exec SQL agent. Thinking about doing it to disk instead without
using veritas, just dumping the database to a file and then backing up
the file. My veritas rep is telling me it will be hard to do a restore
that way.
Is that true? Any other suggestions on backing up?
Thanks
Will
What your Veritas rep is saying is "If you backup to disk, then you won't
need to pay me for an overpriced and underfeatured SQL agent for each
server". Backup to disk and archive to tape is the preferred method for SQL
backups. Make sure you don't backup to the same disk as your data or log
files. I prefer to backup across a dedicated network link to a file server.
That file server is also my tape host so it can backup the files locally.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Will Kubly" <wkubly@.wi.rr.com> wrote in message
news:u0KoQkAIFHA.1392@.TK2MSFTNGP10.phx.gbl...
> hi
> We are evaluating our backup plans. We currently do a live backup with a
> backup exec SQL agent. Thinking about doing it to disk instead without
> using veritas, just dumping the database to a file and then backing up
> the file. My veritas rep is telling me it will be hard to do a restore
> that way.
> Is that true? Any other suggestions on backing up?
> Thanks
> Will
|||Geoff N. Hiten wrote:
> What your Veritas rep is saying is "If you backup to disk, then you won't
> need to pay me for an overpriced and underfeatured SQL agent for each
> server". Backup to disk and archive to tape is the preferred method for SQL
> backups. Make sure you don't backup to the same disk as your data or log
> files. I prefer to backup across a dedicated network link to a file server.
> That file server is also my tape host so it can backup the files locally.
>
That is kinda what I thought. I am not an SQL guru by any means. I do
more of the plumging. Are there any special considerations to restoring
that file into SQL?
Thanks
Will
|||Hi
I was using backup exec to do the backup of the sql server 2000 database.
It is easy and has good GUI to restore.
But apart from that I did not find any compelling reasons to use it.
I am doing a backup on the USB attached Network drive and it takes about the
same time as taking it on tape.
Mangesh
"Geoff N. Hiten" wrote:

> What your Veritas rep is saying is "If you backup to disk, then you won't
> need to pay me for an overpriced and underfeatured SQL agent for each
> server". Backup to disk and archive to tape is the preferred method for SQL
> backups. Make sure you don't backup to the same disk as your data or log
> files. I prefer to backup across a dedicated network link to a file server.
> That file server is also my tape host so it can backup the files locally.
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "Will Kubly" <wkubly@.wi.rr.com> wrote in message
> news:u0KoQkAIFHA.1392@.TK2MSFTNGP10.phx.gbl...
>
>
|||SQL backup files are self-contained and self-describing. That is, they
contain all the information required to recreate the database on the
original or any other SQL server. I strongly suggest you read the section
in BOL (Books On-Line) on Backing Up and Restoring Databases in the
Administering SQL Server section. There are some decisions you must make
when you set up a database or there will be painful consequences down the
road. Read and understand this section now, rather than when your system is
down.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Will Kubly" <wkubly@.wi.rr.com> wrote in message
news:ep68s0AIFHA.560@.TK2MSFTNGP12.phx.gbl...[vbcol=seagreen]
> Geoff N. Hiten wrote:
won't[vbcol=seagreen]
SQL[vbcol=seagreen]
log[vbcol=seagreen]
server.[vbcol=seagreen]
locally.
> That is kinda what I thought. I am not an SQL guru by any means. I do
> more of the plumging. Are there any special considerations to restoring
> that file into SQL?
> Thanks
> Will

backup method question

hi
We are evaluating our backup plans. We currently do a live backup with a
backup exec SQL agent. Thinking about doing it to disk instead without
using veritas, just dumping the database to a file and then backing up
the file. My veritas rep is telling me it will be hard to do a restore
that way.
Is that true? Any other suggestions on backing up?
Thanks
WillWhat your Veritas rep is saying is "If you backup to disk, then you won't
need to pay me for an overpriced and underfeatured SQL agent for each
server". Backup to disk and archive to tape is the preferred method for SQL
backups. Make sure you don't backup to the same disk as your data or log
files. I prefer to backup across a dedicated network link to a file server.
That file server is also my tape host so it can backup the files locally.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Will Kubly" <wkubly@.wi.rr.com> wrote in message
news:u0KoQkAIFHA.1392@.TK2MSFTNGP10.phx.gbl...
> hi
> We are evaluating our backup plans. We currently do a live backup with a
> backup exec SQL agent. Thinking about doing it to disk instead without
> using veritas, just dumping the database to a file and then backing up
> the file. My veritas rep is telling me it will be hard to do a restore
> that way.
> Is that true? Any other suggestions on backing up?
> Thanks
> Will|||Geoff N. Hiten wrote:
> What your Veritas rep is saying is "If you backup to disk, then you won't
> need to pay me for an overpriced and underfeatured SQL agent for each
> server". Backup to disk and archive to tape is the preferred method for S
QL
> backups. Make sure you don't backup to the same disk as your data or log
> files. I prefer to backup across a dedicated network link to a file serve
r.
> That file server is also my tape host so it can backup the files locally.
>
That is kinda what I thought. I am not an SQL guru by any means. I do
more of the plumging. Are there any special considerations to restoring
that file into SQL?
Thanks
Will|||Hi
I was using backup exec to do the backup of the sql server 2000 database.
It is easy and has good GUI to restore.
But apart from that I did not find any compelling reasons to use it.
I am doing a backup on the USB attached Network drive and it takes about the
same time as taking it on tape.
Mangesh
"Geoff N. Hiten" wrote:

> What your Veritas rep is saying is "If you backup to disk, then you won't
> need to pay me for an overpriced and underfeatured SQL agent for each
> server". Backup to disk and archive to tape is the preferred method for S
QL
> backups. Make sure you don't backup to the same disk as your data or log
> files. I prefer to backup across a dedicated network link to a file serve
r.
> That file server is also my tape host so it can backup the files locally.
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "Will Kubly" <wkubly@.wi.rr.com> wrote in message
> news:u0KoQkAIFHA.1392@.TK2MSFTNGP10.phx.gbl...
>
>|||SQL backup files are self-contained and self-describing. That is, they
contain all the information required to recreate the database on the
original or any other SQL server. I strongly suggest you read the section
in BOL (Books On-Line) on Backing Up and Restoring Databases in the
Administering SQL Server section. There are some decisions you must make
when you set up a database or there will be painful consequences down the
road. Read and understand this section now, rather than when your system is
down.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Will Kubly" <wkubly@.wi.rr.com> wrote in message
news:ep68s0AIFHA.560@.TK2MSFTNGP12.phx.gbl...
> Geoff N. Hiten wrote:
won't[vbcol=seagreen]
SQL[vbcol=seagreen]
log[vbcol=seagreen]
server.[vbcol=seagreen]
locally.[vbcol=seagreen]
> That is kinda what I thought. I am not an SQL guru by any means. I do
> more of the plumging. Are there any special considerations to restoring
> that file into SQL?
> Thanks
> Will

backup method question

hi
We are evaluating our backup plans. We currently do a live backup with a
backup exec SQL agent. Thinking about doing it to disk instead without
using veritas, just dumping the database to a file and then backing up
the file. My veritas rep is telling me it will be hard to do a restore
that way.
Is that true? Any other suggestions on backing up?
Thanks
WillWhat your Veritas rep is saying is "If you backup to disk, then you won't
need to pay me for an overpriced and underfeatured SQL agent for each
server". Backup to disk and archive to tape is the preferred method for SQL
backups. Make sure you don't backup to the same disk as your data or log
files. I prefer to backup across a dedicated network link to a file server.
That file server is also my tape host so it can backup the files locally.
--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Will Kubly" <wkubly@.wi.rr.com> wrote in message
news:u0KoQkAIFHA.1392@.TK2MSFTNGP10.phx.gbl...
> hi
> We are evaluating our backup plans. We currently do a live backup with a
> backup exec SQL agent. Thinking about doing it to disk instead without
> using veritas, just dumping the database to a file and then backing up
> the file. My veritas rep is telling me it will be hard to do a restore
> that way.
> Is that true? Any other suggestions on backing up?
> Thanks
> Will|||Geoff N. Hiten wrote:
> What your Veritas rep is saying is "If you backup to disk, then you won't
> need to pay me for an overpriced and underfeatured SQL agent for each
> server". Backup to disk and archive to tape is the preferred method for SQL
> backups. Make sure you don't backup to the same disk as your data or log
> files. I prefer to backup across a dedicated network link to a file server.
> That file server is also my tape host so it can backup the files locally.
>
That is kinda what I thought. I am not an SQL guru by any means. I do
more of the plumging. Are there any special considerations to restoring
that file into SQL?
Thanks
Will|||Hi
I was using backup exec to do the backup of the sql server 2000 database.
It is easy and has good GUI to restore.
But apart from that I did not find any compelling reasons to use it.
I am doing a backup on the USB attached Network drive and it takes about the
same time as taking it on tape.
Mangesh
"Geoff N. Hiten" wrote:
> What your Veritas rep is saying is "If you backup to disk, then you won't
> need to pay me for an overpriced and underfeatured SQL agent for each
> server". Backup to disk and archive to tape is the preferred method for SQL
> backups. Make sure you don't backup to the same disk as your data or log
> files. I prefer to backup across a dedicated network link to a file server.
> That file server is also my tape host so it can backup the files locally.
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "Will Kubly" <wkubly@.wi.rr.com> wrote in message
> news:u0KoQkAIFHA.1392@.TK2MSFTNGP10.phx.gbl...
> > hi
> >
> > We are evaluating our backup plans. We currently do a live backup with a
> > backup exec SQL agent. Thinking about doing it to disk instead without
> > using veritas, just dumping the database to a file and then backing up
> > the file. My veritas rep is telling me it will be hard to do a restore
> > that way.
> > Is that true? Any other suggestions on backing up?
> >
> > Thanks
> >
> > Will
>
>|||SQL backup files are self-contained and self-describing. That is, they
contain all the information required to recreate the database on the
original or any other SQL server. I strongly suggest you read the section
in BOL (Books On-Line) on Backing Up and Restoring Databases in the
Administering SQL Server section. There are some decisions you must make
when you set up a database or there will be painful consequences down the
road. Read and understand this section now, rather than when your system is
down.
--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Will Kubly" <wkubly@.wi.rr.com> wrote in message
news:ep68s0AIFHA.560@.TK2MSFTNGP12.phx.gbl...
> Geoff N. Hiten wrote:
> > What your Veritas rep is saying is "If you backup to disk, then you
won't
> > need to pay me for an overpriced and underfeatured SQL agent for each
> > server". Backup to disk and archive to tape is the preferred method for
SQL
> > backups. Make sure you don't backup to the same disk as your data or
log
> > files. I prefer to backup across a dedicated network link to a file
server.
> > That file server is also my tape host so it can backup the files
locally.
> >
> That is kinda what I thought. I am not an SQL guru by any means. I do
> more of the plumging. Are there any special considerations to restoring
> that file into SQL?
> Thanks
> Will

backup management

I there a backup method to automatically disconnect existing DB users and
prevent
additional logins during backup.
Thanks,
Ed
Hi
No. You need to write a script to KILL the users.
You do not need to kick users off the server, unless you have a good reason
to do it as Backups can be run under full usage..
Also, if the client applications are not well behaved, they might post
partial transactions.
Regards
Mike
"coenzyme" wrote:

> I there a backup method to automatically disconnect existing DB users and
> prevent
> additional logins during backup.
> Thanks,
> Ed

backup management

I there a backup method to automatically disconnect existing DB users and
prevent
additional logins during backup.
Thanks,
EdHi
No. You need to write a script to KILL the users.
You do not need to kick users off the server, unless you have a good reason
to do it as Backups can be run under full usage..
Also, if the client applications are not well behaved, they might post
partial transactions.
Regards
Mike
"coenzyme" wrote:

> I there a backup method to automatically disconnect existing DB users and
> prevent
> additional logins during backup.
> Thanks,
> Ed

backup management

I there a backup method to automatically disconnect existing DB users and
prevent
additional logins during backup.
Thanks,
EdHi
No. You need to write a script to KILL the users.
You do not need to kick users off the server, unless you have a good reason
to do it as Backups can be run under full usage..
Also, if the client applications are not well behaved, they might post
partial transactions.
Regards
Mike
"coenzyme" wrote:
> I there a backup method to automatically disconnect existing DB users and
> prevent
> additional logins during backup.
> Thanks,
> Ed