Download SQL Server 2000 Backup

FSI (FM Solutions) Limited
Technical Memo
SQL Server 2000 Backup
Backing up and restoring databases and
transaction logs is a method that SQL Server
provides to protect from data loss. The backup
operation creates a copy of a database, which
can be used to restore the database if media
failure occurs or if the database is somehow
damaged (for example, from user errors).
SQL Server 2000 supports the following kinds
of backup:
 Full database backup (it is a full copy of
the database)
 Transaction log backup (it contains a
copy of the transaction log only)
 Differential backup (it contains a copy of
only the database pages modified since
the last full database backup)
 File or File Group (copy’s only the
specified file or group)
 File Differential (all changed parts in file
since the last file backup)
SQL Server 2000 supports three recovery
models, which determine how your data is
backed up and what your exposure to data loss
is. There are:
 Simple recovery model
 Full recovery model
 Bulk-Logged recovery model
Simple Recovery model
The Simple Recovery model allows the database
to be recovered to the point of the last backup
(to the most recent backup). With this recovery
model, you cannot restore the database to the
point of failure or to a specific point in time.
Therefore, changes since the last backup will be
lost.
The backup strategy for this recovery model
consists of the full database backups only or full
database backups and some differential
backups. To recover a database, you should
restore the most recent full database backup
and then restore the most recent differential
backup if it exists. The Simple Recovery model
is similar to setting the truncate log on
checkpoint database option in SQL Server 7.0
or earlier. This recovery model takes less time
to perform the backup and restore in
Document
Document
Document
Document
Name:
Author:
Date:
Version:
TM111
Kate Henderson
22 September 2003
1.0
comparison with the Full and Bulk-Logged
models and requires less disk space, but does
not provide the opportunity to restore the
database to the point of failure or to a specific
point in time.
For example, if you make a full database
backup of the Concept database on a Sunday at
1am, and make a differential backup of the
Concept database on Monday at 1am and again
on Tuesday at 1am. Suppose, then, that the
Concept database is damaged on Tuesday at
3am, you should restore the full database
backup from Sunday 1am, and then restore the
differential backup from Tuesday 1am. All
changes since Tuesday 1am will be lost.
Full Recovery model
The Full Recovery model allows the database to
be recovered to the point of failure or to a
specific point in time. This recovery model
provides the best protection of your data, but
requires more time to make the backup and
restore. If the current transaction log file for
the database is available and undamaged, you
should perform the following steps to restore
the database to the point of failure:
1. Back up the active transaction log.
2. Restore the most recent full database
backup without recovering the database.
3. Restore the most recent differential
backups, if it exists.
4. Restore each transaction log backup
created since the most recent full
database backup (or the most recent
differential backups, if differential
backups exist) in the same sequence in
which they were created without
recovering the database.
5. Apply the transaction log backup created
in Step 1, and recover the database.
For example, to perform the Full Recovery
model for the Concept database at the following
backup intervals:
1. Make the full database backup of the
Concept database on Sunday at 1 AM.
© Copyright 2003 FSI (FM Solutions) Ltd
http://www.fsi.co.uk
2. Make the differential backups of the
Concept database on Monday at 1 AM
and on Tuesday at 1 AM.
3. Make the transaction log backups of the
Concept database on Monday at 2 AM
and on Tuesday at 2 AM.
So, if the primary data file of the Concept
database was damaged on Tuesday at 3 AM,
you should recover the Concept database by
using the following steps:
1. Back up the active transaction log.
2. Restore the full database backup from
Sunday 1 AM.
3. Restore the differential backup from
Tuesday 1 AM.
4. Restore the transaction log from
Tuesday 2 AM.
5. Apply the transaction log backup created
in Step 1, and recover the database.
Bulk-Logged Recovery model
The Bulk-Logged Recovery model provides
better performance in comparison with the Full
Recovery model because the SELECT INTO,
Bulk load operations, CREATE INDEX and
WRITETEXT, UPDATETEXT operations are
minimally logged. Full and Bulk-Logged
Recovery models are similar, and you can
switch between them easily. The Bulk-Logged
Recovery model does not allow the database to
be recovered to a specific point in time. Under
this recovery model, the transaction log
backups capture both the log and the results of
any bulk operations performed since the last
backup, so it is not necessary to perform a full
database backup after bulk copy operations
complete.
Document
Document
Document
Document
Name:
Author:
Date:
Version:
TM111
Kate Henderson
22 September 2003
1.0
Setting up a database backup.
1. In SQL Server Enterprise Manager,
expand the SQL Server Group and
then expand your server.
2. Expand the Databases folder, rightclick the Concept database and select
All Tasks - Backup Database
3. On the General tabbed page, enter
the backup set name in the Name text
box.
4. In the Description text box, enter a
description of the backup set.
5. Select the backup type that you wish
to perform.
6. In the Destination section, click the
Add button to add an existing or to
create a new backup device, or click
Remove to remove a backup device
from the list of backup devices to be
used.
Click OK to commence your backup.
© Copyright 2003 FSI (FM Solutions) Ltd
http://www.fsi.co.uk