NTFS Permissions on Restore
OK.
This seems simple.
I performed a Test Restore from an external HDD for a single user to an internal HDD on one of our servers. The restore was successful for 138,000 files in 3,100 folders for a total of 42GB but...
There were a handful of folders (perhaps 5-6) that the restore failed for claiming...
"Access is Denied".
The restore was done "retaining permissions". I checked the destination folder and it was indeed empty but the permissions were the same as folders above it that did restore successfully (permissions were inherited). Further, the account the restore was run from had administrator rights.
Any idea of why this would be a problem considering the above details? I suppose I could have tried a restore ignoring the current permissions but I wanted to test both the restoration and retention of original permissions.
This seems simple.
I performed a Test Restore from an external HDD for a single user to an internal HDD on one of our servers. The restore was successful for 138,000 files in 3,100 folders for a total of 42GB but...
There were a handful of folders (perhaps 5-6) that the restore failed for claiming...
"Access is Denied".
The restore was done "retaining permissions". I checked the destination folder and it was indeed empty but the permissions were the same as folders above it that did restore successfully (permissions were inherited). Further, the account the restore was run from had administrator rights.
Any idea of why this would be a problem considering the above details? I suppose I could have tried a restore ignoring the current permissions but I wanted to test both the restoration and retention of original permissions.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Would I be able to restore ignoring permissions and then move the files into a properly configured folder structure? Or would those files retain the new permissions assigned during the restore?
Note - The original files are not available for me to check for any special permissions. I have only the backup archive generated by MS Server 2003's BU Utility.
Note - The original files are not available for me to check for any special permissions. I have only the backup archive generated by MS Server 2003's BU Utility.
Never used MS b/u utility so I couldnt say yes or no for sure. But if folders were to be stripped of the proper domain/admin permissions, its basically untouchable by domain resources.
ASKER
Re: Stripped of access by domain resources.
Indeed. But would a subsequent move of those files into a folder structure with the proper permissions then restore 'normal' access?
If not, would the domain user - or an administrator be able to restore ownership within the advanced security tab for owner?
Indeed. But would a subsequent move of those files into a folder structure with the proper permissions then restore 'normal' access?
If not, would the domain user - or an administrator be able to restore ownership within the advanced security tab for owner?
ASKER
Deleted the restore and reran the restore requesting that permissions be removed. The same folders failed despite requesting removal of security permissions. Am I missing something (simple)!?
before restoring, take a look at those file 5 or 6 folders you are having problems with. Compare those folders security permissions with any folder that you CAN restore. Any differences?
ASKER
Thanks, but...
Would have done this but cannot (See 11.05.2008 at 10:51AM EST comment above).
Still expected removal of security permissions would have resolved issue. It IS likely that this data was copied from a users local system to the server as backup but it is only certain directories (often pictures for some reason) that will not restore. The remainder of the data restores without problem. I actually doubt that the users' set any special permissions on some folders.
Would have done this but cannot (See 11.05.2008 at 10:51AM EST comment above).
Still expected removal of security permissions would have resolved issue. It IS likely that this data was copied from a users local system to the server as backup but it is only certain directories (often pictures for some reason) that will not restore. The remainder of the data restores without problem. I actually doubt that the users' set any special permissions on some folders.
ASKER
Any other comments/advice?
I'm a bit intrigued by this, though it sounds like you can't verify permissions on those folders, correct?
Or is this a typical scenario for user's pictures folders?
What I've often seen for scenarious like this is that a user will know 'just enough to be dangerous' and try (if allowed) to change the permissions on their extra-sensitive data (i.e personal photos on a business PC). They think they're selectively removing everyone but themself from access, but in the process also remove the all-important system account - which isn't a user, it's the local system authority that should never have access revoked - particularly for cases like this.
If there's no way to check the original source data at this point though, I'm not sure there's much else you can do to resolve it - you've tried both options for restoring (with and without perms), so if you're only operating from a backup object, there's nothing more to do.
If however, you can somehow reproduce this with this same user's data, or another user's, then we may be able to get to the bottom of it, clean it up, and prevent it from reoccuring in the future...
Or is this a typical scenario for user's pictures folders?
What I've often seen for scenarious like this is that a user will know 'just enough to be dangerous' and try (if allowed) to change the permissions on their extra-sensitive data (i.e personal photos on a business PC). They think they're selectively removing everyone but themself from access, but in the process also remove the all-important system account - which isn't a user, it's the local system authority that should never have access revoked - particularly for cases like this.
If there's no way to check the original source data at this point though, I'm not sure there's much else you can do to resolve it - you've tried both options for restoring (with and without perms), so if you're only operating from a backup object, there's nothing more to do.
If however, you can somehow reproduce this with this same user's data, or another user's, then we may be able to get to the bottom of it, clean it up, and prevent it from reoccuring in the future...
Can you post the log for the restore?
ASKER
sirbounty.
Correct. The data is in the backup only and not available to check the source folders or change their ownership. It was originally stored on the file server BUT it appears that the data was copied there from a local users' machine.
In this case, the user made significant changes to their data before they left but there is no suspicion of anything bad going on. Still, some data contained in the backup before reorganization (and deletions) may be important to others so I wanted to pull it off the backup before I have to rotate the backup to a new copy which will ensure its loss, of course.
Since 99% of the data restored successfully I do not actually expect that any permissions were changed or it would have affected more than just these. This is more of a concern for restoring data backups in general as I do not like surprises! <grin>
Besides - I would really have expected to be able to restore the data as a system administrator - especially since there was no error reported in backing it up in the first place.
Does this help clarify?
Correct. The data is in the backup only and not available to check the source folders or change their ownership. It was originally stored on the file server BUT it appears that the data was copied there from a local users' machine.
In this case, the user made significant changes to their data before they left but there is no suspicion of anything bad going on. Still, some data contained in the backup before reorganization (and deletions) may be important to others so I wanted to pull it off the backup before I have to rotate the backup to a new copy which will ensure its loss, of course.
Since 99% of the data restored successfully I do not actually expect that any permissions were changed or it would have affected more than just these. This is more of a concern for restoring data backups in general as I do not like surprises! <grin>
Besides - I would really have expected to be able to restore the data as a system administrator - especially since there was no error reported in backing it up in the first place.
Does this help clarify?
ASKER
honmapog.
It was actually initially done to extract a specific users' data (see above) that has left and, more importantly, as a test to assure all was OK for recovery purposes. Because it was not a full restore due to errors I removed the data. I will run it again to obtain the logs but there was not much detail other than the access rights error.
It was actually initially done to extract a specific users' data (see above) that has left and, more importantly, as a test to assure all was OK for recovery purposes. Because it was not a full restore due to errors I removed the data. I will run it again to obtain the logs but there was not much detail other than the access rights error.
Yes, any Backup operator should be able to perform the restore - typically this sounds like a permissions problem though. Perhaps on the destination/target path? Really not sure - it's an odd scenario, to be sure...
ASKER
sirbounty
Yep... thought it might have been a problem on the destination drive but it would not make sense that everything else restored as the directory structure is created by the restore process itself.
Checked it anyway after the restore to see if the permissions were different in the parent directories where the restore should have occurred and they weren't.
I have scheduled another attempt so we'll see what happens and I will post the log if needed. I will not have any additional info until next week.
Yep... thought it might have been a problem on the destination drive but it would not make sense that everything else restored as the directory structure is created by the restore process itself.
Checked it anyway after the restore to see if the permissions were different in the parent directories where the restore should have occurred and they weren't.
I have scheduled another attempt so we'll see what happens and I will post the log if needed. I will not have any additional info until next week.
ASKER
Hi.
Here's a copy of a portion of the log after a restore... there were further entries stating the same due to restoration attempts of incremental backups but this is the most important as the initial restore set.
Although this is reporting directories that have failed - note that the majority of the nearly 136,000 files did restore successfully and that the failed directories did not compose a large portion of the files.
#####
Restore Status
Operation: Restore
Backup of "E: UACS2-E", Restored to"F: UACS2-F\RESTORE TESTS\"
Backup set #1 on media #1
Backup description: "Set created 01/13/2008 at 12:49 PM"
Restore started on 11/27/2008 at 05:06 PM.
Restore completed on 11/27/2008 at 05:59 PM.
Directories: 1346
Files: 135632
Bytes: 27,979,910,351
Time: 52 minutes and 48 seconds
Backup of "E: UACS2-E", Restored to"F: UACS2-F\RESTORE TESTS\"
Backup set #2 on media #1
Backup description: "Set created 01/28/2008 at 06:36 PM"
Restore started on 11/27/2008 at 05:59 PM.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\PRIVATE
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\PRIVATE
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\PRIVATE
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\PRIVATE
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\PRIVATE
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\SHARED\
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\SHARED\
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\SHARED\
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\SHARED\
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\SHARED\
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\SHARED\
Reason: Access is denied.
#####
Here's a copy of a portion of the log after a restore... there were further entries stating the same due to restoration attempts of incremental backups but this is the most important as the initial restore set.
Although this is reporting directories that have failed - note that the majority of the nearly 136,000 files did restore successfully and that the failed directories did not compose a large portion of the files.
#####
Restore Status
Operation: Restore
Backup of "E: UACS2-E", Restored to"F: UACS2-F\RESTORE TESTS\"
Backup set #1 on media #1
Backup description: "Set created 01/13/2008 at 12:49 PM"
Restore started on 11/27/2008 at 05:06 PM.
Restore completed on 11/27/2008 at 05:59 PM.
Directories: 1346
Files: 135632
Bytes: 27,979,910,351
Time: 52 minutes and 48 seconds
Backup of "E: UACS2-E", Restored to"F: UACS2-F\RESTORE TESTS\"
Backup set #2 on media #1
Backup description: "Set created 01/28/2008 at 06:36 PM"
Restore started on 11/27/2008 at 05:59 PM.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\PRIVATE
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\PRIVATE
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\PRIVATE
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\PRIVATE
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\PRIVATE
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\SHARED\
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\SHARED\
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\SHARED\
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\SHARED\
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\SHARED\
Reason: Access is denied.
Warning: Unable to write data to "F:\RESTORE TESTS\Users\ReganN\SHARED\
Reason: Access is denied.
#####
...and I don't suppose it's a quota limitation that's been exceeded or a disk capacity issue?
ASKER
Nope. No quotas on this disk. It is a non-shared local drive without Quota Management.
I find it very strange that most of the failed directories contain "Pictures" as part of the path name yet (I believe) there are others that did restore.
Clearly this is a permissions issue of some sort but I am not sure of why the server admin account would not override the restriction.
I find it very strange that most of the failed directories contain "Pictures" as part of the path name yet (I believe) there are others that did restore.
Clearly this is a permissions issue of some sort but I am not sure of why the server admin account would not override the restriction.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Absolutely - the restore was redirected as I have a test location I can write to. I do this occassionally in hopes I do not have any nasty surprises if I do need to restore to actual file server shares.
Not sure if I have adequate space in another location but I can check that.
No ideas on why it would such a small and specific part of the restored data?
Not sure if I have adequate space in another location but I can check that.
No ideas on why it would such a small and specific part of the restored data?
No idea at all.
I'm not as familiar with MS backup, but have used several commercial products. Most of these use either a specific service account for this purpose, or the generic system account - both which should have rights to read (backup) and write (restore) to all locations, unless explicitly revoked.
Perhaps you or another expert can check the services list (Start->Run->services.msc <Enter>) to determine if there's an associative service that runs under a specific account - then double-check that account's permissions. From long ago when I was testing the native backup tool, I don't recall there being, but it's sure to have changed a bit since I last used it....
I'm not as familiar with MS backup, but have used several commercial products. Most of these use either a specific service account for this purpose, or the generic system account - both which should have rights to read (backup) and write (restore) to all locations, unless explicitly revoked.
Perhaps you or another expert can check the services list (Start->Run->services.msc <Enter>) to determine if there's an associative service that runs under a specific account - then double-check that account's permissions. From long ago when I was testing the native backup tool, I don't recall there being, but it's sure to have changed a bit since I last used it....
ASKER
Yes, there has to be a specific account for BU if another user is performing it in order that they have access rights to the files for BU purposes. But this restore is run from the same file server under the same account login that the BU was made in the first place. Doesn't make sense to me either.
I would use an alternative but this meets their budget currently (if youi know what I mean). Veritas had been used previously but it messed up bad causing inability to retrieve data at all. Since then I have not used it. What have you used?
I will still try and find the time to restore to an alternate location if I have adequate space....
I would use an alternative but this meets their budget currently (if youi know what I mean). Veritas had been used previously but it messed up bad causing inability to retrieve data at all. Since then I have not used it. What have you used?
I will still try and find the time to restore to an alternate location if I have adequate space....
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Well, Veritas has actually bought up others, so not sure which one you're referring to.
Currently using 6.x of Veritas Netbackup, but I've not liked this product since we first started using it several versions ago. It might be great for coders like myself, but those that know Perl. And I have scripted the install and initial configuration of this using vbscript, but sheesh, it took about 15 pages of code. Perhaps it's more manageable for Perl coders, I can't say.
I've also used the older Backup Exec, and found that to be the best from my perspective. I was able to programmatically report on job completions and automate other tasks - all from a much more intuitive, user-friendly interface (Netbackup, I find extremely cumbersome).
A couple others, including Arcserve, were used many moons ago, but none of these have displayed the odd behavior you're seeing here...(and I understand the budget scenario all too well). The native backup product should be good enough for a small office environment. That is to say, this isn't a normal behavior by any means - at least one that I've come across in my 15+ years of experience.
Will the product allow you to break down the restore - simply choosing one of those failing paths to try another redirected restore somewhere else (not all the way to the child Pictures folder, but perhaps its parent folder)?
Currently using 6.x of Veritas Netbackup, but I've not liked this product since we first started using it several versions ago. It might be great for coders like myself, but those that know Perl. And I have scripted the install and initial configuration of this using vbscript, but sheesh, it took about 15 pages of code. Perhaps it's more manageable for Perl coders, I can't say.
I've also used the older Backup Exec, and found that to be the best from my perspective. I was able to programmatically report on job completions and automate other tasks - all from a much more intuitive, user-friendly interface (Netbackup, I find extremely cumbersome).
A couple others, including Arcserve, were used many moons ago, but none of these have displayed the odd behavior you're seeing here...(and I understand the budget scenario all too well). The native backup product should be good enough for a small office environment. That is to say, this isn't a normal behavior by any means - at least one that I've come across in my 15+ years of experience.
Will the product allow you to break down the restore - simply choosing one of those failing paths to try another redirected restore somewhere else (not all the way to the child Pictures folder, but perhaps its parent folder)?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Interesting...
I routed the restore to an alternate drive location for ONE directory that reported it failed. It restored OK with no errors returned. So, naturally, I decided to do a full restore to the same drive and location for the users' data. It again reported errors as before which I found surprising so I checked further into a couple of the reported paths.
The files EXISTED as restored items despite the log details! I checked further to see if a single file had failed causing the reported "directory" error but there was no such issue. While I do believe that the original restore attempts did indeed not write any files to the stated directories it is possible that the error messages sent me on a goose chase as it got mixed up with attempts to locate the "problem".
Bottom line?
Restoring to an alternate drive and verifying data in the reported error paths would seem to be the best action. (by the way - the original restoration target did not have any permission issues).
Anyway - Thanks for all the input!!
I routed the restore to an alternate drive location for ONE directory that reported it failed. It restored OK with no errors returned. So, naturally, I decided to do a full restore to the same drive and location for the users' data. It again reported errors as before which I found surprising so I checked further into a couple of the reported paths.
The files EXISTED as restored items despite the log details! I checked further to see if a single file had failed causing the reported "directory" error but there was no such issue. While I do believe that the original restore attempts did indeed not write any files to the stated directories it is possible that the error messages sent me on a goose chase as it got mixed up with attempts to locate the "problem".
Bottom line?
Restoring to an alternate drive and verifying data in the reported error paths would seem to be the best action. (by the way - the original restoration target did not have any permission issues).
Anyway - Thanks for all the input!!
Yeah if the user edited those 5 or 6 folder to the point where only that user had access, that could happen. Again, I've seen this several times too...one of those intances the user was trying to hide pornography and mp3's. (Interesting mix, i know hehe)