Migration via external interposition
Shadow filesystem semantics during migration
Snapshots of shadow filesystems
Replicating shadow filesystems
Migration of local filesystems
Testing potential shadow migration
Migrating data from an active NFS server
Filesystem and project settings
Protocol access to mountpoints
Non-blocking mandatory locking
Remote Replication Introduction
Project-level vs Share-level Replication
Modes: Manual, Scheduled, or Continuous
Including Intermediate Snapshots
Sending and Cancelling Updates
Cancelling Replication Updates
Cloning a Package or Individual Shares
Exporting Replicated Filesystems
Reversing the Direction of Replication
Destroying a Replication Package
Snapshots and Data Consistency
Replicating iSCSI Configuration
Upgrading From 2009.Q3 and Earlier
Snapshots are read only copies of a filesystem at a given point of time. For more information on snapshots and how they work, see the concepts page.
Filesystem snapshots can be accessed over data protocols at .zfs/snapshot in the root of the filesystem. This directory contains
a list of all snapshots on the filesystem, and they can be accessed just like normal filesystem data (in read only mode). By default, the '.zfs' directory is not visible when listing directory contents, but can be accessed by explicitly looking it up. This prevents backup software from inadvertently backing up snapshots in addition to new data.
|
Under the "snapshots" tab is the list of active snapshots of the share. This list is divided into two tabs: the "Snapshots" tab is used for browsing and managing snapshots. The "Schedules" tab manages automatic snapshot schedules. Within the "Snapshots" tab, you can select between viewing all snapshots, only manual snapshots, or only scheduled snapshots. For each snapshot, the following fields are shown:
|
To create a manual snapshot, click the icon when the "Snapshots" tab is selected and the list of snapshots is shown. A dialog box will prompt for the snapshot name. Hitting the "apply" button will create the snapshot. There is no limit on the number of snapshots that can be taken, but each snapshot will consume some amount of resources (namely memory), so creating large numbers of snapshots can slow down the system, eventually grinding to a halt. The practical limit on the number of snapshots system-wide depends on the system configuration, but should be on the order of a hundred thousand or more.
To rename a snapshot, click the name within the list of active snapshots. This will change to a text input box. After updating the name within the text input, hitting return or changing focus will commit the changes.
To destroy a snapshot, click the icon when over the row for the target snapshot. Destroying a snapshot will require destroying any clones and their descendents. If this is the case, you will be prompted with a list of the clones that will be affected.
In addition to accessing the data in a filesystem snapshot directory, snapshots can also be used to roll back to a previous instance of the filesystem or LUN. This requires destroying any newer snapshots and their clones, and reverts the share contents to what they were at the time the snapshot was taken. It does not affect any property settings on the share, though changes to filesystem root directory access will be lost, as that is part of the filesystem data.
To rollback a filesystem, click the icon for the destination snapshot. A confirmation dialog will appear, and if there are any clones of the snapshot, any newer snapshots, or their descendents, they will be displayed, indicating that they will be destroyed as part of this process.
A clone is a writable copy of a snapshot, and is managed like any other share. Like snapshots of filesystems, it initially consumes no additional space. As the data in the clone changes, it will consume more space. The original snapshot cannot be destroyed without also destroying the clone. Scheduled snapshots can be safely cloned, and scheduled snapshots with clones will be ignored if they otherwise should be destroyed.
To create a clone, click the icon for the source snapshot. A dialog will prompt for the following values.
|
In addition to manual snapshots, you can configure automatic snapshots according to an arbitrary schedule. These snapshots are named '.auto-<timestamp>', and can be taken on half hour, hourly, daily, weekly, or
monthly schedules. A schedule is a list of intervals and retention policies. To add a new interval, click the icon when viewing the "Schedules" tab. Each interval has the following properties.
|
Automatic snapshots can only be set on a project or a share, but not both. Otherwise, overlapping schedules and retention policies would make it impossible to guarantee both schedules. Removing an interval, or changing its retention policy, will immediately destroy any automatic snapshots not covered by the new schedule. Automatic snapshots with clones are ignored.
Previous versions of the software allowed for automatic snapshots at the frequency of a minute. This proved to put undue strain on the system and was not generally useful. To help users avoid placing undue stress on the system, this feature was removed with the 2010.Q3 release. Snapshots can now only be specified at a period of once every half hour or longer. Existing minute periods will be preserved should the software be rolled back, and previous instances will expire according to the existing schedule, but no new snapshots will be taken. An alert will be posted if a share or project with this frequency is found.
To access the snapshots for a share, navigate to the share and run the snapshots command.
clownfish:> shares select default select builds clownfish:shares default/builds> snapshots clownfish:shares default/builds snapshots>
Snapshots can be listed using the standard CLI commands.
clownfish:shares default/builds snapshots>' list today yesterday clownfish:shares default/builds snapshots>
To take a manual snapshot, use the snapshot command:
clownfish:shares default/builds snapshots> snapshot test clownfish:shares default/builds snapshots>
To rename a snapshot, use the rename command:
clownfish:shares default/builds snapshots> rename test test2 clownfish:shares default/builds snapshots>
To destroy a snapshot, use the destroy command:
clownfish:shares default/builds snapshots> select test2 clownfish:shares default/builds@test2> destroy This will destroy this snapshot. Are you sure? (Y/N) clownfish:shares default/builds snapshots>
You can also use the destroy command from the share context without selecting an individual snapshot:
clownfish:shares default/builds snapshots> destroy test2 This will destroy this snapshot. Are you sure? (Y/N) clownfish:shares default/builds snapshots>
To rollback to a snapshot, select the target snapshot and run the rollback command:
clownfish:shares default/builds snapshots> select today clownfish:shares default/builds@today> rollback Rolling back will revert data to snapshot, destroying newer data. Active initiators will be disconnected. Continue? (Y/N) clownfish:shares default/builds@today>
To clone a snapshot, use the clone command. This command will place you into an uncommitted share context identical to the one used to create shares. From here, you can adjust properties as needed before committing the changes to create the clone.
clownfish:shares default/builds snapshots> select today clownfish:shares default/builds@today> clone testbed clownfish:shares default/testbed (uncommitted clone)> get aclinherit = restricted (inherited) aclmode = groupmask (inherited) atime = true (inherited) checksum = fletcher4 (inherited) compression = off (inherited) copies = 1 (inherited) mountpoint = /export/testbed (inherited) quota = 0 (default) readonly = false (inherited) recordsize = 128K (inherited) reservation = 0 (default) secondarycache = all (inherited) nbmand = false (inherited) sharesmb = off (inherited) sharenfs = on (inherited) snapdir = hidden (inherited) vscan = false (inherited) sharedav = off (inherited) shareftp = off (inherited) root_group = other (default) root_permissions = 777 (default) root_user = nobody (default) quota_snap = true (default) reservation_snap = true (default) clownfish:shares default/testbed (uncommitted clone)> set quota=10G quota = 10G (uncommitted) clownfish:shares default/testbed (uncommitted clone)> commit clownfish:shares default/builds@today>
The command also supports an optional first argument, which is the project in which to create the clone. By default, the clone is created in the same project as the share being cloned.
Automatic scheduled snapshots can be configured using the automatic command from the snapshot context. Once in this context, new intervals can be added and removed with the create and destroy commands. Each interval has a set of properties that map to the BUI view of the frequency, offset, and number of snapshots to keep.
clownfish:shares default/builds snapshots> automatic clownfish:shares default/builds snapshots automatic> create clownfish:shares default/builds snapshots automatic (uncommitted)> set frequency=day frequency = day (uncommitted) clownfish:shares default/builds snapshots automatic (uncommitted)> set hour=14 hour = 14 (uncommitted) clownfish:shares default/builds snapshots automatic (uncommitted)> set minute=30 minute = 30 (uncommitted) clownfish:shares default/builds snapshots automatic (uncommitted)> set keep=7 keep = 7 (uncommitted) clownfish:shares default/builds snapshots automatic (uncommitted)> get frequency = day (uncommitted) day = (unset) hour = 14 (uncommitted) minute = 30 (uncommitted) keep = 7 (uncommitted) clownfish:shares default/builds snapshots automatic (uncommitted)> commit clownfish:shares default/builds snapshots automatic> list NAME FREQUENCY DAY HH:MM KEEP automatic-000 day - 14:30 7 clownfish:shares default/builds snapshots automatic> done clownfish:shares default/builds snapshots>