Manual Chapter :
Configuring Volume Snapshots
Applies To:
Show Versions
ARX
- 6.3.0
An ARX volume can support regular snapshots, or copies from a particular point in time, of its client files and directories.
Most Microsoft Windows clients can view these snapshots with Windows Explorer: they can click Properties on any file or directory and select the Previous Versions tab. The snapshots appear as instances of the same file or directory with progressively-older time stamps. This is called the Volume Shadow-copy Service, or VSS, for shared folders:
A Windows client can recover an older version of any file or subdirectory through the VSS interface.
The ARX presents only snapshots that it created or that were imported using the manage snapshot command.
Note: If you add snapshot support to a volume that already has active CIFS clients, those CIFS clients must close all instances of Windows Explorer for the Previous Versions tab to appear. Windows Explorer only checks its network shares for snapshot support during startup.
To support ARX snapshots, each NetApp volume must have the nosnapdir option turned off. From the NetApp CLI, use the vol options command on each NetApp volume behind the ARX:
vol options vol-name nosnapdir off
where vol-name identifies the NetApp volume.
juser@mgmt17:~$ ssh root@192.168.25.49
root@192.168.25.49s password: password
nas10*> vol options datavol1 nosnapdir off
nas10*> vol options datavol2 nosnapdir off
nas10*> ...
To support this Kerberos authentication, the ARX must understand the Windows-domain hierarchy in the local Active-Directory (AD) forest. See Discovering the Active-Directory Forest (Kerberos), on page 3-9 of the ARX® CLI Storage-Management Guide.
| create a filename-fileset that recursively matches everything in the volume (using path exact / and recurse), |
| create a place-rule, and |
| use the from (gbl-ns-vol-plc) command to have that fileset match directories and promote them. |
bstnA(gbl)# proxy-user nas_admin
bstnA(gbl-proxy-user[nas_admin])# user root
Password: rootpasswd
Validate Password: rootpasswd
bstnA(gbl)# ...
bstnA(gbl)# proxy-user cifs_admin
bstnA(gbl-proxy-user[cifs_admin])# user Administrator
Password: adminpasswd
Validate Password: adminpasswd
bstnA(gbl-proxy-user[cifs_admin])# windows-domain MEDARCH.ORG
bstnA(gbl)# ...
For details on these proxy-user commands and others, see Adding a Proxy User, on page 3-4 of the ARX® CLI Storage-Management Guide.
The ARX requires parameters for using the CLI or API at each snapshot-supporting filer. This includes the type of filer (a vendor name) and proper login credentials for the filers CLI or API. The commands for setting these parameters are described in Preparing the Filer for ARX-Snapshot Support, on page 6-12 of the ARX® CLI Storage-Management Guide.
bstnA(gbl)# external-filer nas10
bstnA(gbl-filer[nas10])# filer-type network-appliance management-protocol rsh
bstnA(gbl-filer[nas10])# proxy-user nas_admin
bstnA(gbl-filer[nas10])# manage snapshots
bstnA(gbl)# external-filer fs2
bstnA(gbl-filer[fs2])# filer-type windows
bstnA(gbl-filer[fs2])# proxy-user cifs_admin
bstnA(gbl-filer[fs2])# manage snapshots
From gbl-ns-vol mode, use the snapshot rule command to create a new snapshot rule:
snapshot rule name
where name (1-64 characters) is a name you choose for the rule. This name is used in the names of the rules individual snapshots, which can be viewed by ARX clients.
The CLI prompts for confirmation before creating a new snapshot rule; enter yes to continue. This puts you into gbl-ns-vol-snap mode, where you enable the new rule. There are also some optional commands you can invoke from this mode, such as applying a schedule.
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot rule dailySnap
snapshot directory cifs-name newdirname
snapshot directory nfs-name newdirname
where newdirname is the name that will be substituted for .snapshot in every directory in the current volume.
The ARX volume retains a limited number of snapshots for each snapshot rule. This conserves disk space on each back-end filer. The default is three snapshots. From gbl-ns-vol-snap mode, use the retain command to change the number of retained snapshots:
retain number
where number (1-1024) is the number of snapshots to retain. If you choose a number lower than the current number of snapshots, the volume removes any excess snapshots the next time the rule runs.
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot rule dailySnap
Use no retain to keep the default number of snapshots for this rule (three):
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot rule hourlySnap
The volume may contain one or more shares that should be excluded from the coordinated snapshot. For example, a share could be backed by a back-end volume that is approaching a size limit, though the filer has other volumes where snapshots are permissible. To exclude a single share from the current snapshot rule, use the exclude command from gbl-ns-vol-snap mode:
exclude share-name
where share-name (1-64 characters) identifies the volume share to exclude. Use the share name from the ARX-volume configuration, not from the filer configuration; type ? in place of the share-name for a valid list of share names.
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot rule hourlySnap
bstnA(gbl-ns-vol-snap[medarcv~/lab_equipment~hourlySnap])# exclude backlots
For a share that was previously excluded, you can use the no exclude command to include it in future runs of the snapshot rule:
no exclude share-name
where share-name (1-64 characters) identifies the volume share to include in future snapshots.
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot rule hourlySnap
bstnA(gbl-ns-vol-snap[medarcv~/lab_equipment~hourlySnap])# no exclude leased
A sparse snapshot is a coordinated snapshot with at least one component snapshot missing. A snapshot rule creates a sparse snapshot if any of the following conditions exist when the rule runs:
| the rule has any exclude share, |
| the volume uses an external-filer with no manage snapshots, or |
All of the files on the excluded shares appear to be missing from the client view of a sparse snapshot. For example, if a file named \mydir\mysub\file.txt is on Share A and another file named \mydir\mysub\otherFile.txt is on an excluded share, a coordinated snapshot only contains \mydir\mysub\file.txt from the included share. You can use file-placement rules to ensure that files that should be backed up reside on the volumes included shares: refer to in Placing Files on Particular Shares, on page 14-4 of the ARX® CLI Storage-Management Guide for instructions on creating file-placement rules.
To create a schedule, use the gbl schedule command (refer to Appendix 12, Creating a Policy Schedule of the ARX® CLI Storage-Management Guide for details). To apply a schedule to the snapshot rule, use the schedule command in gbl-ns-vol-snap mode:
schedule name
where name (1-64 characters) identifies the schedule. Use the show schedule command to list all schedules.
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot rule dailySnap
bstnA(gbl-ns-vol-snap[medarcv~/lab_equipment~dailySnap])# schedule daily4am
If the schedule has no specific start time, it starts when you first enable the snapshot rule (as described later in this section). That is, it takes its first snapshot at enable time. For instructions on setting the schedules start time, see Setting the Start Time (optional), on page 12-7 of the ARX® CLI Storage-Management Guide.
Important: Snapshot grouping can be problematic for EMC-Celerra-backed volumes. As mentioned in EMC Celerra Best Practices, EMC servers serialize their snapshots (called checkpoints in EMC documentation). If multiple ARX volumes have the same snapshot schedule and use shares from multiple file systems on an EMC, the ARX waits for the EMC to perform its checkpoints serially.
For example, suppose 12 ARX volumes have the same snapshot schedule and are backed by 2 different EMC file systems each (for a total of 24 EMC file systems). Further suppose that all 24 EMC file systems reside on a single EMC file server. The EMC server waits for each checkpoint to complete before it begins the next one. The ARX-snapshot operation is not complete until all 24 EMC checkpoints are finished, even though each ARX volume requires only 2 EMC checkpoints.
For example, suppose 12 ARX volumes have the same snapshot schedule and are backed by 2 different EMC file systems each (for a total of 24 EMC file systems). Further suppose that all 24 EMC file systems reside on a single EMC file server. The EMC server waits for each checkpoint to complete before it begins the next one. The ARX-snapshot operation is not complete until all 24 EMC checkpoints are finished, even though each ARX volume requires only 2 EMC checkpoints.
If you remove the schedule, you can only invoke snapshots manually. Use no schedule to remove the schedule from the current snapshot rule:
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot rule test_snap
A progress reports shows all the milestones and results of a snapshot. We recommend this to verify that all filer snapshots succeeded, or to diagnose problems if one of them failed. From gbl-ns-vol-snap mode, use the report command to generate this report every time the rule creates a snapshot:
report prefix
where prefix (1-1024 characters) is the prefix to be used for the report. The report has a name in the following format: prefix_0_create_YearMonthDayHourMinuteSecondsMilliseconds.rpt (for example, mySnap_0_create_20071112133047318.rpt for a report with the mySnap prefix).
Use the show reports command for a list of all reports, or show reports type Snapshot for a list of snapshot reports. Use show reports report-name to read the report, show reports status report-name to get a one-line summary of the report, grep to search through the full report, or tail reports report-name follow to follow a report as it is being written.
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot rule dailySnap
bstnA(gbl-ns-vol-snap[medarcv~/lab_equipment~dailySnap])# report snap_daily
To save space on the ARXs internal disks, you can make the rule skip the report for snapshots that succeed. To accomplish this, use the optional error-only flag at the end of the report command:
report prefix error-only
where prefix is explained above.
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot rule hourlySnap
bstnA(gbl-ns-vol-snap[medarcv~/lab_equipment~hourlySnap])# report snap error-only
From gbl-ns-vol-snap mode, use no report to prevent the snapshot rule from generating reports:
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot rule test_snap
The snapshot-create report contains configuration details for each rule, followed by details about the particular snapshot. The configuration details are in the first two tables in the report, Snapshot Summary and Snapshot Properties. The Snapshot Summary table identifies the namespace, volume, and snapshot rule. The Snapshot Properties table shows the configuration settings for the rule. The Snapshot Summary - rule-name_0 table shows timestamps and the status of the coordinated snapshot. The Included Shares section has a separate table for each snapshot on each back-end share: these show the snapshots back-end locations. An Excluded Shares section and/or Offline Shares section appears for a sparse snapshot; these sections list all shares that were not used in the snapshot operation.
The Volume Snapshot fields in the Included Shares section show the names of the snapshot directories on the back-end filers. On EMC servers, Data Domain systems, and NetApp filers, these are created with the following format:
id is an integer that the snapshot software uses internally.
time-stamp is in yyyymmddHHMM format. This is the time that the snapshot was created.
uuid is the Universally-Unique ID that identifies the ARX. In a redundant pair, this is the UUID for the peer that was originally configured as senior/active, no matter which peer is currently active. An ARXs UUID appears in the output of the show chassis chassinfo command.
filer-volume is the name of the filers volume.
The final step in configuring a snapshot rule is to enable it. By default, the rule is disabled and ignored by policy software. You must enable the rule to run snapshots on a schedule or to invoke the snapshots manually. Use the enable command to enable the rule:
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot rule dailySnap
Disabling the rule prevents it from creating any snapshots. Use no enable from gbl-ns-vol-snap mode to disable a snapshot rule:
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot rule test_snap
You can use the priv-exec command, snapshot remove, to delete all of the back-end snapshots behind a snapshot rule, without removing the rule configuration. You can use this to clear snapshots from several filers at once. From priv-exec mode, use the snapshot remove command to remove the filer snapshots and/or checkpoints behind a snapshot rule:
namespace (1-30 characters) is the namespace,
vol-path (1-1024 characters) selects the ARX volume, and
rule (1-64 characters) is the snapshot rule.
The CLI prompts for confirmation before removing the snapshots and/or checkpoints from the back-end filers. Enter yes to proceed with the snapshot removal. Then it displays the names of one or more removal reports, one per ARX snapshot, which show the results of each removal operation. Use show reports report-name to view any report, or tail reports report-name follow to watch the removal operation as it progresses.
bstnA(gbl)# end
bstnA# snapshot remove medarcv /lab_equipment hourlySnap
bstnA(gbl)# ...
You can remove the back-end snapshots from behind a single ARX-volume snapshot. Add the name of a specific snapshot to the end of the snapshot remove command:
snapshot (1-68 characters) is the specific snapshot to remove. Snapshots are typically named rule-name_n, where rule-name is the same as rule and n is the number of the specific snapshot (for example, hourlySnap_2). Type ? for a complete list of snapshots in the current snapshot rule.
The CLI prompts for confirmation before removing the snapshots and/or checkpoints from the back-end filer(s). Enter yes to proceed with the snapshot removal. Then it displays the name of the removal report, which shows the results of the removal operation.
bstnA(gbl)# end
bstnA# snapshot remove medarcv /lab_equipment dailySnap dailySnap_2
bstnA# ...
The snapshot-remove report has a similar format to the snapshot-create report, shown in Sample Snapshot-Create Report. This report contains configuration details for each rule, followed by details about the particular ARX-snapshot removal. The configuration details are in the first two tables in the report, Snapshot Summary and Snapshot Properties. The Snapshot Summary table shows identifies the namespace, volume, and snapshot rule. The Snapshot Properties table shows the configuration settings for the rule. The Snapshot Summary - rule-name_0 table shows timestamps and the status of the overall snapshot removal. The Included Shares section has a separate table for each snapshot on each back-end share: these show the results and timing of each filer-snapshot removal. If any of the volumes shares were administratively excluded from the snapshot, an Excluded Shares section lists them. Similarly, an Offline Shares section appears if any of the volumes shares were unreachable when the original snapshot was taken.
bstnA# ...
Removing a snapshot rule deletes its configuration from the ARX without affecting any back-end snapshots. This also removes the Previous Versions tab from the client-side view of the ARX volume.
From gbl-ns-vol mode, use the no snapshot rule command to remove a snapshot rule from the current volume:
no snapshot rule name
where name (1-64 characters) identifies the rule to remove.
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# no snapshot rule test_snap
You can incorporate an existing, back-end snapshot into a snapshot rule. After incorporating all of the pre-existing snapshots into the ARX volume, Windows clients can access them as they did before the introduction of the ARX. From priv-exec mode, use the snapshot manage command to import a back-end snapshot into a snapshot rule:
namespace (1-30 characters) is the namespace,
vol-path (1-1024 characters) selects the ARX volume, and
share (1-64 characters) is the ARX share. The volume software seeks the back-end snapshot on the filer behind this share.
rule (1-1024 characters) is the snapshot rule to accept the back-end snapshot.
filer-snap (1-255 characters) is name of the snapshot or checkpoint at the back-end filer or file server.
date-time is the date and time that the ARX snapshot was created, in mm/dd/yyyy:HH:MM:SS format. This identifies a particular ARX snapshot from the above rule. You can use show snapshots (described later) to see the time stamps for existing snapshots. If no ARX snapshot exists for the given time, this command creates a new one.
This command runs synchronously; the CLI prompt does not return until the snapshot import is complete. If it fails, a report name appears. You can use show reports report-name to examine the report and find the cause of the failure.
bstnA(gbl)# end
bstnA# snapshot manage medarcv /lab_equipment leased weekly_snap weekly.1 created-on 03/30/2009:01:05:24
To change the snapshot-manage prefix, you can use the report-prefix option at the end of the snapshot-manage command:
prefix (optional, 1-64 characters), which is the new prefix for the report name.
bstnA(gbl)# end
bstnA# snapshot manage medarcv /lab_equipment leased weekly_snap weekly.3 created-on 03/16/2009:01:05:22 report-prefix getWk3
The volume software only creates a report when the snapshot manage operation fails, by default. To create a report whether or not the operation fails, you can use the verbose option at the end of the command:
bstnA(gbl)# end
bstnA# snapshot manage medarcv /lab_equipment leased weekly_snap weekly.3 created-on 03/16/2009:01:05:22 verbose
If you mismatched the back-end snapshot with its ARX counterpart, you can use a command to disassociate the snapshot from the ARX configuration. From priv-exec mode, the clear snapshot command clears one or more back-end snapshots from the ARX:
namespace (1-30 characters) identifies the namespace where you want to clear at least one snapshot record.
vol-path (optional, 1-1024 characters) focuses on one ARX volume. The command clears all snapshot records in the above namespace if you omit this.
rule (optional, 1-64 characters) is a snapshot rule with one or more snapshots to clear. If omitted, the command clears all of the volumes filer-snapshot records.
snap-name (optional, 1-255 characters) identifies a particular ARX snapshot where you want to clear filer-snapshot associations. If you omit this, the command clears the filer-snapshot records for all retained snapshots in the above rule.
share (optional, 1-64 characters) focuses the command on a single ARX share. This causes the command to clear the single record of a particular snapshot on this share. You can use the show snapshots command to see the exact name of the snapshot on this share. If you omit this, the command clears the records of all the filer snapshots associated with the chosen ARX snapshot, and therefore removes this particular ARX snapshot from the rule.
The CLI prompts for confirmation before clearing any back-end snapshots from the ARX configuration; enter yes to proceed. This does not affect the back-end snapshots themselves, nor does it affect the configuration of any snapshot rule.
bstnA# snapshot clear medarcv /lab_equipment dailySnap snapshot dailySnap_2
Proceed? [no] yes
bstnA# ...
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot vss-mode pre-xp
As mentioned above, support of the VSS interface (the Previous Versions tab in file/directory Properties) incurs a slight performance penalty if extended to Windows 2000 clients. By default, a volume only supports VSS for releases after Windows 2000, such as Windows XP and Windows 2003. Use the following command (also in gbl-ns-vol mode) to return to this default:
bstnA(gbl)# namespace access volume /G
bstnA(gbl-ns-vol[access~/G])# snapshot vss-mode xp
 | For CIFS clients, you can identify the administrative clients in a Windows-Management-Authorization (WMA) group, and limit snapshot access to those clients. |
You can use a Windows-Management-Authorization (WMA) group to restrict snapshot access to a limited number of clients, such as administrators. A WMA group is typically used to identify users who can use MMC and similar management tools in a namespace. Authorizing Windows-Management (MMC/Snapshot) Access, on page 3-25 of the ARX® CLI Storage-Management Guide describes how to create a WMA group, and Opening Windows-Management Access (optional, MMC/Snapshots), on page 7-16 describes how to assign one to a namespace. You can create a WMA group for authorized snapshot clients, permit access to snapshots for that group, assign it to the volumes namespace, and then enforce the WMA group for snapshots in the current volume. All of these steps are described below.
From gbl mode, you can use the windows-mgmt-auth command to create a new WMA group. This places you into gbl-mgmt-auth mode, where you can use the user command once for each Windows client in the WMA group, and the permit snapshot command to allow them access to snapshots. For example, this creates a WMA group named snapViewers with two users:
bstnA(gbl)# windows-mgmt-auth snapViewers
bstnA(gbl-mgmt-auth[snapViewers])# user juser windows-domain MEDARCH.ORG
bstnA(gbl-mgmt-auth[snapViewers])# user jquser windows-domain MEDARCH.ORG
bstnA(gbl-mgmt-auth[snapViewers])# permit snapshot monitor
bstnA(gbl)# ...
These commands are detailed in Authorizing Windows-Management (MMC/Snapshot) Access, on page 3-25 of the ARX® CLI Storage-Management Guide.
From gbl-ns mode, you can use another windows-mgmt-auth command to assign a WMA group to your namespace. For example, this command sequence assigns the snapViewers WMA group to the medarcv namespace:
bstnA(gbl)# namespace medarcv
bstnA(gbl-ns[medarcv])# windows-mgmt-auth snapViewers
This is described in detail in Opening Windows-Management Access (optional, MMC/Snapshots), on page 7-16 of the ARX® CLI Storage-Management Guide.
The snapshot processes ignore the namespaces WMA group(s) by default. From gbl-ns-vol-snap mode, use the snapshot privileged access command to restrict all snapshot access to privileged Windows users (that is, to users in a WMA group with permit snapshot monitor):
bstnA(gbl-ns[medarcv])# volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot privileged-access
Use no snapshot privileged-access to allow all users to access the volumes snapshots:
bstnA(gbl)# namespace access volume /G
bstnA(gbl-ns-vol[access~/G])# no snapshot privileged-access
Well-informed clients always have access to the ~snapshot directory, which is not displayed by default. The ~snapshot directory is a pseudo directory under every directory of the volume. Each subdirectory under ~snapshot is one snapshot for the directory, named rule-name_n (such as hourlySnap_0, hourlySnap_1, and so on). Administrators can traverse these ~snapshot directories and recover files as needed.
From gbl-ns-vol mode, use the snapshot vss-mode none command to shut down support for VSS (the Previous Versions interface), leaving only the obscure ~snapshot directory for accessing snapshots:
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot vss-mode none
Then use one of the snapshot directory display commands to display the root ~snapshot directory to administrators. The following subsections describe these commands.
If the volume has snapshot privileged-access, described earlier, only privileged clients can see or access the ~snapshot directories. The ~snapshot directory appears on the next CIFS dir command or the next refresh of the graphical view.
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot directory display all-exports
The ~snapshot directory contains one subdirectory for each snapshot. Its subdirectories are named rulename_n, where n is the number of the snapshot. Snapshot 0 (zero) is the most-recent snapshot, and the numbers are progressively higher for older snapshots. For example, clients of the medarcv~/lab_equipment volume with the dailySnap rule would see snapshots in directories named dailySnap_0, dailySnap_1, and so on. Every time the rule runs, it creates a new snapshot and moves it to the ..._0 directory (dailySnap_0), moves all the intermediate directories (the earlier dailySnap_0 moves to dailySnap_1, dailySnap_1 moves to dailySnap_2, and so on), and removes the oldest snapshot. The Date Modified stamp for each directory is the time the snapshot was created.
From gbl-ns-vol mode, use the following command to show the snapshot directory in root exports only:
As above, this change is visible to clients (that is, the ~snapshot directory appears) on the clients next CIFS dir command (or the next refresh of the graphical view).
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot directory display volume-root-only
Add the optional hidden argument to the end of the snapshot directory display command to raise the DOS hidden flag for the ~snapshot directory:
If the volume is active when you run this command, the snapshot directory disappears from client view on the next CIFS dir command (or the next refresh of the graphical view).
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot directory display all-exports hidden
By default, the ~snapshot directory does not have the hidden flag raised. All clients can see the directory at the root of the CIFS share. To lower the hidden flag, re-run the snapshot directory display command without the hidden argument at the end:
As above, the ~snapshot directory appears on the clients next CIFS dir command, or the next refresh of the graphical view.
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot directory display all-exports
From gbl-ns-vol mode, you can use the snapshot directory name command to change the name of the volumes ~snapshot directories:
snapshot directory name new-name
where new-name (1-32 characters) is the new name for this volumes snapshot directory. Avoid any characters that are not supported in CIFS (any control character, /, \, :, *, >, <, , |, or ?). Also avoid any name that might already be in use by clients.
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot directory name ~checkpt
Use no snapshot directory name to return to the default name, ~snapshot:
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# no snapshot directory name
Use the snapshot consistency command to guarantee snapshot consistency in the current volume. A consistent snapshot is one with no file or directory changes between the start and end of the coordinated-snapshot operation. Consistency is achieved through a VIP fence, which momentarily blocks client access to the volumes VIP while the back-end filers perform their snapshot and checkpoint operations. The fence remains up until the last filer indicates that its snapshot is complete, or until a timeout expires, whichever comes first.
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot consistency
If multiple snapshot rules use the same schedule, the ARX invokes their filer snapshots in a group. This protects against duplicate snapshots on back-end filers. However, it also extends the fencing timeout, and the time that clients cannot access any ARX volumes behind the VIP(s). This can be time-consuming for volumes backed by EMC Celerra servers, as discussed earlier (recall Snapshot Grouping).
For volumes where snapshot consistency is not required, you can use the no snapshot consistency command to disable VIP fencing:
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# no snapshot consistency
You can manually invoke a snapshot rule and create a coordinated snapshot at any time. From priv-exec mode, use the snapshot create command to manually invoke a snapshot rule:
namespace (1-30 characters) is the namespace,
vol-path (1-1024 characters) selects the volume, and
rule (1-64 characters) is the snapshot rule to invoke.
name (optional; 1-68 characters) is a name you choose for this snapshot. By default, the name is rule_0 (for example, dailySnap_0). You cannot choose the name of an existing snapshot.
The CLI prompts for confirmation. If the rule has a schedule assigned to it (recall Applying a Schedule (optional)), the confirmation notifies you that the unscheduled snapshot affects the rules retained snapshots. For a rule with a full count of retained snapshots, this removes the oldest retained snapshot and creates a new snapshot to replace it. This breaks the scheduled chain of snapshots, so it is only recommended for situations where the most-recent snapshot failed.
Enter yes at the prompt in order to proceed with the snapshot. The CLI then displays the name of the snapshot report; use show reports report-name to view this report, which contains details about the snapshot operation.
bstnA(gbl)# end
bstnA# snapshot create medarcv /lab_equipment dailySnap
namespace (1-30 characters) is the namespace,
vol-path (1-1024 characters) selects the volume, and
rule (1-64 characters) is the snapshot rule to verify.
The CLI displays the name of the verification report(s), one per snapshot. Each report contains the results of one snapshot verification. Use show reports report-name to view any report.
bstnA(gbl)# end
bstnA# snapshot verify medarcv /lab_equipment hourlySnap
bstnA# show reports snap_hourly_0_verify_20091006020708453.rpt
To focus on a single snapshot, you can add the name of the snapshot to the end of the snapshot verify command:
snapshot (1-68 characters) is a specific snapshot. Snapshots are typically named rule-name_n, where rule-name is the same as rule and n is the number of the specific snapshot (for example, hourlySnap_2). The n is 0 (zero) for the newest snapshot and progressively higher for older snapshots. Type ? for a complete list of snapshots for the current snapshot rule.
bstnA(gbl)# end
bstnA# snapshot verify medarcv /lab_equipment dailySnap dailySnap_0
bstnA# ...
From any remote host that supports the Secure Shell (SSH) protocol, you can run snapshot create, snapshot remove, or snapshot verify and see the report(s). Use the following syntax with ssh:
admin-user is the username for a valid administrative account at the ARX (use show users to list all of them, as shown in Listing All Administrative Users, on page 2-14 of the ARX® CLI Network-Management Guide),
mip is a management-IP address for the ARX (use show interface mgmt to show the out-of-band management interface, or show interface vlan to show all in-band management interfaces), and
snapshot ... is the desired snapshot command, described above. Surround this with quotation marks ().
For example, the following command sequence runs the snapshot create command from a remote machine, mgmt17.
juser@mgmt17:~$ ssh admin@10.1.1.7 snapshot create medarcv /lab_equipment dailySnap
juser@mgmt17:~$ ssh admin@10.1.1.7 show reports snap_daily_0_create_20120423012706913.rpt
To see the high-level status of all ARX snapshots, use the show snapshots command:
This shows a separate table of snapshots for every ARX volume. The table contains one row per snapshot, with the name of the snapshot rule, the name of the particular ARX snapshot, the time the snapshot was created (or a status indicator for a failed or in-progress snapshot), and the source of the snapshot (either a Schedule from a snapshot rule or a Manual invocation). The table is empty for volumes without any snapshots. If a status indicator appears for the Created time (such as Incomplete), you can use the snapshot report (show reports type Snapshot) to localize the problem.
bstnA(gbl)# show snapshots
bstnA(gbl)# ...
namespace (1-30 characters) selects a namespace,
vol-path (1-1024 characters) narrows the scope to a specific volume, and
rule (1-1024 characters) narrows the scope further, to a specific snapshot rule in the volume (for example, dailySnap).
If you select a particular rule, the output shows the rules configuration details. After the rule has run at least once, its output contains a Snapshot Summary - rule-name_n section for each retained snapshot. The top table in the Snapshot-summary section shows the time and overall state of the coordinated snapshot. The Included Shares table shows each back-end share with a component snapshot and the location of the snapshot on that share. The Excluded Shares section shows all shares in the volume that were administratively excluded from this coordinated snapshot, if there were any. The Offline Shares section, shows all shares that were unreachable at the time of the snapshot, if there were any. (The Excluded Shares and Offline Shares sections only appear if any such shares were omitted from the snapshot.)
bstnA(gbl)# show snapshots medarcv /lab_equipment hourlySnap
bstnA(gbl)# ...
Snapshot reconstitution is implemented with snapshot reports and a special Perl script that is provided with ARX software. Copy all of these to an external device to prepare for reconstitution at a later date. The snapshot reports contain the names and snapshot times for the back-end snapshots; these names and times can change with each ARX snapshot, so they should be copied after each snapshot operation. You can use the at command, together with some form of the copy command, to regularly send copies of your snapshot reports to an external host. The ARX® CLI Reference describes both of these commands in detail.
Copy the reports so that they are converted to XML format; use the format xml option at the end of the copy command to accomplish this.
bstnA(gbl)# end
bstnA# config
bstnA(cfg)# at 17:32:51 every 1 day do "copy reports snap* ftp://ftpuser:*@172.16.100.183//var/arxSnapRpts/ format xml"
bstnA(cfg)# ...
bstnA(cfg)# end
bstnA# copy software snap-recon.pl ftp://ftpuser:ftpuser@172.16.100.183//var/arxSnapRpts/
bstnA# ...
snap-recon.pl --report-dir path
[--namespace ns [--volume vol-path [--rule rule-name
[--target-ns t-ns --target-vol t-vol --target-rule t-rule]]]]
[--output-script script-name] [--report-prefix prefix] [--verbose]
[--namespace ns [--volume vol-path [--rule rule-name
[--target-ns t-ns --target-vol t-vol --target-rule t-rule]]]]
[--output-script script-name] [--report-prefix prefix] [--verbose]
path is the path to the snapshot reports. This can be a relative path (such as ../arxReports) or an absolute path (such as /var/arxReports).
ns (optional) focuses on the snapshots in the given ARX namespace. From the ARX CLI, you can use show namespace for a complete list of namespaces, volumes, and snapshot rules.
vol-path (optional if you entered a namespace) focuses on the snapshots in the given ARX volume. Specify the volume by its path name, starting with a slash (/); for example, /rcrds or /acct.
rule-name (optional if you entered a volume) takes only the snapshots for a given ARX rule.
--target-ns t-ns --target-vol t-vol --target-rule t-rule (optional if you entered a rule) edits the final output:
| t-ns replaces all instances of the --namespace name with this name. Use this if you want to incorporate the filer snapshots in a new namespace. |
| t-vol replaces all instances of the --volume path with the path you enter here. |
| t-rule replaces the rule name selected with the --rule option. |
script-name (optional) sets a name for the output script. By default, the output script is named snapRecon.cli.
prefix (optional) changes the report prefixes in the output script. These are the prefixes used in the output scripts snapshot manage commands.
juser@lnx2:/var/arxSnapRpts$ ./snap-recon.pl --report-dir .
snap_daily_0_create_20090408013106820.xml snapRecon.cli
Here is a sample of the CLI file, a commented list of snapshot manage commands that re-incorporate the back-end snapshots into their ARX snapshots:
juser@dlnx2:/var/arxSnapRpts$ cat snapRecon.cli
After you review the CLI script, you copy it to the ARX and run it. From the ARX CLI, use the copy command to download the script from your external host to the ARXs scripts directory. For example, this uses FTP to download the snapRecon.cli script that we created above:
bstnA(cfg)# end
bstnA# copy ftp://ftpuser:ftpuser@172.16.100.183//var/arxSnapRpts/snapRecon.cli scripts snapRecon.cli
bstnA# ...
Once it is copied to the scripts directory, use the priv-exec run command to run it and reconstitute your snapshots. The ARX® CLI Reference describes the run command in detail. For example, this command runs the above script:
bstnA# run scripts snapRecon.cli
bstnA# ...
A large CLI script may contain errors that mismatch one or more back-end snapshots with their counterparts on the ARX. To correct this issue, you can use the snapshot clear command to remove the ARX records for one or more back-end snapshots, then you can edit and re-run the ARX-CLI script. For details on the snapshot clear command, recall Clearing the Snapshot from the ARX Configuration.
Create a replica-snap share by setting the replica-snap attribute for an existing share. This attribute can be set only if the share is not enabled.
Executing the no replica-snap command removes the replica-snap attribute, disabling the shares capacity for containing replica snapshots.
Configure a rule for populating a replica-snap share using the snapshot replica-snap-rule CLI command in gbl-ns-vol mode. This command opens gbl-ns-vol-replica-snap mode, which provides commands for defining the rule.
where name identifies the rule that you are defining (up to 1024 characters).
The no form of the command, no snapshot replica-snap-rule name, disables the specified snapshot rule.
| enable: This activates the current replica-snap rule. The command syntax is: |
Executing the no enable command de-activates the replica-snap rule.
| exclude: Specify a share to exclude from the snapshots created by this rule. The command syntax is: |
exclude sharename
where sharename identifies a share in the current volume.
Executing the no exclude sharename negates the exclusion of the specified share, enabling it to be included in replica-snap shares.
| report: Enable reporting for a specified report prefix for the current replica-snap rule. The command syntax is: |
report reportprefix
where reportprefix is a prefix to include in the names of the resulting reports to help identify them. The optional error-only argument causes a report to be generated only if an error occurs during the operation of the snapshot.
Executing the no report command disables reporting for the current replica-snap rule.
| retain: Specify the number of snapshots to retain for a the current replica-snap rule. |
retain number
where number is the maximum number of snapshots to keep on the share, up to a maximum of 1024.
Executing no retain reverts the retention of replica snapshots to the default.
| schedule: Specify an existing schedule to associate with the current replica-snap rule. |
schedule name
where name identifies a previously-defined schedule.
Executing no schedule dissociates the current replica-snap rule from any schedule.
Execute the show snapshots command to see the current status of one or more replica-snap rules.
| Replica-snap shares can be removed from the configuration using the no share command in global-namespace-volume mode. For replica-snap shares, the no share command does not require or accept the relocate-dirs, force, or remove-files-entries options. This is the same as executing a no share command on a direct share. A no share command can be executed on a replica-snap share whether it is enabled or not. |
| The remove share migrate and remove share no-migrate commands work if given a replica-snap share as the share being removed. They ignore any specified relocate and force options, skip the migration step, and implement the same functionality as the no share command. |
| If a subshare is created via the export command while a volume containing replica-snap shares is enabled, the subshare subsystem attempts to create the subshare on all shares, including the replica-snap share. If the directory does not exist, or the creation fails on any of the replica-snap share, the failure is noted in the associated subshares report, but the operation is still considered a success. This provides access to the snapshot data as soon as possible if the target directory has already been replicated to the replica-snap share. Since subshares are synchronized at each snapshot attempt, any failed subshares synchronizations are resolved during later snapshot attempts. |
| The promote subshares and sync subshares functionality also ignores failures on replica-snap shares, and returns success if the failures only occur on replica-snap shares. |
| The cifs access-based-enum <ns> <vol> [force] command also synchronizes the ABE setting to all replica-snap shares in the volume. |
