Purpose	You can use the bandwidth-limit command to set a bandwidth ceiling for the current shadow-copy rule. Each run of the rule abides by this limit. Use no bandwidth-limit to remove any limit on bandwidth.
Modes	gbl-ns-vol-shdwcp
Security Level	storage-engineer or crypto-officer
Syntax	bandwidth-limit rate[K|M|G|T] no bandwidth-limit   rate (100,000-4,000,000,000,000, or 1M-4T) is maximum bandwidth that you choose for the current shadow-copy rule. K|M|G|T (optional) chooses the units. These are Kbps, Mbps, Gbps, or Tbps. They are 10-based: 1 Kbps is 1,000 bps, 1 Mbps is 1,000,000 bps, and so forth. Do not include any space between the rate and this unit: 100G is correct, but 100 G is not. If you omit this, the units are bits-per-second (bps).
Default(s)	no bandwidth-limit
Guidelines	Each run of the current shadow-copy rule abides by this bandwidth limit.
Sample	bstnA(gbl-ns-vol-shdwcp[wwmed~/acct~SVrule])# bandwidth-limit 750000 allows the SVrule rule to use up to 750,000 BPS for its file transfers.
Related Commands	shadow-copy-rule

Purpose	File systems that support CIFS also support an alternate name for its files and directories. A file or directory whose name does not fit the old-style 8.3 pattern gets an alternate name from its back-end filer. If a file on the source volume has a primary name that matches another files alternate name, the shadow-copy rule cannot copy the file to the target volume. To enable the rule to safely perform this copy operation, use the cifs-8dot3-resolution command. Use no cifs-8dot3-resolution to return to the default; this is not recommended.
Modes	gbl-ns-vol-shdwcp
Security Level	storage-engineer or crypto-officer
Syntax	cifs-8dot3-resolution no cifs-8dot3-resolution
Default(s)	no cifs-8dot3-resolution
Guidelines	The no form of this command implies that it is impossible for a client to create an 8.3 name that matches the alternate name of a different file. While this event is rare, it is possible at any site that supports CIFS. We recommend enabling this feature for all shadow-copy rules in all CIFS-supporting volumes.
Sample	bstnA(gbl-ns-vol-shdwcp[insur~/claims~insurSV])# cifs-8dot3-resolution sets the insurSV rule to support copies of 8.3 names.
Related Commands	shadow-copy-rule

Purpose	The shadow-copy database is critical for the maintenance of the shadow volume, so the shadow-copy rule should never run out of space for it. You can place this database on the shadow volumes metadata share or on its storage shares. The metadata share is the recommended location for this critical database. For rare situations when a shadow volumes storage shares have more space than its metadata share, you can use the database-location volume command to place the shadow volumes database on its storage shares. Use database-location metadata-share to place the shadow-copy database onto the metadata share, as generally recommended.
Modes	gbl-ns-vol-shdwcp
Security Role(s)	storage-engineer or crypto-officer
Syntax	database-location volume database-location metadata-share
Default(s)	database-location metadata-share
Guidelines	You must rebuild the shadow volume (with nsck ... rebuild) before you can use the database-location volume command. This is not required for moving the database to the recommended metadata share. If the shadow-copy rule runs out of disk space for its database, the database may be corrupted or the rule could hang indefinitely. A corrupted database causes a full scan of the source volume. The re-scan occurs on the next run of the rule, and it is time-consuming if the source volume is large. We recommend storing this on the metadata share for the volume. The volumes storage shares can expand unpredictably, according to the changing habits of the source volumes clients, and may unexpectedly run low on space. Volume metadata is generally smaller and grows at a regular pace. Furthermore, the ARX carefully monitors the disk space on a metadata share, issuing SNMP traps whenever space runs low.
Sample	bstnA(gbl-ns-vol-shdwcp[wwmed~/acct~SVrule])# database-location metadata-share places the shadow-copy database for SVrule onto its target volumes metadata share.
Related Commands	shadow-copy-rule

Purpose	When a source file changes, a shadow-copy rule transfers only the files changed portion (delta) to the shadow volume. Files that are considered too small are transferred in their entirety. Use delta-threshold to set the minimum file size to trigger a delta transfer, so that a file is always copied whole if it is smaller than the threshold. Use no delta-threshold to revert to the default delta threshold.
Modes	gbl-ns-vol-shdwcp
Security Role(s)	storage-engineer or crypto-officer
Syntax	delta-threshold file-size[k|M|G|T] no delta-threshold   file-size (1-18,446,744,073,709,551,615) is the minimum size of a file that is eligible for delta transfers. k|M|G|T (optional) specifies units; k for KiloBytes (1024 bytes), M for MegaBytes (1024*1024 bytes), G for GigaBytes (1024*1024*1024), and T for TeraBytes (1024*1024*1024*1024). Do not put any space between the number and this unit (for example, 100k is valid but 100 k is not). The default is bytes.
Default(s)	100M
Guidelines	A delta-transfer uses lower bandwidth than a full transfer, but requires more computation time on both the source volume and the shadow volume. This threshold saves the computation time for small files, which would not require a great deal of bandwidth if the rule always transfers the whole file. This is intended for networks with higher bandwidth, or for installations where the source and shadow volumes are on the same switch.
Samples	bstnA(gbl-ns-vol-shdwcp[wwmed~/acct~SVrule])# delta-transfer 1G allows delta transfers only for files larger than 1 GigaByte.   bstnA(gbl-ns-vol-shdwcp[archives~/etc~shdw])# no delta-transfer returns to the default threshold.
Related Commands	shadow-copy-rule

Purpose	Use the enable command to enable the current shadow-copy rule. Use no enable to disable the rule.
Modes	gbl-ns-vol-shdwcp
Security Role(s)	storage-engineer or crypto-officer
Syntax	enable no enable
Default(s)	no enable
Guidelines	You must enable the shadow-copy rule for the policy engine to use it. Once enabled, the shadow-copy rule follows its assigned schedule and copies its fileset from the source volume to the shadow volume.
Samples	bstnA(gbl-ns-vol-shdwcp[archives~/etc~shdw])# enable enables the shdw rule.   prtlndA(gbl-ns-vol-shdwcp[nemed~/acct~SV2])# no enable disables the SV2 shadow-copy rule.
Related Commands	shadow-copy-rule

Purpose	Use the from fileset command to select the source fileset for the current shadow-copy rule. The shadow-copy rule periodically copies the fileset from the source volume to the shadow volume.
Mode	gbl-ns-vol-shdwcp
Security Role(s)	storage-engineer or crypto-officer
Syntax	from fileset fileset-name [match {files | all}]   fileset-name (1-1024 characters) identifies the fileset. match {files | all} (optional) determines whether the fileset matches files only or files and directories.
Default(s)	match - files only (and the directories that contain the matching files)
Guidelines	You can use a single fileset as your source. All files in this fileset will be copied to the shadow volume, which you configure with the target (gbl-ns-vol-shdwcp) command. If a single fileset is too restrictive, use the union-fileset command to join multiple filesets into one. The policy-cifs-attributes-fileset is not compatible with shadow-copy rules. This command returns an error if you use a policy-cifs-attributes-fileset or a container fileset that includes one. (Container filesets are intersection-filesets and union-filesets).
Sample	The following example selects the worthSaving source fileset for the shadow-copy rule, SVrule:
prtlndA(gbl-ns-vol-shdwcp[wwmed~/acct~SVrule])# from fileset worthSaving
Related Commands	shadow-copy-rule target (gbl-ns-vol-shdwcp)

Purpose	A shadow-copy rule keeps track of all source-volume directories where at least one change occurred. Each time the shadow-copy rule runs, it only examines and copies from the set of changed directories. Use no inline-notify to stop tracking source-volume changes, thus forcing a full tree-walk of the source volume for every shadow-copy run. Use the inline-notify command track all source-volume changes.
Modes	gbl-ns-vol-shdwcp
Security Role(s)	storage-engineer or crypto-officer
Syntax	no inline-notify inline-notify
Default(s)	inline-notify
Guidelines	The default improves performance by keeping track of changed directories since the previous shadow copy. The policy engine performs a tree-walk (a complete scan) of the directories that changed, not wasting any cycles on directories that remained the same. You should only turn off inline notifications on advice from F5 Support.
Sample	bstnA(gbl-ns-vol-shdwcp[ns3~/vol~betaSV])# no inline-notify disables inline notification for betaSV.
Related Commands	shadow-copy-rule

Purpose	By default, the first run of a shadow-copy rule ends by pruning all extraneous files and directories from the shadow volume. These are files and/or directories that were imported into the shadow volume but that have no counterparts in the source volume. The rule prunes these files and directories to ensure that the source and shadow are identical from the start. If the two volumes are already known to be identical, you can use no prune-target to avoid the unnecessary pruning phase. Use the prune-target command to enable initial target pruning on the shadow (target) volume.
Modes	gbl-ns-vol-shdwcp
Security Level	storage-engineer or crypto-officer
Syntax	no prune-target prune-target
Default(s)	prune-target
Guidelines	The prune-target command allows enabling or disabling of initial pruning on the target volume. Even if the source and target volumes are identical, millions of files can consume time as the rule compares the two directory trees. The no form of this command is useful when performance is an issue. This command has no effect on the rules ability to synchronize deletions. If a client deletes a file or directory on the source volume, the shadow-copy rule always deletes its counterpart on the shadow volume. This command only affects files and directories that are unique to the shadow volume.
Sample	bstnA(gbl-ns-vol-shdwcp[wwmed~/acct~SVrule])# no prune-target disables pruning of shadow volume target volumes for the SVrule rule.
Related Commands	shadow-copy-rule

Purpose	A shadow-copy rule copies each file individually, publishing the file in the client-visible directory tree immediately after a successful transfer to a staging area. Some applications require all files to successfully transfer as a group. Use publish group to publish all of the files as a single group, after all files transfer without errors. Use publish individual, to return to the default: publish each file after a successful transfer.
Modes	gbl-ns-vol-shdwcp
Security Role(s)	storage-engineer or crypto-officer
Syntax	publish {group | individual}   group | individual is a required choice: group publishes all files as a group, after they have all successfully transferred to the shadow volumes staging area. individual publishes each file individually, as it is transferred.
Default(s)	publish individual
Guidelines	The group publishing phase is designed for applications that require all shadow files to be present and consistent, such as a CAD project. If any part of the file-transfer fails, none of the changed files are published. The publish individual method is intended for shadow volumes where file consistency is less important. For example, an installation with /home directories may prefer to have all the latest files as soon as possible, not allowing one failed transfer to prevent the publication of thousands of other files. Some CIFS applications block all access to a file when the file is open, making it impossible for the shadow volume to copy the file. To prevent open CIFS files from stopping the entire transfer, use publish individual.
Samples	bstnA(gbl-ns-vol-shdwcp[wwmed~/acct~SVrule])# publish group reinstates the group-publishing phase for SVrule.   prtlndA(gbl-ns-vol-shdwcp[nemed~/acct~SV2])# publish individual removes the group-publishing phase; each file is published directly after a successful transfer.
Related Commands	shadow-copy-rule

Purpose	Use this command to enable progress reports for the current shadow-copy rule. Use no report to prevent progress reports.
Mode	gbl-ns-vol-shdwcp
Security Role(s)	storage-engineer or crypto-officer
Syntax	report file-prefix [verbose] [list-identical] [delete-empty] no report   file-prefix (1-1024 characters) sets a prefix for all shadow-copy reports. Each report has a unique name in the following format: prefixYearMonthDayHourMinute.rpt For example, home_backup200403031200.rpt could be the name for one report with the home_backup prefix. verbose (optional) enables verbose data in the reports. list-identical (optional) includes all files that are identical on both the source and shadow volumes. These files are not copied, so they are unlisted by default. delete-empty (optional) causes the rule to delete any reports that contain no data. Empty reports are created when the source fileset did not change since the previous shadow copy.
Default(s)	no report
Guidelines	Every time the shadow-copy rule fires and duplicates the source fileset, the rule can generate a report to show the details of the copy session. The reporting feature is disabled by default; we recommend that you enable reporting for all shadow-copy rules, to keep a log of all shadow-copy sessions. Use show reports for a list of reports, or show reports file-name to show the contents of one report.
Samples	prtlndA(gbl-ns-vol-shdwcp[wwmed~/acct~SVrule])# report SVetc enables reports for the shadow-copy rule, SVrule. For a sample report, see Figure 29.1.   bstnA(gbl-ns-vol-shdwcp[archives~/etc~shdw])# report etc verbose list-identical enables verbose reports for the shadow-copy rule, shdw. The reports also include any files that were found to be identical on both the source and shadow volumes.   bstnA(gbl-ns-vol-shdwcp[ns3~/usr~cdn])# no report disables reports for the cdn rule.
Related Commands	shadow-copy-rule

Purpose	If a shadow-copy rule fails to transfer any files to the shadow volume, the rule makes multiple attempts to transfer the failed files. This retry mechanism can help a shadow-copy operation to succeed during a transient network failure, or during a failover at the target-volume site. Use the retry attempts command to set the retry limit for this rule.
Modes	gbl-ns-vol-shdwcp
Security Role(s)	storage-engineer or crypto-officer
Syntax	retry attempts count   count (0-2,147,483,647) is the total number of retries for a failed shadow copy before waiting for the next rule run.
Default(s)	5
Guidelines	The shadow-copy rule keeps a list of all directories with failed files as it runs. After the run is complete, the rule checks the list and retries any directories that are in it. The rule repeats this process as often as you dictate with this command. If there are still failed transfers after the final retry attempt, the rule declares the run a failure. The retry delay command sets the delay between these retry attempts. You can use these commands to compensate for transient network issues between your source and target sites. Each retry attempt creates a separate shadow-copy report. The report shows the results of the retry operation. (Use the report (gbl-ns-vol-shdwcp) command to make the shadow-copy rule generate reports.)
Sample	bstnA(gbl-ns-vol-shdwcp[insur~/claims~insurSV])# retry attempts 10 sets the shadow-copy rule, SVrule, to retry up to 10 times if it encounters any file-transfer failures.
Related Commands	shadow-copy-rule retry delay

Purpose	When a shadow-copy run fails to transfer one or more of its files, the rule pauses for a period of time before retrying the failed file(s). You can use the retry delay command to set the length of this pause.
Modes	gbl-ns-vol-shdwcp
Security Role(s)	storage-engineer or crypto-officer
Syntax	retry delay seconds   seconds (60-7200) is the number of seconds between retries.
Default(s)	300 (seconds)
Guidelines	The retry attempts command sets the number of retry attempts. Use these commands to compensate for transient network issues between your source and target sites. After the connection is re-established, the rule resumes at the last-completed directory.
Sample	bstnA(gbl-ns-vol-shdwcp[insur~/claims~insurSV])# retry delay 120 causes the shadow-copy rule, insurSV, to pause for two minutes (120 seconds) between each retry attempt.
Related Commands	shadow-copy-rule retry attempts

Purpose	Use this schedule command to assign a schedule to the current shadow-copy rule. Use no schedule to remove the rules schedule.
Mode	gbl-ns-vol-shdwcp
Security Role(s)	storage-engineer or crypto-officer
Syntax	schedule name no schedule   name (1-64 characters) identifies the schedule. Use show schedule for a list of configured schedules.
Default(s)	None.
Guidelines	A shadow-copy rule copies its fileset from the source volume to the shadow volume; each shadow-copy session occurs on a schedule. This command determines which schedule to use. To create a schedule, use the gbl-mode schedule command. You cannot use a schedule with a fixed duration; a shadow-copy rule must always run to completion in order to succeed.
Sample	prtlndA(gbl-ns-vol-shdwcp[wwmed~/acct~SVrule])# schedule hourly assigns the hourly schedule to the shadow-copy rule, SVrule.
Related Commands	shadow-copy-rule schedule show schedule

Purpose	Use the shadow command to transform a standard volume into a read-only shadow volume. A shadow volume is a target for a shadow-copy. Use no shadow to make the volume ineligible as a shadow-copy target, and to make it writable.
Mode	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	shadow no shadow
Default(s)	no shadow
Guidelines	The volume must be disabled (no enable (gbl-ns, gbl-ns-vol)) before you can use either shadow or no shadow. A Shadow volume is typically created on a different switch from its source volume(s). To add a volume at a different switch, log into the CLI at that switch and add the volume from there. A shadow volume does not keep its imported files; it uses its shares as repositories for the shadowed fileset(s). Therefore, the shadow volume deletes all extraneous files on its shares as soon as the shadow-copy rule first runs. The CLI prompts for confirmation before allowing this; to create the shadow volume, answer yes at the prompt. The no shadow command issues a similar warning, indicating that shadow copies in progress are aborted if you continue. This means removal of some interim files and databases, possibly affecting the shadow volume. The source volume is unaffected. Again, answer yes to continue. Clients can only have read access to the shadow volume. (Writes would corrupt the shadow copy.)
Guidelines: Configuration Rules	A volume cannot be used as a shadow volume if it contains any imported NetApp share with multiple qtrees. This is not an issue if each NetApp share is a single qtree, or if none of the NetApp shares contain any qtrees. The shadow-copy-rule must write to the volumes metadata when it copies files; use modify to allow this. Choose a shadow volume with at least as much disk capacity as its source volume(s), or some shadow-copy operations may fail. A direct volume (also known as a presentation volume) cannot be used as a shadow volume. CIFS subshares are not supported on the filers behind a shadow volume. Some filers do not allow the shadow-copy rule to delete a directory under a subshare, and this is necessary if the same directory was deleted at the source volume. For more information on CIFS subshares and how a managed volume supports them, see the documentation for the filer-subshares command. A shadow volume must support all of the protocols for its source volume(s). For example, an NFSv3 and CIFS volume can be a shadow for another volume with both of those protocols, or for a CIFS-only volume, or for an NFSv3 volume. It cannot be the target for an NFSv2 volume.
Samples	prtlndA(gbl-ns-vol[archives~/cdn])# shadow   This will cause all the shares in the volume to be erased.   Are you sure you want to remove all data? [yes/no] yes changes the /cdn volume into a shadow volume.   prtlndA(gbl-ns-vol[nemed~/testvol])# no enable prtlndA(gbl-ns-vol[nemed~/testvol])# no shadow   This will cause any un-published files and shadow databases to be erased.   Are you sure you want to proceed? [yes/no] yes reverts the /testvol volume back to a managed volume.
Related Commands	namespace -> volume no enable (gbl-ns, gbl-ns-vol) modify

Purpose	Use the shadow-copy-rule command to instantiate a shadow-copy rule in the current volume. A shadow-copy rule regularly copies a fileset from the current volume to a read-only shadow volume. Use the no form of the command to delete the rule.
Modes	gbl-ns-vol
Security Role(s)	storage-engineer or crypto-officer
Syntax	shadow-copy-rule name no shadow-copy-rule name   name (1-1024 characters) is the name you choose for the rule.
Default(s)	None
Guidelines	When you first create a shadow-copy rule, a prompt asks for confirmation; enter yes to continue. This command puts you into gbl-ns-vol-shdwcp mode, where you have various configuration commands for configuring the shadow-copy rule. Use the from fileset (gbl-ns-vol-shdwcp) command to select a fileset to copy. Use the target (gbl-ns-vol-shdwcp) command to choose a shadow volume as a destination for the file copies. The shadow volume must reside in the current RON; use show ron for a list of ARXes in the current RON. The schedule (gbl-ns-vol-shdwcp) command determines the schedule for making the shadow copies. Use the enable (gbl-ns-vol-shdwcp) command to start the rule. If there are any network disconnects during a rule run, the rule pauses and retries to establish the connection. You can use the retry attempts and retry delay commands to manipulate the number of attempts and the length of time between them. If a CIFS client has a file open on the source volume, the client must have opened the file with shared read access for the file to be shadow copied. Otherwise, the shadow copy fails for the current run of the rule. No application (including the shadow-copy rule) can open a file that is already opened, unless the first application opened with shared read access. A volume cannot support a shadow-copy rule if it contains any imported NetApp share with multiple qtrees. This is not an issue if each NetApp share is a single qtree, or if none of the NetApp shares contain any qtrees.
Guidelines: CIFS Options (Local Groups and 8.3 Names)	If the filers behind the source volume use any Windows Local Groups or Local users, you may want to translate CIFS Security IDs (SIDs) between the source and shadow volumes. The sid-translation (gbl-ns-vol-shdwcp) command tells the rule to translate SIDs. This only applies to source/shadow volumes that support CIFS. File systems that support CIFS also support an alternate name for any file or directory with a long file or directory name. The alternate-name support is for older Windows applications that only support 8.3 names. An 8.3 name is one with up to 8 characters and an optional extension with up to 3 characters. If a source-volume file has a primary name that matches a target-volume files alternate name, the source-volume file could overwrite the target-volume file. This causes the shadow copy to fail for the given file or directory, unless you set cifs-8dot3-resolution for this rule. This is a recommended setting.
Guidelines: Options	The gbl-ns-vol-shdwcp mode contains some additional, optional commands: The report (gbl-ns-vol-shdwcp) command enables the shadow-copy rule to generate a report every time a shadow copy occurs. Reports are recommended, to keep a running log of all shadow copies. The optional delta-threshold command changes the minimum size of a file to be delta-transferred (as opposed to entirely transferred) to the shadow volume. You can use the publish group command to back out any shadow copy where any of its files fails to transfer properly. The optional bandwidth-limit command sets a limit on the amount of bandwidth used when the rule runs. After the initial run of the rule, it goes through a pruning phase to find extra files and directories at the target and remove them. If you are sure that the target has no extra files or directories, you can use the no prune-target command to avoid this extra processing.
Guidelines: Shadow-Volume Targets	To create a shadow volume, use the gbl-ns-vol shadow command at the target switch. This command changes a standard volume into a shadow volume. To copy a source volume to multiple shadow-volume targets, configure one shadow-copy-rule for each target.
Guidelines: Schedule	To create a schedule to be applied to the shadow-copy rule, use the gbl schedule command at the source switch. The rule fires as dictated by its schedule: if the schedule has a start time that is earlier than now, the first shadow copy begins as soon as you enable the rule. If you make a configuration change when the rule is running on a schedule, the configuration change is ineffective until the next time the rule runs. This includes changes to the rules behavior between scheduled runs, such as a change to inline-notify behavior. You can make the change take effect immediately by using no enable (gbl-ns-vol-shdwcp) followed by enable on the rule.
Guidelines: Reports	As mentioned above, we recommend that you use the shadow-copy report feature to keep a detailed log of all shadow copies. The reports appear on the source switch: the show reports command shows all reports on the switch, including shadow-copy reports. You can use the standard file-management commands with these reports: delete, rename, show reports file-name, tail, and/or grep.
Sample	prtlndA(gbl-ns-vol[wwmed~/acct])# shadow-copy-rule SVrule This will create a new policy object.   Create object 'SVrule'? [yes/no] yes prtlndA(gbl-ns-vol-shdwcp[wwmed~/acct~SVrule])# instantiates a new shadow-copy rule, SVrule, for the current volume.
Related Commands	from fileset (gbl-ns-vol-shdwcp) target (gbl-ns-vol-shdwcp) retry attempts retry delay schedule (gbl-ns-vol-shdwcp) report (gbl-ns-vol-shdwcp) sid-translation (gbl-ns-vol-shdwcp) delta-threshold publish bandwidth-limit prune-target inline-notify enable (gbl-ns-vol-shdwcp) schedule show reports

Purpose	Use the show shadow command to see the current status of one or more shadow-copy rules.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show shadow show shadow namespace show shadow namespace vol-path show shadow namespace vol-path rule-name   namespace (1-30 characters) identifies the namespace with the source volume. vol-path (1-1024 characters) focuses on one source volume in the namespace. rule-name (1-1024 characters) focuses on one rule.
Guidelines	Each rule starts with the following fields, for identification: Namespace Source Volume Shadow Rule Report File, where the prefix is chosen by the report (gbl-ns-vol-shdwcp) command. Fileset, which is chosen by the from fileset (gbl-ns-vol-shdwcp) command. Delta Threshold shows the minimum size for a file to qualify for delta-transfers. A delta transfer is a copy of only the changed portions of a file. This is set with the delta-threshold command. Publishing Mode indicates whether or not all of the files are published together as a group if (and only if) all of them are successfully transferred. This can be group or individual, as set by the publish command. CIFS SID Translation is Fail on Errors, Ignore Errors, or Disabled. If either of the first two options, the shadow-copy rule translates CIFS Security IDs (SIDs) from source-volume filers to their equivalent SIDs at the shadow-volume filers. This enables local-group support at both filers. Fail on Errors indicates that the rule refuses to copy any file or directory where the SID translation fails. You control this with the sid-translation (gbl-ns-vol-shdwcp) command. Shared Access Allowed indicates that the shadow-copy rule allows other applications to write to a file during the copy operation. This makes it possible for the rule to copy an open file. Inline Notifications appears if the shadow-copy rule monitors the source volume for inline changes. An inline change is one that occurs due to a client operation, such as a file rename. If the rule tracks these changes, it can avoid a full scan of the source volume the next time the rule runs. Use the inline-notify command to set this. Prune Target only appears if the rule prunes empty directories from the target volume after a successful shadow copy. Use the prune-target command to determine this.
Guidelines (Cont.)	Bandwidth Limit only appears if it was set with the bandwidth-limit command. Retry Attempts shows the number of retries the rule makes if a shadow-copy run is interrupted by a network disconnect. This only applies to a rule with a target volume on another ARX. Use the retry attempts command to change this number. Retry Delay shows the number of seconds between retry attempts. Use the retry delay command to change this time. Database Location is either metadata-share or volume. This indicates where the shadow-copy rule keeps its database. A setting of metadata-share is recommended. Use the database-location command to change this setting. CIFS 8dot3 Resolution appears if the rule can copy files with 8.3 names that collide with other files at the shadow volume. This is recommended for all shadow-copy rules in volumes that support CIFS. Use the cifs-8dot3-resolution command to set this. These are followed by three fields to show the latest run time and status for the rule: Processing Started states the date and time. Processing Completed only appears when the shadow copy has concluded. Elapsed Time is stated in hours, minutes, seconds. The next several fields describe the shadow-copy run at a high level: Operating Mode is Full tree walk (examine the full source-volume tree with every shadow-copy session) or Inline notification (keep track of directories that change between shadow copies, and only examine the changed directories on the next shadow copy). Use the inline-notify command to change the mode.
	Tree Walk Reason is present if the shadow volume rule is performing a full tree walk of the source volume (instead of using inline notification of changes) and indicates why the tree walk is being performed. Possible reasons include: Initial run means that it is the first run of the rule, so a tree walk is necessary. Initial run (resumed) is caused by the ARX rebooting before the first tree-walk completes. Rule started indicates the rule was disabled and then re-enabled. Rule modified indicates the rule parameters changed. Publishing database rebuild is caused by an nsck ... rebuild of the source or target volume requiring the targets publishing database to be rebuilt. Inline notification overflow occurs if a large number of notification events were generated and the database used to store these events overflowed. Previous run failed indicates the previous run of the rule encountered an error. Inline notification disabled indicates that someone used no inline-notify to disable inline notification. Source Status appears if there is a problem with the source volume. The problem is summarized here. Current Phase shows the phase of the current shadow-copy run. See Guidelines: Shadow-Copy Phases for a list of all possible settings in this field.
Guidelines (Cont.)	Target Information lists the target for the current shadow-copy rule. This shows the status of the most-recent (or current) shadow copy to the target volume. See Guidelines: Target Status for a list of all possible status settings. Copy Phase Information shows details about the copy phase. This is when the rule copies all files from the source volume to the shadow volume. If publish group is in effect, all files must copy successfully before going into Publishing phase, below. Publishing Phase Information shows the files that have moved to the final locations. If publish group is in effect, this phase does not start until the Copy Phase ends. If the rule is set to publish individual, this table updates in tandem with the Copy Phase table. Pruning Phase Information appears only for the first run of the shadow-copy rule, if at all. In this phase, the shadow volume scans its directory tree and prunes away all files and directories that are not on the source volume, too. For cases where the source and shadow volumes are known to be identical from the outset, you can disable this phase with no prune-target. Cleaning Phase Information also appears very rarely. This means removing empty directories and files that the shadow-copy rule created in the staging area. This is only necessary in a limited number of cases.
Guidelines: Shadow-Copy Phases	Current Phase goes through the following settings, in order: Inactive - The rule is enabled, but has not yet run. Initializing - The rule is starting. Connecting - The source switch is connecting to the target switch. Opening Database - The rule is opening a database at the target switch. Reindexing Database only occurs rarely, after a software upgrade or a failure at the target site. The rule is writing an index file for fast access to the target database. Copying then Publishing, or Copying/Publishing - The Copying phase is when the rule copies files from the source volume to a staging area on the shadow volume. All files must copy successfully before the rule enters its Publishing phase. During the Publishing phase, the rule moves the files from the staging area to their final locations. These two phases occur when publish group is in effect. If publish is set to individual, this phase is Copying/Publishing; each file is copied to the staging area and then immediately moved to its final location. Pruning appears only for the first run of the shadow-copy rule, if at all. In this phase, the shadow volume scans its directory tree and prunes away all files and directories that are not on the source volume, too. For cases where the source and shadow volumes are known to be identical from the outset, you can disable this phase with the no prune-target command. Cleaning also appears very rarely. This means removing empty directories and files from a staging area behind the target volume. This is only necessary in a limited number of cases. Closing Database is the final step before a completed run. Completed - The operation is finished. Success or failure is indicated under Target Information, below. Some phases may go by too quickly for you to ever see them on this screen. If the phase is Unknown, there may be a system anomaly. Disabled appears if the shadow-copy rule is disabled.
Guidelines: Target Status	The Target Information field shows the status of the most-recent (or current) shadow copy to the target volume: Successful indicates that the shadow-copy run finished and completely succeeded. Error(s) detected means that some problem occurred. Details appear in the shadow-copy report for the run. The show reports command shows all reports on the switch, including shadow-copy reports. Unable to establish connection indicates that the remote switch is unreachable through the Resilient Overlay Network (RON). Use show ron to view the status of your RON connections. Error(s) detected, Connection failed shows that the RON connection with the remote switch was lost after the shadow-copy run started. As above, use show ron to view the status of your RON connections. Target volume is offline indicates a problem at the remote ARX. Use show namespace at the remote ARX to find the status of the shadow volume. Target is not a shadow volume means that the shadow-copy rule has the wrong target (gbl-ns-vol-shdwcp), or that the target volume itself is not configured as a shadow volume. To convert a managed volume to a shadow volume, use the shadow command. Target volume is no modify shows that the shadow volume has the no modify setting. This prevents the shadow-copy rule from writing to the shadow volume. At the target switch, you can use the modify command in the shadow volume to allow write access. Target volume has insufficient space indicates that the file servers behind the shadow volume do not have enough space to hold a replica of the source volume. Consider using a larger share behind the shadow volume, or adding additional shares. Target host does not exist, Target namespace does not exist, and Target volume does not exist all indicate a bad target in the shadow-copy rule. Use the target (gbl-ns-vol-shdwcp) command to change the shadow-volume target. Target volume is unavailable indicates a problem at the remote ARX. Use show namespace at the remote ARX to find the status of the shadow volume. Target host is not reachable indicates that the remote switch is unreachable through the network. Use the ping command and/or expect traceroute to check the connection to the remote ARX. Target version not supported means that the software release on the target ARX is incompatible with the release on the source ARX. From either CLI, use show version to see the currently-running release of software. You can install new software through the CLI; refer to the ARX CLI Maintenance Guide for software-upgrade instructions.
Sample	bstnA# show shadow wwmed shows the status of all shadow copies from the wwmed namespace. See Figure 29.2 on page 29-28 for sample output.
Related Commands	shadow

Purpose	Behind either the source or the shadow volume, one of the back-end CIFS filers may be configured for Local Groups. These filers use local Security IDs (SIDs) for their group names instead of those issued by a Domain Controller (DC). You can configure a shadow-copy rule to translate all local SIDs to their corresponding names at the source filer, then translate the names back to SIDs at the target filer. This preserves local-group privileges, so that members of a local group at the source filer can access copies of their files and directories at the shadow volume. Use the sid-translation command to enable SID translation for the current rule. Use no sid-translation to disable SID translation for this shadow-copy rule.
Mode	gbl-ns-vol-shdwcp
Security Role(s)	storage-engineer or crypto-officer
Syntax	sid-translation [fail-on-errors] no sid-translation   fail-on-errors (optional) causes the rule to abort any file or directory copy where the SID translation fails. Translation failures can occur if a local group on the source filer does not exist on the target filer. For SID translation to reliably succeed, all local groups on the source volumes filers must be duplicated on the shadow volumes filers. If SID translation fails and you omitted this option, the rule copies the SID to the shadow volume without translating it; the Access-Control Entry (ACE) is therefore unusable while on the shadow volume, though it will be usable if someone later copies the file back to the source volume.
Default(s)	no sid-translation
Guidelines	This command does not apply to a rule in an NFS-only namespace. While SID translation is enabled, the rule translates each SID to a group name (at the source volume), then translates the group name back to a SID (at the target volume). This ensures that the final SID is one that is properly configured at the shadow volume. SID translations are only needed if any filers behind the source volume have local groups defined, and CIFS clients in those local groups require read access to the files at the shadow volume. Before you enable SID translations, all filers behind both volumes should support all of each others local-group names. These are the filers behind the source volume and the shadow volume. If a file tagged with local-group name, staff, is copied to remote filer without any definition for a staff group, the shadow-copy rule copies the SID for staff verbatim; this SID will be unusable at the destination filer. To avoid these translation failures, duplicate all local group names and user names on all of the filers behind both volumes. The gbl-ns-vol-shr ignore-sid-errors command is designed for filers that return an error for an unknown SID but accept the file or directory anyway. If this is set for a share in the shadow volume, the shadow-copy rule ignores SID errors from that filer, even if you used fail-on-errors in the sid-translation command. If the source and shadow volume are in two different Windows domains, your site may require additional preparation. Contact F5 Support if you want to configure SID translation for an inter-domain shadow-copy rule. Use the gbl-ns-vol-shr sid-translation command to perform SID translations for file migrations within the volume.
Sample	bstnA(gbl-ns-vol-shdwcp[wwmed~/acct~SVrule])# sid-translation enables SID translation for the rule named SVrule.
Related Commands	shadow-copy-rule ignore-sid-errors sid-translation

Purpose	Use the target command to choose a shadow-volume target for the current shadow-copy rule. A shadow-copy rule copies a fileset from the current volume to a shadow volume.
Mode	gbl-ns-vol-shdwcp
Security Role(s)	storage-engineer or crypto-officer
Syntax	target [hostname host [namespace name]] volume shadow [path sub-path]   hostname host (optional, 1-32 characters) identifies the host for the shadow volume. The shadow volume must reside on the current switch or another ARX in the same RON. Use the show ron command to view all hosts in the RON. namespace name (optional, 1-30 characters) identifies the shadow volumes namespace. shadow (1-256 characters) identifies the shadow volume itself. path sub-path (optional, 1-1024 characters) selects a subdirectory in the shadow volume.
Default(s)	host - the local switch name - the current namespace
Guidelines	This command sets a storage target for the current shadow-copy rule. A target volume must be configured as a shadow volume; use the gbl-ns-vol shadow command to change a standard volume into a read-only shadow volume. To use another switch as the host for the shadow volume, log into the CLI on that switch and add the volume from there. To consolidate multiple shadow copies into a single volume, use the optional path argument. Multiple volumes can use the same shadow volume as a target, where each source volume is copied to a unique path. For example, the /etc volume can have a target volume and path of /shadow/etc while the /var volume has a target and path of /shadow/var. Both source volumes are thereby copied to the /shadow volume. This simplifies backups for the two volumes. If you use paths, do not overlap them. For example, you cannot use a target of /shadow/var for one source volume in addition to /shadow/var/log for another. A target volume must support all of the protocols for its source volume(s). For example, an NFSv3 and CIFS volume can be a shadow target for another volume with both of those protocols, or for a CIFS-only volume, or for an NFSv3 volume. It cannot be the target for an NFSv2 volume. If the volume contains any imported NetApp share with multiple qtrees, it cannot be used as the source or target of a shadow-copy rule. This is not an issue if each NetApp share is a single qtree, or if none of the NetApp shares contain any qtrees.
Samples	bstnA(gbl-ns-vol-shdwcp[wwmed~/acct~SVrule])# target hostname prtlndA namespace nemed volume /acctShadow uses /acctShadow as the target for SVrule. This shadow volume resides on a remote switch, prtlndA, in the same RON.   bstnA(gbl-ns-vol-shdwcp[archives~/usr~buUsers])# target namespace allBackups volume /bu path /usr uses allBackups~/bu/usr as the target for the buUsers rule.   bstnA(gbl-ns-vol-shdwcp[archives~/log~buLogs])# target namespace allBackups volume /bu path /log uses allBackups~/bu/log as the target for the buLogs rule.
Related Commands	shadow-copy-rule shadow