Table of Contents
Advertisement
Adding HTTP Access to a Share (BUI)
Only paths that are mountpoints of existing shares, or contained within existing shares, may be
specified for backup. If the backup path matches a share's mountpoint, only that share is backed
up. Otherwise the path must be contained within a share, in which case only the portion of that
share under that path is backed up. In both cases, other shares mounted inside the specified
share under the backup path will not be backed up; these shares must be specified separately for
backup.
Snapshots - If the backup path specifies a live filesystem (e.g., /export/code) or a path
contained within a live filesystem (e.g., /export/code/src), the appliance immediately takes a
new snapshot and backs up the given path from that snapshot. When the backup completes, the
snapshot is destroyed. If the backup path specifies a snapshot (e.g., /export/code/.zfs/snapshot/
mysnap), no new snapshot is created and the system backs up from the specified snapshot.
Share metadata - To simplify backup and restore of complex share configurations, "dump" and
"tar" backups include share metadata for projects and shares associated with the backup path.
This metadata describes the share configuration on the appliance, including protocol sharing
properties, quota properties, and other properties configured on the Shares screen. This is not to
be confused with filesystem metadata like directory structure and file permissions, which is also
backed up and restored with NDMP.
For example, if you back up /export/proj, the share metadata for all shares whose
mountpoints start with /export/proj will be backed up, as well as the share metadata for their
parent projects. Similarly, if you back up /export/someshare/somedir, and a share is mounted
at /export/someshare, that share and its project's share metadata will be backed up.
When restoring, if the destination of the restore path is not contained inside an existing
share, projects and shares in the backup stream will be recreated as needed with their original
properties as stored in the backup. For example, if you back up /export/foo, which contains
project proj1 and shares share1 and share2, and then destroy the project and restore from the
backup, then these two shares and the project will be recreated with their backed-up properties
as part of the restore operation.
During a restore, if a project exists that would have been automatically recreated, the existing
project is used and no new project is automatically created. If a share exists that would have
been automatically recreated, and if its mountpoint matches what the appliance expects based
on the original backup path and the destination of the restore, then the existing share is used and
no new share is automatically created. Otherwise, a new share is automatically created from
the metadata in the backup. If a share with the same name already exists (but has a different
mountpoint), then the newly created share will be given a unique name starting with ndmp- and
with the correct mountpoint.
It is recommended that you either restore a stream whose datasets no longer exist on the
appliance, allowing the appliance to recreate datasets as specified in the backup stream, or
precreate a destination share for restores. Either of these practices avoids surprising results
related to the automatic share creation described earlier.
Appliance Services
269
Advertisement
Table of Contents
