Chapter 1 Oracle ZFS Storage Appliance Overview
Chapter 3 Initial Configuration
Chapter 4 Network Configuration
Chapter 5 Storage Configuration
Chapter 6 Storage Area Network Configuration
Chapter 8 Setting ZFSSA Preferences
Chapter 10 Cluster Configuration
Configuring Services Using the BUI
Viewing a Specific Service Screen
Viewing a Specific Service Screen
Configuring Services Using the CLI
iSCSI Service Targets and Initiators
SMB Microsoft Stand-alone DFS Namespace Management Tools Support Matrix
Example: Manipulating DFS Namespaces
Adding a User to an SMB Local Group
SMB Users, Groups, and Connections
Active Directory Configuration
Project and Share Configuration
SMB Data Service Configuration
Allowing FTP Access to a share
HTTP Authentication and Access Control
Allowing HTTP access to a share
NDMP Local vs. Remote Configurations
Allowing SFTP access to a share
Configuring SFTP Services for Remote Access
Allowing TFTP access to a share
Configuring virus scanning for a share
Adding an appliance administrator from NIS
Adding an appliance administrator
Active Directory Join Workgroup
Active Directory Domains and Workgroups
Active Directory Windows Server 2012 Support
Active Directory Windows Server 2008 Support
Active Directory Windows Server 2008 Support Section A: Kerberos issue (KB951191)
Active Directory Windows Server 2008 Support Section B: NTLMv2 issue (KB957441)
Active Directory Windows Server 2008 Support Section C: Note on NTLMv2
Configuring Active Directory Using the BUI
Configuring Active Directory Using the CLI
Example - Configuring Active Directory Using the CLI
Identity Mapping Rule-based Mapping
Identity Mapping Directory-based Mapping
Mapping Rule Directional Symbols
Identity Mapping Best Practices
Identity Mapping Case Sensitivity
Identity Mapping Domain-Wide Rules
RIP and RIPng Dynamic Routing Protocols
Registering the Appliance Using the BUI
Registering the Appliance Using the CLI
Configuring SNMP to Serve Appliance Status
Configuring SNMP to Send Traps
Receiver Configuration Examples
Configuring a Solaris Receiver
Chapter 12 Shares, Projects, and Schema
The 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:
|
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 need not be configured directly by administrators.
Below is a sample incremental backup schedule:
|
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 Properties below).