Manual Chapter :
Tracking Files on Your Back-End Storage
Applies To:
Show Versions
ARX
- 6.3.0
File tracking is the process of periodically archiving the back-end locations of your files so that you can learn where any file was stored on any given day. Some sites back up and restore their files directly from their back-end filers, behind the ARX and its managed volumes. These sites use a data-protection device, called a backup server in this manual, to coordinate NDMP backups and restores between filers and backup tapes. If a managed volume migrates files since the most-recent backup operation, you may not know the filer where the files were backed up. You can use file tracking to keep records of files as they migrate, and to identify the filer that held any given file at any given time.
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.21
root@192.168.25.21s password: password
nas1*> vol options vol1 nosnapdir off
nas1*> ...
Two or more ARX-snapshot rules with the same schedule perform snapshot grouping, described in Snapshot Grouping. That is, the ARX determines the fewest-possible back-end snapshots that it can take to satisfy all of the concurrent rules. This improves snapshot performance. However, any single back-end snapshot may end up in a larger group, and may have to wait for the EMC serialization described in this section.
To invoke snapshots at the volumes metadata filer, the ARX volume requires administrative privileges at the filers CLI. You enter the proper administrative username and password as a proxy user. If the metadata share is hosted by a NetApp or EMC device, these are UNIX credentials for RSH or SSH logins; they do not require a Windows domain. If the metadata share is hosted by a Windows Server, the volume uses WinRM to access it: in this case, the proxy user must have an FQDN to facilitate Kerberos authentication.
bstnA(gbl)# proxy-user nas_admin
bstnA(gbl-proxy-user[nas_admin])# user root
Password: rootpasswd
Validate Password: rootpasswd
bstnA(gbl)# ...
For details on these proxy-user commands and others, see Adding a Proxy User, on page 3-4 of the ARX® CLI Storage-Management Guide.
The ARX logs into the CLI at the metadata shares filer, and requires parameters for doing so. These parameters include the type of filer (identified by vendor) and assignment of the proxy-user credentials from above. The commands for setting these parameters are described in Preparing the Filer for ARX-Snapshot Support, on page 6-12 of the ARX® CLI Storage-Management Guide.
bstnA(gbl)# external-filer nas1
bstnA(gbl-filer[nas1])# filer-type network-appliance
bstnA(gbl-filer[nas1])# proxy-user nas_admin
bstnA(gbl-filer[nas1])# manage snapshots
For external filers where the ARX tracks files, use the filer-type command and the proxy-user command. It is unnecessary to use the manage snapshots command to support this path-retrieval process:
bstnA(gbl)# external-filer fs2
bstnA(gbl-filer[fs2])# filer-type windows
bstnA(gbl-filer[fs2])# proxy-user cifs_admin
 | For NFS shares, each path includes the back-end-export path used in the gbl-ns-shr filer command. This may be a virtual path on the filer, not an actual part of the physical file system, so you may need to translate it to use it with your backup server. For information on the filer command, see Identifying the Filer and Share, on page 9-34 of the ARX® CLI Storage-Management Guide. |
From gbl mode, use the file-history archive command to start the process of configuring one:
file-history archive name
where name (1-64 characters) is a name you choose for the archive configuration.
The CLI prompts for confirmation before creating a new archive object; enter yes to continue. This puts you into gbl-archive mode, where you choose a filer or managed volume to hold the archive records.
bstnA(gbl)# file-history archive fileRecordsMed
From gbl-archive mode, use the location filer command to choose an external filer where the archive will reside. The following syntax selects an NFS export to store the archive:
ext-filer (1-64 characters) identifies the filer where the archive will reside. This is the external-filer name for the filer; use show external-filer for a complete list of configured filers on the ARX.
nfs3tcp | nfs3 are a required choice. The nfs3tcp option is NFSv3 over TCP, and the nfs3 option is NFSv3 over UDP.
share-name (1-64 characters) is the name of the back-end NFS export where the archive will reside.
path path (optional, 1-1024 characters) chooses a subdirectory to store the archive.
ext-filer (1-64 characters) identifies a CIFS-supporting filer.
cifs is a required keyword.
share-name (1-64 characters) is the name of the back-end CIFS share where the archive will reside.
proxy (1-32 characters) is the name of a proxy-user configuration (see Adding a Proxy User, on page 3-4 of the ARX® CLI Storage-Management Guide). The CLI uses the proxy-user credentials to store archive files on the share-name share. These credentials require read and write permission at the share; they do not require Backup Operator or Administrator privileges. Use show proxy-user for a full list of all proxy users.
path path (optional, 1-1024 characters) chooses a subdirectory to store the archive.
bstnA(gbl)# file-history archive fileRecordsMed
bstnA(gbl-archive[fileRecordsMed])# location filer fs4 cifs arx_file_archv proxy-user acoProxy2
Note: If you export this archive to clients who do not understand its purpose, the clients may inadvertently delete important records. We recommend using an ARX volume or directory that is accessible to management personnel only. Management access may not even be necessary except on rare occasions. For instructions on exporting volume storage to clients, see Sharing a Namespace Volume, on page 11-15 and Exporting a Namespace Volume, on page 11-4 of the ARX® CLI Storage-Management Guide.
Use the location namespace command to store the archive on one of the ARXs volumes. The file-access protocol(s) and the proxy user are part of the namespace configuration, so they are not required in this form of the command:
name (1-30 characters) is a namespace on the current ARX. Use show namespace for a list of all available namespaces. If you choose a multi-protocol (NFS and CIFS) namespace, the archive uses NFS to store its records.
vol-path (1-1024 characters) selects a volume from the above namespace. Type a ? character for a list of the namespaces volumes.
path path (optional, 1-1024 characters) chooses a subdirectory to store the archive.
bstnA(gbl)# file-history archive testFA
bstnA(gbl-archive[testFA])# location namespace wwmed volume /acct path /fileArchs
/yyyy
/mm
/dd
/namespace-name
/volume-name
/namespace-name
/volume-name
/dd
/mm
/yyyy
This structure starts at the path given by the location command, described above. If there is no path, this starts in the root of the ARX volume or filer share.
As time goes on, a location filer may run low on disk space. For this situation, you can move the location to a larger filer or to a managed volume. You begin by using the no location command, which stops the ARX from writing to the current archive location:
Then manually copy or move the acopia_file_history folder to the destination filer or volume. To complete the migration, run the location command with the new filer or volume location.
bstnA(gbl)# file-history archive FHinsur
bstnA(gbl-archive[FHinsur])# no location
bstnA(gbl)# file-history archive FHinsur
bstnA(gbl-archive[FHinsur])# location namespace medarcv volume /fhStore
You can add a description to the archive for use in some of the show commands described below. The description can differentiate the archive from others. From gbl-archive mode, use the description command to add a description string:
description text
where text is 1-255 characters. Quote the text if it contains any spaces.
bstnA(gbl)# file-history archive fileRecordsMed
bstnA(gbl-archive[fileRecordsMed])# description archive share for ARX file histories
From gbl-archive mode, use no description to remove the description string from the current file-history archive:
bstnA(gbl)# file-history archive testFA
bstnA(gbl-archive[testFA])# no description
Use the show file-history archive command to display a list of all the archives on the current ARX. You can enter this command from any CLI mode:
bstnA(gbl)# show file-history archive
bstnA(gbl)# ...
where name (1-64 characters) identifies the desired archive.
bstnA(gbl)# show file-history archive fileRecordsMed
bstnA(gbl)# ...
Use the show global-config archive command to show the full configuration for all archives on the ARX:
bstnA(gbl)# show global-config archive
bstnA(gbl)# ...
where name (1-64 characters) identifies the archive to display.
If no volumes currently use this archive, you can remove it from the ARX. From gbl mode, use the no file-history archive command to remove an archive from the ARX configuration:
where name (1-64 characters) identifies the archive to remove.
bstnA(gbl)# no file-history archive testFA
bstnA(gbl)# ...
The next step in keeping your file history is to create snapshots of your volumes metadata and configuration, and to store those snapshots in your file-history archive. You can set up a snapshot rule to take these types of snapshots on a regular basis. An earlier chapter explained the CLI commands for configuring snapshots; recall Appendix 2, Configuring Volume Snapshots. This section explains the CLI commands for setting up a snapshot rule for file tracking.
bstnA(gbl)# namespace medarcv volume /rcrds
bstnA(gbl-ns-vol[medarcv~/rcrds])# snapshot rule rcrdsArchive
From gbl-ns-vol-snap mode, use the archive command to select a file-history archive for the current snapshot rule:
archive name
where name (1-64 characters) selects an existing archive.
bstnA(gbl)# namespace medarcv volume /rcrds
bstnA(gbl-ns-vol[medarcv~/rcrds])# snapshot rule rcrdsArchive
bstnA(gbl-ns-vol-snap[medarcv~/rcrds~rcrdsArchive])# archive fileRecordsMed
You can disconnect the current snapshot rule from its file-history archive with the no archive command. This prevents future snapshots from tracking any file history. This is the default for a typical snapshot rule, one configured only for client-data snapshots.
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# snapshot rule hourlySnap
From gbl-ns-vol-snap mode, use the contents command to determine the contents of this rules snapshots:
user-data selects client-viewable files and directories. This is the default for a snapshot rule.
volume-config selects the current configuration of the volume. This stores the mappings of front-end shares to back-end paths.
metadata (optional) chooses the volumes metadata, too. The metadata contains the locations of all client files and directories in the volume.
bstnA(gbl)# namespace medarcv volume /rcrds
bstnA(gbl-ns-vol[medarcv~/rcrds])# snapshot rule rcrdsArchive
bstnA(gbl-ns-vol-snap[medarcv~/rcrds~rcrdsArchive])# contents volume-config metadata
You can use no contents to remove either user data or the volume configuration from this rules snapshots:
user-data removes client-viewable files and directories from the rules snapshots.
volume-config removes the volume configuration and metadata from future snapshots.
For example, the following command sequence removes user data from the rcrdsArchive rules snapshots:
bstnA(gbl)# namespace medarcv volume /rcrds
bstnA(gbl-ns-vol[medarcv~/rcrds])# snapshot rule rcrdsArchive
bstnA(gbl-ns-vol-snap[medarcv~/rcrds~rcrdsArchive])# no contents user-data
If a snapshot rule includes user-data as well as volume metadata, the metadata filer keeps the same number of snapshots as the user-data filers. The total number of snapshots is controlled by the rules retain directive, described in Changing the Number of Retained Snapshots (optional).
As described in the chapter about snapshots, the ARX volume can create snapshots on a regular schedule. A schedule is not required because you can invoke a snapshot rule manually (recall Creating a Manual Snapshot). However, it is recommended for file tracking.
To create a schedule, use the gbl schedule command (refer to Appendix 12, Creating a Policy Schedule in 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.
The best practice for scheduling is to configure daily snapshots; one file-tracking record per day is sufficient for most installations. Another good practice is to choose a non-busy hour for the snapshot. Client access is blocked by a VIP fence while the snapshot is taking place, and other volumes in the same namespace may also be blocked. The VIP fence is discussed in more detail below.
bstnA(gbl)# namespace medarcv volume /rcrds
bstnA(gbl-ns-vol[medarcv~/rcrds])# snapshot rule rcrdsArchive
bstnA(gbl-ns-vol-snap[medarcv~/rcrds~rcrdsArchive])# schedule daily4am
For detailed instructions on using a schedule in a snapshot rule, refer back to Applying a Schedule (optional).
A progress reports shows all the milestones and results of a snapshot. We recommend this to verify that all filer snapshots succeeded, or to diagnose problems if one of them failed. From gbl-ns-vol-snap mode, use the report command to generate this report every time the rule creates a snapshot, or only when a snapshot has an error:
report prefix [error-only]
where error-only (optional) causes the snapshot rule to generate reports if there is an error in the snapshot operation. This is not recommended for snapshots with client data, as it makes snapshot reconstitution impossible for client shares. This option is acceptable for snapshots that are limited to volume configuration and/or metadata, because those snapshots are archived and do not require reconstitution.
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 /rcrds
bstnA(gbl-ns-vol[medarcv~/rcrds])# snapshot rule rcrdsArchive
bstnA(gbl-ns-vol-snap[medarcv~/rcrds~rcrdsArchive])# report FA_rcrds error-only
For details about snapshot reports, including sample reports, refer back to Configuring a Progress Report (optional).
The final step in configuring any snapshot rule is to enable it. By default, the rule is disabled and ignored by policy software. You must enable the rule to run snapshots on a schedule or to invoke the snapshots manually. As described in Enabling the Snapshot Rule, you use the enable command to enable the rule. For example, the following command sequence enables the rcrdsArchive rule:
bstnA(gbl)# namespace medarcv volume /rcrds
bstnA(gbl-ns-vol[medarcv~/rcrds])# snapshot rule rcrdsArchive
When the snapshot rule takes a snapshot of the volumes metadata, the volumes clients are unable to modify the metadata until the snapshot is complete. This raises a VIP fence, which is discussed in Enabling Snapshot Consistency. Every VIP that exports this volume puts up a VIP fence, thus blocking client access to any other volumes behind the same VIP or VIPs.
We recommend that you choose a metadata filer that can perform fast snapshot operations. If multiple volumes send their snapshots to a file archive, we recommend that they have all of their metadata shares backed by the same filer volume (or a small set of filer volumes), and that the ARX volumes share the same schedule for their snapshot rules. With the same schedule and the same filer volume(s), you can take advantage of snapshot grouping, discussed in Snapshot Grouping.
From priv-exec mode, you can use the cancel snapshot archive command to cancel an archiving process that is currently underway:
ns (1-30 characters) selects the namespace,
vol-path (1-1024 characters) is the managed volume, and
rule-name (1-1024 characters) identifies the snapshot rule that is currently running the archive operation.
bstnA(gbl)# end
bstnA# cancel snapshot archive namespace medarcv volume /rcrds rule rcrdsArchive
Confirming this command will cause all archiving operations in namespace ''medarcv'' volume /rcrds''
bstnA# ...
You can use the snapshot remove command to delete all of the back-end snapshots behind a snapshot rule. If this snapshot rule includes user data as well as metadata, this also removes any metadata snapshots on the volumes metadata filer. This command only removes filer snapshots, not the rule configuration.
You can skip this section if the snapshot rule only includes volume configuration and/or metadata (recall Selecting the Contents of the Snapshot). If the snapshot rule does not include any user data, the rule deletes the metadata snapshot as soon as it is successfully copied to the archive. This prevents the metadata filer from accumulating unnecessary snapshots.
From priv-exec mode, use the snapshot remove command to remove the filer snapshots and/or checkpoints behind a snapshot rule and the volumes metadata share. Removing all Snapshots Behind a Rule, describes this command in detail.
bstnA(gbl)# end
bstnA# snapshot remove medarcv /lab_equipment dailyArchive
bstnA# ...
From gbl-ns-vol mode, use the no snapshot rule command to remove a snapshot rule from the current volume. For details on this command, see Removing a Snapshot Rule.
bstnA(gbl)# namespace medarcv volume /lab_equipment
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# no snapshot rule test_fha
For situations where you are unsure of the earlier configuration, you can use the show virtual path-history command from any mode. This command only functions after one or more snapshots have archived the volumes configuration:
time-frame establishes the date(s) for your query. This takes several forms, discussed in the subsections below.
report rpt-prefix (optional, 1-255 characters) sends the output to a report. Without this option, the output appears at the CLI prompt. The report name is in rpt-prefix_archive-name_date-time.rpt format; the exact name appears after you enter the command. You can use show reports to list all reports, and show reports report-name to view any report.
archive arch-name (optional, 1-64 characters) specifies a particular file-history archive.
verbose (optional) expands the output with further details.
today | date indicates that you want the configuration from a single day. Use mm/dd/yyyy format for a date.
The output contains a block of information for each archived snapshot in the given time-frame. Each block has a heading, As of date time, and contains configuration information followed by two tables. The configuration information identifies the file-history archive, the ARX, the global server that clients accessed to reach their files, and the particular namespace and volume containing the files. The first table contains one row per volume share, with the ARX-share name in one column and the shares back-end location in the other column. The second table has one row per front-end export, and maps the name of the client-visible export to its root directory in the ARX volume.
Note: The ARX volume uses a filers CLI to find its back-end-share locations. The volume software uses CLI-access parameters to find those paths, which are provided in the external-filer configuration. Recall Preparing External Filers Behind the Volumes Shares. As explained in that section, the paths are reduced to best guesses for any volume shares where the ARX has no CLI access.
For example, the following command shows the full path history for a single day, 9/14/2009. This shows an archived snapshot for the medarcv~/lab_equipment volume, followed by another archived snapshot for the medarcv~/rcrds volume. From the Export tables in this output, we find that the ac1.medarch.org has a share named labs along with two other shares, and that it has several additional shares (ARCHIVES, Y2005, and more) backed by the /rcrds volume. These data points will be useful later, and are shown in bold below:
bstnA(gbl-ns-vol[medarcv~/lab_equipment])# show virtual path-history date 09/14/2009
Global Server: ac1.medarch.org
You can set a start date and/or an end date for the path historys time frame. To set a range of dates in this way, use the start-date clause, the end-date clause, or both. These go in place of the date clause shown above.
where today | date is the last day in the query. Implicitly, the start date is the date of the first snapshot in the archive. Use mm/dd/yyyy format for a date.
bstnA(gbl)# show virtual path-history start-date 01/07/2009 report pathsSinceJan verbose
bstnA(gbl)# show virtual path-history end-date 06/05/2009 archive fileRecordsMed
You can also count back from an end date with the show virtual path-history command. To accomplish this, you specify some number of days, weeks, months, and so on that lead up to the end date:
count (1-100) is the number of days, weeks, or whatever you choose with the next argument.
days|weeks|...|years indicates the time unit.
the remaining arguments, not shown above, are the ones described earlier: report, archive, and verbose.
bstnA(gbl)# show virtual path-history 1 year before today archive fileRecordsMed
From priv-exec mode, use the show file-history virtual-service command to view the location of a particular file on a particular day. This is the general syntax of the command:
server-and-share specifies the server name and the share name as seen by ARX clients during the time-frame. Server and share names may change over time, so you can use the show virtual path-history command to find the correct names for that date, as described above.
time-frame is a time period when the snapshot rule archived the volumes configuration and metadata at least once.
file-path is the file or directory to seek.
options (all optional) include search parameters, such as recursion into subdirectories.
fqdn (1-1024 characters) identifies the front-end service that clients use to access the file. As mentioned above, you can use show virtual path-history to find a service name that is appropriate to your date. This can also be the VIP, WINS name, or WINS alias from the time (all included in the output of show virtual path-history).
fe-share (1-1024 characters) is the front-end share that clients use (or used) to access the file. This is case-sensitive for NFS shares (that is, thisShare is different than THISshare), but not for CIFS shares.
date {today | date} is the specific date for which you want the files location. To specify a date other than today, use mm/dd/yyyy format. A query for today applies to the time of day when the file-history record was archived; for a file location as of this minute, use the find command or run a nsck ... report metadata-only report. Both of these commands are described in later chapters.
[file filename] [path path] chooses the file or directory to seek. This is required: you must select the file, the path (a directory), or both.
| filename (1-255 characters) is the file itself. This is not case sensitive: for example, an entry of myfile.txt would match an actual filename of myFile.txt or MYFILE.TXT. You can also use wildcard characters and sequences supported by the wildmat standard: * means 0 or more characters, ? means any single character, [0-9] means any single digit, [^a-z] means any single character except a lowercase letter, and so on. This searches the root directory of the fe-share, or the path that you specify in the next argument. |
| path is a directory path, relative to the root of the fe-share. You use forward slashes (/) in an NFS share or a CIFS share: for example, myDir/yourDir is a valid path in any share. This also supports wildmat expressions. |
The output shows the date you have chosen, the configuration of the archive and ARX service, and a separate table for each snapshot that contains the file record. For example, if the snapshot rule took three snapshots on the date you gave, there would be three sub tables. Each sub table shows the time of the snapshot/archive operation, the files namespace and volume, the files back-end share (in \\external-filer-name\share-name format), and the files back-end path.
Note: The ARX volume uses a filers CLI to find its back-end-share paths. The volume software uses CLI-access parameters to find those paths, which are typically provided in the external-filer configuration for snapshot-supporting filers (recall Preparing External Filers Behind the Volumes Shares). As explained in that section, the paths are reduced to best guesses for any volume shares where the ARX has no CLI access.
bstnA# show file-history virtual-service ac1.medarch.org ARCHIVES 09/14/2009 today file a_adams.dat path /2005/planA
bstnA# ...
You have several options at the end of the show file-history command to control the search parameters and the output. You can use any of these options at the end of any show file-history virtual-service command:
recurse (optional) extends the search into subdirectories.
case-sensitive (optional) limits the search to the exact filename or path that you typed. This means that an entry of INDEX.html does not match the index.html file. By default, INDEX.html would match index.html, Index.html, or any other case combination.
verbose (optional) expands the output with further details. If you specify a path with this option, the output is a list of the files in all matching directories.
report rpt-prefix (optional, 1-255 characters) sends the output to a report. Without this option, the output appears at the CLI prompt. The report name is in rpt-prefix_archive-name_date-time.rpt format; the exact name appears after you enter the command. You can use show reports to list all reports, and show reports report-name to view any report.
archive arch-name (optional, 1-64 characters) specifies a particular file-history archive.
bstnA# show file-history virtual-service ac1.medarch.org labs date today file index.html recurse verbose report indexPaths
bstnA# ...
You can set a start date and/or an end date for the files time frame. To set a range of dates in this way, use the start-date clause, the end-date clause, or both. These go in place of the date clause shown above.
where today | date is the last day in the query. Implicitly, the start date is the date of the first snapshot in the archive. Use mm/dd/yyyy format for a date.
bstnA(gbl)# end
bstnA# show file-history virtual-service ac1.medarch.org labs start-date 11/12/2008 file index.html recurse
You can also count back from an end date with the show file-history virtual-service command. To accomplish this, you specify some number of days, weeks, months, and so on that lead up to the end date:
show file-history virtual-service fqdn fe-share count {days|weeks|months|quarters|years} before {today | date} ...
count (1-100) is the number of days, weeks, or whatever you choose with the next argument.
days|weeks|...|years indicates the time unit.
bstnA(gbl)# end
bstnA# show file-history virtual-service ac1.medarch.org labs 3 days before today file reagentlist.pdf recurse
Using a virtual-file path, visible through a VIP, you can find a files location on its actual back-end filer. This is the location of the file now, as opposed to an earlier location that you can discover with show file-history commands from above.
From any mode, use the find command to find a files current back-end location:
hostname-or-vip (1-255 characters) is the DNS hostname or VIP that clients use to access the file (syntax for a WINS name appears later), To use a hostname defined at an external DNS server, you must first identify the server with the ip name-server command. For instructions on using this command, see Configuring DNS Lookups, on page 4-31 of the ARX® CLI Network-Management Guide.
{cifs | nfs} share-name (1-4096 characters) is the share that clients use, and
path (1-4096 characters) specifies the client-visible path to the file. Use forward slashes (/), even for paths in CIFS shares.
bstnA(gbl)# find global-server ac1.medarch.org cifs ARCHIVES path /2005/planA/a_adams.dat
bstnA(gbl)# find host 192.168.25.15 cifs STATS path /carrierCrossCheck.html
You can also show the NFS filehandles, both from the client perspective and the server perspective. Use the optional verbose keyword at the end of the command to add the filehandles to the output:
where verbose (optional) adds the NFS filehandles to the output. The other options were explained above.
bstnA(gbl)# find host 192.168.25.15 nfs /claims path /stats/carrierCrossCheck.html verbose
fqdn (1-255 characters) identifies the global server that clients use to access the file (for example, myServer.com),
{cifs | nfs} share-name (1-4096 characters) is the share that clients use, and
path (1-4096 characters) specifies the client-visible path to the file. As above, use forward slashes (/) for all paths.
verbose (optional) adds the files NFS filehandles to the output.
A CIFS front-end service can advertise its shares using a NetBIOS name registered with a WINS server (see Setting the NetBIOS Name (optional, CIFS), on page 10-7 of the ARX® CLI Storage-Management Guide). If you used the optional wins-name and/or wins-alias command to set up a special NetBIOS name, you can use this name to find a file:
netbios-name (1-255 characters) identifies a NetBIOS name for a global server, advertised by a WINS server (for example, CIFSSERVER),
{cifs | nfs} share-name (1-4096 characters) is the share that clients use, and
path (1-4096 characters) specifies the client-visible path to the file. As above, use forward slashes (/) for all paths.
verbose (optional) adds the files NFS filehandles to the output.
bstnA(gbl)# find wins INSURANCE cifs CLAIMS path /index.html
namespace (1-30 characters) identifies the namespace of the file,
path (1-4096 characters) specifies the client-visible path to the file, and
verbose (optional) adds the files NFS filehandles to the output. This output is sometimes incomplete; use one of the other versions of the find command (such as find host) to guarantee complete NFS filehandles.
bstnA(gbl)# find namespace wwmed path /acct/index.html
bstnA(gbl)# find namespace wwmed path /acct/index.html verbose
You may wish to monitor the disk space used by file-history records in the file-history archive. For a list of the records in an archive, you can expand on the show file-history archive command discussed earlier (recall Listing All File-History Archives). Use the name of a particular archive followed by the contents keyword, a time frame, and possibly some options:
name (1-64 characters) identifies the desired archive.
contents is a required keyword.
time-frame establishes the date(s) for your query. This takes several forms, discussed in the subsections below.
ns (optional, 1-30 characters) selects the records from a particular ARX namespace.
vol-path (optional, 1-1024 characters) focuses on one ARX volume.
report rpt-prefix (optional, 1-255 characters) sends the output to a report. Without this option, the output appears at the CLI prompt. The report name is in rpt-prefix_archive-name_date-time.rpt format; the exact name appears after you enter the command. You can use show reports to list all reports, and show reports report-name to view any report.
today | date indicates that you want the archive contents from the given day. This shows any and all snapshots that were archived today or on the date you provide. Use mm/dd/yyyy format for a date.
bstnA(gbl)# show file-history archive fileRecordsMed contents date today
bstnA(gbl)# ...
bstnA(gbl)# show file-history archive fileRecordsMed contents date today namespace medarcv volume /rcrds
bstnA(gbl)# ...
You can set a start date and/or an end date for archives contents. To set a range of dates in this way, use the start-date clause, the end-date clause, or both. These go in place of the date clause shown above.
where today | date is the last day in the query. Implicitly, the start date is the date of the first snapshot in the archive. Use mm/dd/yyyy format for a date.
bstnA(gbl)# show file-history archive fileRecordsMed contents start-date 01/07/2009 report flRcrdsSinceJan
You can also count back from an end date with the show file-history archive command. To accomplish this, you specify some number of days, weeks, months, and so on that lead up to the end date:
show file-history archive name contents count {days|weeks|months|quarters|years} before {today | date} ...
count (1-100) is the number of days, weeks, or whatever you choose with the next argument.
days|weeks|...|years indicates the time unit.
the remaining arguments, not shown above, are the ones described earlier: namespace, volume, and report.
bstnA(gbl)# show file-history archive fileRecordsMed contents 3 months before today
As time goes on, the number of file-history records (volume configurations, and possibly metadata snapshots) on the file-history archive grows. You may want to remove very-old records from the archive to conserve space. You may also want to remove all the file-history records for a removed service; recall Removing a Full Namespace Service. Other occasions may also arise where it is useful to remove file-history records from the archive filer.
From priv-exec mode, use the clear file-history archive command to remove volume configurations (and possibly volume metadata) from an archive:
name (1-64 characters) identifies the desired archive.
metadata-only (optional) limits the clearing operation to volume metadata, and preserves all of the selected volume-configuration data. Without the volume metadata, you can query the front-end-service configurations from a given record (Showing Historical Configurations), but you cannot query the locations of particular files or directories (Showing File History).
time-frame (optional) identifies specific file-history record(s) to clear. If you omit this option, the command clears file-history records from the fullest span of time. A specific time frame takes several forms, discussed in the subsections below.
ns (optional, 1-30 characters) selects the records from a particular ARX namespace.
vol-path (optional, 1-1024 characters) focuses on one ARX volume.
The CLI prompts for confirmation before removing any file-history records from the archive; enter yes to proceed.
bstnA(gbl)# end
bstnA# clear file-history archive fileRecordsMed namespace medarcv volume /rcrds
The subsections below explain the various time frames that you can specify for this command. These are the same time-frame formats used for the show file-history archive command described above.
today | date indicates that you want to clear the archive contents from the given day. This clears any and all configurations/snapshots that were archived today or on the date you provide. Use mm/dd/yyyy format for a date.
For example, the following command sequence exits to priv-exec mode and clears the file-tracking records archived on a particular date in January. The clear command only removes records from a particular volume, medarcv~/rcrds:
bstnA(gbl)# end
bstnA# clear file-history archive fileRecordsMed date 01/07/2009 namespace medarcv volume /rcrds
bstnA(gbl)# end
bstnA# clear file-history archive fileRecordsMed date 01/07/2009
You can set a start date and/or an end date for clearing archive records. To set a range of dates in this way, use the start-date clause, the end-date clause, or both. These go in place of the date clause shown above.
where today | date is the last day in the query. Implicitly, the start date is the date of the first snapshot in the archive. Use mm/dd/yyyy format for a date.
bstnA(gbl)# end
bstnA# clear file-history archive fileRecordsMed metadata-only end-date 01/07/2009
You can also count back from an end date with the clear file-history archive command. To accomplish this, you specify some number of days, weeks, months, and so on that lead up to the end date:
clear file-history archive name [metadata-only] count {days|weeks|months|quarters|years} before {today | date} ...
count (1-100) is the number of days, weeks, or whatever you choose with the next argument.
days|weeks|...|years indicates the time unit.
bstnA(gbl)# end
bstnA# clear file-history archive fileRecordsMed 4 months before 01/07/2009
bstnA# ...
