Copies in Replication Versus Copies and Versions in Storage Manager

Snpolicy supports multiple copies (instances) of files and directories on the target, while TSM supports both multiple copies and multiple versions of files and directories. It’s important to understand what "copies of a file or directory" means. There are several meanings, and this section attempts to clarify where StorNext supports additional copies and versions of a file or directory.

Context 1

"Number of copies to keep on target" is one property (rep_copies) of an snpolicyd policy. This parameter specifies the number of replicated directories to keep on the target file system for a source directory. Remember, the replication process involves replicating a source directory and all of files and subdirectories that it contains. You can create from 1 to 16 target directories, depending on the "Number of copies to keep on target". Number of copies in this context means the number of target directory instances. By default, the different directories are differentiated by names like dir, dir.1, dir.2, and so on.

Context 2

There is a special case where policy parameter rep_copies is set to 0. In this configuration, the target creates a target directory for the first namespace replication. It then operates on the same target directory for all subsequent replications on the same source directory.

Note: Currently there are some limitations to this setting:

1. If a file is removed on the source, the target will not remove the file accordingly at next namespace replication time.

2. If a file is renamed on the source, at the next namespace replication, though the new name will appear in the target directory, but the old file name still stays.

Context 3

snpolicyd does not support multiple versions. Though we support multiple copies, so a file can appear in directories of multiple copies, however, they are all linked to the same inode. This means whenever a change is made on the source and is populated to target by replication, all copies of the file will be impacted on the target. For instance, if a source file has its file owner changed, and the change is populated to the target through replication, all previous copies of this file will have the new owner instead of the prior owner.

Context 4

Number of target files systems for an snpolicyd replication source policy. When configuring replication, you can specify up to three target file systems. For example, you could specify file system /stornext/bk on machine hist1, and file systems /snfs/backup and /snfs/dr on machine host2. Each of these directories can be a target of a replication source directory. The replication process is not complete until each of the three target file system targets have been completely made.

If a replication source policy specified 10 for the "Number of copies to keep on target" and specified 3 target file systems, you would eventually have 30 replication directories: 3 after the first replication, 6 after the second replication, etc.

Context 5

Storage Manager also supports multiple copies. Storage Manager stores 1 through 4 copies of a file. The number of files is configured under the Steering tab when editing or creating a Storage Manager policy. (Actually, 4 is the default maximum number of copies. The number can be greater than 4.) Each of these copies is a copy of the same file contents. Different from snpolicy copies, the set of files and directories are the same in different copies.

Context 6

Unlike snpolicyd, Storage Manager supports multiple versions. Versions refer to changed contents of the same file. By default, Storage Manager keeps ten versions of a file. Unlike Storage Manager copies, Storage Manager versions refers to different file contents. If there is a file called "log" that changes every day, and Storage Manager stores "log" every day, after ten days there would be ten versions of "log". The fsversion command is used to examine, and change the Storage Manager versions of a file.

Context 7

File Recovery. When a file is removed by accident from a snpolicy source directory, before a new namespace replication occurs, or if the policy is configured with multiple rep copies, the file still exists in rep copies on target (if new namespace replication does not occur, the file exists in each rep copy, otherwise, the file exists in all rep copies except rep copy 0) and can be copied back to restore. On the other hand, when a file is removed from a Storage Manager relation point, the previous copies stored by Storage Manager are still on media, and in the SM database. These previous versions may be recovered using the fsrecover command. There is no a limit to the number of SM instances which can be recovered in this manner. Eventually the administrator may use the fsclean command to clean up older versions of SM media. After running fsclean, files that used to reside on the media can no longer be recovered with the fsrecover command.