snap create vol_name name
snap delete vol_name name
snap delete -a [ -f ] [ -q ] vol_name
snap rename vol_name from to
snap reserve [ vol_name [ percent ] ]
snap restore [ -f ] [ -t vol | file ] [ -s snapshot_name ] [ -r restore_as_path ] vol_name | restore_from_path
snap sched [ vol_name [ weeks [ days [ hours[@list] ] ] ] ]
A snapshot is a read-only copy of the entire file system, as of the time the snapshot was created. The filer uses a copy-on-write technique to create snapshots very quickly without consuming any disk space. Only as blocks in the active file system are modified and written to new locations on disk does the snapshot begin to consume extra space.
Volume snapshots are exported to all CIFS or NFS clients. They can be accessed from each directory in the file system. From any directory, a user can access the set of snapshots from a hidden sub-directory that appears to a CIFS client as ~snapsht and to an NFS client as .snapshot. These hidden sub-directories are special in that they can be accessed from every directory, but they only show up in directory listings at an NFS mount point or at the root of CIFS share.
Each volume on the filer can have up to 255 snapshots at one time. Because of the copy-on-write technique used to update disk blocks, deleting a snapshot will generally not free as much space as its size would seem to indicate. Blocks in the snapshot may be shared with other snapshots, or with the active file system, and thus may be unavailable for reuse even after the snapshot is deleted.
The snap commands are persistent across reboots. Do not include snap commands in the /etc/rc. If you include a snap command in the /etc/rc file, the same snap command you enter through the command line interface does not persist across a reboot and is overridden by the one in the /etc/rc file.
Automatic snapshots
Automatic snapshots can be scheduled to occur weekly,
daily, or hourly. Weekly snapshots are named weekly.N,
where N is "0" for the most recent snapshot, "1" for the
next most recent, and so on. Daily snapshots are named
daily.N and hourly snapshots hourly.N. Whenever a new
snapshot of a particular type is created and the number of
existing snapshots of that type exceeds the limit specified
by the sched option described below, then the oldest
snapshot is deleted and the existing ones are renamed.
If, for example, you specified that a maximum of 8 hourly
snapshots were to be saved using the sched command, then
on the hour, hourly.7 would be deleted, hourly.0 would be
renamed to hourly.1, and so on.
Volume engineering
%/used %/total date name
---------- ---------- ------------ --------
0% ( 0%) 0% ( 0%) Nov 14 08:00 hourly.0
50% (50%) 0% ( 0%) Nov 14 00:00 nightly.0
67% (50%) 0% ( 0%) Nov 13 20:00 hourly.1
75% (50%) 0% ( 0%) Nov 13 16:00 hourly.2
80% (50%) 0% ( 0%) Nov 13 12:00 hourly.3
83% (50%) 1% ( 0%) Nov 13 08:00 hourly.4
86% (50%) 1% ( 0%) Nov 13 00:00 nightly.1
87% (50%) 1% ( 0%) Nov 12 20:00 hourly.5
Volume marketing
%/used %/total date name
---------- ---------- ------------ --------
0% ( 0%) 0% ( 0%) Nov 14 08:00 hourly.0
17% (16%) 0% ( 0%) Nov 14 00:00 nightly.0
28% (16%) 0% ( 0%) Nov 13 20:00 hourly.1
37% (16%) 0% ( 0%) Nov 13 16:00 hourly.2
44% (16%) 0% ( 0%) Nov 13 12:00 hourly.3
49% (16%) 1% ( 0%) Nov 13 08:00 hourly.4
54% (16%) 1% ( 0%) Nov 13 00:00 nightly.1
58% (16%) 1% ( 0%) Nov 12 20:00 hourly.5
snap list -o [ qtree_path ]
Displays the relationship between qtree replicas
and the snapshots in which they were captured.
Qtree replicas are created and
maintained by Qtree SnapMirror and SnapVault.
If the -q option is specified, snapshots are listed for all volumes, or for only the specified volume if one is provided. For each snapshot, a list of qtrees captured by that snapshot is also displayed. The qtree list displays the name of each qtree, along with content type, a timestamp, and the replication source, if applicable.
The content type is one of Original, Replica, or Transitioning. The Original label indicates that the snapshot contains an original copy of the qtree, and not a replicated one. At the time the snapshot was created, the qtree was writable. The Replica label indicates that the snapshot contains a a consistent replica of some original source qtree, which is also listed on that line. The timestamp for a replica qtree is given as the date of the replication, not of the snapshot. The Transitioning label indicates that at the time the snapshot was taken, the replica qtree was in a transitional state, and therefore does not represent an exact copy of any original source qtree.
The following is an example of the snap list command with the -q option, on a filer named toaster with a volume named vault. The volume contains SnapVault qtree replicas from a volume named usr3 on a system named oven.
toaster> snap list -q vault
Volume vault
working...
qtree contents date source
-------- ------------- ------------ --------
sv_hourly.0 (Nov 18 18:56)
dr4b Replica Nov 18 18:55 oven:/vol/usr3/dr4b
gf2e Replica Nov 18 18:55 oven:/vol/usr3/gf2e
mjs Replica Nov 18 18:55 oven:/vol/usr3/mjs
xydata Original Nov 18 18:56 -
toaster(0007462703)_vault-base.0 (Nov 18 18:56)
dr4b Replica Nov 18 18:55 oven:/vol/usr3/dr4b
gf2e Replica Nov 18 18:55 oven:/vol/usr3/gf2e
mjs Replica Nov 18 18:55 oven:/vol/usr3/mjs
xydata Original Nov 18 18:56 -
hourly.0 (Nov 18 18:55)
dr4b Transitioning - -
gf2e Transitioning - -
mjs Transitioning - -
xydata Original Nov 18 18:55 -
hourly.1 (Nov 18 18:52)
dr4b Replica Nov 18 18:50 oven:/vol/usr3/dr4b
gf2e Replica Nov 18 18:51 oven:/vol/usr3/gf2e
mjs Replica - Unknown
sv_nightly.0 (Nov 18 18:51)
dr4b Replica Nov 18 18:50 oven:/vol/usr3/dr4b
sv_hourly.1 (Nov 18 18:49)
The following is an example of the snap list command with the -o option, on a filer named toaster with a volume named vault. The volume contains SnapVault qtree replicas from a volume named usr3 on a system named oven.
toaster> snap list -o /vol/vault/dr4b Qtree /vol/vault/dr4b working... date source name ------------ -------- -------- Nov 18 18:55 oven:/vol/usr3/dr4b sv_hourly.0 Nov 18 18:55 oven:/vol/usr3/dr4b toaster(0007462703)_vault-base.0 Nov 18 18:50 oven:/vol/usr3/dr4b hourly.1 Nov 18 18:50 oven:/vol/usr3/dr4b sv_nightly.0
snap create vol_name name
Creates a snapshot of volume vol_name with the
specified name.
snap delete vol_name name
Deletes the existing snapshot belonging to
volume vol_name that has the specified name.
snap delete -a [ -f ] [ -q ] vol_name Deletes all existing snapshots belonging to volume vol_name. Before beginning deletion, the user is requested to confirm the operation. The -f option suppresses this confirmation step. A message is printed out to indicate each snapshot deleted, unless the -q option is specified, in which case deletion will occur silently. This command can be interrupted by entering CTRL-C. Note that certain filer utilities, such as RAID sync mirror, need to lock snapshots periodically to temporarily prevent snapshot deletion. In such a case, all snapshots may not be deleted by snap delete -a.
snap rename vol_name from to
Gives an existing snapshot a new name. You
can use the snap rename command to move a
snapshot out of the way so that it won't be
deleted automatically.
snap reserve [ vol_name | [ percent ] ] Sets the size of the indicated volume's snapshot reserve to percent. With no percent argument, prints the percentage of disk space that is reserved for snapshots in the indicated volume. With no argument, the snap reserve command prints the percentage of disk space reserved for snapshots for each of the volumes in the system. Reserve space can be used only by snapshots and not by the active file system.
snap restore [ -f ] [ -t vol | file ] [ -s snapshot_name
]
[ -r restore_as_path ] vol_name | restore_from_path
Reverts a volume to a specified snapshot, or reverts a single file to a revision from a specified snapshot.
If you do not specify a snapshot, the filer prompts you for the snapshot.
Before reverting the volume or file, the user is requested to confirm the operation. The -f option suppresses this confirmation step.
If the -t option is specified, it must be followed by vol or file to indicate which type of snaprestore is to performed.
A volume cannot have both a volume snaprestore and a single-file snaprestore executing simultaneously. Multiple single-file snaprestores can be in progress simultaneously.
For volume snaprestore:
The volume must be online and must not be a mirror.
If reverting the root volume, the filer will be rebooted. Non-root volumes do not require a reboot.
When reverting a non-root volume, all ongoing access to the volume must be terminated, just as is done when a volume is brought offline. See the description under the vol offline command for a discussion of circumstances that would prevent access to the volume from being terminated and thus prevent the volume from being reverted.
After the reversion, the volume is in the same state as it was when the snapshot was taken.
For single-file snaprestore:
The volume used for restoring the file must be online and must not be a mirror.
If restore_as_path is specified, the path must be a full path to a filename, and must be in the same volume as the volume used for the restore.
Files other than normal files and LUNs are not restored. This includes directories (and their contents), and files with NT streams.
If there is not enough space in the volume, the single file snap restore will not start.
If the file already exists (in the active filesystem), it will be overwritten with the version in the snapshot.
It could take upto several minutes for before the snap command returns. During this time client exclusive oplocks are revoked and hard exclusive locks like the DOS compatibility lock are invalidated.
Once the snap command returns, the file restore will proceed in the background. During this time, any operation which tries to change the file will be suspended until the restore is done. Also, other singlefile snap restores can be executed.
Also it is possible for the single file snap restore to be aborted if we run out of disk space during the operation. When this happens the timestamp of the file being restored will be updated. Thus it will not be the same as the timestamp of the file in the snapshot.
An in-progress restore can be aborted by removing the file. For NFS users, the last link to the file must be removed.
The snapshot used for the restore cannot be deleted. New snapshots cannot be created while a single-file snaprestore is in progress. Scheduled snapshots on the volume will be suspended for the duration of the restore.
Tree, user and group quota limits are not enforced for the owner, group and tree in which the file is being restored. Thus if the user, group or tree quotas are exceeded, /etc/quotas will need to be altered after the single file snap restore operation has completed. Then quota resize will need to be run.
When the restore completes, the file's attributes (size, permissions, ownership, etc.) should be identical as those in the snapshot.
If the system is halted or crashes while a single file snap restore is in progress then the operation will be restarted on reboot.
snap sched [ vol_name [ weeks [ days [ hours [ @list ] ] ]
] ]
Sets the schedule for automatic snapshot creation.
The argument vol_name identifies the volume the
schedule should be applied to. The second argument
indicates how many weekly snapshots should be kept
on-line, the third how many daily, and the fourth
how many hourly. If an argument is left off, or
set to zero, then no snapshot of the corresponding
type is created. Daily snapshots are created at
24:00 of each day except Sunday, and weekly
snapshots are created at 24:00 on Sunday. Only one
snapshot is created at a time. If a weekly snapshot
is being created, for instance, no daily or
hourly snapshot will be created even if one would
otherwise be scheduled. For example, the command
snap sched vol0 2 6
indicates that two weekly snapshots and six daily snapshots of volume vol0 should be kept on line. No hourly snapshots will be created. For snapshots created on the hour, an optional list of times can be included, indicating the hours on which snapshots should occur. For example the command
snap sched vol0 2 6 8@8,12,16,20
indicates that in addition to the weekly and daily snapshots, eight hourly snapshots should be kept on line, and that they should be created at 8 am, 12 am, 4 pm, and 8 pm. Hours must be specified in 24-hour notation.
With no argument, snap sched prints the current snapshot schedule for all volumes in the system. With just the vol_name argument, it prints the schedule for the specified volume.
The time required by the snap list command depends on the size of the file system. It can take several minutes on very large file systems.