Applies To:

Show Versions Show Versions

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

29 
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.
bandwidth-limit rate[K|M|G|T]
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).
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.
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.
Use database-location metadata-share to place the shadow-copy database onto the metadata share, as generally recommended.
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.
bstnA(gbl-ns-vol-shdwcp[wwmed~/acct~SVrule])# database-location metadata-share
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.
delta-threshold file-size[k|M|G|T]
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.
Use the enable command to enable the current shadow-copy rule.
Use no enable to disable the rule.
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.
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.
match - files only (and the directories that contain the matching files)
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).
Use the inline-notify command track all source-volume changes.
Use the prune-target command to enable initial target pruning on the shadow (target) volume.
The prune-target command allows enabling or disabling of initial pruning on the target volume.
Use publish individual, to return to the default: publish each file after a successful transfer.
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.
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.
Use no report to prevent progress reports.
report file-prefix [verbose] [list-identical] [delete-empty]
file-prefix (1-1024 characters) sets a prefix for all shadow-copy reports. Each report has a unique name in the following format:
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.
Use show reports for a list of reports, or show reports file-name to show the contents of one report.
bstnA(gbl-ns-vol-shdwcp[archives~/etc~shdw])# report etc verbose list-identical
bstnA# show reports SVetc_201002270226.rpt
count (0-2,147,483,647) is the total number of retries for a failed shadow copy before waiting for the next rule run.
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.
seconds (60-7200) is the number of seconds between retries.
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.
Use this schedule command to assign a schedule to the current shadow-copy rule.
Use no schedule to remove the rules schedule.
name (1-64 characters) identifies the schedule. Use show schedule for a list of configured schedules.
You cannot use a schedule with a fixed duration; a shadow-copy rule must always run to completion in order to succeed.
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.
The volume must be disabled (no enable (gbl-ns, gbl-ns-vol)) before you can use either shadow or no shadow.
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.
The shadow-copy-rule must write to the volumes metadata when it copies files; use modify to allow this.
A direct volume (also known as a presentation volume) cannot be used as a shadow volume.
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.
name (1-1024 characters) is the name you choose for the rule.
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.
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.
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.
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 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.
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.
prtlndA(gbl-ns-vol[wwmed~/acct])# shadow-copy-rule SVrule
Use the show shadow command to see the current status of one or more shadow-copy rules.
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.
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.
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.
Processing Completed only appears when the shadow copy has concluded.
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.
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.
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.
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 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.
bstnA# show shadow wwmed
bstnA# show shadow wwmed
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.
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.
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.
Use the gbl-ns-vol-shr sid-translation command to perform SID translations for file migrations within the volume.
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.
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.
host - the local switch
name - the current namespace
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.
bstnA(gbl-ns-vol-shdwcp[wwmed~/acct~SVrule])# target hostname prtlndA namespace nemed volume /acctShadow
bstnA(gbl-ns-vol-shdwcp[archives~/usr~buUsers])# target namespace allBackups volume /bu path /usr
bstnA(gbl-ns-vol-shdwcp[archives~/log~buLogs])# target namespace allBackups volume /bu path /log
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)