Block-Level Incremental Backup

(1)

A S T O R A G E M A N A G E M E N T S O L U T I O N from VERITAS Software Corporation

(2)

(3)

Figures

FIGURE 1: FULL AND INCREMENTAL BACKUPS... 6

FIGURE 2: RESTORING A FILE SYSTEM FROM DIFFERENTIAL AND CUMULATIVE BACKUPS... 7

FIGURE 3: USING A SNAPSHOT... 9

FIGURE 4: MULTIPLE CHECKPOINTS AND DATABASE ROLLBACK... 10

FIGURE 5: CONSISTENT DATABASE BACKUP USING STORAGE CHECKPOINTS... 11

(4)

(5)

Backup: Because Stuff Happens

In the best designed data center in the world, things can go wrong.

➨ Hardware can fail.

➨ Operating systems and other environmental software can malfunction.

➨ Application errors can corrupt operating data.

➨ A disaster can incapacitate the data center.

➨ Humans can make errors.

Advanced techniques such as disk volume mirroring, clustering, and remote data rep-lication significantly reduce exposure to most of these failures. As experienced sys-tem administrators know, however, mirrored volumes store incorrect data just as re-liably as they store correct data, and clusters restart applications with bugs just as quickly as they restart applications that are working properly.

For some failures, a data center has to be able to restore a stable point-in-time data-base backup image, and recover from there. In other words, regular reliable backup is as necessary as it ever has been.

Backup Seems Simple…

Backup is simple. A system administrator:

➨ decides which data is critical and has to be backed up,

➨ determines an appropriate time to perform the backup,

➨ uses a utility program like tar to make the backup copy, and,

➨ stores the copy in a safe place in case it is ever required for recovery.

Conceptually, this really is simple. The difficulties for system administrators lie in:

➨ Resources: It’s obviously important to get backup done as quickly as possible.

But to finish faster, data has to be copied faster, which means greater demands on disks and I/O channel bandwidth. But disks and channels that are busy with backup requests can’t process transactions. Simply put, the more I/O resources a backup uses, the slower online operations become.

➨ Timing: In order to represent a consistent point-in-time image, backups should

(6)

Block-Level Incremental Backup Edition: 02/16/00 3:10 PM

Copyright  VERITAS Software Corporation, 2000 by: Paul Massiglia

6

Advanced Backup Techniques

The bigger an enterprise, the more data needing backup it is likely to possess. Be-cause backup is very resource intensive, large enterprises invariably wish to minimize its impact on operations. Both storage system and software vendors (like EMC, VERITAS, and Oracle) have developed innovative techniques to minimize the impact of backup on online operations. Two of the most important ones are incremental backup and frozen image technology.

Incremental Backup

In most applications, only a small percentage of data changes between successive backups. Incremental backup techniques use this fact to shorten backup times and minimize resource requirements. For example, an incremental backup of a file system copies only files that have changed since the last backup. If only a few files have changed, an incremental backup completes much faster and has less impact on online operations. Figure 1 compares full and incremental backup.

Application Updates File A File System File D File G File B File E File H File C File F Unused Space File A File D File G File B File E File H File C File F File A File System File D File G File B File E File H File C File F File I File J File B File H File H File B

Full backup: all files are copied Incremental bakcup: only changed files are copied

Figure 1: Full and Incremental Backups

Incremental backup does not replace full backup; it reduces the frequency with which full backups are required. An incremental backup contains data that have changed since the latest point in time for which a full backup is available. To restore a file system, one restores the newest full backup, and then restores all newer incremental backups in order.

(7)

small amounts of data are copied during busy times. The disadvantage is that restores may involve more media handling and take longer to execute.

Differential and Cumulative Incremental Backup

A differential backup copies all data modified since the last backup of any kind. To restore from a differential backup, one restores the newest full backup and all newer differential backups.

A cumulative backup copies all data modified since the last full backup. To restore from a cumulative backup one restores the newest full backup and the newest cumu-lative backup. This is simpler and faster than restoring from differential backups. The disadvantage is that each cumulative backup takes longer to make than the previous one, since more data has changed since the last full backup.

File A File System File D File G File B File E File H File C File F File I File J File A File System File D File G File B File E File H File C File F File I File J File A File D File G File B File E File H File C File F File I File J All Differential Backups made since newest Full Backup File E File J File A File F File C File J Newest Cumulative Backup Both restores start by

restoring the Newest Full Backup

Restored File Systems are identical File A File D File G File B File E File H File C File F File I File J File E File A File F File C File J

(8)

8

Sunday Monday Tuesday Wednesday Thursday Friday Saturday Type of

Backup

Full backup Differential Incremental Differential Incremental Cumulative Incremental Differential Incremental Differential Incremental Differential Incremental Data in backup copy Full database as it stood on Sunday Changes since Sunday’s full backup Changes since Monday’s backup Changes since Sunday’s full backup Changes since Wednesday’s backup Changes since Thursday’s backup Changes since Friday’s backup Full Database Restore Procedure Restore Sunday’s full backup Restore Sunday’s full backup and Monday’s differential Restore Sunday’s full backup, Monday’s and Tuesday’s differentials Restore Sunday’s full backup and Wednesday’s cumulative Restore Sunday’s full backup, Wednesday’s cumulative, and Thursday’s differential Restore Sunday’s full backup, Wednesday’s cumulative, Thursday’s and Friday’s differentials Restore Sunday’s full backup, Wednesday’s cumulative, Thursday’s, Friday’s, and Saturday’s differentials

Table 1: Sample Weekly Backup Strategy using Differential and Cumulative Backups

Frozen Image Technology

Today, IT organizations are faced with the conflicting demands of:

➨ regular reliable backup, required because of the value of data, and,

➨ continuous application availability to meet competitive pressures.

In other words, backup has to be done, but the database can’t be taken down to do it. Both RAID and storage management software vendors have risen to this challenge with innovative technologies that enable an image of online data to be frozen at a user-determined point in time. Frozen images, sometimes called snapshots, can be the source for backup while applications continue to update the main data.

Two popular frozen image techniques are breakaway mirrors and copy-on-write. For breakaway mirrors, a volume manager maintains two or more identical copies of data on separate sets of disks. To initiate a backup, database and other volume activity are stopped. One set of disks is remounted as a read-only volume, and backed up. Appli-cations process against the other set (or sets) while the backup is occurring.

Breakaway mirrors are very reliable, because they contain two or more complete copies of data. Their disadvantages are storage consumption and the I/O resources re-quired to resynchronize the breakaway disks with operational data each time a backup completes.

To overcome these disadvantages, the copy-on-write technique was developed. As the name suggests, a copy-on-write snapshot of a file system contains both new and old copies of modified data, but only one copy of unmodified data.

(9)

Next, a changed block map in which changes will be recorded is created. Additional space for before images of changed data may also be allocated at this time. When these steps (typically requiring a few seconds) are complete, application access can resume. The snapshot can be mounted immediately as a read only file system.

File A

File System _Snapshot

File B

Free Space

Changed Block Map

Free Space

application (e.g., backup) reads from the snapshot

Free Space

No: Read from original location File D: Block 1 Modified block? Yes: Read from snapshot

Other Changed Blocks

application writes to the file system

No: Just write data

Yes: Copy to snapshot before overwriting First modification of block?

Read File A: Block 1 Read File D: Block 1

Write File D: Block 1

application reads from the file system

Read File A: Block 1

Figure 3: Using a Snapshot

Using Snapshots

Figure 3 illustrates reading and writing in a file system with a snapshot. Application reads from the file system are identical whether or not a snapshot is in effect. When an application (such as backup) reads from the snapshot, the data is delivered:

➨ from its original file system location if it has not been modified, or,

➨ from the snapshot’s before image if the file system image has been modified. When an application writes data for the first time since snapshot initiation, the data being overwritten is first copied to the snapshot. In addition, the changed block map is updated to indicate the location of the before image in the snapshot area.

(10)

10

VERITAS NetBackup and Oracle

If a snapshot is to be used for database backup, both the containing file system and the database must be quiescent when it is created. The VERITAS Database Edition for Oracle can request that Oracle quiesce a database momentarily for snapshot initiation. Snapshot initiation, normally a second or two, is the only time during which the data-base is unavailable to applications.

To further facilitate Oracle backup, the VERITAS file system implements a special type of snapshot called a Storage Checkpoint. Storage Checkpoints differ from other VERITAS snapshot implementations in that:

➨ They are persistent (i.e., they still exist after a system reboot).

➨ They use the file system free space pool rather than separately allocated space.

➨ They are only accessible to the NetBackup component of the VERITAS Data-base Edition for Oracle.

Table Space A Main Database Image Table Space B Table Space C database updates Storage Checkpoint T3

Changed Block Map “Before Images” of Changed Blocks

since T3

Storage Checkpoint T2

Changed Block Map “Before Images” of Changed Blocks since

T2

T1 T2 T3

Database state at T1, T2, or T3 can be backed up Database can be rolled back to

its state at T1, T2, or T3.

Storage Checkpoint T1

Changed Block Map “Before Images” of Changed Blocks since

T1 U4 U5 U6 U7 U8 U1 U2 U3 U4 U5 U6 U7 U8 U1 U2 U3 U4 U5 U6 U7 U8 U1 U2 U3 U4 U5 U6 U7 U8 “Before Images” of updated data U7 U8 U7 U8 U4 U5 U6 U7 U8 U1 U2 U3 U4 U5 U6 U7 U8

Figure 4: Multiple Checkpoints and Database Rollback

The VERITAS VxFS file system supports multiple concurrent Storage Checkpoints, as Figure 4 illustrates. This has three advantages for database administrators:

➨ Choice of backup times: A point-in-time backup can be made from any active

Storage Checkpoint.

➨ Database rollback. The VERITAS Database Edition for Oracle can copy the

(11)

➨ Point-in-time queries. A Storage Checkpoint can be used for systematic data

mining or ad hoc queries to a database as it existed at a specific point in time.

Block-Level Incremental Backup

A typical database consists of a small number of relatively large datafiles. While only a small fraction of its data may change between backups, changes to a database are usually distributed throughout its datafiles. Thus, an incremental backup that copies each changed file in its entirety is likely to include all of a database’s datafiles, effec-tively becoming a full backup. As with a true full backup, the impact on online I/O resources can be substantial.

A Storage Checkpoint’s changed block map identifies changed database blocks re-gardless of what files they reside in. VERITAS NetBackup can use this information to create Block-Level Incremental Backups that contain only changed database blocks. Figure 5 illustrates block level incremental backup.

Storage Checkpoint

Changed Block Map “Before Images” of Changed Blocks Table Space A Main Database Image Table Space B Table Space C Backup of changed blocks (only) Application Updates “Before Images” of updated data U1 U2 U3 U4 U5 U6 U7 U8 U1 U2 U3 U4 U5 U6 U7 U8 U1 U2 U3 U4 U5 U6 U7 U8 U1 U2 U3 U4 U5 U6 U7 U8 U1 U2 U3 U4 U5 U6 U7 U8 NetBackup Block Level Incremental Backup

Figure 5: Consistent Database Backup Using Storage Checkpoints

A block level incremental backup contains only “before images” of database blocks modified since the instant of Storage Checkpoint creation. If only a small percentage of a database is updated, its block level incremental backup image is correspondingly small. Compared to full database backup, block level incremental backup typically takes very little time and uses only small amounts of storage and I/O bandwidth. By greatly reducing the resource impact of backup, block level incremental backup encourages database administrators to schedule more frequent backups. Frequent backups reduce backup bandwidth and storage capacity requirements still further, and enable database restores to points in time closer to failure instants.

(12)

da-Block-Level Incremental Backup Edition: 02/16/00 3:10 PM

12

lowed by restores of all newer block level incremental backups. VERITAS Net-Backup keeps track of backup relationships and automatically applies the appropriate full and incremental backups necessary to restore a database to a given state.

Closer Integration with Oracle

The latest release of VERITAS NetBackup (Version 3.2) integrates even more closely with Oracle. A NetBackup Advanced Block-Level Incremental Agent can be invoked by Oracle’s Recovery Manager (RMAN). A database administrator can use RMAN’s proxy backup feature to request that NetBackup back up some or all of a database’s datafiles (Oracle control files cannot use this technique, and are backed up separately through RMAN). NetBackup will use the block level incremental backup technique if appropriate. Thus, the database administrator has both the backup cataloging feature and central control of RMAN and the minimal operational impact of block level in-cremental backup and NetBackup’s media management, data stream multiplexing, and backup automation facilities.

Summary

The conflicting IT imperatives of protecting enterprise data against failures of all kinds and 24x7 online operation make database backup a particularly difficult prob-lem for database administrators. On the one hand, frequent, consistent database im-ages need to be maintained in case database recovery is necessary. But taking a data-base out of service for backup is no longer an option for many installations. Even if databases didn’t have to be online all the time, the I/O resource impact would make frequent full backups impractical.

Software technology has developed techniques that enable incremental backups of frozen database images. By reducing the amount of data copied, incremental backup reduces resource requirements and makes it practical for database administrators to schedule more frequent backups. By backing up from a frozen database image mounted as a separate read-only file system, consistent backups are guaranteed with almost no application down time.

(13)

data-files that include only blocks actually changed since the last backup. VERITAS has gone further, integrating NetBackup’s block level incremental backup capability with the Oracle Recovery Manager’s proxy backup feature, allowing a database adminis-trator to use RMAN to schedule or invoke incremental backups that are actually man-aged and executed by NetBackup. This gives the database administrator single-point control over Oracle database management, while providing all the media manage-ment, performance, and feature advantages of NetBackup managed backups.

Block-Level Incremental Backup

Contents

Figures

Backup: Because Stuff Happens

Advanced Backup Techniques

VERITAS NetBackup and Oracle

Summary