TIH 2016 Fails to Backup Win10 OS Partition Ver 1511 Bld 10586.3

Steve, try making a backup with the ATIH 2016 rescue media instead.  It won't solve your problem, but you'll have a recent backup as a saftey net.

David

Steve,

We know that the program gets involved in all partitions--much more than just the data being backed up.

I would run an error check on any other partitions on the source disk, and that error check should include any without drive letters.

Acronis is notorious for not providing informational error messages.  Is there any possibility that the storage disk had a lack of space issue?

Does the log file provide any more info about the error--perhaps in prior backups?

Review the Windows logs for info about the disk error check results.

I am just checking the obvious --not any known solution.

David,  Thanks for your suggestion.  I'll give that a try !

Grover,  thank you for the reply.  I will re-run the chkdsk for each disk.  There are no hidden partitions on either Disk 1 or 2.

I'll see if I can find the log files after the next test or two.  For clarity, here is the simple setup.

Disk 1 originated as a new clean disk, not oem.  Windows 8.1 was installed last year and then followed up with the Win10 upgrade and more recently as the Win10 ver. 1115 update. 

Disk 1: Capacity: 1TB, 2 partitions"  C: 540gb with 91gb used  and M: Partition (data): 390gb  20gb used, 370gb free.

Disk 2: Capacity: 1 TB  Used Space:502gb  Free: 498gb  One Partition  TIH backup storage only.

Chkdsk with the "f" switch reported no errors for either disk.

I will be testing again over the next hour.

Thankyou for your comments and assistance.

Steve

David,  Thanks for your suggestion.  I'll give that a try !

Grover,  thank you for the reply.  I will re-run the chkdsk for each disk.  There are no hidden partitions on either Disk 1 or 2.

I'll see if I can find the log files after the next test or two.  For clarity, here is the simple setup.

Disk 1 originated as a new clean disk, not oem.  Windows 8.1 was installed last year and then followed up with the Win10 upgrade and more recently as the Win10 ver. 1115 update. 

Disk 1: Capacity: 1TB, 2 partitions"  C: 540gb with 91gb used  and M: Partition (data): 390gb  20gb used, 370gb free.

Disk 2: Capacity: 1 TB  Used Space:502gb  Free: 498gb  One Partition  TIH backup storage only.

Chkdsk with the "f" switch reported no errors for either disk.

I will be testing again over the next hour.

Thankyou for your comments and assistance.

Steve

Darn.... That double posted... sorry folks...If I could delete, I would.

Steve

Just a "just in case" note.  As it appears, you have more than one internal disk, so

you should not use the option "Backup Entire PC" as that option will  include ALL internal disks and be twice as large as expected.

If you have more than one internal disk, you may need to use the "disk & partition" option.

Grover,

Thanks for the reply.   All of my tasks are partition or file backup.

The OS task in question is a partition "c:" only task.  The other taks I have are also partition or file only tasks.

So, I really only have 2 general tasks also more are showing in my attached photo sent earlier.  They are basically data backups and an occassional OS backup.  All other tasks are performing ok.  It is only the OS backup that seems to have failed.

I have killed task, created a new one (several times), pointed the backup to a new destination etc..etc...

Nothing seems to work.  I end up with the same error.  Anyway.. I am going to log out and do the chkdsk again and then attempt a boot to media backup of my C; partition so I have a save backup... I'll report back as soon as completed.

Thank you all so very much for your comments !

Steve

Hello all,

Booting from the TIH Rescue Media ver 5634 resulted in a good backup of the "C:" Win10 ver 1115 partition.

Later, I will execute a recovery, using the recovery media to a new, empty HD.  I suspect the recovery will be successful but will still leave me in a situation where a Win10 originated OS C: partition backup fails.  Begining to wonder if I need to uninstall TIH2016, Re-install and the favored method to do that. ??

Steve

Another test completed:

Restoring the newly created C: partition OS backup from the boot media was successful.

It took 14 minutes to restore a 70gig C: drive OS Win10 ver 1115 partition to a new, blank HDD.

So, what does that tell us... Nothing wrong with the source selection and nothing wrong with the destination selection.

Still, the error persists:  Cannot create a C: drive OS partition backup from within Win10 ver 1115 with a destination the same as the recovery media backup performed about an hour ago.

I will try one more time to create the OS partition backup.  I'll create a new task (C partition with option defaults) , select the same destination drive as described earlier and see what happens.

Steve

Well, same results...

Created a NEW OS partition task, used defaults, set destination and executed.

Backup failed.

the process executed about 3-4 minutes with heavy disk usage as indicated with steady on HD activity light.

then after about 4 minutes, only an occassional blink, then the error message popped up.

I have included a screen image of the test just starting and when error pops up.

Steve

 If the disks are spin type rather than SSD, I would check for disk errors rather than file errors.

CHKDSK C: /R

One of the KB items indicated on place to look was permission issues for whatever that might be.

https://kb.acronis.com/content/46893

Grover,  Thank you for your assistance.

I will run the chkdsk c: /r  against the C; partition and test again.

Note that the earlier test using the recovery media to create the backup and restore the backup was successful.

If there were disk errors, shouldn't that have been a problem when using the recovery media too ?

Back soon, thanks !

Steve

Grover,  yes the HDD's are spin not SSD.

Well, the chkdsk c: /r has been running for some time now...

Makes me nervous.

Scanning and repairing drive c: went from 0 to 11% fairly quickly then for the past 20 minutes or so has been sitting dead on 11%.  HDD activity light solid on with an occassional flicker.

Oh gee...that OS partition is my main squeeze !  Sure glad I made a tested backup this morning with the recovery media

Still... the solid drive light and 11% has me pretty nervous.  I am going to need that computer in an hour or so.

Steve

Oh gee...what have I done...

The chkdsk with the /r option has been running for about an hour now... HDD activity light still solid on, still at 11%

Talk about nervous... This cannot be correct.

Anyone chime in ... If nothing changes, will it be safe to ABORT this chkdsk with the power off button.

Still solid hdd light and holding at 11%.

This is worse than being in a weather holding pattern at LAX .

Steve

May not be related, but the update to 1511 put my systems into the compact state.  Macrium Reflect made me aware of this change when I created new resue media following today's patch.  The prompt said I would need to create my rescue media using WinPE 10 because the OS was in the compact state.  The following command can be used to check your systems.  Again it may not be related to your issue, but many Windows 10 users may not be aware of this change to their systems.

compact /compactos:query

Joey,  thank you for the reply.

The running chkdsk /r finally completed with no reported errors.

It was STUCK at 11% for over an hour but in actuality it was NOT really stuck and did complete.

I ran the compact query on this computer and the one I am having difficulty with.

This one (one I am using to type this message) report that is is NOT in the comact state.  The Winver is 10

The computer with the backup trouble reports that it IS in the compact state and is Win10 ver 1115.

the query states that the OS IS in the compact state and will remain that way until an admin changes it.

Now wondering if the "Compact State" has affected by ability to backup the OS.

We were not having any trouble backing up the Win10 OS partition prior to the upgrade.

Interesting.... I was not aware of this change and do not really know what the "Compact OS" is ...

Hope others chime in

Steve

Compact OS is a Win 10 tool that can be used to compress an entire OS or single instance files and then use those files or run the OS in this compressed state.

See this link for more details:

http://www.tenforums.com/tutorials/22088-compact-os-compress-uncompress…

Enchantech,

Thanks for your reply.

I am now wondering if the compressed state of my Win10 ver 1115 is the reason my Win10 OS partition backup is failiing.  See earlier posts and photos.  Have you heard anyone else complaining about a Win10 ver 1115 OS backup ?

Backups of our data partition, on the same disk as the Win OS have not experienced any trouble.

The trouble began on our very first backup of Win10 Ver 1115.  Prior backups were fine.

Afterthought:  I suppose I could run the "Un-Compress" routine and see if the backup can be completed without error.  Note that in an earlier post here that I did have a successful backup using the recovery media.  The backup only fails when executed from within the win 10 ver 1115 environment..

Steve

Well, no success. 

I have disabled the OS compression and the Win10 ver 1115 is now in un-compressed mode.

TIH2016 is still failing to create a new backup of the Win10 ver 1115 OS partition.

Backup creation with the restore media works and restores to a test disk without error.

Anyone else having trouble creating a new backup with Win10 ver 1115 ??

Data backups from a different partition have been unaffected.

Steve

To the best of my knowledge you are the first to report such issue with Win 10 any version.  What I do not understand is why the upgrade defaulted to a compressed state.  I have upgraded myself 3 machines and have not run into this issue.

I suspect that True Image cannot deal with the compression routine used by Windows CompactOS.  It certainly appears that way in your case.  I think you could verify this by "Un-Compress" and attempt backup again.  If successful I think that would verify that there is a problem with that.  At this point I do not know very much about this compression routine but it is reliant on the NTFS file system and that may have something to do with your issue and also may explain why recovery media was successful in creating a backup of the partition.

This is all quite interesting and I intend to do some research on it as time permits.

Enchantech,

You must have been posting about the same time I was reporting the continued failiure even after Un-Compressing the Win10.

I re-checked the OS and it is, in fact, in Un-Compressed mode.

Oh...and yes, I did not initiate the CompressOS mode.  It probably happend during an upgrade.  Just not sure.

The backup failure continues.  I create a new backup task each time I attempt a new backup.

I select Diff scheme and take all the defualts.   The failure is the same as reported earlier with screen shots.

I appreciate your interest and hope someone may run across the same issue.

In the meantime, I can run OS backups using the recovery media.

Data backups from a different partition on the same disk completes with no error.  Only the OS backup is failing.

Happy that I have a data partition, away from the OS, where all work is stored and diff. backups continue without error.

I thank you for your assistance and look forward to hearing from you concerning this issue.

Steve

Steve,

Well that is quite interesting indeed.  The fact that the error continues might lead to a different direction.  I will see what I can dig up.  Will get out the old mining tools as it were!  I will post back when I have more.

Enchantech,

Thank you !

Not to wish ill on anyone else, but I am hoping that I am not the only one seeing this problem.

Look forward to hearing back from you and others.

Many Thanks !

Steve

Steve,

I have found an article from Microsoft that explains how and why your system has/had CompactOS enabled.  Excerpt from the article.  "Since a diversity of Windows devices exist, Windows 10 performs this suitability assessment in the upgrade path.  If compressed system files will give you storage capacity back without compromising your device’s responsiveness, then upgrade will automatically compress Windows 10. For new Windows 10 devices, manufacturers perform the suitability assessment and enable system compression appropriately."

Complete article link:  https://blogs.windows.com/windowsexperience/2015/03/16/how-windows-10-a…

Thank you Microsoft for thinking for us dumb users once again!  I can certainly understand the implementation of this compression scheme on devices with limited storage space such as mobile devices but desktops!  You have got to be kidding me! 

It sure looks like that a Windows 10 upgrade will assess your device and if it determines that you can benefit from OS compression you automatically get it!  Well, I have not had time to check my systems yet to see if in fact this has happened to me.  I certainly hope not because I for one will undo that immediately. User choice needs to be in place here in my opinion! 

Won't the OEM's have fun with this jewel!!

Steve,

I had another look at your posts and the error message you received indicates the backup file as being accessed by some other application.  I wonder if in your test to disable CompactOS did you restart your PC after making the change?  I have a feeling that such a change would need a restart in order to become in effect.  If you did not restart the machine that might be the reason for the second failure.

I'm wondering if the new service may also be involved.  Try disabling when you get done with all your other testing.

Acronis Managed Machine Service Mini

https://kb.acronis.com/content/56697

Some very nice postings from MVP Enchantech.

Hello Enchantech and Grover,

Thank you for the posts.

The "forced" CompactOS saved me about 3 gig... WOW..

Current OS partition: 540gig   Used Space: 90gb    Free Space: 450gb

I did reboot after changing the settings back to   compactos never.

The process, run under the command promt as Admin, took about 20 minutes to accomplish.

The backup test after the re-boot gave the same failure results.

I am going to create a new task in a few minutes and test again.

I'll report the findings.

I am very appreciative of your effots to understand and resolve this problem.

As a reminder, this failure only happens when backing up the OS partition.

Backing up the Data Partition (On the same disk) is successful.

Steve

If you don't plan on reverting to the previous build you can do a disk cleanup on C: to free up about 6GB.

Try running the backkup with your AV disabled.

Steve,

I have to say here that I agree with Grover.  Your error message indicates that another application is accessing the backup file while the backup is in progress.  Logically this would point to an anti-virus or possibly certain malware applications that see the backup being run as a threat and is/are actively tracking what is going on to a point where the app halts the backup process which in turn causes TI to output the error.

Having said that, it is possible I suppose that Win 10 CompactOS is at root cause here but probably not very likely.  I would think that if CompactOS were at root here it would be because of conflicting compression algorythms.  If that were the case the backup should fail immediately upon execution. 

Question, have you setup any Windows System Maintenence to run which could conflict with the backup?  In reading your posts I think this very unlikely as well.  Bottom line here is we are looking for another installed application or a possible process that intrudes upon the backup task by attempting to or gaining access to the backup file being generated.  Again this points heavily toward anti-virus/malware apps as they are designed to do just that.

As for CompactOS, as I said earlier I can see legitimate use for such a feature but allowing Windows upgrade to be the judge I am in disagreement with!  I have had oppurtunity to check 2 of my 3 Win 10 installs all of which have been upgraded with the latest build 10586.  One of those was indeed converted to CompactOS.  That install is on my test bench machine which is running an Asus Z97 Deluxe board, an i5 4690K CPU, 16GB of G.Skill 2400 DDR3 ram and an assortment of SSD's and HDD's.  This machine was built with high performance in mind and it is just that.  Being that is the case Win 10 upgrade decided that this machine could handle the performance hit of using CompactOS and indeed it can.  Problem is I do NOT want it to!!  I did not spend extra dollars on top end hardware to have my OS assess a peformance hit on my rig just because it can handle it!! 

So I too ran the NEVER option to disable CompactOS.  In my case the process took about 10 minutes decompressing over 15,900 files.  Now once that process completed I closed the command prompt windows and selected reboot.  Machine did reboot to the Welcome screen but my wired USB keyboard would not function, my wireless USB mouse would.  So I chose Shutdown and the machine did shutdown however, my keyboard remained powered on so I shutoff the power supply to kill power to the entire machine.  Once that was done I restored power and restarted the machine and everything worked as it should.  Now I must say that startup did seem a bit faster than it had been before but not by a huge amount.  Not having a lot of time to test things out I only performed a few simple things like open an Explorer window, task manager, control panel, etc..  All of these functions showed a nice improvement in load/response time.  When I finally shutdown the machine the shutdown was almost instant whereas before it would take 10 to 20 seconds to accomplish.

So my experience so far has shown that if it is performance you are after do not use CompactOS! 

Hello Nils, Grover and Enchantech
Thank you all for so much assistance and effort to isolate this problem
I am feeling a bit "Dumbed Out" here... I feel that I may have stubled upon the problem today.
Believe me, it was only a stumble. 

I was insistant on finding out why the backup failed and disregarded a simple test.
I create a new task and created a NEW destination folder on the same drive.
I executed the backup and viola, the NEW OS backup task was successful.
So, I created a second backup task, pointed to another new folder on the same dive and it was also successful.

So, I created a new task and pointed it to the suspect folder and VIOLA, It failed.

Now the kicker... I re-executed an existing OS backup task (shown in the attached photo as : Win10_Alt) and it was also successful.

At this point, I am thinking this was only a "Rights" problem.  If so, TIH2016 should have alerted me to that.
Their error message was telling us that the file was in use... not possible, since there was no file there to be "In Use".

So, bottom line... I can continue with backups and it appearts that I can be successful if I avoid and delete the questionable folder.
I feel that this problem may come up again.  I have only had ONE login on this machine since it was created with a Win8.1 disc.  Always use the same login and that login is an admin.
Since I am the only one creating any folder on this machine... duh.. how can this have been a rights problem.

Action:  I am going to deleted the suspect folder and continue to test for the next 3 or 4 days.
If I have any trouble, or find something new, I will post promptly.

Oh, I never addressed your questions:  I am using Windows Defender (now, don't laugh) and the free Malwarebytes, manually run once or twice a week.
I have no maintenance schedule set up, not to say Mr. MS isn't sneaking stuff in here and there.

Hopefully, this thread wont slide too far into oblivion before we are sure of the problem.

I am so very grateful for everyone's , extremely well written, replies !
and...for the continuing assistance.

Thank you !
Steve

Steve,

Glad you got it sorted out.  That's a good thing!  I suspose you have already deleted the offending folder but I think it would be interesting to see what the Properties were for that folder vs a folder that works.  Might just shed some light on the issue.  Another thought is that of this problem folder being open in another application such as File Explorer while attempting to backup to it. 

At any rate glad you got it sorted!

Enchantech,

I did not delete the folder yet and have included a screen capture of the properties of the bad folder and a good folder.

I see what you mean.  there is a difference.   One has "System" privideges and the other does not.

One might think that TIH2016 should have caught that error condition and alerted me with a message that indicated a possible rights problem ?

Anyway, attached is a screen shot that you may be interested in seeing.

I look forward to your comments !

and...Thank you so very much for your interest in this little issue.

Steve

Steve,

I had a look at your screenshots.  Interesting indeed!  It looks like a permissions issue may well be the root.  I take it that your install is Win 10 Pro?  I ask because my install on which I found the CompactOS enabled is a Win 10 Pro.  I have done some testing on my install.  I wanted to see how creating a destination folder may have an effect on permissions if any.  What I found on my system is there was not.  I created test destination folders using Windows File Explorer and the TI 2016 app and checked the effective permissions for both.  There was no difference.

Where I do see a difference is that on this machine my folders have the following Group of user names: Authenticatied Users, SYSTEM, Administrators, Users, in that order.  Both SYSTEM and Administrators hold the same effective permissions which is all but Special Permissions, this is what I would expect to see.  Authenticated Users lack Full Control and Users only have Read & execute, List folder contents, and Read, which is also what I would expect to see.

I believe the Authenticated Users Group is there because I have Sharing enabled on the machine.  This Group gives permissions to logon using credentials.  If you have not setup your machine for this you would not have this Group so I am assuming that is the case.

In your screenshots I cannot tell which listed user is selected for the screenshot.  I am assuming that the numbered user is selected in bad and SYSTEM in the good.  Thus, in the bad screenshot the numbered user has all effective permissions enabled whereas in the good screenshot it appears the SYSTEM has NO effective permissions so I assime that the permissions that should be enabled for SYSTEM have been assumed by the numbered user. 

This numbered user account is bit of a mystery.  Has your machine ever been part of a Domain?  The S-1-5-21 starting sequence suggests this Domain question however that may not be necessarily so.  Often times such numbered accounts are leftovers from deleted user accounts of old accounts brought into the machine for instance when a disk is originally used in a machine and then is later transferred to another machine.  Now I am not sure if an upgrade from say Win 8 to Win 10 would do that.  I do not think so but I am not sure.

I do not wish to alarm you with this but you should know that some virus/malware are known to create user accounts like this as well although those occurrances happened many years ago and I have not heard of anything like that recently still, it would be prudent to run scans on your machine!

Such numbered accounts are usually SID numbers assigned by Windows to an account.  You can see these under User Profilelist in Windows Registry for example and can also see the user or account name associated with the SID there.

So enough background info, I would do some checking though on that numbered user account.  I think your problem with TI 2016 here is the fact that for the bad folder there is no Administrators (Win10PRO\Administrators) user account listed.  This would be the account that 2016 would use for establishing permissions I would think.  So another question, when you created this bad folder where you logged on as another user?  Possibly from another machine using a logon credential over a network which is possibly a Domain?  Probably not likely I would think.

Looking forward to any new details you can discover in this.  Happy Hunting!

EDIT: If you care to experiment you can add the Administrators (Win10PRO\Administrators) to the bad folder and see if that fixes the problem with TI 2016.  I am thinking it will.

Enchantech,

Yes, the install was Win10 pro, originating from the upgrade from Win8.1 pro.

I only have one login on this machine.  Well there is an Administrator login... but never used.  I have only used this one login.

I think you are exactly correct about adding the Win10Pro Admin to teh bad folder and fixing it.

I agree with you.  After looking at the security for some of the existing folders, I see some with my login (the S-1-5-21...) only, some system and Administrators etc... I really do not know how this got to be all jumbled up.   I have had the same login on this machine for a couple of years, machine not on a domain and I am the only user.  I am wondering if running the chkdsk /f and /r functions a couple of times in the past 2 weeks messed something up.  That was done in between the good OS backups and this failure.  The data backups (on a diff partition)  continued to be good but they were using a different storage folder.  Maybe it was something else but I think you are right.  This is a rights issue that was created, either by a system upgrade process or running the chkdsk function several times.  I think my best course of action at this point is to create a whole new storage backup structure and verify that the folder rights look correct before re-creating any backups.

One thig is for sure... This was not created from me messing around with rights or user accounts. My account has been stable on this machine for quite some time.  

I think I will take your advice, assume it is a rights issue, re-establish known good folders and re-create backups.

I am going to go ahead and delete all the questionable folders after setting up and testing new backups.

I only do 4 backups for this machine:  The OS partition, 2 seperate tasks ( A & B) in differential mode and 2 tasks for the Data partition, also done in differential mode.  All manual, no auto.

Thank you for all the pointers and advice.  and YES YES... I will definately run anti virus checks on the entire machine before proceeding.

If all goes well without any hitch for a week or so, I will be pretty confident that this was a rights error, nothing to do with TIH and be a bit more aware of what to look for.

I really appreciate your advice and help !  Some of us would be in quite the mess without the great volunteers here on the forum.

Acronis should send you and a lot of other volunteers on a free holiday vacation for all the time and effort you spend helping !!

THANK YOU !

Steve

Glad that you are able to get some resolution.

Questions:

1. When installIng  which option is used:

Is TI installed for a single user or installed for all users? I am aware that you are the sole user.

2. Is the storage disk used for backup storage of other computeres,

or stated another way, is the storage disk attached to other computers so other computers may also be creatiing folders?

Grover

Grover, Hello !

1. TI was installed for all users.

2. The internal storage disk is only used for backup on this computer.

No other computer has access to this machine.  Well it is connected to the internet so who knows "who" at microsoft is peeping...ha

Since I am here, I will report current progress and tests: 

I took Enchantech's advice and did a bunch of testing and backups.

Machine:  2 Internal sata:  Disk 1: Win10 OS Partition and Data Partition    Disk 2: Backup Storage Only

Completed Anti-Virus checks.

Created a NEW backup storage folder and checked rights: all appear normal.

Created 4 new tasks:  2ea for the Win10 OS and 2ea for the Data Partition on the same disk as OS   All 4 tasks are manual, differential, no-auto cleanup.

Executed all 4 tasks one at a time: All completed normally

Deleted ALL OLD TIH2016 tasks and verified with Win explorer that all of the old backups were deleted.

Deleted ALL of the OLD Problem Folders.

Made a small file change in the Data partition and re-executed my "Win10_Data_A" task: completed normally.

At this point, everything seems to work as advertised. 

I feel that TIH2016 should have caught that type of error.  I appears to be a simple case of TIH cannot write to an existing folder that it may have had access to at some point earlier.   If that is the case, based on the error reported, TIH should have alerted the user that it cannot complete the task at hand because it cannot wite there instead of suggesting that some other application was using a TIH file that did not even exist.

The most important issue is that my backups are now functional again.

Next test: Tomorrow: Restore OS and Data to a New HD.   I am ready to go with that one.  No backup is worth a penny if it cannot be 100% restored and bootable.  I will report the results here.

Thanks for all you do to help us in need ! 

Steve

Update to previous post:

Action: TIH2016 Restore a Win10 partition to a new blank disk.

Booted with the TIH2016 recovery media, restored the Win10 partition, booted, Win10 restore was perfect.

Started TIH2016 in Win10, restored the Data partiton, perfect restore.

I am, once again, a very happy camper.

Steve

Steve,

Gald to see you got it sorted.  I still do not understand why the error you were given leads one down the path of another program or process accessing the backup file.  You should be getting a not sufficient privledges message.

Enchantech,

I agree with you.  The screen shot os_backup111715b.jpg

shown in an earlier post reports an error of a file in use by another application.  In fact, that file was not yet created as TIH2016 was trying to create the backup using that file name.  There were no files in the folder at the time this error was generated.

Acronis should take a look at that and maybe re-visit their error catching routines.

If I had been given an error code similar to:  "Cannot Write to the Destination Folder" it would have been a no brainer to troubleshoot.

Have a Great Weekend !

Steve