Applies To:

Show Versions Show Versions

Manual Chapter: Configuring Volume Snapshots
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

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:
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
nas10*> vol options datavol1 nosnapdir off
nas10*> vol options datavol2 nosnapdir off
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
Password: rootpasswd
bstnA(gbl)# proxy-user cifs_admin
Password: adminpasswd
bstnA(gbl-proxy-user[cifs_admin])# windows-domain MEDARCH.ORG
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.
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)# 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:
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
where newdirname is the name that will be substituted for .snapshot in every directory in the current volume.
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
Use no retain to keep the default number of snapshots for this rule (three):
bstnA(gbl)# namespace medarcv volume /lab_equipment
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
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
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,
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:
where name (1-64 characters) identifies the schedule. Use the show schedule command to list all schedules.
bstnA(gbl)# namespace medarcv volume /lab_equipment
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.
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
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
report prefix error-only
where prefix is explained above.
bstnA(gbl)# namespace medarcv volume /lab_equipment
From gbl-ns-vol-snap mode, use no report to prevent the snapshot rule from generating reports:
bstnA(gbl)# namespace medarcv volume /lab_equipment
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.
bstnA(gbl)# show reports snap_daily_0_create_20120411005104661.rpt
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:
acopia_id_time-stamp_uuid_filer-volume
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.
bstnA(gbl)# namespace medarcv volume /lab_equipment
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
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:
snapshot remove namespace vol-path 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# snapshot remove medarcv /lab_equipment hourlySnap
snapshot remove namespace vol-path rule snapshot
namespace vol-path, and rule are described above, and
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# snapshot remove medarcv /lab_equipment dailySnap dailySnap_2
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(gbl)# show reports snap_daily_2_remove_20120411005258066.rpt
From gbl-ns-vol mode, use the no snapshot rule command to remove a snapshot rule from the current volume:
where name (1-64 characters) identifies the rule to remove.
bstnA(gbl)# namespace medarcv volume /lab_equipment
snapshot manage namespace vol-path share rule filer-snap created-on date-time
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.
bstnA# snapshot manage medarcv /lab_equipment leased weekly_snap weekly.1 created-on 03/30/2009:01:05:24
snapshot-manage-namespace-volume-rule-yyyymmddHHMM.rpt.
To change the snapshot-manage prefix, you can use the report-prefix option at the end of the snapshot-manage command:
snapshot manage namespace ... rule filer-snap created-on date-time [report-prefix prefix]
prefix (optional, 1-64 characters), which is the new prefix for the report name.
bstnA# snapshot manage medarcv /lab_equipment leased weekly_snap weekly.3 created-on 03/16/2009:01:05:22 report-prefix getWk3
snapshot manage namespace ... filer-snap created-on date-time [report-prefix prefix] [verbose]
bstnA# snapshot manage medarcv /lab_equipment leased weekly_snap weekly.3 created-on 03/16/2009:01:05:22 verbose
snapshot clear namespace [vol-path [rule [snapshot snap-name [share share-name]]]]
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
bstnA(gbl)# namespace medarcv volume /lab_equipment
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
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
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
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
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
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.
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:
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot directory display all-exports hidden
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:
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
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
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
snapshot create namespace vol-path rule [name]
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# snapshot create medarcv /lab_equipment dailySnap
snapshot verify namespace vol-path 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 verify.
bstnA# snapshot verify medarcv /lab_equipment hourlySnap
bstnA# show reports snap_hourly_0_verify_20091006020708453.rpt
snapshot verify namespace vol-path rule snapshot
namespace vol-path, and rule are described above, and
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# snapshot verify medarcv /lab_equipment dailySnap dailySnap_0
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:
ssh admin-user@mip snapshot ...
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
bstnA(gbl)# show snapshots
show snapshots [namespace [vol-path [rule]]]
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
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# 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# copy software snap-recon.pl ftp://ftpuser:ftpuser@172.16.100.183//var/arxSnapRpts/
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]
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.
verbose (optional) adds the verbose option to all of the output scripts snapshot manage commands.
juser@lnx2:/var/arxSnapRpts$ ./snap-recon.pl --report-dir .
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:
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# copy ftp://ftpuser:ftpuser@172.16.100.183//var/arxSnapRpts/snapRecon.cli scripts snapRecon.cli
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
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.
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.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)