Snapshots

Introduction

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.

Snapshot Properties

.zfs/snapshot visible

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.

BUI Value	CLI Value	Description
Hidden	hidden	The .zfs directory is not visible when listing directory contents in the root of the filesystem. This is default.
Visible	visible	This .zfs directory appears like any other directory in the filesystem.

Scheduled Snapshot Label

This optional property appends a user-defined label to each scheduled snapshot and is blank by default. The label can either be set for an individual share, or set for a project and inherited by its shares, but not both. Snapshot labels can help identify the project or share for which a snapshot was taken, for example "project1:share1" could indicate a scheduled snapshot taken on share1 within project1. Labels can be up to 35 alphanumeric characters and include special characters _ - . :

BUI

Listing Snapshots (BUI)

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:

Field	Description
Name	The name of the snapshot. There are two types of snapshots: manual and automatic.
	`Manual Snapshots:` "Name" is the name provided when the snapshot was created. Manual snapshots can be renamed by clicking on the name and entering a new value.
	`Automatic Snapshots:` There are three types, and they cannot be renamed:
	- `.auto:` User-configured scheduled snapshots with custom retention policies (see Scheduled Snapshots).
	- `.ndmp:` Used for NDMP backup and automatically pruned.
	- `.rr:` Used for remote replication and automatically pruned.
Creation	The date and time when the snapshot was created.
Unique	The amount of unique space used by the snapshot. Snapshots begin initially referencing all the same blocks as the filesystem or LUN itself. As the active filesystem diverges, blocks that have been changed in the active share may remain held by one or more snapshots. When a block is part of multiple snapshots, it will be accounted in the share snapshot usage, but will not appear in the unique space of any particular snapshot. The unique space is blocks that are only held by a particular snapshot, and represents the amount of space that would be freed if the snapshot were to be destroyed.
Total	The total amount of space referenced by the snapshot. This represents the size of the filesystem at the time the snapshot was taken, and any snapshot can theoretically take up an amount of space equal to the total size as data blocks are rewritten.
Clones	Show the number of clones of the snapshot. When the mouse is over a snapshot row with a non-zero number of clones, a "Show..." link will appear. Clicking this link will bring up a dialog box that displays the complete list of all clones.

Tasks

Taking Manual Snapshots (BUI)

There are two types of snapshots; project level and share/LUN level snapshots.

Create a project level snapshot

Open the project that you want to snapshot.
Click the Snapshots tab.
Click the icon. The snapshots list appears.
In the dialog box, type a name for the snapsnot.
To create the snapshot, click "apply".

Create a share/LUN level snapshot

Open the share/LUN that you want to snapshot.
Click the Snapshots tab.
Click the icon. The snapshots list appears.
In the dialog box, type a name for the snapsnot.
To create the snapshot, click "apply".

There is no limit on the number of snapshots that can be taken, but each snapshot consumes memory, so creating large numbers of snapshots can slow the system. The practical limit on the number of snapshots system-wide depends on the system configuration, but should be over a hundred thousand.

Renaming a Snapshot (BUI)

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.

Destroying a Snapshot (BUI)

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.

Rolling back to a Snapshot (BUI)

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.

Cloning a Snapshot (BUI)

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.

Property	Description
Project	Destination project. By default, clones are created within the current project, but they can also be created in different projects (or later moved between projects).
Name	The name to give to the clone.
Preserve Local Properties	By default, the all currently inherited properties of the filesystem will inherit from the destination project in the clone. Local settings are always preserved. Setting this property will cause any inherited properties to be preserved as local setting in the new clone.
Mountpoint	When preserving local properties, the clone must be given a different mountpoint, as shares cannot save the same mountpoint. This option is only available when "Preserve local properties" is set.

Scheduled Snapshots (BUI)

In addition to manual snapshots, you can configure automatic snapshots according to the table below. These snapshots are named ".auto-<timestamp>", and can be taken on half hourly, 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.

Property	Description
Frequency	One of "half hour", "hour", "day", "week", or "month". This indicates how often the snapshot is taken.
Offset	This specifies an offset within the frequency. For example, when selecting an hour frequency, snapshots can be taken at an explicit minute offset from the hour. For daily snapshots, the offset can specify hour and minute, and for weekly or monthly snapshots the offset can specify day, hour, and minute.
Keep at most	Controls the retention policy for snapshots. Automatic snapshots can be kept forever (except for half hour and hour snapshots, which are capped at 48 and 24, respectively) or can be limited to a certain number. This limit will delete automatic snapshots for the given interval if they are older than the retention policy. This is actually enforced by the time they were taken, not an absolute count. So if you have hour snapshots and the appliance is down for a day, when you come back up all your hour snapshots will be deleted. Snapshots that are part of multiple intervals are only destroyed when no interval specifies that they should be retained.

Times are displayed in the local (client browser) time zone. However, times are stored and executed in UTC format and without regard to such conventions as daylight saving time. For example, a snapshot scheduled for 10:00 a.m. PST (UTC-8) is stored and executed at 18:00 UTC.

Automatic snapshots can 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.

CLI

To access the snapshots for a share, navigate to the share and the snapshots context.

clownfish:> shares select default select builds
clownfish:shares default/builds> snapshots
clownfish:shares default/builds snapshots>

Listing Snapshots (CLI)

Snapshots can be listed using the standard CLI commands.

clownfish:shares default/builds snapshots> list
today
yesterday
clownfish:shares default/builds snapshots>

Taking Manual Snapshots (CLI)

To take a manual project-level snapshot, navigate to the project and snapshot node and then use the snapshot command:

clownfish:cd /
clownfish:shares select myproject snapshots
clownfish:shares myproject snapshots> snapshot cob_monday

To take a manual share-level snapshot of an individual share, navigate to that share and use the snapshot command there:

clownfish:cd /
clownfish:shares select myproject select share1 snapshots
clownfish:snapshot lunchtime

Renaming a Snapshot (CLI)

To rename a snapshot, use the rename command:

clownfish:shares default/builds snapshots> rename test test2
clownfish:shares default/builds snapshots>

Destroying a Snapshot (CLI)

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>

Rolling back to a Snapshot (CLI)

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>

Cloning a Snapshot (CLI)

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 = discard (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.

Scheduled Snapshots (CLI)

Automatic scheduled snapshots can be configured using the automatic command from the snapshot context, at the project level of that of an individual share. 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. Schedules are maintained in UTC format.

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>

Setting the Scheduled Snapshot Label (CLI)

In the BUI, the "scheduled snapshot label" property can be set for either a project or a share. Likewise, in the CLI, the label can be set by first navigating to either the project or share context. To create a scheduled snapshot label, use the set snaplabel command:

clownfish:shares project1/share1> set snaplabel=project1:share1

Skip Navigation Links
Exit Print View
	Oracle ZFS Storage Appliance Administration Guide