The fts dump command converts the contents of a fileset to a byte stream format that can be stored in a file. Dumping a fileset does not affect its status in the FLDB or at the site from which it is dumped. You can dump a non-LFS fileset or any of the three types of DCE LFS filesets.
Dumping is useful when you need to save a snapshot of a fileset (for example, when a fileset is removed but may later be restored). It is also useful if the read/write version of a fileset becomes corrupted; you can dump a backup or read-only version of the fileset and restore it as the read/write version, replacing the current, corrupted version.
You can perform a full or incremental dump of a fileset. A full dump of a fileset dumps the entire fileset as it currently exists. An incremental dump of a fileset dumps only those files from the fileset that have changed since a specified date and time; only those files with modification time stamps equal to or later than the specified time are dumped.
With DCE LFS filesets, you can also perform incremental dumps of only those files that have changed since a specified fileset version. Every DCE LFS fileset has a distinct version number that increments every time an operation is performed on the fileset or a file it contains (for example, when a file, directory, or ACL is modified). Each file in the fileset also has a version number. When an operation is performed on a file in a fileset, both that file and the fileset are marked with the current version number of the fileset plus one. When you do an incremental dump based on version, files in the fileset with version numbers equal to or greater than the version number you specify are dumped. (A DCE LFS fileset's version number is recorded in its fileset header; it has the same format as a fileset ID number. Use the fts lsheader or fts lsft command to view the current version number of a DCE LFS fileset.)
The fts restore command restores information from a previously dumped fileset back into the file system. Although you can dump a non-LFS fileset or any of the three types of DCE LFS filesets, you can restore a dump file only as a read/write fileset. When you restore a fileset, its creation date is set to the restoration date.
You can use the fts dump and fts restore commands to dump and restore data between different types of file systems. For example, a dump file of a DCE LFS fileset can be restored to a DCE LFS fileset or to any type of non-LFS fileset. Similarly, a dump file of a non-LFS fileset can be restored to a DCE LFS fileset or to a different type of non-LFS fileset. In any case, the contents of the dump file are translated into the appropriate format for the file system to which the file is restored. (See your vendor's documentation to verify the level of support for dump and restore operations between different types of file systems.)
Note that incompatible information may be lost when a fileset is dumped and restored between different types of file systems. For example, ACLs on objects in a DCE LFS fileset may be lost if the fileset is restored to a file system that does not support ACLs.
You can restore a dump file as a new DCE LFS fileset by specifying a name and site (File Server machine and aggregate) for the new fileset. The fileset is assigned an entry in the FLDB, and it receives the name that you specify with the command. The dump file must contain the full dump of a fileset if it is to be restored as a new fileset. After the fileset is restored, use the fts crmount command to create a mount point for the fileset, which makes it visible in the DCE namespace.
You can also restore a dump file as an existing read/write fileset (DCE LFS or non-LFS) by specifying the name and site of the existing fileset that is to be overwritten. The contents of the dump file overwrite the contents of the existing fileset. Include the -overwrite option with the fts restore command to specify that the existing fileset is to be overwritten; if you omit the -overwrite option, the command displays an error message and exits instead of overwriting the fileset. A non-LFS fileset must exist before the non-LFS partition on which it resides can be exported to the DCE namespace; therefore, when restoring a dump file as a non-LFS fileset, you must use the -overwrite option to overwrite the existing non-LFS fileset, even if the fileset to be overwritten contains no data.
If you are overwriting an existing fileset with an incremental dump, the fileset to be overwritten should initially have been restored as a new read/write fileset from a full dump. Also, both the dump file that is to be restored and the full dump that initially produced the read/write fileset that is to be overwritten must be dumps of the same fileset. Note that a full dump can be restored to overwrite an existing fileset, but the restored dump file overwrites all of the data in the existing fileset; an incremental dump cannot be restored to overwrite an existing fileset that was not created from the restoration of a full dump.
For the same reasons that you cannot move a fileset between sites in different cells, you cannot restore a fileset dumped in one cell to a site in another cell. (See Moving DCE LFS Filesets for information on the reasons for this restriction.)
Multiple incremental dumps of a fileset can be restored to overwrite the same existing fileset provided the following conditions are true:
· The fileset that is to be overwritten must not have been modified since its most recent restoration.
· The dump file that is to be restored must have been created from a date and time (as specified with the -date or -version option of the fts dump command) no later than the date and time at which the most-recently restored dump of the fileset that is to be overwritten was dumped.
· The dump file that is to be restored must have been created at a date and time later than the date and time at which the most-recently restored dump of the fileset that is to be overwritten was dumped.
The last two conditions specify that the span of time recorded in the incremental dump that is to be restored must overlap and extend the span of time recorded in the fileset that is to be overwritten. For example, suppose a full dump of a fileset was made on 1 February, an incremental dump from 31 January was made on 7 February, and a second incremental dump from 6 February was made on 14 February. The only possible way to restore all three dump files is to restore the full dump to a new read/write fileset, overwrite the new fileset with the incremental dump made on 7 February, and then overwrite the fileset with the incremental dump made on 14 February. Other sequences of restore operations involving all three dumps are very likely to result in some or all of the data in the fileset being inaccessible or inconsistent.
When restoring a dump file as a DCE LFS fileset, you can use the -ftid option to specify the fileset ID number that is to be associated with the fileset. If you are restoring to a new DCE LFS fileset, omit the -ftid option to let the FL Server allocate a new ID number; if you are overwriting an existing DCE LFS fileset, omit the option to retain the fileset's current ID number. Specify a fileset ID number only if you are sure you can specify an unused ID.
When restoring a dump file as a non-LFS fileset, do not use the -ftid option. Omit the option to continue to use the fileset ID number specified for the non-LFS fileset in the entry for the partition on which the fileset resides in the dfstab file. Note that the restored dump file overwrites all data on the non-LFS partition.
Note: The contents of a fileset are unavailable during a dump operation. For this reason, you may want to dump only the backup version of a fileset, which does not interrupt access to the read/write and read-only versions.
More:
Restoring a Dump File to a New Fileset
Restoring a Dump File by Overwriting an Existing Fileset