Adding HTTP Access to a Share (BUI)
Day Details
Every 7th, 14th, 21st of month Level-1 backup. Backup contains all files changed since
the last full (monthly) backup
Every day Level-2 backup. Backup contains all files changed since
the last level-1 backup
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” on page 274).
272 Oracle ZFS Storage Appliance Administration Guide, Release OS8.6.x • September 2016
To Next Page
Loading...
Need help?
General
