Scheduling Snapshots (BUI)
Use the following procedure to configure automatic snapshots of a filesystem, LUN, or project and set a retention policy for those snapshots.
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, unless the snapshots are under a retention hold. Automatic snapshots with clones are ignored.
Automatic snapshots can be taken half-hourly, hourly, daily, weekly, or monthly and are named .auto[-<snaplabel>]-<timestamp>
. In the Creation column of the Snapshots list, times are displayed in the local (client browser) time zone. However, times are stored and executed in UTC format, 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, and this is the time that will appear as the timestamp in the snapshot name.
Older versions of the software allowed for automatic snapshots at the frequency of a minute. To help users avoid placing undue stress on the system, this feature was removed with the 2010.Q3 release. If the software is rolled back, existing minutes will be preserved. 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.
Automatic snapshots can be kept forever (except for half-hourly and hourly snapshots, which are capped at 48 and 24, respectively), or they can be limited to a certain number. When the number of snapshots exceeds the number for the Keep at most property, the oldest snapshots are deleted first. This is known as the "keep-at-most" scheme.
A retention hold can be placed on automatic snapshots to prevent deletion by locking them, which is especially beneficial for meeting internal retention and regulatory compliance needs. Because a retention policy is set at the parent level, the project and its shares are equally protected from deletion. However, filesystems, LUNs, and other snapshots within the share can be modified or deleted. Snapshot retention holds are preserved when moving the snapshot to another system via remote replication, NDMP (zfs format), or cloud snapshot backup (zfs format). However, retention holds cannot be added to original remote replication snapshots nor original NDMP snapshots.
When the threshold is met for the Retention property, the retention hold is set to off
for excessive snapshots, and they are automatically deleted using the keep-at-most scheme. Also, a retention hold cannot be modified nor removed. Therefore, a snapshot schedule with a retention hold cannot be deleted until it is the oldest snapshot in the keep-at-most scheme. For a snapshot within a share, its share and project also cannot be deleted early.
To use the snapshot retention hold feature, apply deferred update "Support for Snapshot Retention." For information about deferred updates, see Deferred Updates in Oracle ZFS Storage Appliance Customer Service Manual, Release OS8.8.x.
The following user role authorizations are required to configure an automatic snapshot:
-
Schedule an automatic snapshot:
scheduleSnap
-
Set a retention hold:
scheduleLockedSnap
For information on editing authorizations for a role, see Editing Authorizations for a Role (BUI). For information on editing the retention hold value, see Editing a Snapshot Retention Policy (BUI).