NDMP Incremental Backups
Oracle ZFS Storage Appliance supports level-based incremental backups for all of the above backup types. To specify a level backup, DMAs typically specify the following three environment variables:
| Variable | Details |
|---|---|
|
|
Integer from 0 to 9 identifying the backup level. |
|
|
Specifies a particular incremental backup set. Multiple sets of level incremental backups can be used concurrently by specifying different values for |
|
|
Indicates whether this backup can be used as the base for subsequent incremental backups |
By definition, a level-N backup includes all files changed since the previous backup of the same backup set (specified by DMP_NAME) of the same share using LEVEL less than N. Level-0 backups always include all files. If UPDATE has value y (the default), then the current backup is recorded so that future backups of level greater than N will use this backup as a base. These variables are typically managed by the DMA, and do not need to be configured directly by administrators. The following table describes a sample incremental backup schedule:
Table 3-26 Sample Incremental Backup Schedule
| Day | Details |
|---|---|
|
First of month |
|
|
Every 7th, 14th, 21st of month |
|
|
Every day |
|
To recover the filesystem's state as it was on the 24th of the month, an administrator typically restores the Level-0 backup from the 1st of the month to a new share, then restores the Level-1 backup from the 21st of the month, and then restores the Level-2 backup from the 24th of the month.
To implement level-based incremental backups the appliance must keep track of the level backup history for each share. For "tar" and "dump" backups, the level backup history is maintained in the share metadata. Incremental backups traverse the filesystem and include files modified since the time of the previous level backup. At restore time, the system simply restores all the files in the backup stream. In the above example, it would therefore be possible to restore the Level-2 backup from the 24th onto any filesystem and the files contained in that backup stream will be restored even though the target filesystem may not match the filesystem where the files were backed up. However, best practice suggests using a procedure like the above which starts from an empty tree restores the previous level backups in order to recover the original filesystem state.
To implement efficient level-based incremental backups for type "zfs", the system uses a different approach. Backups that are part of an incremental set do not destroy the snapshot used for the backup but rather leave it on the system. Subsequent incremental backups use this snapshot as a base to quickly identify the changed filesystem blocks and generate the backup stream. As a consequence, the snapshots left by the NDMP service after a backup must not be destroyed if you want to create subsequent incremental backups.
Another important consequence of this behavior is that in order to restore an incremental stream, the filesystem state must exactly match its state at the base snapshot of the incremental stream. In other words, in order to restore a Level-2 backup, the filesystem must look exactly as it did when the previous Level-1 backup completed. Note that the above commonly used procedure guarantees this because when restoring the Level-2 backup stream from the 24th, the system is exactly as it was when the Level-1 backup from the 21st completed because that backup has just been restored.
The NDMP service will report an error if you attempt to restore an incremental "zfs" backup stream to a filesystem whose most recent snapshot doesn't match the base snapshot for the incremental stream, or if the filesystem has been changed since that snapshot. You can configure the NDMP service to rollback to the base snapshot just before the restore begins by specifying the NDMP environment variable ZFS_FORCE with value y or by configuring the Rollback datasets property of the NDMP service (see NDMP Properties and Logs).