When restoring a filesystem on a separate system (i.e., possibly a different system than the one where the filesystem was originally mounted and in use), I would like to apply the correct security labels to the files that are being restored.
There's a few facets to this query:
If possible, I'd like to apply the proper label to each file as it restores (as opposed to doing the restore followed by a pass with SELinux tools to separately apply the labels).
It's possible that the restoring OS is different than the OS that originally hosted the filesystem being restored.
If (1) is possible, can I somehow point the restoring tool at a different set of file contexts than the default of the restoring OS (e.g., /etc/selinux/targeted/contexts/files/file_contexts) - or override any security context information that may be associated with the archive. See also (5).
Similar to (2), how "different" can the restoring OS be than the target OS? That is, at what point will differing kernel versions (for instance, linux 2.6 on restoring OS vs 4.4 of the target OS), different filesystems or different userland (e.g., libc & selinux tools) have an impact? Are there rules of thumb that apply to "cross-version" restores (e.g., API/ABI guarantees from one major version of OS to another & forward/backward compatibility gotchas to be aware of).
Much as one might like to preserve classic unix permissions & file ownership & extended file attributes, one might like to preserve the original security context of files being restored. Many backup tools  can embed file ownership, but probably most do not have extensions to preserve the security context (thus making it easier to restore the context during restoration) - maybe there are some? The security context need not be embedded in the archive - it could be saved "out of band" in a file or files that may be preserved along with the archive itself.
This question is posed with a focus primarily on the SELinux implementation, but generally applies to other security frameworks (such as MAC & Capsicum). Related information applicable to other security frameworks is helpful as well.
The question is also framed around restoring a filesystem, but also generally applies to restoring from a backup image that was not necessarily of a filesystem - it could be just a hierarchy of files that was part of a filesystem. The distinction is sometimes important because different backup tools have different capabilities with regard to storing (and extracting) some extended information about the contents of the archive.
 The question is also applicable to the dump(8)/restore(8) tools, but could also apply to other tools such as tar(1) & libarchive(3) based options.
Recent RPM formats have some support for embedding security policy information. I haven't looked at it in much detail as it's not really a general purpose backup tool. Maybe I should start backing up with RPM? </joke>