Does a file/folder restore from a image based back-up recover NTFS permissions on Windows server?
Hello!
Currently, it doesn’t. We have a feature request for it, so, for now, we can say that it will be implemented in one of the nearest releases.
Ok thanks so if have a image based back-up it is not possible to restore only folders and files with ntfs permission
restore the complete image to the volume will restore ntfs permissions also?
Restoring the complete Image will restore the NTFS permissions as well.
This will be very nice, it saves a lot of time because now we have a image level AND file level backup, because sometimes a profiles gets corrupted and you want to restore only that profile we need NTFS permissions restore.
But now i’m trying to do a back-up with a lot of small files inside userprofiles and group shares and I think it’s almost impossible to use for arround1 TB of data. It says like 7 KB/s till max 1 MB/s. I did already increase the threats and this is only a test to a network share.
[reply=“QiQQ;848”] Unfortunately issues like that are almost unavoidable when dealing with small files and large data sets. If you’re backing up NTFS permissions and additionally use compression/encryption that makes things worse.
Yes I understand, but all are needed 
- NTFS permissions are always needed
- Encryption is also always needed
- Maybe not compression, but most clients like to pay less. Does compression take that much from the speed, also when CPU is almost doing nothing?
[reply=“QiQQ;858”] Even when copying such amount of files locally such speeds are expected. Encryption and NTFS permissions might not slow the operation down on a small scale, but when dealing with large quantities of files these options affect the upload.
[reply=“Matt;860”] Image based back-up will speed this up, but then it will be perfect to have the possibility to restore file level from the image (whats already possible), with an option to restore NTFS permissions from the image based back-up. So we can only restore some effected data.
Let’s say this scenario:
- A server with about 1 or 2 TB of data, a file level back-up will take forever. So we make a image based back-up from drive D
- Workstations are connected to the domain controller
- A user logs in with roaming profile and folder redirections
- The user is affected with e cryptowhere so files that have been affected:
- \data.client.domain.nl\profiles$%username%
- \data.client.domain.nl\users$%username%
- \data.client.domain.nl\dfs$\groupdata shares where the user has rights to let say:
– But the user don’t have rights to:
— \data.client.domain.nl\dfs$\administration
— \data.client.domain.nl\dfs$\direction
- So the only needed restores are:
- \data.client.domain.nl\profiles$%username%
- \data.client.domain.nl\users$%username%
- \data.client.domain.nl\dfs$\groupdata
- When having a file based back-up it’s easy to restore the affected share
- With image based back-up the complete drive needs to be restored, but users that have permissions to also have new files for that day:
- \data.client.domain.nl\dfs$\administration
- \data.client.domain.nl\dfs$\direction
- So now we have a problem, there a affected files from point 5 and changed files from point 7
Doing a full disk restore and replacement will lose files from point 7, so we only want to restore files from point 5 “WITH” NTFS permissions.
So having the possibility to restore NTFS permissions from image based back-up will be awesome and make the product perfect for simulair scenario’s.
[reply=“QiQQ;861”] Yes, I understand the situation and we’re working on that option.
[reply=“Matt;862”] Yes, I already read that above. I only wanted to explain a scenario, for other users to understand the reason why the ability to restore NTFS permissions is important
But that sounds very good and will help to make this product more powerful, good job!
But what do you advise? Enryption is now set to AES 256, NTFS permissions are backed-up and compression is enabled. NTFS and encryption is needed and maybe no compression, but that will make the data be a lot more.
[reply=“QiQQ;866”] Currently there’s no workaround for that, that’s simply how file transfers always worked everywhere.