RMAN Disk to Disk Backup Methods

Disk to disk backups are becoming the norm. This article
takes a 1,000 foot view to help evaluate your options.

Database Storage

are three distinct options available for an installer of an Oracle database.
Those available storage options for database files are File Systems, Oracle’s
Automatic Storage Management (ASM), or Raw Devices. Each of these storage
options are defined further in the Installation Guides for the particular
operating system supported. The Installation Guide should be read to determine
how to take advantage of the storage option chosen.

File Systems

Systems are what most DBAs are familiar with and have extensively used. For
instance, File Systems can reside on disks through locally attached disks
internal to a server, through a Logical Volume Manager (LVM) or Redundant Array
of Inexpensive Disks (RAID) that are on some form of attached storage device such
as a Storage Area Network (SAN). Regardless of the form, these file systems are
mounted on the host server and when Oracle storage is required to create
objects or store data Oracle will make use of physical files in some form of
predefined directory structure. These physical files can either be named by an
Oracle DBA or can be automatically generated by Oracle. The Installation Guides
provided by Oracle should be consulted for your particular operating system to
determine how to place database files on a File System and how to follow
Oracle’s Flexible Architecture (OFA) to ensure a reliable and manageable

Automatic Storage Management (ASM)

Storage Management (ASM) is Oracle’s proprietary storage solution for Oracle
databases that simplifies and removes most of the need for traditional disk
management tools. A DBA no longer needs to lay out or create database directory
structures. ASM handles all underlying disk usage. ASM is able to manage all
forms of database files, provide redundancy, and handle disk corruption and
failures. ASM is another Oracle instance that communicates with a database
instance through Oracle Cluster Synchronization Services (CSS). One or more
disk devices are allocated to an ASM instance and then placed in ASM Disk
Groups that in turn are referenced by the database instance. The Installation
Guide provided by Oracle for your particular operating system should be read to
determine how to install and configure ASM, and then enable use with an Oracle

Raw Devices

devices are nothing more than disks that have not been formatted with a file
system. When data is written from Oracle it bypasses the operating system file
system layer and writes directly to the partition or volume. Because of the
complexity to manage, Oracle does not recommend using raw devices. As such, this
paper will not present additional information about raw devices and is merely
here as a placeholder to let the reader know they are available.

Typical Database Layout

database instances are configured in such a way as depicted by the following
layout. File Systems or ASM groups may be used to segregate and create the
individual Oracle database structures on.

Flash Recovery Area

Oracle’s Flash Recovery Area is an allocated disk storage
location where all backup and recovery related files are stored. The Flash
Recovery Area can be pointed to a File System or Automatic Storage Management
(ASM) disk group. All database related files required for recovery can be
backed up and stored in the Flash Recovery Area. These files include the
control file, online logs, archive logs, flashback logs, control file
autobackups, control file copies, datafile copies, and backup pieces.

The Flash Recovery Area is tightly integrated within the
Oracle database and is an opportunistic area for performing disk to disk
backups. With the use of RMAN and the Flash Recovery Area, assuming it has been
allocated enough storage, a powerful mechanism can be created to provide
faster, simpler, and automatic recovery of an Oracle database. Oracle also
manages and keeps the Flash Recovery Area clean by storing only what is
necessary and automatically removing obsolete files that might would not be
needed for a recovery scenario, are redundant copies, or have been backed up to
another storage device such as tape.

The Installation Guide provided by Oracle for your particular
operating system should consulted to determine how to configure the Flash
Recovery Area. It is as easy as setting two init.ora parameters. Those
being: DB_RECOVERY_FILE_DEST (location of Flash Recovery Area) and
DB_RECOVERY_FILE_DEST_SIZE (Amount of disk available for Flash Recovery Area)
and then all RMAN backups, archive logs, control file autobackups, and datafile
copies will automatically be written to the specified file system or ASM group.

The Flash Recovery Area can also be tailored to meet any
database’s needs. It can be large enough to keep full, incremental, and archive
logs available, as large as the database itself so a complete backup can be
done, or small enough to just keep archive logs around. Flash Recovery Area
should be taken advantage of if for nothing else than archive redo logs, online
redo logs, and control files. These database structures already take up disk
space and thus there is no real advantage to not having them within the Flash
Recovery Area. Moreover, administration of recoveries becomes much easier with
added features that would not normally be available.

Integration of Flash Recovery Area

following figure depicts how a Flash Recover Area might be used within an
Oracle database. Archive log destinations are directly written to the Flash
Recovery Area as well as handling online redo logs. Also, but not shown on the
figure, control files may be stored in the Flash Recovery Area. Backups through
RMAN are also written to this area.

When configuring database
storage, keep in mind that the same storage option is not required for database
or recovery area. File Systems may be used for the database while the Flash
Recovery Area might be ASM. The only unsupported file type would be raw devices
for the Flash Recovery Area, thus another reason to stay away from raw devices.

Oracle Recovery Manager (RMAN)

Oracle Recovery Manager (RMAN)
is an Oracle utility used for backups and restores to an Oracle database. Its use
has been widely accepted in the Oracle community for the ease and efficient
method with which it can be scheduled, determining backup and recovery needs,
as well as finding corruption down to the database block level. Under best
practices, the RMAN environment consists of a dedicated RMAN instance, which
can be directed at any number of target database instances for backup and
recovery needs.

With the reduction in cost of
many disks coupled with the simplicity of RMAN and the plain fact that many
storage vendors are unable to keep pace with Oracle technology, Oracle suggests
that disk to disk (D2D) backups should be done using the RMAN utility. The
intuitive nature of RMAN and the fact that RMAN is tightly integrated with the
Oracle database makes this a strategy that should be seriously thought of. Plus,
many database need to be near real time, which can only be accomplished if disk
to disk backup and restores have been implemented.

As noted earlier in this paper,
RMAN can use the Flash Recovery Area to make backups of a target database. This
type of backups is inline with Oracle’s suggested strategy for full and
incremental backups as well as the keeping of archive and online redo logs. The
tight integration of RMAN with the Oracle kernel and its knowledge of what
resides in the Flash Recovery Area, and what needs to be backed up or recovered
makes it nearly the only choice for optimal management of Oracle databases to
circumvent disaster. There is no comparison when placed side by side with user-managed
backups and no backup strategy should be considered that does not take
advantage of RMAN in some form or fashion. For instance, RMAN is able to detect
block-level corruption that is not available in most alternative backup
solutions. RMAN also contains a catalog that keeps information about each
backup and aids in the recovery process.


Availability will often dictate the backup and recovery
device actually required. However, for database environments that need to be
available as much as possible there is no comparison when confronted with the
question of tape or disk.

Backups in themselves do not necessarily hinder the
availability of a database because an Oracle database can be continually
available while hot backups are being done. The real determining factor for
disk over tape is the recovery time. Recovering a database from tape can, very
conservatively, take in excess of 10 times the amount of time it would from
disk. Compound this with the time required to reassemble the individual pieces
of Oracle, an Oracle database could be down for hours if not days depending on
how large the database is and what pieces are actually going to be restored.

The advantages to disk based backups and restores can easily
be seen in the following:

  • Decreasing cost of high-volume
    low-cost storage such as SATA drives
  • Decreased backup window by
    using multiple I/O streams
  • Decreased recovery time by
    using multiple I/O streams
  • Increased availability of
  • Increased protection through
    RAID technology
  • Increased usage and viability
    of backups through SANtricity Premium Features


See All Articles by Columnist
James Koopmann

James Koopmann
James Koopmann
James Koopmann has fourteen years of database design, development and performance tuning experience. In addition, he has extensive database administration experience in Oracle and other relational databases in production environments, specializing in performance tuning of database engines and SQL based applications. Koopmann is an accomplished author with several technical papers in various Oracle related publications such as Oracle Magazine, Oracle Professional and SQL>UPDATE_RMOUG. He is a featured author and database expert for DatabaseJournal, a member of the editorial review committee for Select Journal (The Magazine for the International Oracle Users Group), an Oracle Certified Professional DBA and noted speaker at local Oracle User Groups around the country.

Latest Articles