Does Restore-WBBackup preserve alternate data streams and security descriptors during file recovery?
0 reputation · 09 Mar 2023, 13:07 UTC
0 reputation · 09 Mar 2023, 13:07 UTC
Determine whether the PowerShell Restore-WBBackup cmdlet retains alternate data streams, extended attributes, and file security descriptors when recovering files from a Windows Server Backup.
The Backup module does not provide a built‑in switch to validate metadata integrity after a restore, and documentation does not explicitly state which file system attributes are preserved. Consequently, administrators must rely on external checks, but the exact behavior of Restore-WBBackup with respect to ADS, EA, and ACLs remains unclear.
Specific questions:
Restore-WBBackup preserve alternate data streams attached to restored files?32775 reputation · 09 Mar 2023, 22:12 UTC
Yes, Restore-WBBackup preserves alternate data streams (ADS) and security descriptors when recovering files to an NTFS-formatted volume. Because Windows Server Backup leverages the Volume Shadow Copy Service (VSS), it captures the full NTFS metadata of the source files, including the primary data stream, associated alternate streams, and the security descriptor (Owner, Group, DACL, and SACL).
The preservation of these attributes is a function of the underlying backup mechanism rather than a specific switch in the PowerShell cmdlet. The backup image stores the file system metadata as it existed at the time of the snapshot. During the restore process, the system attempts to write this metadata back to the target volume.
However, there are three critical conditions that can affect the outcome:
To verify that your specific environment is retaining this metadata, use the following scoped commands on a test file:
echo "Test Stream Content" > testfile.txt:mystream
icacls testfile.txt /grant "Everyone:(R)"
Restore-WBBackup.dir /R testfile.txt
icacls testfile.txt
Diagnostic Detail Required: Are you restoring these files to the original volume or to a different volume/server? This determines whether you will encounter SID resolution issues or permission inheritance conflicts.
Use comments to ask for clarification. Post a solution as an answer.
32,775 reputation · 09 Mar 2023, 23:52 UTC
One gap worth adding to the existing answer: the EFS case is the most common silent failure. The encrypted file's raw data and its NTFS metadata may come back, but the encryption context depends on the user's EFS certificate being available on the target machine. Restore to a rebuilt server without importing the original certificate (or a recovery agent cert) and you can end up with files that exist but cannot be decrypted. Treat EFS-protected content as a separate restore test case, not an assumption.
A second clarification on SIDs: the security descriptor is restored verbatim, but verbatim is not the same as usable. On a domain-joined rebuild with the same domain, SIDs resolve fine. On a workgroup machine or different forest, you get orphaned SIDs that show as unknown accounts in the ACL editor — the ACEs are present but grant nothing meaningful until remapped.
For a quick post-restore check (Windows Server 2016+ / PowerShell 5.1):
Get-Item .\restored.txt -Stream * | Select Stream, Length
(Get-Acl .\restored.txt).Sddl
Compare the SDDL string and stream list against a pre-backup capture. If they match, ADS and the full security descriptor survived; if the owner changed to the restoring account, the target volume's policy overrode it.