A database can become unusable because of hardware or software failure, or both. You may, at one time or another, encounter storage problems, power interruptions, application failures, and different failure scenarios that require different recovery actions. It is important to protect your data against the possibility of loss by having a well-rehearsed recovery strategy in place. Some of the questions that you should answer when developing your recovery strategy are:
Now the question is, Why back up? What are you trying to protect? What failures do you expect?
A database recovery strategy should ensure that all information is available when it is required for database recovery. It should include a regular schedule for taking backups and, in the case of partitioned database systems, should include backups when the system is scaled (when database partitions are added or dropped).
The overall strategy should also include procedures for recovering command scripts, applications, user -defined functions (UDFs), as well as stored procedure code in the operating system libraries, and load copies.
Different recovery methods are discussed in the sections that follow, and you will discover which recovery method is best suited to your business environment.
The concept of a database backup is the same as any other data backup: taking a copy of the data, then storing it on a different medium in case of failure or damage to the original. The simplest case of a backup involves shutting down the database to ensure that no further transactions occur, then simply backing it up. You can then rebuild the database if it becomes damaged or corrupted in some way.
The rebuilding of the database is called recovery .
Each database includes logs, which are used to recover from application or system errors. In combination with the database backups, they are used to recover the consistency of the database right up to the point in time when the error occurred.
Data that is easily recreated can be stored in a non-recoverable database. This includes data from an outside source that is used for read-only applications and tables that are not often updated, for which the small amount of logging does not justify the added complexity of managing log files and rolling forward after a restore operation. Non-recoverable databases have both the LOGRETAIN and the USEREXIT database configuration parameters turned off. This means that the only logs that are kept are those required for crash recovery.
These logs are known as active logs , and they contain current transaction data. Version recovery using offline backups is the primary means of recovery for a non-recoverable database. An offline backup means that no other application can use the database when the backup operation is in progress. Such a database can be restored only offline. It is restored to the state it was in when the backup image was taken, and rollforward recovery is not supported.
Data that cannot be easily recreated should be stored in a recoverable database. This includes data whose source is destroyed after the data is loaded, data that is manually entered into tables, and data that is modified by application programs or users after it is loaded into the database. Recoverable databases have either the LOGRETAIN database configuration parameter set to RECOVERY, the USEREXIT database configuration parameter set to YES, or both.
Active logs are still available for crash recovery, but when the database is configured as a recoverable database, you also have the archived logs, which contain committed transaction data. Such a database can be restored only offline. It is restored to the state it was in when the backup image was taken. However, with rollforward recovery, you can roll the database forward (that is, past the time when the backup image was taken) by using the active and archived logs either to a specific point in time or to the end of the active logs.
Recoverable database backup operations can be performed either offline or online. An online backup means that other applications can connect to the database when the backup operation is in progress. Database restore and rollforward operations must always be performed offline. During an online backup operation, rollforward recovery ensures that all changes are captured and reapplied if that backup is restored.
If you have a recoverable database, you can back up, restore, and roll individual table spaces forward, rather than the entire database. When you back up a table space online, it is still available for use, and simultaneous updates are recorded in the logs. When you perform an online restore or rollforward operation on a table space, the table space itself is not available for use until the operation completes, but users can be allowed to access tables in other table spaces.
The Recovery History File
The recovery history file contains certain historical information about major actions that have been performed against a database. The information recorded in the recovery history file is used to assist with the recovery of the database in the event of a failure. The following is a list of the actions that will generate an entry in the history file:
A recovery history file is also created automatically when a database is created. This file is located in the database directory. You cannot directly modify a recovery history file; however, you can delete entries from the recovery history file using the PRUNE HISTORY command. You can also use the REC_HIS_RETENTN database configuration parameter to specify the number of days that the recovery history file will be retained.
Recovery history file related to backup information for the database SAMPLE:
db2 list history backup all for sample List History File for sample Number of matching file entries = 1 Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID --- --- ---------------- ---- --- ------------ ------------ --------- B D 20020829090733001 F D S0000000.LOG S0000000.LOG -------------------------------------------------------------------------- Contains 2 tablespace(s): 00001 SYSCATSPACE 00002 USERSPACE1 -------------------------------------------------------------------------- 00002 USERSPACE1 Comment: DB2 BACKUP SAMPLE OFFLINE Start Time: 20020829090733 End Time: 20020829090756 ------------------------------------------------------------------------ 00001 Location: /data/dbbackup
Deciding How Often to Back Up
Your recovery plan should allow for regularly scheduled backup operations, because backing up a database requires time and system resources. Your plan may include a combination of full database backups, table space backups, and incremental backup operations.
You should take full database backups regularly, even if you archive the logs (which allows for rollforward recovery). It is more time consuming to rebuild a database from a collection of table space backup images than it is to recover the database from a full database backup image. Table space backup images are useful for recovering from an isolated disk failure or an application error.
You should also consider not overwriting backup images and logs, saving at least two full database backup images and their associated logs as an extra precaution.
If the amount of time needed to apply archived logs when recovering and rolling a very active database forward is a major concern, consider the cost of backing up the database more frequently. This reduces the number of archived logs you need to apply when rolling forward. You can initiate a backup operation while the database is either online or offline. If it is online, other applications or processes can connect to the database, as well as read and modify data while the backup operation is running. If the backup operation is running offline, other applications cannot connect to the database.
To reduce the amount of time that the database is not available, consider using online backup operations. Online backup operations are supported only if rollforward recovery is enabled. If rollforward recovery is enabled and you have a complete set of recovery logs, you can rebuild the database, should the need arise. You can use an online backup image for recovery only if you have the logs that span the time during which the backup operation was running.
Offline backup operations can be faster than online backu operations, because there is no contention for the data files.
The backup utility lets you back up selected table spaces. If you use DMS table spaces, you can store different types of data in their own table spaces to reduce the time required for backup operations. You can keep table data in one table space, long field and large object (LOB) data in another table space, and indexes in yet another table space. If you do this and a disk failure occurs, it is likely to affect only one of the table spaces. Restoring or rolling forward one of these table spaces will take less time than it would have taken to restore a single table space containing all of the data.
If a table is split among table spaces, you must restore all of the table spaces for the table to roll forward to a point in time prior to the end of the logs.
You can also save time by taking backups of different table spaces at different times, as long as the frequency of changes to them are not the same. If long field or LOB data is not changed as frequently as the other data, you can back up these table spaces less frequently. If long field and LOB data are not required for recovery, you can also consider not backing up the table space that contains that data. If the LOB data can be reproduced from a separate source, choose the NOT LOGGED column option when creating or altering a table to include LOB columns .
When formulating a recovery plan, you should take these recovery costs and their impact on your business operations into account. Testing your overall recovery plan will assist you in determining whether the time required to recover the database is reasonable, given your business requirements. Following each test, you should determine whether the recovery time required is acceptable; if it is too long, you may want to increase the frequency with which you take a backup. If rollforward recovery is part of your strategy, this will reduce the number of logs that are archived between backups and, as a result, reduce the time required to roll the database forward after a restore operation.
When deciding which recovery method to use, consider the storage space required.
The version recovery method requires space to hold the backup copy of the database and the restored database. The rollforward recovery method requires space to hold the backup copy of the database or table spaces, the restored database, and the archived database logs.
If a table contains long field or LOB columns, you should consider placing this data into a separate table space. This will affect your storage space considerations, as well as your plan for recovery, as mentioned above. With a separate table space for long field and LOB data, and knowing the time required to back up long field and LOB data, you may decide to use a recovery plan that only occasionally saves a backup of this table space. You may also choose, when creating or altering a table, to include LOB columns, not to log changes to those columns. This will reduce the size of the required log space and the corresponding log archive space.
To prevent media failure from destroying a database and your ability to rebuild it, keep the database backup, the database logs, and the database itself on different devices. For this reason, it is highly recommended that you use the NEWLOGPATH configuration parameter to put database logs on a separate device, once the database is created.
The database logs can use up a large amount of storage. If you plan to use the rollforward recovery method, you must decide how to manage the archived logs. Your choices are the following:
Keeping Related Data Together
As part of your database design, you will know the relationships that exist between tables. These relationships can be expressed at the application level, when transactions update more than one table; at the database level, where referential integrity exists between tables; or where triggers on one table affect another table. You should consider these relationships when developing a recovery plan. You will want to back up related sets of data together. Such sets can be established at either the table space or the database level. By keeping related sets of data together, you can recover to a point where all of the data is consistent. This is especially important if you want to be able to perform point-in-time rollforward recovery on table spaces.
Using Different Operating Systems
When working in an environment that has more than one operating system, you must consider that you cannot back up a database on one operating system, then restore that database on another operating system (such as UNIX to/from Linux or Windows).
In such cases, you should keep the recovery plans for each operating system separate and independent. There is, however, support for cross-platform backup and restore operations between operating systems with similar architectures, such as AIX, HP/UX, and Sun Solaris, and between 32-bit and 64-bit operating systems.
When you transfer the backup image between systems, you must transfer it in binary mode. The target system must have the same (or later) version of DB2 as the source system. Restore operations to a down-level system are not supported.
If you must move tables from one operating system to another and cross-platform backup and restore support is not available in your environment, you can use the db2move command, or the export utility followed by the import or the load utility.
Transactions or units of work against a database can be interrupted unexpectedly. If a failure occurs before all of the changes that are part of the unit of work are completed and committed, the database is left in an inconsistent and unusable state. Crash recovery is the process by which the database is moved back to a consistent and usable state. This is done by rolling back incomplete transactions and completing committed transactions that were still in memory when the crash occurred. When a database is in a consistent and usable state, it has attained what is known as a point of consistency .
If you want the rollback of incomplete units of work to be done automatically by the database manager, enable the automatic restart (AUTORESTART) database configuration parameter by setting it to ON; this is the default value. If you do not want automatic restart behavior, set the AUTORESTART database configuration parameter to OFF. As a result, you will need to issue the RESTART DATABASE command when a database failure occurs. If the database I/O was suspended before the crash occurred, you must specify the WRITE RESUME option of the RESTART DATABASE command in order for the crash recovery to continue. The administration notification log records when the database restart operation begins.
If crash recovery is applied to a database that is enabled for forward recovery (that is, the LOGRETAIN configuration parameter is set to RECOVERY, or the USEREXIT configuration parameter is set to ON) and an error occurs during crash recovery that is attributable to an individual table space, that table space will be taken offline and cannot be accessed until it is repaired. Crash recovery continues. At the completion of crash recovery, the other table spaces in the database will be accessible, and connections to the database can be established. However, if the table space that is taken offline is the table space that contains the system catalogs, it must be repaired before any connections will be permitted.
Recovering Damaged Table Spaces
A damaged table space has one or more containers that cannot be accessed. This is often caused by media problems that are either permanent (a bad disk) or temporary (an offline disk or an unmounted file system).
If the damaged table space is the system catalog table space, the database cannot be restarted. If the container problems cannot be fixed, leaving the original data intact, the only available options are:
If the damaged table space is not the system catalog table space, DB2 attempts to make as much of the database available as possible.
If the damaged table space is the only temporary table space, you should create a new temporary table space as soon as a connection to the database can be made. Once created, the new temporary table space can be used, and normal database operations requiring a temporary table space can resume.
You can, if you wish, drop the offline temporary table space. There are special considerations for table reorganization using a system temporary table space:
Recovering Table Spaces in Recoverable Databases
When crash recovery is necessary, a damaged table space will be taken offline and will not be accessible. It will be placed in rollforward pending state. A restart operation will succeed if there are no additional problems, and the damaged table space can be used again once you:
Reducing the Impact of Media Failure
To reduce the probability of media failure causing a database problem and to simplify recovery from this type of failure if it does occur:
Protecting Against Disk Failure
If you are concerned about the possibility of damaged data or logs due to a disk crash, consider the use of some form of disk fault tolerance. Generally , this is accomplished through the use of a disk array or disk/file system mirroring.
A disk array is sometimes referred to simply as a RAID. Disk arrays can also be provided through hardware or software at the operating system or application level. The point of distinction between hardware and software disk arrays is how processing of I/O requests is handled.
For hardware disk arrays, I/O activity is managed by the disk controllers; for software disk arrays, this is done by the operating system/file system.
Hardware Disk Arrays
In a hardware disk array, multiple disks are used and managed by a disk controller (or controllers), complete with its own memory/storage. All of the logic required to manage the disks forming the array is contained on the disk controller; therefore, this implementation is independent of the operating system.
There are several types of RAID architecture, differing in function and performance, but RAID levels 1 and 5 are the most commonly used today.
RAID level 1 is also known as disk mirroring or duplexing .
RAID level 5 involves data and parity striping by sectors, across a set of disks. Parity is interleaved with the data, rather than being stored on a dedicated drive. With this technology, data protection is also good: If any disk fails, the data can still be accessed by using the parity information from the other disks. Read performance is good, but write performance can be adversely affected. A RAID level 5 configuration requires a minimum of three identical disks. The amount of disk space required for overhead varies with the number of disks in the array. In the case of a RAID level 5 configuration with 5 disks, the space overhead is 20% (i.e., five disks plus a parity disk).
When using a RAID (but not a RAID level 0) disk array, a disk failure will not prevent you from accessing data on the array. When hot-pluggable or hot-swappable disks are used in the array, a replacement disk can be swapped with the failed disk while the array is in use. With RAID level 5, if two disks fail at the same time, all data is lost (but the probability of simultaneous disk failures is very small).
You might consider using a RAID level 1 hardware disk array or a software disk array for your logs, because this provides recoverability to the point of failure and offers good write performance, which is important for logs. In cases where reliability is critical (because time cannot be lost recovering data following a disk failure) and write performance is not so critical, consider using a RAID level 5 hardware disk array. Alternatively, if write performance is critical and the cost of additional disk space is not significant, consider a RAID level 1 hardware disk array for your data, as well as for your logs.
You should consider using MIRRORLOGPATH to specify a secondary log path for the database to manage copies of the active log. It is recommended that you place the secondary log path on a separate physical disk (preferably one that is also on a different disk controller). That way, the disk controller cannot be a single point of failure.
A software disk array accomplishes much the same as does a hardware disk array, but disk traffic is managed either by the operating system or by an application program running on the server. Like other programs, the software array must compete for CPU and system resources. This is not a good option for a CPU-constrained system, and it should be remembered that overall disk array performance is dependent on the server's CPU load and capacity.
A typical software disk array provides disk mirroring. Although redundant disks are required, a software disk array is comparatively inexpensive to implement, because costly disk controllers are not required.
Having the operating system boot drive in the disk array prevents your system from starting if that drive fails. If the drive fails before the disk array is running, the disk array cannot allow access to the drive. A boot drive should be separate from the disk array.
Reducing the Potential of Transaction Failure
To reduce the potential of a transaction failure, try to ensure:
Recovering from Transaction Failures in a Partitioned Database Environment
If a transaction failure occurs in a partitioned database environment, database recovery is usually necessary on both the failed database partition and any other database partitions that were participating in the transaction:
In a partitioned database environment, the database partition on which an application is submitted is the coordinator partition, and the first agent that works for the application is the coordinator agent. The coordinator agent is responsible for distributing work to other database partitions, and it keeps track of which ones are involved in the transaction. When the application issues a COMMIT statement for a transaction, the coordinator agent commits the transaction by using a two-phase commit protocol.
During the first phase, the coordinator partition distributes a PREPARE request to all the other database partitions that are participating in the transaction. These database partitions then respond with one of the following:
If one of the database partitions responds with a NO, the transaction is rolled back. Otherwise, the coordinator partition begins the second phase.
During the second phase, the coordinator partition writes a COMMIT log record, then distributes a COMMIT request to all the database partitions that responded with a YES. After all the other database partitions have committed, they send an acknowledgement of the COMMIT to the coordinator partition. The transaction is complete when the coordinator agent has received all COMMIT acknowledgements from all the participating partitions. At this point, the coordinator agent writes a FORGET log record.
Transaction Failure Recovery on an Active Database Partition
If any database partition detects that another database partition is down, all work that is associated with the failed database partition is stopped :
The transaction will be indoubt only on database partitions that are still active if the coordinator partition returns an SQL0279N.
Any process (such as an agent or deadlock detector) that attempts to send a request to the failed partition is informed that it cannot send the request.
Transaction Failure Recovery on the Failed Database Partition
If the transaction failure causes the database manager to end abnormally, you can issue the db2start command with the RESTART option to restart the database manager, once the database partition has been restarted. If you cannot restart the database partition, you can issue db2start to restart the database manager on a different partition.
If the database manager ends abnormally, database partitions may be left in an inconsistent state. To make them usable, crash recovery can be triggered on a database partition:
Crash recovery reapplies the log records in the active log files to ensure that the effects of all complete transactions are in the database. After the changes have been reapplied, all uncommitted transactions are rolled back locally, except for indoubt transactions. There are two types of indoubt transaction in a partitioned database environment:
Crash recovery attempts to resolve all the indoubt transactions by doing one of the following. The action that is taken depends on whether the database partition was the coordinator partition for an application:
It is possible that crash recovery may not be able to resolve all the indoubt transactions (for example, some of the database partitions may not be available). In this situation, the SQL warning message SQL1061W is returned. Because indoubt transactions hold resources, such as locks and active log space, it is possible to get to a point where no changes can be made to the database because the active log space is being held up by indoubt transactions. For this reason, you should determine whether indoubt transactions remain after crash recovery and recover all database partitions that are required to resolve the indoubt transactions as quickly as possible.
If one or more partitions that are required to resolve an indoubt transaction cannot be recovered in time, and access is required to database partitions, you can manually resolve the indoubt transaction by making a heuristic decision. You can use the LIST INDOUBT TRANSACTIONS command to query, commit, and roll back the indoubt transaction on the database partition.
Identifying the Failed Database Partition
When a database partition fails, the application will typically receive one of the following SQLCODEs. The method for detecting which database manager failed depends on the SQLCODE received:
Determining which database partition failed is a two-step process. The SQLCA associated with SQLCODE SQL1229N contains the database partition number of the server that detected the error in the sixth array position of the sqlerrd field.
If multiple logical database partitions are being used on a single server, the failure of one logical database partition may cause other logical database partitions on the same single server to fail.
Recovering from the Failure of a Database Partition
To recover from the failure of a database partition:
The term disaster recovery is used to describe the activities that need to be done to restore the database (in a remote location) in the event of a fire, earthquake, vandalism, or other catastrophic events. A plan for disaster recovery can include one or more of the following:
If your plan for disaster recovery is to recover the entire database on another machine, you require at least one full database backup and all the archived logs for the database. You may choose to keep a standby database up to date by applying the logs to it as they are archived. Or you may choose to keep the database backup and log archives in the standby site and to perform the restore and rollforward operations only after a disaster has occurred. With a disaster, however, it is generally not possible to recover all of the transactions up to the time of the disaster, i.e., some of the active log files may be lost.
The usefulness of a table space backup for disaster recovery depends on the scope of the failure. Typically, disaster recovery requires that you restore the entire database; therefore, a full database backup should be kept at a standby site. Even if you have a separate backup image of every table space, you cannot use them to recover the database.
Both table space backups and full database backups can have a role to play in any disaster recovery plan. The DB2 facilities available for backing up, restoring, and rolling data forward provide a foundation for a disaster recovery plan. You should ensure that you have tested recovery procedures in place to protect your business.
Version recovery is the restoration of a previous version of the database, using an image that was created during an offline database backup operation. You use this recovery method with non-recoverable databases (that is, databases for which you do not have archived logs). You can also use this method with recoverable databases by using the WITHOUT ROLLING FORWARD option on the RESTORE DATABASE command.
A database restore operation will rebuild the entire database, using a backup image created earlier. A database backup allows you to restore a database to a state identical to the state at the time that the backup was made. However, every unit of work from the time of the backup to the time of the failure is lost.
Using the version recovery method, you must schedule and perform full offline backups of the database on a regular basis.
In a partitioned database environment, the database is located across many database partitions. You must restore all partitions, and the backup images that you use for the restore database operation must all have been taken at the same time. Each database partition is backed up and restored separately. A backup of each database partition taken at the same time is known as a version backup .
You need to restore the catalog partition first, then the remaining database partitions.
To use the rollforward recovery method, you must have taken a backup of the database and archived the logs (by setting to YES either the LOGRETAIN or the USEREXIT database configuration parameters, or both). Restoring the database and specifying the WITHOUT ROLLING FORWARD option is equivalent to using the version recovery method. The database is restored to a state identical to the one at the time that the offline backup image was made. If you restore the database and do not specify the WITHOUT ROLLING FORWARD option for the restore database operation, the database will be in rollforward pending state at the end of the restore operation. This allows rollforward recovery to take place.
The WITHOUT ROLLING FORWARD option cannot be used if the database backup was taken online.
The two types of rollforward recovery to consider are:
You can roll forward through the logs to one of two points:
Table space rollforward recovery can be used in the following two situations:
If the table space in error contains the system catalog tables, you will not be able to start the database. You must restore the SYSCATSPACE table space, then perform rollforward recovery to the end of the logs.
In a partitioned database environment:
Incremental Backup and Recovery
As the size of databases, and particularly data warehouses, continues to expand into the tens and hundreds of terabytes time and hardware resources required to back up and recover these databases are also growing substantially.
Full database and table space backups are not always the best approach when dealing with large databases, because the storage requirements for multiple copies of such databases are enormous . When only a small percentage of the data in a warehouse changes, it should not be necessary to back up the entire database or table space.
An incremental backup is a backup image that contains only pages that have been updated since the previous backup was taken. In addition to updated data and index pages, each incremental backup image also contains all of the initial database metadata (such as database configuration, table space definitions, database history, and so on) that is normally stored in full backup images.
Two types of incremental backup are supported:
The key difference between incremental and delta backup images is their behavior when successive backups are taken of an object that is continually changing over time. Each successive incremental image contains the entire contents of the previous incremental image, plus any data that has changed or is new since the previous full backup was produced. Delta backup images contain only the pages that have changed since the previous image of any type was produced.
Combinations of database and table space incremental backups are permitted in both online and offline modes of operation. Be careful when planning your backup strategy, because combining database and table space incremental backups implies that the predecessor of a database backup (or a table space backup of multiple table spaces) is not necessarily a single image but could be a unique set of previous database and table space backups taken at different times.
To rebuild the database or the table space to a consistent state, the recovery process must begin with a consistent image of the entire object (database or table space) to be restored and must then apply each of the appropriate incremental backup images in the order described below.
To enable the tracking of database updates, DB2 supports a database configuration parameter, TRACKMOD, which can have one of two accepted values:
The tracking of updates to the database can have an impact on the runtime performance of transactions that update or insert data.
For SMS and DMS table spaces, the granularity of this tracking is at the table space level. In table space level tracking, a flag for each table space indicates whether there are pages in that table space that need to be backed up.
If no pages in a table space need to be backed up, the backup operation can skip that table space altogether.
Restoring from Incremental Backup Images
A restore operation from incremental backup images always consists of the following steps:
There are two ways to restore incremental backup images.
Manual Incremental Restore Example
To restore a set of incremental backup images, using manual incremental restore, specify the target image using the TAKEN AT timestamp option of the RESTORE DATABASE command and follow the steps outlined above.
db2 restore db sample incremental taken at 20020829102021
If you are using manual incremental restore for a database restore operation, and table space backup images have been produced, the table space images must be restored in the chronological order of their backup timestamps.
If you want to use manual incremental restore, the db2ckrst utility can be used to query the database history and generate a list of backup image timestamps needed for an incremental restore. A simplified restore syntax for a manual incremental restore is also generated. It is recommended that you keep a complete record of backups and use this utility only as a guide.
Automatic Incremental Restore Example
To restore a set of incremental backup images using automatic incremental restore, specify the TAKEN AT timestamp option on the RESTORE DATABASE command. Use the timestamp for the last image that you want to restore.
db2 restore db sample incremental automatic taken at 20020829102037
It is highly recommended that you not use the FORCE option of the PRUNE HISTORY command. The default operation of the PRUNE HISTORY command prevents you from deleting history entries that may be required for recovery from the most recent, full database backup image; but with the FORCE option, it is possible to delete entries that are required for an automatic restore operation.
Limitations to Automatic Incremental Restore
Scenario #1: Automatic incremental restore is unable to proceed
When a table space name has been changed since the backup operation you want to restore from the backup images, and you use the new name when you issue a table space level restore operation, the required chain of backup images from the database history will not be generated correctly with automatic incremental restore, and an error will occur (SQL2571N).
Example restore procedure:
The following is sample output from automatic incremental restore:
[View full width]
Scenario #2: Automatic incremental restore is out of sequence
When you drop a database, the database history will be deleted. If you restore the dropped database, the database history will be restored to its state at the time of the restored backup, and all history entries after that time will be lost. If you then attempt to perform an automatic incremental restore that would need to use any of these lost history entries, the RESTORE utility will attempt to restore an incorrect chain of backups and will return an "out of sequence" error (SQL2572N).
Example Restore Procedure:
The following is sample output from automatic incremental restore:
[View full width]
Scenario #3: Automatic incremental restore is different from the backup image database
When you restore a backup image from one database into another database, then do an incremental (delta) backup, you can no longer use automatic incremental restore to restore this backup image, and an error will occur (SQL2542N).
Example Restore Procedure: