Note:

Place the database and backups on separate devices. Otherwise, if the device containing the
database fails, your backups will be unavailable.

Placing the data and backups on separate devices also enhances the I/O performance for both
writing backups and the production use of the database.

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, of which the following are especially significant:

 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:

o
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.
o 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.
 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 file backups can be useful.

 How much disk space will a full database backup require?

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. You can estimate the size of a full database backup by using
the sp_spaceused system stored procedure.
Files Overview:

Recovery Model:

The recovery model determines how transactions are logged, and for how long time committed transactions will be stored in
the transaction log. The recovery model is set by T-SQL command, ALTER DATABASE:

-- setting full recovery model

ALTER DATABASE <database_name> SET RECOVERY FULL

The recovery model has three possible options:

SIMPLE
 SQL Server clears transactions from the transaction log when they are checkpoint. This approach leads to a relatively
small
 transaction log file
 The SIMPLE recovery model is a good option when data stored in the database is not mission-critical, or when
potential data loss is not critical for users
 As an example of a database where data is not crucial for business, we can imagine development databases where
data is sometimes damaged intentionally.

BULK_LOGGED
 This option has almost the same behavior as a full recovery model which additionally permits high-performance bulk
copy operations.
 Reduces log space usage by using minimal logging for most bulk operations
 The BULK_LOGGED recovery model doesn't provide the ability to restore the database at any point in time.
  If the log is damaged or bulk-logged operations occurred since the most recent log backup, changes since that last
backup must be redone.

FULL
 When the recovery model set to FULL, SQL server keeps transaction log records in the transaction log file until BACKUP
LOG statement is executed.
 With recovery model set to full, SQL Server keeps all transaction records indefinitely until the transaction log file is full,
then the database stops its work and becomes inaccessible. That's why we need to back up the transaction log
regularly because the backup clears the transaction log, keeps it a manageable size, and defends the database against
stopping work.
 As an advanced point, we have to say that when the recovery model is set to full, we can restore the database at any
point in time.

Full BKP

A full backup is simply the backup of a complete database. When performing a full
backup, SQL Server stores metadata of the database (its name, creation date, all options set
to the database, paths to all files belonging to the database, and so on), used data pages of
every data file, and also the active part of the transaction log (which means all transactions
that are not checkpoint yet and all running transactions even if they are not finished).
At the end of the backup process, SQL Server stores the last Log Sequence Number (LSN)
for possible additional backups.
A full backup never clears the transaction log file!

Place the database and backups on separate devices. Otherwise, if the device containing the
database fails, your backups will be unavailable. Placing the data and backups on separate
devices also enhances the I/O performance for both writing backups and the production use of
the database.