Back Up Database in

Ms-SQL Server
Database Model
• A recovery model is a database configuration option that determines
the type of backup that one could perform, and provides the ability to
restore the data or recover it from a failure.
• The recovery model decides how the transaction log of a database
should be maintained and protects the data changes in a specific
sequence, which may later be used for a database restore operation.
Types of recovery models
All SQL Server database backup, restore, and recovery operations
are based on one of three available recovery models:
• SIMPLE
• FULL
• BULK_Logged
 Database Model(SIMPLE)
• The SIMPLE recovery model is the simplest among the It supports:
available models. It supports full, differential, and file level Full backup
backups. Transaction log backups are not supported. The log Differential backup
space is reused whenever the SQL Server background Copy-Only backup
process checkpoint operation occurs. The inactive portion of
File backup
the log file is removed and is made available for reuse.
Partial backup
• Reasons to choose the simple database recovery model
1. Most suited for Development and Test databases
2. Simple reporting or application database, where data loss
is acceptable
3. The point-of-failure recovery is exclusively for full and
differential backups
4. No administrative overhead
 Database Model(FULL)
In this recovery model, all the transactions (DDL (Data Definition Language) + DML (Data It supports all type of following
Manipulation Language)) are fully recorded in the transaction log file. The log sequence is backups
unbroken and is preserved for the databases restore operations. Unlike the Simple recovery • Full backup
model, the transaction log file is not auto-truncated during CHECKPOINT operations. • Differential backup
All restore operations are supported, including point-in-time restore, page restore and file • Transaction log backup
restore. • Copy-Only backup
• File and/or file-group backup
Reasons to choose the full database recovery model: • Partial backup

• Supporting mission critical applications

• Design High Availability solutions
• To facilitate the recovery of all the data with zero or minimal data loss
• If the database designed to have multiple filegroups, and you want to perform a
piecemeal restore of read/write secondary filegroups and, optionally, read-only
filegroups.
• Allow arbitrary point-in-time restoration
• Restore individual pages
• Incur high administration overhead
 Database Model(BULK_LOGGED)
It supports all types of
It’s a special purpose database configuration backups:
option and it works similar to FULL recovery model • Full backup
except that certain bulk operations can be minimally • Differential backup
• Transaction log backup
logged. The transaction log file uses a technique
• Copy-Only backup
known as minimal logging for bulk operations. The
• File and/or file-group
catch is that it’s not possible to restore specific backup
point-in-time data. • Partial backup

Reasons to choose the bulk logged recovery model:

• Use minimal logging technique to prevent log file
growth
What is Backup database?
Database backup is the process of backing up the operational state, architecture and stored
data of database software.
Following are the most common types of backups available in SQL Server:
• Full
• Differential
• Transaction log
• Tail Log backup
There are other backup types available as well:
• Copy-only backup
• File backups
• Partial backups.
Full backups
A full backup, as the name implies, backs up everything. It is the foundation of any
kind of backup. This is a complete copy, which stores all the objects of the database:
Tables, procedures, functions, views, indexes etc. Having a full backup, you will be able to
easily restore a database in exactly the same form as it was at the time of the backup.
A full backup creates a complete backup of the database as well as part of the
transaction log, so the database can be recovered. This allows for the simplest form of
database restoration, since all of the contents are contained in one single backup.
A full backup must be done at least once before any of the other types of backups
can be run—this is the foundation for every other kind of backup.
Full backups
• How to create full database backup using T-SQL
The BACKUP DATABASE is the command used to create a full database backup. It
requires at least two input parameters: the database name and the backup device.
Following is the example for a full database backup to be stored in a device:

BACKUP DATABASE [AdventureWorks2019]

To DISK='f:\PowerSQL\SQLShackDemoATC.BAK'
Full Database Backup to Multiple files
Sometimes in some instances, we’re limited by the amount of space we
have. What if we wanted to backup an entire database that is huge? Or what if
we have to copy the backup files over the network? It might be a good idea in
these cases to split the backup into smaller chunks—each being a separate
file.

BACKUP DATABASE [AdventureWorks2019] TO

DISK = 'C:\bak\ATC_1.BAK',
DISK = 'C:\bak\ATC_2.BAK',
DISK = 'C:\bak\ATC_3.BAK',
DISK = 'C:\bak\ATC_4.BAK'
WITH INIT, NAME = 'FULL SQLShackDemoATC backup'
Full Database Backup to Mirror Copy &
Compress
If we want to backup to many destination we can backup with mirror to disk.

BACKUP DATABASE [AdventureWorks2019]

TO DISK = N'C:\Bak\Demo_1.BAK'
MIRROR TO DISK = N'C:\Bak\Demo_2.BAK'
WITH FORMAT
If you want to compress database you add keyword COMPRESSION in backup script

BACKUP DATABASE [AdventureWorks2019] TO

DISK = N'C:\bak\ADVCompress.BAK' WITH NOFORMAT, COMPRESSION
GO
Differential Backup
• A differential database backup is the superset of the last full backup
and contains all changes that have been made since the last full
backup. So, if there are very few transactions that have happened
recently, a differential backup might be small in size, but if you have
made a large number of transactions, the differential backup could be
very large in size.
Differential Backup
• How to create Differential database backup using T-SQL
The BACKUP DATABASE command is used with the differential clause to
create the differential database backup. It requires three parameters:
1.Database name
2.Backup device
3.The DIFFERENTIAL clause
BACKUP DATABASE [AdventureWorks2019]
To DISK='C:\bak\Diff.BAK’
WITH DIFFERENTIAL
Transaction Log Backup
• The log backup, as its name implies, backs up the transaction logs. This
backup type is possible only with full or bulk-logged recovery models. A
transaction log file stores a series of the logs that provide the history of
every modification of data, in a database. A transaction log backup contains
all log records that have not been included in the last transaction log backup.
• It allows the database to be recovered to a specific point in time. This means
that the transaction log backups are incremental and differential backups are
cumulative in nature. If you want to restore the database to a specific point
in time, you need restore a full, recent differential, and all the corresponding
transaction log records which are necessary to build the database up to that
specific point, or to a point very close to the desired point in time, just before
the occurrence of the accident that resulted in the data loss.
Transaction Log Backup
Transaction Log Backup
• How to create Transactional log
backup using T-SQL

The BACKUP LOG command is used

to backup the transaction log. It requires
the database name, the destination device
and the TRANSACTION LOG clause to
initiate the transaction log backup.

BACKUP LOG [AdventureWorks2019]

To DISK='C:\bak\Log.trn'
Tail log backups
In the event of a failure, when you need the database to get back
up and running, and the database is operating in FULL or BULK_LOGGED
recovery model, it’s always easy to start the recovery operation and start
restoring the backups. But before that, the first action to be taken after
the failure is what is called as a tail log backup of the live transaction log.
This is an intermediate step that we need to take before we start
the restoration. This process is called tail log backup restoration.
BACKUP LOG [AdventureWorks2019]
TO DISK = 'C:\bak\TailLog.log’
WITH CONTINUE_AFTER_ERROR;

The WITH CONTINUE_AFTER_ERROR clause will force SQL Server to store

the log file, even though it’s generating an error.
Copy_Only Backup
• A copy-only backup is a special type of full backup, which is
independent of the conventional sequence of backups. The difference
between copy-only and a full backup is that a copy-only backup
doesn’t become a base for the next differential backup.
• A full backup works on all database recovery models. Copy-only
backup, on the other hand, is applicable only to a full or bulk-logged
recovery models. The restoration of a copy-only backup is no different
than a normal restoration process.
• Performing the copy-only backup is pretty simple. The syntax would
look something like this:
Copy_Only Backup
BACKUP DATABASE [AdventureWorks2019]
To DISK='C:\bak\DemoATC_1.BAK'
WITH COPY_ONLY;

BACKUP LOG [AdventureWorks2019]

TO DISK = 'C:\bak\DemoATCCopyOnly.log'
WITH COPY_ONLY;
GO

The BACKUP LOG command with the COPY_ONLY option generates a

copy-only log backup. It doesn’t involve in transaction log truncation.
Copy_Only Backup

It is necessary to use “COPY_ONLY” backup option in order to

preserve the database backup sequence.
Partial backups
• Partial backups are one of the least-used backup methods available in
SQL Server. All database recovery models support partial backups, but
partial backups are mostly used in the simple recovery model in order
to improve flexibility when backing up large databases that contain
read-only filegroups.
• The READ_WRITE_FILEGROUPS option is used with the BACKUP
DATABASE command. This command is for partial backup. It processes
the backup of read-write file groups.
• AdvantureWorkBackup is the database created with primary and
secondary file groups. Let’s use this database for this demo.
Partial backups
CREATE DATABASE [AdventureWorks2022] ON PRIMARY
( NAME = N'ADVPartialBackup_1’, FILENAME = N'C:\bak\PartialBackup_1.mdf' ,
SIZE = 5000KB , FILEGROWTH = 1024KB ),

FILEGROUP [Secondary]
( NAME = N'ADVPartialBackup_2',FILENAME = N'C:\bak\PartialBackup_2.ndf' ,
SIZE = 5000KB , FILEGROWTH = 1024KB )

LOG ON
( NAME = N'ADVPartialBackup_Log',FILENAME = N'C:\bak\PartialBackup_log.ldf' ,
SIZE = 1024KB , FILEGROWTH = 10%)
GO
Partial backups
• Let’s change the recovery model of the database to SIMPLE using the
following ALTER statement
ALTER DATABASE [AdventureWorks2022] SET RECOVERY SIMPLE
Now, set the secondary file-group to READONLY mode
ALTER DATABASE [AdventureWorks2022] MODIFY FILEGROUP [Secondary] READONLY
Initiate a backup using the READ_WRITE_FILEGROUPS option
BACKUP DATABASE [AdventureWorks2022] READ_WRITE_FILEGROUPS
TO DISK = N'C:\bak\PartialBackup_Full.bak’
GO
File and File Group Backups
• This topic is relevant for SQL Server databases that contain multiple
files or filegroups. File backups of read-only filegroups can be
combined with partial backups. Partial backups include all the
read/write filegroups and, optionally, one or more read-only filegroups.
• Let’s create a database with multiple files and filegroups.
Query Check Backup Database
• We can check database size by query:

SELECT
database_name = DB_NAME(database_id)
, log_size_mb = CAST(SUM(CASE WHEN type_desc = 'LOG' THEN size END) * 8. / 1024 AS DECIMAL(8,2))
, row_size_mb = CAST(SUM(CASE WHEN type_desc = 'ROWS' THEN size END) * 8. / 1024 AS DECIMAL(8,2))
, total_size_mb = CAST(SUM(size) * 8. / 1024 AS DECIMAL(8,2))
FROM sys.master_files WITH(NOWAIT)
WHERE database_id = DB_ID() -- for current db
GROUP BY database_id

We can check database backup size by the following script.

Check Database Backup Size.txt

 Point of
Time
Recovery