...

For filesystem-level/namespace backup and restore, the .Trash directory will not be visible to the backup utility during namespace traversal, so deleted files in the Trash will not be backed up.

For MDT-level/device backup and restore, the Trash directory and its contents will be backed up in the same way as any other directory in the filesystem.  The stub pFID directory is named by the parent directory FID, so it will be backed up and restored as-is (its FID is not really important, but should be treated normally).  The FID on the actual parent directory will be preserved in the trusted.lma xattr, but the FID lookup in the restored OI will not be possible until after the initial post-restore OI Scrub has completed.  Otherwise, the FID lookup in the restored OI will reference the old inode number, which will reference a wrong or unused inode number/generation, and should return -EINPROGRESS or possibly -ESTALE.

  However, if a deleted directory is restored from Trash then if it has a new FID (== new inode number) the backup utilities may consider this to be a new directory and back it up again.  At a minimum, it would be desirable to preserve the inode number.  Similarly, HSM integration may depend on the FID of the file, so it may be desirable to preserve the original parent FID of the directory when it is restored from Trash.  A deleted directory could only be restored to use the same FID if the original directory had been deleted.

For MDT-level/device backup and restore, the Trash directory and its contents will be backed up in the same way as any other directory in the filesystem.  The stub pFID directory is named by the parent directory FID, so it will be backed up and restored as-is (its FID is not really important, but should be treated normally).  The FID on the actual parent directory will be preserved in the trusted.lma xattr, but the FID lookup in the restored OI will not be possible until after the initial post-restore OI Scrub has completed.  Otherwise, the FID lookup in the restored OI will reference the old inode number, which will reference a wrong or unused inode number/generation, and should return -EINPROGRESS or possibly -ESTALE.

It may be necessary to add special support to OI Scrub/LFSCK to handle the Trash directory on each MDT, so that it can do a top-level scan of the stub pFID directories to confirm that the parent FID still references a valid parent directory.

Trash Can and fscrypt Files and Directories

When an fscrypt directory is deleted, the encryption context on the directory must be copied from the parent directory to the new pFID stub directory when it is first created, so that the encrypted filenames and contents can be accessed properly via the .Trash/ directory, as well as if an encrypted file or directory is undeleted.  The fscrypt context is partly derived from the parent directory, as well as a unique per-inode Cryptographic nonce value that ensures the encrypted data is unique, even if the same data is encrypted multiple timesIt may be necessary to add special support to OI Scrub/LFSCK to handle the Trash directory on each MDT, so that it can do a top-level scan of the stub pFID directories to confirm that the parent FID still references a valid parent directory.

Virtual .Trash Directory Support 

...