SUMMARY
This article explains why why restores may not include access control lists or security properties for certain users.
ISSUE
Restores do not include access control lists or security properties for certain users. Permissions are not as expected after a restore.
User access lists are not shown in the security properties of restored files. The permissions on the restored files match the permissions of the parent folder. The permission architecture of folders is stored in the NTFS metabase, not on the folder object itself. Therefor file restores can only inherit permissions from their folder parent.
RESOLUTION
When using Agent File Based protection for Windows operating systems, or for CIFS or NFS NAS backups, ACLs cannot be restored for individual files or folders. To restore selective NTFS attributes, restore of the entire original machine or full volume path to the original machine is required. It is impossible to restore an ACL from one server to another or to a subpath or alternate path.
Therefore ACLs for Windows folders can restored to NTFS volumes via file agent backup when recovering entire paths to original volumes on original servers via file backup restores. Share-level permissions however are a component of the OS, not the files, and cannot be restored except through BareMetal recovery of the server prior to data recovery.
To restore the ACLs for full paths from file level agent backups:
- The backup type must be agent file backups.
- The restore must be to the original server.
- The restore must be to the original volume and path.
- If there are any existing files in the path restored, the parent folder permissions will be used instead of the ACLs. To ensure this does not occur, the root folder of the objects being restored must not exist prior to restoring.
- Make sure that the "overwrite" option is used with the file restore from the advanced restore options menu.
Restoring ACLs from NDMP NAS backups:
- The backup type must be NFS/CIFS but NDMP (only supported on Some NAS and requires Unitrends Enterprise plus Licensing)
- The restore must be to the original mountpoint (note some NAS do not support granular restore to original volumes)
- The restore must include the full root path
- If there are any existing files in the path restored, the parent folder permissions will be used instead of the ACLs. To ensure this does not occur, the root folder of the objects being restored must not exist prior to restoring.
- Make sure that the "overwrite" option is used with the file restore from the advanced restore options menu.
Other ACL restore options:
For VM or image backup types a user may do one of the following:
- restore the entire machine to a prior point in time to production.
OR
- Access the original machine and remove from it the disk containing the data to recover. The entire disk must be removed from the VM not just partitions. This cannot be done for paths on partitions on the disk containing boot/system/OS data. The disk must be connected to the original machine to move the ACL and 2 disks with the same ID cannot co-exist in windows. Your restored disk will have the same volume ID creating a conflict if the original disk can't first be removed.
- perform a FLR restore of the VM/image backup from the chosen RPO in the Unitrends Appliance.
- Connect the original machine to the iSCSI FLR instance and connect the disk to access data from.
- Copy the needed contents from the original disk to a new or temporary disk in the server. The entire root path containing the data needed must be copied in this way. When copying, the root folder you are copying must not already exist in partition the data is copied to.
- disconnect the iSCSI connection from the windows machine and tear down the Unitrends FLR when the copy is completed.
- Optionally reconnect the original disk detached above to the windows machine then move the data to the original partition. To move data back to it's original path on the original disk, you must delete the paths from the root of the disk being recovered before copying data from the temporary disk back to the original path.
Note the above processes will restore the file/folder permissions. However, if a path is shared, share level permissions are not restored in this way. the only way to recover share level permissions is through OS-level restore of the machine through BareMetal or full server restore of a VM or image backup. ADFS shares are maintained in active directory itself and not in the original server.
CAUSE
This behavior is by design of the Microsoft Windows operating system. It prevents restored files from having permissions that conflict with, or do not exist, on the server to which the files are restored, such as when recovering a file to an alternate path or a path containing existing files. Windows removes the permissions on those files and applies the current inherited permissions of the folder to ensure conflicts are not created. This is the same behavior seen when copying a file to a share from one server to another. Unitrends Agent cannot override this process as it is enforced by Windows itself after the data is sent.