Table of contents
Backing up ZFS attributes
When Solaris is the file system type selected in the Backup What page, the Advanced Options displayed after clicking the link include an Extended Attributes checkbox, which selects the archive program used for backing up the Solaris file system. If you are using ZFS filesystem, you most likely need to backup ZFS ACLs. Enable extended attributes option in this case. If you do not need to back up ZFS Access Control Lists (ACLs), this option should be disabled.
When the option is disabled (the default), Amanda Enterprise uses (and requires) amgtar as the archive program (and the procedures in this appendix aren't required).
When the option is enabled amsuntar(8) is used for backup. The amsuntar application is designed to protect ZFS ACLs, as ZFS ACLs can only be backed up using the bundled Solaris native tar utility(/usr/sbin/tar). To ensure successful backup and and restore of ZFS ACLs, follow the instructions below. Once the requirements for backup have been met, you can use the ZMC to back up the ZFS with no further steps. Restores through the ZMC will require you to extract an uncompressed tarball after the ZMC restore is complete as described here.
Requirements for amsuntar Backup
If amsuntar is used, check the following:
Configuring the amandabackup user with the "Media backup" profile
The amandabackup user should be set with the Media backup profile. The profile is set correctly if the amandabackup user is created by the installation program; if the user exists prior to installation its profile should be manually set with the following command:
usermod -P "Media Backup" amandabackup
Setting the Block Size, Extended Attribute, and Extended Header options
Set amsuntar properties as required by your site (the default values should work in most cases). The amsuntar application supports the following properties, enabling ACLs (suntar option p) by default. To set properties (which is only required in rare circumstances), edit the the /etc/zmanda/zmc_aae/zmc_user_dumptypes file to define the application tool app_amsuntar_user with the following lines:
define application-tool "app_amsuntar_user" { property "BLOCK-SIZE" "block_size_integer"
property "EXTENDED-ATTRIBUTES" "[YES | NO]"
property "EXTENDED-HEADERS" "[YES | NO]" }
For example:
define application-tool "app_amsuntar_user" { property "BLOCK-SIZE" "64"
property "EXTENDED-ATTRIBUTES" "YES"
property "EXTENDED-HEADERS" "YES" }
These settings are global to all backup sets processed by the server. When "EXTENDED-HEADERS" is set to "YES", amsuntar uses the -E option of suntar, which will allow archiving of files larger then 8GB in size,
filenames that exceed PATH_MAX, and also process timestamps with microsecond granularity.
When "EXTENDED-ATTRIBUTES" is set to "YES", amsuntar uses the @ option to archive extended attributes such as atime, ctime, mtime, uname, uid, gname, gid, etc. This information is archived in a special file included with the archive that can be used during recovery to restore the extended attributes.
Configuring File Exclusions
amsuntar supports suntar include/exclude files that list relative pathnames of files or directories to be included/excluded from the archive. Refer to the suntar man page for details on the syntax of include/exclude file, which can be specified in the zmc_suntar_userapp section of the /etc/zmanda/zmc_aee/zmc_user_dumptypes.
For example, to exclude /etc/sysevent/sysevent_door (a Solaris special file that can't be backed up), you might create a file called /tmp/exclude.list that contains one line:
/etc/sysevent/sysevent_door
You would then edit /etc/zmanda/zmc_aee/zmc_user_dumptypes so that the zmc_suntar_userapp section to look like:
define dumptype zmc_suntar_userapp {exclude list "/tmp/exclude.list"}
Restoring ZFS files backed up with amsuntar
amsuntar supports only level 0 (in other words, full) backups, as there is no support for incrementals in the native archive tool. Also the native tools only restore in raw mode. The result after restoring through the ZMC is an uncompressed raw tar ball in the specified destination location. To complete the restore, you must manually run the Solaris tar utility to retrieve the desired files and directories. Open a terminal and change directories to where the tarball is located and enter a command similar to:
tar xvf ./mytarballfile
This will extract all the files contained in mytarballfile. If ZFS ACLs are part of the tarball, Solaris tar will restore them by default.
Important Note: Special files such as device files, named pipes, sockets, etc. can cause errors from the native backup and restore tools. They should be excluded from the backup using Exclude specifications.
Backup using ZFS snapshots
Amanda can backup ZFS file systems by taking ZFS snapshots and backing data from the ZFS snapshots. After the backup operation is complete, the ZFS snapshot is deleted. Using ZFS snapshots provides two advantages:
-
All files that are open or locked get backed up. For example: You can create crash consistent backups of Virtual machine images stored on ZFS, while corresponding VMs are running. No process other than Amanda backup process will be accessing the ZFS snapshot created for backup.
-
Backup is consistent to a point in time. Usually backup process captures files over the backup window and will not consistent to a point in time. ZFS snapshot allows backup to be consistent to time when the snapshot is taken.
Backup configuration
Configuration for using ZFS snapshots for backup should be done in the ZMC Backup What page.
- Select Backup Type as Solaris File system.
- Provide Host (ZFS file system should be accessible from Host) and Directory (ZFS file system from output of zfs list command).
- Click on Advanced Options.
- Set Custom Application field value to zfssnapshot.
- Click Save to save the configuration.
- Verify the configuration before starting a backup run.