Backup and Recovery

‫عبد المطلب العبور‬

1
Database Backup and Recovery
Database backup and recovery are important processes for protecting and restoring
data in case of any failure, disaster, or corruption. There are different types of
database backup and recovery techniques, such as full, differential, incremental,
transaction log, and file-snapshot backups. Each technique has its own advantages
and disadvantages, depending on the size, frequency, and availability requirements
of the database.

2
Why back up?
Backing up databases, running test restores procedures on your backups, and storing copies of backups in a
safe, off-site location protects you from potentially catastrophic data loss. Backing up is the only way to
protect your data.
•With valid backups of a database, you can recover your data from many failures, such as:
• Media failure.
• User errors, for example, dropping a table by mistake.
• Hardware failures, for example, a damaged disk drive or permanent loss of a server.
• Natural disasters. By using Backup to cloud Blob Storage, you can create an off-site backup in a
different region than your on-premises location, to use in the event of a natural disaster affecting your
on-premises location.
•Additionally, backups of a database are useful for routine administrative purposes, such as copying a
database from one server to another, setting up Always On availability groups or database mirroring, and
archiving.
3
Database Backup and Recovery
Some of the best practices for database backup and recovery are:
• Develop a comprehensive backup plan that covers all the components and scenarios of
the database system.
• Perform effective backup management by verifying, testing, and securing the backup
files.
• Perform periodic database restore testing to ensure the validity and usability of the
backups.
• Have backup and recovery service level agreements (SLAs) drafted and communicated
to all stakeholders.
• Have the disaster recovery plan (DRP) database portion drafted and documented.
• Keep your knowledge and know-how on database and OS backup and recovery tools
up to date.

4
Glossary of backup terms
back up [verb]
The process of creating a backup [noun] by copying data records from a SQL Server database, or log records
from its transaction log.
backup [noun]
A copy of data that can be used to restore and recover the data after a failure. Backups of a database can also
be used to restore a copy the database to a new location.
backup device
A disk or tape device to which SQL Server backups are written and from which they can be restored. SQL Server
backups can also be written to an Azure Blob Storage, and URL format is used to specify the destination and the
name of the backup file. backup media
One or more tapes or disk files to which one or more backups have been written.

5
 Glossary of backup terms
data backup
A backup of data in a complete database (a database backup), a partial database (a partial backup), or a set of
data files or filegroups (a file backup).
database backup
A backup of a database. Full database backups represent the whole database at the time the backup finished.
Differential database backups contain only changes made to the database since its most recent full database
backup.

6
 Glossary of backup terms
differential backup
A data backup that is based on the latest full backup of a complete or partial database or a set of
data files or filegroups (the differential base) and that contains only the data that has changed since
that base.
full backup
A data backup that contains all the data in a specific database or set of filegroups or files, and also
enough log to allow for recovering that data.
log backup
A backup of transaction logs that includes all log records that were not backed up in a previous log
backup. (full recovery model)

7
 Glossary of backup terms
recover
To return a database to a stable and consistent state.
recovery
A phase of database startup or of a restore with recovery that brings the database into a transaction-consistent
state.
recovery model
A database property that controls transaction log maintenance on a database. Three recovery models exist:
simple, full, and bulk-logged. The recovery model of database determines its backup and restore requirements.
restore
A multi-phase process that copies all the data and log pages from a specified SQL Server backup to a specified
database, and then rolls forward all the transactions that are logged in the backup by applying logged changes
to bring the data forward in time.

8
Backup and restore strategies
Designing an effective backup and restore strategy requires careful planning, implementation, and
testing. Testing is required: you do not have a backup strategy until you have successfully restored
backups in all the combinations that are included in your restore strategy and have tested the
restored database for physical consistency. You must consider a variety of factors. These include:
• The goals of your organization regarding your production databases, especially the requirements
for availability and protection of data from loss or damage.
• The nature of each database: its size, its usage patterns, the nature of its content, the requirements
for its data, and so on.
• Constraints on resources, such as: hardware, personnel, space for storing backup media, the
physical security of the stored media, and so on.

9
 Choose appropriate recovery model
Backup and restore operations occur within the context of a recovery model. A recovery model is a database
property that controls how the transaction log is managed. Thus, the recovery model of a database determines:
• what types of backups and restore scenarios are supported for the database.
• what the size of the transaction log backups would be.
Typically, a database uses either the simple recovery model or the full recovery model.
➢ The full recovery model can be augmented by switching to the bulk-logged recovery model before bulk
operations.
➢ The best choice of recovery model for the database depends on your business requirements. To avoid
transaction log management and simplify backup and restore, use the simple recovery model.
➢ To minimize work-loss exposure, at the cost of administrative overhead, use the full recovery model.

10
Design your backup strategy
After you have selected a recovery model that meets your business requirements for a specific database, you
have to plan and implement a corresponding backup strategy. The optimal backup strategy depends on a variety
of factors:
• How many hours a day do applications have to access the database?
• If there is a predictable off-peak period, we recommend that you schedule full database backups for that
period.
• How frequently are changes and updates likely to occur?
• If changes are frequent, consider the following:
• Under the simple recovery model, consider scheduling differential backups between full database
backups. A differential backup captures only the changes since the last full database backup.
• Under the full recovery model, you should schedule frequent log backups. Scheduling differential backups
between full backups can reduce restore time by reducing the number of log backups you have to restore
after restoring the data.

11
Design your backup strategy

• Are changes likely to occur in only a small part of the database or in a large part of the database?
• For a large database in which changes are concentrated in a part of the files or filegroups, partial
backups and or full file backups can be useful.
• How much disk space will a full database backup require?
• How far in the past does your business require to maintain backups?
• Make sure you have a proper backup schedule established according to the needs of the
application and business requirements. As the backups get old, the risk of data loss is higher
unless you have a way to regenerate all the data till the point of failure. Before you choose to
dispose of old backups due to storage resource limitations, consider if recoverability is required
that far in the past

12
Design your backup strategy

Estimate the size of a full database backup

Before you implement a backup and restore strategy, you should estimate how much disk space a full database
backup will use. The backup operation copies the data in the database to the backup file. The backup contains
only the actual data in the database and not any unused space. Therefore, the backup is usually smaller than the
database itself.

Schedule backups
Performing a backup operation has minimal effect on transactions that are running; therefore, backup operations
can be run during regular operations. You can perform a SQL Server backup with minimal effect on production
workloads.

13
Design your backup strategy
Test your backups!
You do not have a restore strategy until you have tested your backups. It is very important to thoroughly test your
backup strategy for each of your databases by restoring a copy of the database onto a test system. You must test
restoring every type of backup that you intend to use. It is also recommended that once you restore the backup,
you perform database consistency checks via DBCC CHECKDB of the database to validate the backup media was
not damaged.

Verify Media Stability and Consistency

14
SQL Server Backup Types

• Full SQL server backup

A full SQL server backup makes a copy of the entire SQL database. This is the simplest and most
straightforward type of SQL server backup available, since it includes all objects and data available
in the relational database. Other types of SQL server backup use a full SQL server backup as a
foundation to work from.

• Differential SQL server backup

Using a full backup as the base, a differential backup of an SQL server only backs up the data that
has changed since the last full backup. Possible changes to the database that can be accounted for
include schema objects, log files, and other data. This helps to save on time, storage, and ensure
that every change to the server is accounted for and backed up.

15
SQL Server Backup Types

• Transaction log SQL server backup

A transaction log server backup consists of all the transactions since the last transaction log
backup. This backup aids in restoration of the database to a particular point in time.
Microsoft recommends, “If a database uses either the full or bulk-logged recovery model, you must
back up the transaction log regularly enough to protect your data, and to prevent the transaction
log from filling. This truncates the log and supports restoring the database to a specific point in
time.”

16
SQL Server Backup Types

17
Transaction Log Backup

• A transaction log backup contains all transaction log records that have been made
between the last transaction log backup or the first full backup and the last log record
that is created upon completion of the backup process.
• The transaction log backup allows to restore a database to a particular point-in-time
before the failure has occurred. It is incremental, meaning that in order to restore a
database to a certain point-in-time, all transaction log records are required to replay
database changes up to that particular point-in-time.

18
Transaction Log Backup

19
Transaction Log Backup Chain

A transaction log backup chain is a continuous sequence of transaction log backups

starting with first full database backup. Each backup from the chain has its own
FirstLSN (oldest log record in the backup set) and LastLSN (the number of the next log
record after the backup set), that help to restore transaction log backup files in the right
sequence.

20
Transaction Log Backup Chain

21
How to Make a Transaction Log Backup

22
Differential Backup

• A differential backup is created similarly to a full backup, but with one important difference – the
differential backup only contains the data that has changed since the last full backup
• Differential backups are cumulative not incremental. This means that a differential backup
contains all changes made since the last full backup
• The size of a differential backup depends directly on the amount of data that has changed. The
more changes are marked in the differential bitmaps the bigger next differential backup will be.
• Ultimately the differential database backup can become as large as the full backup. Therefore, it
is recommended to make the next full backup regularly to reset all bitmaps in the differential
bitmap.

23
Differential Backup

24
How to Make a Differential Backup

25
Full Backup

• The simplest kind of SQL Server backup is a full database backup. It provides a
complete copy of the database

• The good thing about database backup is that transactions continue running during
the backup process, although database I/O operations may slow them down.
However, since the transaction log cannot be truncated at this time you may face a
problem when a huge number of changes in the database during the full backup
make the transaction log grow rapidly and, therefore, occupy your free disk space.

26
Full Backup

27
What Transaction Log Records Get into Full Backup

Transaction A started before the full backup began, made some changes after the checkpoint and committed before
the backup completed. In this case the full backup includes all transaction log records starting from the latest active
transaction. This implies that the full backup includes the whole transaction A with all changes that were made after
the checkpoint to apply those changes during the database recovery process.

28
How to Make a Full Backup

29
Log Sequence Number (LSN)

• Every record in SQL Server transaction log has its own log sequence number or LSN.
• Log sequence numbers are ordered in such a way that changes related to the record
with greater LSN occur after the changes related to records with smaller LSN.
• Each backup that is set in SQL Server has FirstLSN and LastLSN values.
• To find out all backup’s LSN values you need to look at its header using the following
syntax:

30
Log Sequence Number (LSN)

31
Log Sequence Number (LSN)

32
Log Sequence Number (LSN)

The previous commands produce the

following results:

33
Log Sequence Number (LSN)

The DatabaseBackupLSN of the first full backup is always equal to zero:

The FirstLSN of the first full backup is the same as the CheckpointLSN

34
Log Sequence Number (LSN)

Full database backup is the main type on which all other backups (especially differential
backups) are dependent. In the restore sequence, a differential backup is always
restored after the full backup. In order to determine the full backup to which the
differential backup relates, you need to check the values of DatabaseBackupLSN of
differential backup and CheckpointLSN of the full backup – their values should be
identical.

35
Log Sequence Number (LSN)

But what if there is no differential backup, and there is a need to restore the database
with the full and transaction log backups? To find out which transaction log backup
should be restored right after the full backup is restored take a look at the LastLSN of the
full backup and the FirstLSN and the LastLSN of the transaction log backup. The LastLSN
of the full backup should be between the FirstLSN and the LastLSN of the transaction log
backup.

36
Log Sequence Number (LSN)

in order to find out which transaction log backup should be restored after the differential
backup you need to pay attention to the LastLSN of the differential backup and the
FirstLSN and the LastLSN of the transaction log backup. The LastLSN of the differential
backup should be between FirstLSN and LastLSN of the transaction log backup followed
right after it:

37
Log Sequence Number (LSN)

The CheckpointLSN of the differential backup maps to the CheckpointLSN of the first transaction log
backup created after this differential backup:

38
Log Sequence Number (LSN)

For a transaction log backup, the LastLSN value is the same as the FirstLSN of the next
transaction log backup:

39
 Database Restore

• Restoring a database can involve different types of restore operations depending on

your recovery requirements and backup strategy.

• Restoring a SQL Server database involves using backup files to bring the database
back to a specific point in time, often in response to data loss or corruption. SQL
Server provides various types of restore operations to meet different recovery needs.

40
Full Database Restore
This type of restore uses a full backup to restore the entire database to a previous
point in time.

• WITH RECOVERY: Use if this is the only backup you're restoring (it makes the
database operational).
• WITH NORECOVERY: Use if you plan to restore additional differential or log
backups.
41
Differential Restore

• Differential backups only include changes since the last full backup. To restore a
differential backup,
• you must first restore the last full backup using NORECOVERY, followed by the
differential backup.

42
Transaction Log Restore
Transaction log backups allow for point-in-time recovery. To perform this type of restore, you need to
first restore the last full backup (and differential backup if applicable) with NORECOVERY, then apply
each transaction log backup in sequence.

43
Transaction Log Restore

44
Naming Backup files

When setting up backups, following a consistent and informative naming convention for backup files can
help with organization, automation, and recovery. Below are best practices for naming backup files:
1. Include Database Name: Begin the filename with the database name to quickly identify which database the
backup is for Example: SalesDB_
2. Specify Backup Type: Indicate the type of backup in the filename (e.g., FULL, DIFF, LOG), making it easy to
distinguish between full, differential, and log backups. Example: SalesDB_FULL_
3. Include Date and Time: Add a timestamp in the filename, typically in YYYYMMDD or YYYYMMDD_HHMMSS
format, for clear versioning and to track backup schedules.Example: SalesDB_FULL_20241101_230000
4. File Extension: Use .bak for full and differential backups, and .trn for transaction log backups. This helps
immediately identify the backup type. Example: SalesDB_FULL_20231101_230000.bak or
SalesDB_LOG_20231101_230000.trn

45
Naming Backup files

In this example the backup file name is: University_FULL_2024-11-02_20-21-07.bak

46