Backup Strategy

I am a newbie to SQL.
I am running SQL 2000 on a SBS 2003 R2 box. What is the best way to make
sure our databases are backed up in the event of a data loss or a crash?
Thanks,
Rich
The easiest way is to create a maintenance plan using the SQL Enterprise
Manager.
Or you can create jobs that use T-SQL statement to backup the databases.
Always make sure that the backup's are stored on offline storage, eg another
server or tapes.
The best way depends or your businessneeds and databasesize.
Robert Hartskeerl, MCTS
http://hartskeerl.nl/blogs/robert/
"Rikellent" wrote:

> I am a newbie to SQL.
> I am running SQL 2000 on a SBS 2003 R2 box. What is the best way to make
> sure our databases are backed up in the event of a data loss or a crash?
> Thanks,
> Rich
|||Hello,
You could use the maintenence wizard to create a backup plan and schedule
it. But I had lot of issues with maintenanceplans and so i went for TSQL
backup
script and schedule it using SQL Server agent.
Take a look into the below article:-
http://www.microsoft.com/india/msdn/articles/185.aspx
Thanks
Hari
"Rikellent" <Rikellent@.discussions.microsoft.com> wrote in message
news:BB10385E-8923-4AF7-B5B8-75F7B44CD993@.microsoft.com...
>I am a newbie to SQL.
> I am running SQL 2000 on a SBS 2003 R2 box. What is the best way to make
> sure our databases are backed up in the event of a data loss or a crash?
> Thanks,
> Rich

Backup strategy

Hello,
I manage a SQL Server that requires frequent backups to insure not
much data is lost in the event of a failure. Here is how backups are
performed currently:
Sunday, 1:00am
== * Full database backup of ALL databases
* Transaction log backup WITH INIT
Mon-Sat, 1:00am
== * Differential database backup of ALL databases
Daily, Hourly
== * Transaction log backup
I am currently having 2 problems. The first problem is that sometimes
on Sunday mornings when the job attempts to backup the transactions
logs WITH INIT the job will fail because the Daily, Hourly process is
also backing up at the same time. The second problem is that the
transaction log backups seem to grow larger and larger and take longer
and longer to complete. Is it really necessary to store the entire
week of transaction log backups when I'll always have a differential I
can apply for each day? The only purpose of the transaction log
backups is to insure we can restore to the latest point in time before
a failure occurs. There isn't a need to revert back to more than the
previous day's transaction log backup.
Is what I'm doing the best way? How can this be improved upon?
Thank you in advance for your time and efforts.
ShawnHi,
> Is it really necessary to store the entire
> week of transaction log backups when I'll always have a differential I
> can apply for each day? The only purpose of the transaction log
> backups is to insure we can restore to the latest point in time before
> a failure occurs. There isn't a need to revert back to more than the
> previous day's transaction log backup.
Based on these requirements you do not need an entire week of transaction
log backups. You just need the transaction log backups taken after your last
differential backup.
But most important, test your strategy restoring your database to another
database server using this combination of full, differential and transaction
log backups.
Hope this helps,
Ben Nevarez
"ITistic" wrote:
> Hello,
> I manage a SQL Server that requires frequent backups to insure not
> much data is lost in the event of a failure. Here is how backups are
> performed currently:
> Sunday, 1:00am
> ==> * Full database backup of ALL databases
> * Transaction log backup WITH INIT
> Mon-Sat, 1:00am
> ==> * Differential database backup of ALL databases
> Daily, Hourly
> ==> * Transaction log backup
> I am currently having 2 problems. The first problem is that sometimes
> on Sunday mornings when the job attempts to backup the transactions
> logs WITH INIT the job will fail because the Daily, Hourly process is
> also backing up at the same time. The second problem is that the
> transaction log backups seem to grow larger and larger and take longer
> and longer to complete. Is it really necessary to store the entire
> week of transaction log backups when I'll always have a differential I
> can apply for each day? The only purpose of the transaction log
> backups is to insure we can restore to the latest point in time before
> a failure occurs. There isn't a need to revert back to more than the
> previous day's transaction log backup.
> Is what I'm doing the best way? How can this be improved upon?
> Thank you in advance for your time and efforts.
> Shawn
>

Backup strategy

Hello,
I manage a SQL Server that requires frequent backups to insure not
much data is lost in the event of a failure. Here is how backups are
performed currently:
Sunday, 1:00am
==
* Full database backup of ALL databases
* Transaction log backup WITH INIT
Mon-Sat, 1:00am
==
* Differential database backup of ALL databases
Daily, Hourly
==
* Transaction log backup
I am currently having 2 problems. The first problem is that sometimes
on Sunday mornings when the job attempts to backup the transactions
logs WITH INIT the job will fail because the Daily, Hourly process is
also backing up at the same time. The second problem is that the
transaction log backups seem to grow larger and larger and take longer
and longer to complete. Is it really necessary to store the entire
week of transaction log backups when I'll always have a differential I
can apply for each day? The only purpose of the transaction log
backups is to insure we can restore to the latest point in time before
a failure occurs. There isn't a need to revert back to more than the
previous day's transaction log backup.
Is what I'm doing the best way? How can this be improved upon?
Thank you in advance for your time and efforts.
Shawn
Hi,

> Is it really necessary to store the entire
> week of transaction log backups when I'll always have a differential I
> can apply for each day? The only purpose of the transaction log
> backups is to insure we can restore to the latest point in time before
> a failure occurs. There isn't a need to revert back to more than the
> previous day's transaction log backup.
Based on these requirements you do not need an entire week of transaction
log backups. You just need the transaction log backups taken after your last
differential backup.
But most important, test your strategy restoring your database to another
database server using this combination of full, differential and transaction
log backups.
Hope this helps,
Ben Nevarez
"ITistic" wrote:

> Hello,
> I manage a SQL Server that requires frequent backups to insure not
> much data is lost in the event of a failure. Here is how backups are
> performed currently:
> Sunday, 1:00am
> ==
> * Full database backup of ALL databases
> * Transaction log backup WITH INIT
> Mon-Sat, 1:00am
> ==
> * Differential database backup of ALL databases
> Daily, Hourly
> ==
> * Transaction log backup
> I am currently having 2 problems. The first problem is that sometimes
> on Sunday mornings when the job attempts to backup the transactions
> logs WITH INIT the job will fail because the Daily, Hourly process is
> also backing up at the same time. The second problem is that the
> transaction log backups seem to grow larger and larger and take longer
> and longer to complete. Is it really necessary to store the entire
> week of transaction log backups when I'll always have a differential I
> can apply for each day? The only purpose of the transaction log
> backups is to insure we can restore to the latest point in time before
> a failure occurs. There isn't a need to revert back to more than the
> previous day's transaction log backup.
> Is what I'm doing the best way? How can this be improved upon?
> Thank you in advance for your time and efforts.
> Shawn
>

Backup Strategy

Hi,
for backups, do we need to back up the Temp DB as well?
What restoration strategy is recommended in the event of Reporting Services
failure?
regards
MattYes, it is a good idea if you want to avoid have to install RS again to
recreate the database.
Backup the ReportServer database, the encryption keys, and the config files
for you report manager and server.
See:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rsadmin/htm/arp_dbadmin_v1_4915.asp
http://support.microsoft.com/?kbid=842425
--
erik perez
www.solien.com
"Matt" <NoSpam:Matthew.Moran@.Computercorp.com.au> wrote in message
news:uJhSpvIlEHA.536@.TK2MSFTNGP11.phx.gbl...
> Hi,
> for backups, do we need to back up the Temp DB as well?
> What restoration strategy is recommended in the event of Reporting
Services
> failure?
> regards
> Matt
>|||Thanks Erik. Great!!
"erik perez" <erik.nojunkmail.at.solien.com> wrote in message
news:OEmiesOlEHA.596@.TK2MSFTNGP11.phx.gbl...
> Yes, it is a good idea if you want to avoid have to install RS again to
> recreate the database.
> Backup the ReportServer database, the encryption keys, and the config
files
> for you report manager and server.
> See:
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rsadmin/htm/arp_dbadmin_v1_4915.asp
> http://support.microsoft.com/?kbid=842425
> --
> erik perez
> www.solien.com
>
> "Matt" <NoSpam:Matthew.Moran@.Computercorp.com.au> wrote in message
> news:uJhSpvIlEHA.536@.TK2MSFTNGP11.phx.gbl...
> > Hi,
> >
> > for backups, do we need to back up the Temp DB as well?
> >
> > What restoration strategy is recommended in the event of Reporting
> Services
> > failure?
> >
> > regards
> >
> > Matt
> >
> >
>