Tape Backup And Volume Move Operations Must Not Be Performed Simultaneously; Smtape Restore To An Offline Volume Overwrites The Data On That Volume; Deleted Files Occupy Additional Space On Smtape Restored Volumes; Limitations When Using Snapvault With Non-Default Vfiler Units - IBM N Series Manual

Tape backup and volume move operations must not be performed
simultaneously
You must not perform a tape backup or restore operation while a volume
move operation is in cutover phase. Similarly, you must not perform a volume
move operation while a tape backup or restore is in progress. You should wait
until one of the operations is complete before initiating the other.
For more information about volume move operation, see Data ONTAP 8.0
7-Mode Block Access Management Guide for iSCSI and FC.

SMTape restore to an offline volume overwrites the data on that volume

If you perform an SMTape restore to an offline volume, the data on tape
overwrites the data on that offline volume.

Deleted files occupy additional space on SMTape restored volumes

On an SMTape restored volume, a Snapshot copy might lock the data blocks
of a deleted file, thus occupying additional space on the restored volume.
When you delete a large file from a volume, the data blocks of that file are
not freed immediately. If you perform an SMTape backup immediately after
deleting the file, some data blocks of the deleted file are also backed up. After
restore, those data blocks reside on the volume and are locked in the Snapshot
copy.
To free the space on the restored volume, delete the Snapshot copy that locked
the data blocks of the deleted file.

Limitations when using SnapVault with non-default vFiler units

There are certain limitations when using SnapVault with non-default vFiler
units. These limitations apply to all Data ONTAP releases that support
non-default vFiler units.
The management of SnapVault secondary (creation or modification of
SnapVault relationships and schedules at the SnapVault secondary) is only
supported from the default vFiler unit (vfiler0). The management of
SnapVault secondary is not supported from a non-default vFiler context. If the
volume containing the SnapVault destination qtree is owned by a non-default
vFiler unit, the SnapVault secondary needs to be managed through the default
vFiler unit (vfiler0).
Table 1. vFiler unit support with SnapVault secondary volumes for different
combinations
Management of SnapVault
secondary volume Ownership of SnapVault secondary volume
Default vFiler unit
(vfiler0)
Known problems and limitations
Non-default vFiler unit
107