Backup

Backup can be understood as a copy of used data pages or a copy of transaction log records.
Backup has to be done regularly. Backup is needed not only to restore databases in case of
physical or logical failure, but it is also useful when, for example, we want to make a copy of the
database or migrate the database to another SQL Server instance.
Backup types

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).

How Many Types of Backup are There?

There are mainly three types of backup: full, differential, and incremental.

Let’s dive in to know more about the types of backup, the difference between
them and which one would be the best fit for your business.
Database Backup and Recovery Best Practices
The ability to restore databases from valid backups is a vital part of ensuring business
continuity. Backup integrity and restorations are an important piece of the IT
Governance Institute’s IT Control Objectives for Sarbanes-Oxley,
2nd Edition. In many instances, IT auditors merely confirm whether backups are being
performed either to disk or to tape, without considering the integrity or viability of the
backup media.
This article covers the topics related to data loss and the types of database backup and
recovery available. Best practices that can assist an auditor in assessing the
effectiveness of database backup and recovery are also provided. This article focuses
on the technologies and capabilities of the Oracle relational database management
system (RDBMS) and Microsoft (MS) SQL Server because, together, they cover
approximately 40 percent of all database installations. Figure 1 provides a short
comparison of Oracle and MS SQL Server.

One of the key responsibilities of a database administrator (DBA) is to prepare for the
possibility of media, hardware and software failure as well as to recover databases
during a disaster. Should any of these failures occur, the major objective is to ensure
that the database is available to users within an acceptable time period, while ensuring
that there is no loss of data. DBAs should evaluate their preparedness to respond
effectively to such situations by answering the following questions:
  How confident is the DBA that the data on which the company business
depends are backed up successfully and that the data can be recovered
from these backups within the permissible time limits, per a service level
agreement (SLA) or recovery time objective, as specified in the
organization’s disaster recovery plan?
 Has the DBA taken measures to draft and test the procedures to protect
as well as recover the databases from numerous types of failures?

The following is a checklist for database backup and recovery procedures that are
explained throughout this article:

1. Develop a comprehensive backup plan.

2. Perform effective backup management.
3. Perform periodic databases restore testing.
4. Have backup and recovery SLAs drafted and communicated to all
stakeholders.
5. Have the disaster recovery plan (DRP) database portion drafted and
documented.
6. Keep your knowledge and know-how on database and OS backup and
recovery tools up to date.

Comprehensive Backup Plan

DBAs are responsible for making a comprehensive backup plan for databases for which
they are accountable. The backup plan should include all types of RDBMSs within the
enterprise and should cover the following areas:

 Decide what needs to be backed up. It is imperative that the DBA

be aware of database and related OS and application components that
need to be backed up, whether via an online backup or an offline cold
backup.
The following are details of what needs to be backed up:
o OS software—An event such as a hardware failure will
require a complete system restore, starting with the OS, so
there is a need to back up the database server OS initially
and after any system updates or configuration changes.
o RDBMS software—The RDBMS software should be
backed up initially and after any patches/upgrades.
o Application software where applicable— This applies
especially to Oracle E-Business Suite, Oracle Application
Server and Oracle Enterprise Manager (OEM). The
 application DBA should complete an initial full backup of
the applications to disk using an appropriate OS command
and, then, schedule future incremental backups, e.g., after
any patches/ upgrades. These backups should also be
transferred to tape.
o Passwords—All superuser passwords that may be required
during recovery should be preserved. It is a good idea to
ensure that the default passwords that came with the initial
installation of the RDBMS are changed.
o All components of Oracle databases:
 Database parameter file—A parameter file or server
parameter file (SPFILE) defines persistent
initialization parameters of a database, including
information about database control files.
 Database control file(s)—The control file stores the
status of physical structure of the database. If it
becomes unavailable, the database cannot operate. It
is imperative that these files be backed up while
backing up other components of the database. In later
versions of Oracle (9i onward), the DBA can configure
automatic backup of the parameter file as well as the
control file to ensure that these get backed up after
each backup and after any structural changes in the
database.
 Database data files—These should be backed up
during cold backup as well as during online backup,
using Oracle’s Recovery Manager (RMAN) or, in
Oracle Database versions in which RMAN was not
introduced, by putting tablespaces in backup mode.
The DBA should try to run all production databases in
Archive log mode so that recovery to the point of
failure is possible.
 Redo log files and archived redo logs—While making
a cold backup, the DBA needs to backup redo logs.
When the database is running in archive log mode
and doing and online backup, the DBA needs to
 archive redo logs manually or automatically and then
back up all archive redo logs.
 Oracle network files—It is important to back up all
Oracle network files initially and after any change.
 Password files—Password files when used should be
backed up initially and after any change.
o MS SQL Server databases:
 Back up both system and user databases.
 Have a separate maintenance plan for system
databases, i.e., master, model, msdb. Master
supports only full backups; tempdb backup is not
required, as it gets rebuilt during SQL Server startup.
 Back up all user databases. Set up all user databases
for full recovery model, and back up both database
and transaction logs.
 Determine the appropriate backup type to use for your data.
o Oracle databases:

1. Logical backups—This type of backup is performed

through Oracle utilities “exp.” From version 10g
onward, Data Pump can also be used. The whole
database, individual schemas, tables or tablespaces
can be backed up. Restore is done using “imp” or
Data Pump. With such backups, recovery to the point
of failure is not possible.
2. Physical offline or cold backups—The database must
be shut down and a copy must be made of all
essential data files and other components of the
database.
3. Physical online or hot backups—This method enables
the database to be backed up while the database is
up and running. The following points should be kept in
mind while doing online backups:
 Either put the tablespaces in backup mode and
back up the associated data files using an OS
copy command, or use RMAN, a robust tool
provided by Oracle for backup and recovery with
 version 8.x onward. Oracle adds new
functionality to this tool with each version.
RMAN can use the database control file to keep
its catalog, or the DBA can setup schema for
each database, in a separate database for
RMAN catalogs.
 The DBA must review and keep in mind the
RMAN compatibility matrix for the database
being backed up/ restored as well as the RMAN
executable and RMAN Catalog
Database/Schema.
 DBAs must familiarize themselves with full,
incremental and differential backups and set
these up using RMAN scripts. DBAs must
review their RDBMS edition, e.g., incremental
backups are not possible in standard editions
prior to Oracle 10g. To restore/ recover a
database to the point of failure or a previous
point in time, the DBA must put the database in
archive log mode and back up all archived redo
logs.
 It is important not to forget to back up the RMAN
catalog at the end of each backup. DBAs can do
an export backup of RMAN catalog schema.
o SQL Server databases:
1. Logical backups—In SQL Server, individual schema
objects can be backed up to flat files in any of the
supported file formats. Then flat files can be restored
using tools such as the bcp utility, the Import and
Export Wizard, or the SQL Server Integration
Services tools.
2. Physical backups—It is recommended that all user
databases be set up for full recovery model, and both
database and transaction logs should be backed up to
restore/recover the database to the point of failure.
DBAs should thoroughly familiarize themselves with
database recovery models and full, differential and
 transaction-log backups, and set these up
accordingly. File or filegroup backup strategy can be
used if the databases to be backed up are very large
databases (VLDBs) that are partitioned among
multiple files.
 Establish a strategy for handling VLDB backups—In Oracle,
the DBA can reduce the backup window for VLDBs by allocating
multiple channels and fine-tuning backups, can save disk space by
using compressed backups, and can block tracking with incremental
backup techniques with the latest versions. The DBA must review the
version and edition of the database to confirm availability of this option.
If this does not do the trick, the DBA can consider setting up split mirror
backups. For SQL Server, the DBA can partition the database among
multiple files and use the file or filegroup backup strategy. Also, using
multiple backup devices in SQL Server allows backups to be written to
all devices in parallel.
 Establish an appropriate backup schedule and window — It is
good practice to select a backup window at a point when the lowest
amount of activity affects the database so that the backup does not
reduce available database server resources and slow down the
database user’s activity. The DBA can tune the backup window by
parallelizing backups using multiple channels; however, the DBA must
review the version and edition of the database to confirm availability of
this option. In the vast majority of cases, it is best to set up a weekly
backup cycle starting with full backups on Friday night or Saturday
morning and incremental/differential backups throughout the weekdays.
Archive/transaction log backups can be scheduled for every few hours,
depending on the volatility of the database.
 Decide where to store backups—Both Oracle and MS SQL Server
databases can be backed up directly to tape or disk (locally or over the
network), and then the backups can be archived to tape. It is good
practice to back up to disk, transfer to tape and store tapes offsite for
disaster recovery (DR). The backups to disk are faster; DBAs have
more control and can better monitor these and, with this method, DBAs
hold two sets of backups—one on disk, the other on tape. During
restore, if backups are still on disk, it will be a faster restore, reducing
mean time to recover (MTTR).
 Develop a backup retention policy—The backup retention policy
relates to both the disk and tape rotation schedule and should be
decided upon based on the SLA established with the business-user
 community. The data owner should specify the retention period for the
data. The retention period may vary from months to years, depending
on local laws. Accordingly, the DBA should be deleting old backups to
create space for current backups. The data retention policy should be
chosen carefully, making sure that it complements the backup media
subsystem retention policy and requirements for the backup recovery
strategy. If not using a catalog, the DBA must ensure that the control file
record keep time instance parameter matches the retention policy.

Effective Backup Management

After making a solid backup plan and completing initial work, the DBA should properly
manage backups, keeping the following points in mind:

 Automating backups—For Oracle, either set backups through OEM

or use an OS scheduling tool, and Spool output to a log file that can be
reviewed for any errors. In SQL Server, use Maintenance Plans for
scheduling backups.
 Monitoring backups—Set up monitoring using appropriate tools so
that the DBA gets an e-mail or alert through a pager or cell phone for
any failed backups, which should be rerun as soon as possible.
 Backup logs and catalogs—Review backup logs and backup
catalog information periodically for any issues. Use RMAN reporting to
show backup status. For Oracle, back up the RMAN catalog database
by exporting all catalog schemas periodically as well as by doing an
export backup of RMAN catalog schema at the end of each backup. For
SQL Server, backup system databases, especially master and msdb.
 Database catalog maintenance—With Oracle databases, use
“delete obsolete” to remove backups that are outside the organization’s
retention policy. If obsolete backups are not deleted, the catalog will
continue to grow and performance will become an issue. Cross-
checking (cross-check backup) will check that the catalog/control file
matches the physical backups.
 Validating backups—Validate and verify backups without doing
actual restores.
 Setting up dependencies—When backing up to disk, archive these
backups to tape as soon as backup to disk completes.

Set up a process so that disk backups get transferred to tape without loss of time.

Backup Restoration Testing

Imagine the following scenario: A flood has hit the area in which a company’s
headquarters resides, and the entire IT infrastructure has been damaged, but not
destroyed. Before the event, the DBAs performed backups to the backup media,
following all of the processes noted previously in this article, and had these stored
offsite. In the enterprise’s most recent IT audit, the auditor rated the backup process as
“effective.”

The backup media from the offsite storage is retrieved and loaded. A message appears
on-screen that states that the backup media are “unreadable” due to integrity issues.
What could have happened?

Many things could have happened. However, it is clear that a critical step
did not happen. The restoration from the backup media was never really tested. The
control was marked as effective because a backup process was in place and being
performed. In addition, no errors were ever received when the enterprise backed up to
the backup media.

Backups are of no use if the IT team cannot restore the data to the system at the time of
need. A DBA should formulate a detailed strategy for this task:

1. Databases restore testing—There should be a requirement to test

database restores from disk as well as from tape backups.
2. Validating restores where possible—The DBA can validate and
verify backups without doing actual restores. Validating backups using
the “restore validate database” command will do everything except
actually restore the database. This is the best method to determine if
the backup is good and usable before being in a situation in which it
becomes critical.
3. Refreshing nonproduction databases from production
backups—It is good practice to periodically build nonproduction
databases from production backups using appropriate backup/restore
utility commands as a restore practice.
4. Performing annual/biannual restore testing from tape as
part of audit—The DBA will have to explain the process through a
narrative, preserve logs and take screenshots to show this type of
restore testing.
5. Actual restores—During actual restores, the DBA should back up the
database before doing the restore. Depending on the type of loss and
backups available, the DBA must decide on whether to go for complete
(point-in-time) or incomplete recovery. Incomplete recovery can be time-
based, cancel-based or change-based.
 6. Strategy to recover from database corruption—For Oracle
databases, the DBA can turn on block checking using appropriate
parameters to detect the presence of corrupt blocks in the database.
This has a slight performance overhead, but will allow early detection of
corrupt blocks caused by underlying disk, storage system or
input/output (I/O) system problems. By default, RMAN also checks for
corrupt blocks during backup. In later versions of Oracle, RMAN can be
used to repair corrupted blocks in the database.

Backup and Recovery SLA

The DBA team must draft a backup and recovery SLA, covering details of backup
procedures and including a timeline for recovery, and have management sign off on it.
The SLA does not assist in the recovery process itself, but sets the user community’s
(and management’s) expectations for the recovery process, which may provide the
team more time to complete the restore process.

Disaster Recovery Plan

The DBA should take care to ensure that databases are included as a key element in
the company’s overall DRP. All stakeholders need to understand the elements of the
recovery plan and in what order the IT team will restore the databases. The business
must provide its input at this stage so that the most business-critical applications are
available as soon as possible.

Database and OS Backup and Recovery Tools

It seems obvious, but DBAs play the final and most important role in the process in that
they must keep their knowledge of backup and recovery tools for RDBMSs up to date.
During the actual restore event, DBAs will not have time to figure out any advancements
in backup and recovery tools.

Conclusion
The primary responsibility of the database administration team is to review all types of
RDBMSs in the enterprise and to develop a comprehensive backup plan to conduct
effective backup management by proactively monitoring backups, getting alerted for
failed backups and rerunning these seamlessly, without loss of time. It is good practice
to back up data to physical disk and to then archive the data to tape for disaster
recovery purposes.

Once an approach has been established, it is imperative to test data restoration

periodically as part of the backup and restore strategy, and to review all options before
executing the actual restoration/recovery. It is important to confirm that the DBA team is
abreast of the latest backup and recovery tools and to ensure that the team has a
clearly documented process in place with clear responsibilities. If DBAs maintain proper
backups, monitor these proactively and can provide assurance of the recovery of data
up to the point required by the business, they have done a major part of the job for
which they were hired.

IT auditors can assist data administration teams in strengthening their controls and data
recovery processes by validating the DBA operations, including the testing of the
recovery of data. This continuous, proactive and cooperative effort between internal
audit and the DBA team can provide assurance to management that, in the event of a
disaster, the business’s data can be recovered.

Ali Navid Akhtar, OCP, has more than two decades of experience with
databases. He works as a lead database administrator at Solo Cup Co.
Jeff Buchholtz, has more than 18 years of design, implementation and support of
global IT technology solutions. He works in an IT leadership role and is an Oracle
database administrator.
Michael Ryan, CIA, CPA, is the director of internal audit for Solo Cup Co., with
the primary responsibility of building and executing US Sarbanes-Oxley Act 404
compliance strategies.
Kumar Setty, CISA, has more than 10 years of experience in the areas of data
analysis, systems administration, auditing and computer security. He is a manager at
PricewaterhouseCoopers LLP.

Reference

https://www.isaca.org/resources/isaca-journal/past-issues/2012/database-backup-and-
recovery-best-practices
Full Backup
A full backup is the most complete type of backup where you clone all the selected
data. This includes files, folders, SaaS applications, hard drives and more. The
highlight of a full backup is the minimal time it requires to restore data. However,
since as everything is backed up in one go, it takes longer to backup compared to
other types of backup.
The other common issue with running full backups is that it overloads storage space.
That’s why most businesses tend to run a full backup and occasionally follow it up
with differential or incremental backup. This reduces the burden on the storage space,
increasing backup speed.

Differential Backup
A differential backup straddles the line between a full and an incremental backup.
This type of backup involves backing up data that was created or changed since the
last full backup. To put it simply, a full backup is done initially, and then subsequent
backups are run to include all the changes made to the files and folders.

It lets you restore data faster than full backup since it requires only two
backup components: an initial full backup and the latest differential backup.

Let’s see how a differential backup works:

Day 1 – Schedule a full backup

Day 2 – Schedule a differential backup. It will cover all the changes

that took place between Day 1 and Day 2

Day 3 – Schedule a differential backup. It will make a copy of all the data that has
changed from Day 2 (this includes the full backup on Day 1 + differential backup) and
Day 3.
Incremental Backup
The first backup in an incremental backup is a full backup. The succeeding backups
will only store changes that were made to the previous backup. Businesses have more
flexibility in spinning these types of backups as often as they want, with only the most
recent changes stored.

Incremental backup requires space to store only the changes (increments), which
allows for lightning-fast backups.
Difference Between Full, Differential and Incremental
Backups
 Full Differential Incremental

Storage Space High Medium to High Low

Backup Speed Slowest Fast Fastest

Restoration Speed Fastest Fast Slowest

Most recent full backup & Most recent full backup &
Media Required for
Most recent backup only most recent differential all incremental backups
Recovery
backup since full backup

Stores a lot of duplicate

Duplication Stores duplicate files No duplicate files
files

The Right Backup Strategy With the Right Type of

Backup
Let’s celebrate World Backup Day by choosing the right type of backup, which
often depends on the amount of data you need to backup.

For instance, if you have a high volume of data, you need a backup strategy
that uses the combined power of a full and an incremental backup.

These insights offer clarity for your SaaS backup buying process and can help
you narrow down your search for the right backup solution that meets your
backup needs. After all, you want a reliable solution that will store your
business information, like Google Workspace, Office 365 and Salesforce data,
and help you recover it when you need it.

Spanning, a Kaseya company, is the leader in SaaS Cloud-to-Cloud Backup,

proven and trusted by more than 10,000 organizations to provide enterprise-
class data protection for Office 365, Google Workspace and Salesforce. It
enables end users as well as administrators to easily backup and restore data
in just a few clicks.

Full backups
The most basic and complete type of backup operation is a full backup. As the name
implies, this type of backup makes a copy of all data to a storage device, such as a
disk or tape. The primary advantage to performing a full backup during every
operation is that a complete copy of all data is available with a single set of media.
This results in a minimal time to restore data, a metric known as a recovery time
objective. However, the disadvantages are that it takes longer to perform a full backup
than other types (sometimes by a factor of 10 or more), and it requires more storage
space.

Thus, full backups are typically run only periodically. Data centers that have a small
amount of data (or critical applications) may choose to run a full backup daily, or even
more often in some cases. Typically, backup operations employ a full backup in
combination with either incremental or differential backups.

2. Incremental backups
An incremental backup operation will result in copying only the data that has changed
since the last backup operation of any type. An organization typically uses the
modified time stamp on files and compares it to the time stamp of the last backup.
Backup applications track and record the date and time that backup operations occur
in order to track files modified since these operations.

Because an incremental backup will only copy data since the last backup of any type,
an organization may run it as often as desired, with only the most recent changes
stored. The benefit of an incremental backup is that it copies a smaller amount of data
than a full. Thus, these operations will have a faster backup speed, and require
less media to store the backup.

3. Differential backups
A differential backup operation is similar to an incremental the first time it is
performed, in that it will copy all data changed from the previous backup. However,
each time it is run afterwards, it will continue to copy all data changed since the
previous full backup. Thus, it will store more backed up data than an incremental on
subsequent operations, although typically far less than a full backup. Moreover,
differential backups require more space and time to complete than incremental
backups, although less than full backups.

As shown in "A comparison of different types of backup," above, each backup process
works differently. An organization must run a full backup at least once. For
subsequent backups, it is possible to run either another full, an incremental or a
differential backup. The first partial backup performed, either a differential or
incremental, will back up the same data. By the third backup operation, the data that is
backed up with an incremental is limited to the changes since the last incremental. In
comparison, the third backup with a differential will back up all changes since the first
full backup, which was "Backup 1."

From these three primary types of backup, it is possible to develop an approach

for comprehensive data protection. An organization often uses one of the following
backup settings:

 Full daily

 Full weekly + differential daily

 Full weekly + incremental daily

Many considerations will affect the choice of the optimal backup strategy. Typically,
each alternative and strategy choice involves making tradeoffs between performance,
data protection levels, total amount of data retained and cost. In "A backup strategy's
impact on space" below, the media capacity requirements and media required for
recovery are shown for three typical backup strategies. These calculations presume 20
TB of total data, with 5% of the data changing daily, and no increase in total storage
during the period. The calculations are based on 22 working days in a month and a
one-month retention period for data.

As shown above, performing a full backup daily requires the most amount of space,
and will also take the most amount of time. However, more total copies of data are
available, and fewer pieces of media are required to perform a restore operation. As a
result, implementing this backup policy has a higher tolerance to disasters, and
provides the least time to restore, since any piece of data required will be located on at
most one backup set.

As an alternative, performing a full backup weekly, coupled with running incremental

backups daily, will deliver the shortest backup time during weekdays and use the least
amount of storage space. However, there are fewer copies of data available and
restore time is the longest, since an organization may need to use six sets of media to
recover the necessary information. If data is needed from data backed up on
Wednesday, the Sunday full backup, plus the Monday, Tuesday and Wednesday
incremental media sets, are required. This can dramatically increase recovery times,
and requires that each media set work properly; a failure in one backup set can impact
the entire restoration.

Running a weekly full backup plus daily differential backups delivers results in
between the other alternatives. Namely, more backup media sets are required to
restore than with a daily full policy, although less than with a daily incremental
policy. Also, the restore time is less than using daily incremental backups, and more
than daily full backups. In order to restore data from a particular day, at most two
media sets are required, diminishing the time needed to recover and the potential for
problems with an unreadable backup set.

4. Mirror backups
A mirror backup is comparable to a full backup. According to a blog from backup
vendor Nakivo, "This backup type creates an exact copy of the source data set, but
only the latest data version is stored in the backup repository with no track of different
versions of the files." The backup is a mirror of the source data, thus the name. All the
different backed up files are stored separately, like they are in the source.

One of the benefits of mirror backup is a fast data recovery time. It's also easy to
access individual backed up files.

One of the main drawbacks, though, is the amount of storage space required. With
that extra storage, organizations should be wary of cost increases and maintenance
needs. In addition, if there's a problem in the source data set, such as a corruption or
deletion, the mirror backup experiences the same. As a result, it's a good idea not to
rely on mirror backups for all your data protection needs, and to have other types of
backup for the data. You'll want to follow the 3-2-1 rule of backup, which includes
three copies of data on two different media, with one copy off site.

One specific kind of mirror, disk mirroring, is also known as RAID 1. This process
replicates data to two or more disks. Disk mirroring is a strong option for data that
needs high availability because of its quick recovery time. It's also helpful for disaster
recovery because of its immediate failover capability. Disk mirroring requires at least
two physical drives. If one hard drive fails, an organization can use the mirror copy.
While disk mirroring offers comprehensive data protection, it requires a lot of storage
capacity.

Do the right thing for your organization

For organizations with small data sets, running a daily full backup provides a high
level of protection without much additional storage space costs. Larger organizations
or those with more data or server volume find that running a weekly full backup,
coupled with either daily incremental backups or differential backups, provides a
better option. Using differentials provides a higher level of data protection with less
restore time for most scenarios and a small increase in storage capacity. For this
reason, using a strategy of weekly full backups with daily differential backups is a
good option for many organizations.

Most of the advanced types of backup such as synthetic full, mirror and continuous
data protection require disk storage as the backup target. A synthetic full simply
reconstructs the full backup image using all required incremental backups or the
differential backup on disk. This synthetic full may then be stored to tape for offsite
storage, with the advantage being reduced restoration time. Finally, continuous data
protection enables a greater number of restoration points than traditional backup
options.

When deciding which type of backup strategy to use, the question is when to use each,
and how these options should be combined with testing to meet the overall business
cost, performance and availability goals.

The purpose of most backups is to create a copy of data so that a particular file or
application may be restored after data loss, corruption or deletion, or a disaster strikes.
Thus, backup is not the goal, but rather it is one means to accomplish the goal of
protecting data. Testing backups is just as important as data backup and restore.
Again, the point of data backup is to enable restoration of data at a later point in time.
Without periodic testing, it is impossible to guarantee that the goal of protecting data
is being met.

What is a Database Backup?

Before we start talking about backup methods, let’s talk about the basics. A
database backup is the process of creating a duplicate instance of a database at a
specified interval. This can be done manually by a DBA, by using a backup script, by
using an automated service, or by using database management software. The
backup taken can then be used during the for a partial or a full database recovery.

Database Backup Methods

Database backups can be done in three common ways; full, incremental, and
differential. To minimize downtime, organizations should have a good
combination of at least two of these methods implemented. Let’s look at the basic
idea behind each of these ways and try to understand why it’s best to have the
combination of them in your backup policy.

Full Database Backups

A full backup (as its name implies) is a method to copy all data including user data,
system files, and configuration files from one location to another. Since it makes a
copy of everything, it’s a time consuming process. However, this type of backup
takes a minimal amount of time recovering the data.

This backup method is typically done periodically for large data centres, however,
if the database is a small one, this type of backup could be done on a daily or even
a more frequent interval.

Although it takes time for a full backup, this method ensures all data is at one
location from a specific timestamp. Restoration time, therefore, is faster though
there might be some loss of data in time but the operation can be resumed with a
good amount of data. This may occur, provided the backup has been scheduled
periodically and at reasonable time intervals (especially if this is the only method
employed in the organisation).
Incremental Database Backups
Incremental backups make a copy of updated or newly created files since its last
normal backup in an iterative manner. This type of backup compares the state
change since the last incremental backup. This type of backup is best when the
restoration requires you to store recent changes in smaller chunks.

Incremental means the backup is done in a shorter time with a smaller amount of
data, hence this backup method is faster and requires less space. If the entire data
set is lost, both backups (i.e full and incremental backup data) are required for a
full database restoration.

Differential Database Backups

This backup method stores the recent updates since the last full backup, very
similar to the incremental backup. Differential backup stores the cumulative copies
of changes compared between the first backup and daily transaction changes.
Once a differential backup reaches a certain size a full backup should be triggered,
otherwise the backup copies will exceed the original baseline backup. During
restoration, only a full backup is required, as it has been updated regularly with the
differential backup files. There is a full backup with recent changes, but this
method relies heavily on the network bandwidth to check the recent files and of
course more space.

Pros and Cons of the Database Backup

Method
The three database backup methods each have their own advantages and
disadvantages to be considered while preparing a good database backup strategy
for an organisation.

A full database backup takes longer to backup and needs large storage space. If the
organisation considers to do a frequent full back , a retention policy would be
necessary to know how to manage and archive the older backup copies. A full
backup can be done while the database process is still running or it may require a
downtime for a full backup . This, of course, depends if the organisation is able to
have downtime. At any time , during a recovery period , the full backup will be the
best option for a fast and safe recovery.

When an incremental backup is done frequently, it runs faster and requires a

smaller storage space. It also does not need high computing resources, as it takes a
copy of the new transactions. Ideally, having an incremental backup in place is
important to ensure you have any recent changes. This would ensure the full
system image and timely activity data if a restoration is needed. Of course, the
disadvantage of the incremental backup is the potential need to have both full and
incremental backups for a proper recovery. It might be time-consuming to have
this pieced together during the recovery point, but it's still a lot faster than
differential backups.

Differential backups are faster when compared to the full backup method.
Restoration is faster as only the last full backup and differential backup sets are
required for recovery. There are two perspectives to consider when it comes to
space management. Differential backups do save space (as it only stores the last
changes) but progressively it does require a larger storage space compared to the
incremental backup method. A full backup must be available before starting a
differential backup. If any subsequent differential backup fails, the recovery
process will fail as well. This method always compares the changes with the full
backup, hence it requires high network bandwidth.

Conclusion
It’s best to have at least two types of database backups available at all times for
data protection. A set of full backups is always best to have to handle any full-
recovery scenarios. Full and Incremental backups would be a good combination to
have (the full backup copy to hold the recent transactions).

A full backup should be scheduled weekly on an external device. Ideally, also

having an incremental backup in place to have the recent changes. This would
ensure the full system image and timely activity data in any case of restoration, of
course you would need a tool in merge the full and incremental

Reference

https://backup.ninja/news/Choosing-a-Database-Backup-Method

How to Test a Database Backup & Recovery Plan

Written by

MADELINE CLARKE
Why is TechnologyAdvice Free?

If your organization’s database security is compromised, how would your operations be

affected? Whether it be due to a cyber-attack, a virus, or a physical disaster, there are countless
possible threats to the safety of your organization’s data. And if you aren’t worried about the
effects of data loss, think again. According to a study by the British Chambers of Commerce, 93
percent of businesses that suffer extended data loss of longer than ten days file for bankruptcy
within a year, and fifty percent file for bankruptcy immediately.

For situations like these, database backup and recovery plans can provide some reassurance that
your data is covered – if they are successful. But if your data backup fails, you may still be
unable to recover your organization’s data despite having these precautions set in place. This is
why database backup and recovery plan testing are vital for organizations.
 Testing backup and recovery plans enable you to better prepare for worst-case scenarios and
avoid loss of data that could interrupt production and be detrimental to the success of your
organization. Read on to learn about the importance of backup and recovery plan testing and the
best way to test your backup and recovery processes to ensure the safety of your company data.

Skip to:

 Why it is important to test your plan

 Steps on testing your database backup & recovery plan
 Familiarize yourself with your backup and recovery systems
 Run tests to recover deleted or corrupted files
 Test the backup of your applications
 Test your database recovery
 Time how long it takes to back up your data
 Try testing your backup & recovery plan remotely
 Continue to test your database backup and recovery plan regularly

Why it is important to test your plan

When you’re free-falling out of a plane, the last thing you want to experience is the failure of
your parachute to deploy. To avoid situations like these, skydiving companies constantly test
their equipment to maintain proper safety for their jumpers.

While ensuring the security for your business may not seem like a life or death situation like the
one I just described, let’s face it, data breaches can wreak havoc on the success of an
organization. Whether you like it or not, your livelihood and your workers’ positions are
dependent on your data security to keep the business safe and keep operations moving forward.

Many risks can be involved with the failure to maintain security through database backup and
recovery plan testing. Loss of essential data can put businesses at risk and cause organizations to
halt operations. For example, a Coveware study reflected the average downtime for businesses
due to a ransomware attack to be 22 days. The inability of a company’s operations to continue
for so long due to poor backup recovery plans could result in a loss of money, customers, and
credibility.

If you’re not sure how to accurately test your backup and recovery plan, you’ve come to the right
place. The following text will provide a step-by-step explanation of how to test your plans and
maintain data safety for your organization.

Steps on testing your database backup & recovery

plan
1. Familiarize yourself with your backup and recovery systems

It is crucial to ensure that your organization is familiar with the backup and recovery software
and processes before you need to use them. The last thing you want in an emergency is to be
confused about accessing your restored data because you or your team is inexperienced with the
technology. Your organization’s IT or security staff must know about your software’s
infrastructure, storage capacity, and other components of your backup systems. By having this
knowledge, you will know whether your system meets your database’s needs and how to access
and recover your data quickly.

2. Run tests to recover deleted or corrupted files

In the case that your files become deleted or corrupted, you should be able to rely on your
backup systems to restore them to their original capacity. Testing this can confirm that your
system can restore these files correctly and allows you to familiarize yourself with the process.

To begin, choose some files within the specific file system that you are testing. These files
should have been recently altered or added. Next, you can create a folder for the testing process.
After, you can use your backup system to locate these files and restore them to that folder. Once
you have the files that the system produced, you may then compare the restored files to your
actual files.

When comparing the restored files to your actual files, you should consider any changes or
alterations between the two. For example, ensure that the restored files can be opened and
accessed, that they are the same size as the originals and that all of the recent updates to the
original files are included in the restored ones. This will help you determine whether your system
accurately restored the files and would be able to in a situation where the originals were lost.

3. Test the backup of your applications

Applications can house essential data that may be lost if they aren’t properly backed up. Similar
to the process of testing your file recovery, you can run a restore of your applications.

When comparing the restored application to the original, you should test for changes in the data
contained within the application and the functionality of the application. The restored application
should be accessible with a similar amount of stored data and the same capabilities as the
original.

You should look for consistency between your original and restored applications. If your restored
application cannot be utilized with your original data, then your application backup cannot be
considered successful.

Also read: Databricks vs. Snowflake

4. Test your database recovery

Database recovery consists of restoring the entire database, should it be compromised. This
process is a bit more extensive, as you first need to ensure that the place you restore your data
has the database software installed but won’t interfere with the original database. Therefore,
using a separate database server or restoring the data virtually to the cloud is suggested.

Suppose you only have one database server available. In that case, you can still perform this test
on the same machine that hosts the production database if it has enough space, as long as you use
a separate name for the restored database to avoid the possibility of overwrites or interferences to
the original database during the restoration process.

Once your software has restored the database, test the recovered database compared to the
production database. This can be done by running queries against each database, running macro
tests, and connecting apps to the recovered database to ensure that they function correctly.

5. Time how long it takes to back up your data

It is beneficial to test how long it takes for your system to complete the backup restoration
throughout this process. This is important to be aware of since a long time for backups to process
could mean more downtime for your company and consequences to your internal operations,
clients, and reputation.

By taking note of the time your system takes to backup your test data, you can apply this to the
amount of data necessary for your organization to function. This can enable you to determine
how long your restoration process could leave your company waiting before work became
possible again if an emergency wiped out the entire system.

Knowing this information can allow you to plan for such a scenario and may help you to
consider faster alternatives for backing up your data if necessary.

Also read: 5 Ways Tokenization Can Improve Database Security

6. Try testing your backup & recovery plan remotely

Many organizations utilize cloud-based applications and software systems because they are
accessible from remote locations. Likewise, being able to restore your data remotely can be
crucial in case of an emergency.

It is beneficial for organizations to ensure that they can access their data in an emergency, even if
it must be done remotely. This could be due to several reasons, such as natural disasters
damaging your company infrastructure or a system failure.

Therefore, running an offsite restore test will help you test whether your cloud-based or remotely
located data can be restored and how long this would take before your company could
commence operations.
7. Continue to test your database backup and recovery plan regularly

Testing your database and recovery plan can give you peace of mind, but changes to your data
storage and system are ordinary for organizational networks and may cause changes in your
plan’s capability to restore your data. It is because of this that many organizations conduct these
tests regularly.

So how often should organizations conduct database backup and recovery testing? It is best to
schedule tests regularly, such as weekly or monthly. The frequency of tests can also be based
upon resource needs. For example, you can test the backup of data that is necessary to the
company’s operation more frequently, as its ability to be restored is more critical.

Database backup and recovery plans should be tested on their reliability to restore data as
accurately and quickly as possible. By conducting regular tests and staying on top of
your backup and recovery plan’s capabilities, your organization will be more protected from
potential threats.

Reference
https://technologyadvice.com/blog/information-technology/how-to-test-database-backup/