User's Manual

140 Migration, release, recall, and deletion
Starting the deletion job
You start a deletion job by running the following command on the FSE client:
Before running the command, ensure that the HSM file system of the selected FSE partition is mounted.
By default, fsefile requires confirmation before starting the deletion process. You can suppress the
confirmation request by specifying the --force option. This is particularly useful when using the
command within scripts.
During execution of the deletion job, fsefile reports the job execution progress to the standard output,
allowing you to monitor the deletion process in the command shell. You can disable monitoring (force
fsefile to return to the command prompt immediately) by specifying the --no-monitor option.
NOTE: If two consecutive deletion jobs using the same deletion policy are started on the same HSM file
system in a short period of time, the files that were deleted by the first job may show up as still present on
the HSM file system during the execution of the second job. This happens if the deletions had not yet been
“migrated” to FSE media by the time the second job was started. In this case, the second deletion job does
not perform any operation on these files, but returns an error for the files that have already been deleted.
If the HSM file system on which the deletion job is running is unmounted during the job, the job is aborted.
To complete the deletion process, you need to restart it from the beginning.
For more information on fsefile, see the FSE CLI reference.
Recalling deleted files
Files which were deleted from an HSM file system can still be recreated using the “recall by file ID”
functionality. You can find file IDs of the deleted files by searching for the delete events in the
corresponding HSM file system log file. This log file is named hsmfs_PartitionName.log.
To recall deleted files using their file IDs, run the command fsefile --recall --id
PartitionName FileID... on the FSE client.
Note that files that were deleted from an HSM file system and whose file data was stored on FSE medium
volumes that were subsequently reorganized can no longer be recalled. This happens when all migrated
generations of the deleted files were considered obsolete (outdated) by the FSE media reorganization
process and all medium volumes that stored these file generations were reorganized.
CAUTION: When sensitive data is to be completely erased from the FSE implementation, you must ensure
that they are first deleted from the HSM file system, and then reorganize its FSE media so that all migrated
generations (and all additional copies if multiple copying is configured for the appropriate FSE partition) of
the data are considered as obsolete.
Additionally, if the migrated data reside on WORM-type media, these media must be removed from FSE
and destroyed.
Resource allocation
FSE resources are physical and logical objects, controlled by the FSE implementation. For detailed
information on configuring resources, see chapter ”Configuring FSE” on page 37.
Resource allocation concepts
FSE resources can be grouped according to their characteristics, as follows:
• Physical resources:
• FSE libraries, each library includes FSE library slots
• FSE drives
fsefile --trigger-deletion PartitionName [--force] [--no-monitor]