Section: FSCLI (1)
Updated: September 2018


fsrecover – Report or recover Recoverable files on media.


fsrecover filename… [-t starttime [ endtime]]
fsrecover dirname-d [-r] [-a [-t dirtime]]
fsrecover [RM_time::]filepathname-u [-v]
fsrecover dirpathname-u -d [-r] [-v] [-a [-t dirtime [-n destination_dir]]]


The fsrecover(1) command can be used to report on Recoverable files. It can also be used to recover those files back to disk. A Recoverable file is a file for which there is still knowledge of its location on managed media, but the file no longer resides on disk (it has been removed.)

A Recoverable file can be recovered up until the time the managed media has been cleaned via the fsclean(1) command. At that point the files cleaned are completely gone. When a file is recovered, the version of the file that was active at remove time is made the active version.

The following conditions must exist for a file to be recovered: – The Recoverable file must be stored on media. – The user must have read access to the file and write access to the directory from which the file was stored.

The following list shows the ways to use fsrecover(1): – To report Recoverable files and directories that contain them. – To recover these Recoverable files back to disk.


The report generated by fsrecover(1) lists all Recoverable files and the directories that contain them. Names and wildcards can be used to limit what list is reported.

Note that the report wildcard is ‘%’ so that it will not conflict with the shell wildcard.

The time range option (-t starttime) extracts only information over the time period specified. The starttime and endtime must be before the current time, and the starttime must be before the endtime. If no endtime is specified, endtime defaults to current time.

If the directory time option (-t dirtime) is used when reporting on a directory that indicates that only files that were active in the directory at that time will be reported. Note that those files may have been removed since then, or updated and now have a new version. Likewise files that were active before that time, then were removed, will not be included in the report.

Restoring Deleted Files and Directories

Although a report can be generated with a file name or a path name, execution of fsrecover -u to recover a file or a directory requires that a full path be indicated. The user cannot change the placement of the recovered file or directory. All files are recovered with the same name and directory in which the files had at the time when removed. After recovering a file or directory, it can then be renamed as usual. (Note that recovering a directory instance with the -a, -t and -n options is an exception to this behavior and will be covered more below.)

When reporting Recoverable files the complete path names are reported along with the time of the remove in the form of (RM_time::PATH_NAME) The expected format for the remove time string “RM_time” is shown in this example:


If there are multiple files with the same path that can be recovered then by default the one with the most recent remove time is recovered. If it is desired to recover an older instance of the file with that name, then the remove time string must be provided with the file.

Files that are recovered are considered stored on media and truncated from disk. The file is not copied to disk, but appears in a listing of the directory contents (UNIX ls command). An attempt to read or edit the file results in a copy of the file from a medium to disk, as in all other stored and truncated Tertiary Manager-controlled files. Additionally, if the file is configured to have a stub file, then the stub will not be present until the file is retrieved again.

If a list of files or directories are specified, fsrecover(1) processes each file and directory individually, failing invalid entries but continuing to recover what it can.

The fsrecover -d -u command, when used with the directory path and without the -a, -t and -n options, recovers the directory and its child files. The fsrecover -d -u command will recover the latest instance of all files in those directories. If the recurse option is specified, the Tertiary Manager software attempts to recover all child files and recursively recover subdirectories and subdirectory child files.

Recovering an Instance of a Directory

The fsrecover -d command, when used with the -a, -t and -n options, can be used to recover an instance of a directory. This flavor of the command accepts the recursive -r option and works like any directory recover with the following exceptions: – Files that are recovered from the directory are recovered to a new location (not where they were located when removed, if indeed they were removed). – Because the files are recovered to a new location they end up as new files with only a limited relation to the existing files. If the original files are still active then any actions such as removal or modification of those files will not affect the newly recovered directory. (The one relation the files do have is they share the same media copies. So if the media that contained the original is lost or the info is removed via fsrminfo(1) then both sets of files are gone.)

When recovering a directory instance it can be thought of as recovering the files that were active in a directory at the specified time. Hence the use of the -a and -t options. Here is sample usage for recovering an instance of directory /stornext/snfs1/relp1/subdir1 from Apr 10, 2010 at 4:30pm: – fsrecover /stornext/snfs1/relp1/subdir1 -duat 2010:04:10:16:30 -n /stornext/snfs1/relp1/newdir

Note that the destination directory does not have to exist but at least its parent directory must exist. Also the destination directory must be on the same file system and be of the same policy class as the original directory.

Note that file versions which have been removed and then recovered, via a normal fsrecover(1), will be counted as active from the time the version was first created until the final endtime. This is true regardless of how many times it was updated/removed and re-recovered during that time. Any recovery of the directory instance between those times will result in that file being recovered to the new destination directory.

Lastly note that recovering an instance of a directory should always be done to a new directory. (If a recover operation is stopped for whatever reason it can be restarted to the same destination directory.) The reason for this recommendation is that if an instance is recovered to an existing directory, for any name collisions those files will not be recovered. This is true even if the collisions are with removed files in the destination directory. To ensure getting every file from an instance in time always use a new destination directory.

For example: if you have recovered an instance of a directory, then accidentally remove file(s) from that directory; you can use the command options not related to recovering an instance of a directory for reporting or recovering those file(s). Don’t attempt to re-run the instance recovery again.
Another example: if you have recovered an instance, and you realize that for some of the files you want them from a different instance in time; you will have to recover that instance to a new directory. (You can then move any of those newly recovered files to the desired location.)


The file name(s) of the file(s) to report. The name can be a file name, partial path name, or full path name. The full path name of each file matching the name is reported.
The dir name(s) to report. The name can be a dir name, partial path name, or full path name.
Full path name of each file to recover. If the command is being run in the directory desired a full path can be indicated by specifying: ./filename A timestamp of the form returned in the report can be provided with the file path.
Full path name of each dir to recover. If the command is being run in the directory desired a full path can be indicated by specifying: ./dirname
Indicates recovery processing requested. (Undo the remove.) Required option to recover files or directories. If the option is not specified, a report is produced. Wildcards cannot be used with this option.
Indicates that directory processing is requested.
DEPRECATED: Previously this option was required to report files that the user had permissions to access verses just files that the user owned. Now the report mode will show all files the user has permission to recover, which is the same behavior as recovery mode.
Indicates recursive processing is requested. Recursive processing is available for either a directory report or for recovering a directory.
-t starttime [endtime]
Indicates a time range to restrict the report length displayed to the user. If an entry to be displayed is a file to which the user has access and is within the time range specified by the user, it is displayed. If specifying a time range, the user must enter a starttime, but the starttime can not be greater than the current time. If the endtime is not specified, the current time is used. If the user specifies an endtime, it must be greater than the starttime. The format for the time parameter is YYYY:MM:DD:hh:mm:ss where:

YYYY = Numeric, year
The following are optional; defaults are shown:,

MM = Numeric, two-digit month
(default:01 (January)),

DD = Numeric, two-digit day
(range: 01-31, default:01),

hh = Numeric hour
(range: 00-23, default:00),

mm = Numeric minute
(range: 00-59, default:00),

ss = Numeric second
(range: 00-59, default:00)

-t dirtime
This indicates the point in time a directory instance should be reported/recovered.
-n destination_dir
This indicates the destination directory when recovering a directory instance.
When reporting or recovering a directory use active files instead of Recoverable files. Wildcards cannot be used with this option.
Verbose mode during a recover. Will report on files recovered.


Here is a description of the renameTracking feature wich can be enabled on a managed file system.

Some Microsoft applications end up making temporary copies of operational files while they are being updated. For example while a file myDocument.doc is being updated with Word it may be renamed to a random sequence of characters like ABC123DYXab. When Word completes the updates it will save the new myDocument.doc file and remove ABC123DYXab. When Storage Manager recognizes that file ABC123DYXab has been removed it makes it recoverable but with the current temp name. This makes tracking old instances of myDocument.doc difficult if not impossible to accomplish. To get around this scenario the renameTracking feature is provided. This can be turned on in the file system (see the snfs_config(5) man page) and makes tracking of old instances of these temporary files possible.

When renameTracking is enabled, as a file is renamed it is made recoverable at that time. As an example: in the scenario described above as Word renames myDocument.doc to ABC123DYXab, Storage Manager will make myDocument.doc recoverable with its original name before the rename proceeds. (That renamed instance becomes inactive.) Then after Word is done, the new myDocument.doc will be the new instance of the file and the previous instance will be available for recovery via fsrecover(1) with the correct name.

Note that renameTracking is NOT a general purpose feature for keeping the Storage Manager database up to date with rename activity. Turning it on results in files that are being renamed being re-stored. This is not in general a desirable behavior except in the specific case described.


fsclean(1), snfs_config(5)