WARNING: v11 restore from bootmode STILL produces "corrupt and unreadable" files!

This is a warning to all potential users of TrueImage -- a warning that Acronis should have given us all, instead of me having to corrupt my own disk and find out for myself.

There are serious unresolved, multi-year-old issues with restoring files from Acronis Startup Recovery Manager to NTFS disks. You should avoid this "feature" of Acronis entirely and either:

• do all your restores from Windows XP (which will work as long as your OS is still intact), or
• use the (rather technical) BartPE solution that Acronis offers, as explained at https://www.wilderssecurity.com/showthread.php?t=162424

I just downloaded Acronis TrueImage Home v10 build 8,101 to evaluate the product. I had had good experiences with other Acronis products and was hoping this worked well too.

I was shocked to find that during a simple test restore of a few files and folders, Acronis created corrupt files my hard drive and corrupted my NTFS filesystem's MFT. Some restored files have bad data, and some restored files I can neither access nor delete.

I was even more shocked to find that many people have been reporting reproducible cases of my problem since 2005, including these long threads from 2006 on (there are many more threads):

https://www.wilderssecurity.com/showthread.php?t=145505
https://www.wilderssecurity.com/showthread.php?t=207029
https://www.wilderssecurity.com/showthread.php?t=202587

It is clear from the threads that Acronis has only fixed some of the problems, and that some of them have gone away and come back in later versions of TrueImage.

Now, sometimes problems like this are caused by "easy" causes like bad disks, bad memory, bad cables, etc., and it is the instinct of support people to give you these stock answers, but it is crystal clear from the long threads above that Acronis still has serious bugs writing to NTFS volumes, even in version 11. Fortunately, some Acronis employees have been giving honest and useful answers about this problem on this forum. I am hoping to hear from some of those folks again.

Furthermore, in my case, the NTFS volume to which I restored was an external USB device, so it's easy to blame "bad USB drivers," but again looking at the threads we can see that folks had the same problem writing to internal IDE/SATA drives.

To Acronis: you really, really, really need to add an item to your "knowledgebase" for this product saying that there are known problems writing to NTFS volumes from the Recovery Manager:

http://www.acronis.com/homecomputing/support/kb/?topic=Products&cid=175

You clearly still have data corruption issues that you have not resolved. Your own support people have acknowledged this on the forum. To not mention this in your knowledgebase is unethical. I did not even know this forum existed until I googled "corrupt and unreadable." You may limit and qualify the scope of the problem in your knowledgebase as much as the truth will allow, but you must mention it so that innocent users like me do not get their drives corrupted.

In my opinion, you should counsel customers to avoid this part of Acronis until it works. You should recommend that they use BartPE or do image-based backups. You should consider removing the functionality entirely until it works.

You need to at least admit to this, to warn people like myself and the poster above away from data corruption. Then you need to fix the problem.

I would like to know how I can fix my filesystem, and if Acronis will ever fix these NTFS writing issues.

Details of my situation:

I just

• downloaded Acronis TrueImage Home v10 build 8,101 trial
• used the Windows TI application to create a full backup of my notebook's internal hard drive to an external USB drive, with verification, which succeeded without errors.
• to do a check of Acronis, I booted to the Startup Recovery Manager and did a small folder restore from the backup to a new folder on my external USB drive, a 700GB disk fomatted with NTFS.

Booting back into windows, I found that one file's contents was corrupt (files no longer byte compare, due to a "ZoneTransfer..." text string being appended to the end of my restored file -- a bug that was REPORTED LAST YEAR AND IS STILL NOT FIXED!!!!). It was an .exe file but PLEASE notice that it doesn't actually matter what kind of file it was (pdf, exe, even small text files have been corrupted in the user threads).

And I found a second .exe file which is reporting exactly the same NTFS "corrupt and unusable" error which many posters reported back in 2006 on the threads I quoted above. DIR /Q reports "cmd.exe -- corrupt file. The file or directory ... is corrupt and unreadable." Windows Explorer outputs similar messages. CHKDSK does not find any errors, but no application can access the file--this is exactly the same pattern reported in the threads above.

I would be happy to provide the corrupted file, but from reading the threads this appears to be a known issue with Acronis mis-handling the "ZoneTransfer" Windows file stream created by IE. If you need any more info, please let me know.

I have already submitted an Acronis support question with exactly the same content as this post. I included the full Acronis Report and sysinfo output as explained in your support post:

https://www.wilderssecurity.com/showthread.php?t=55317

So here are my questions

• is there any realistic prospect of Acronis fixing these bugs? Is the development team still working on this part of the product? please be honest.
  
• from what we know so far, is the corruption limited to that file/folder or is the other data on my (nearly full) 700GB hard drive at risk?
  
• how can I delete the corrupt file without the linux boot CD gymastics found in the long 2007 thread quoted above? has anyone found an easier way?

Thank you and please help restore my faith in Acronis' products with a little honesty...

 

FWIW today I went through the painful process of creating a BartPE bootable CD with the Acronis TrueImage v11 BartPE plugin.

I did the exact same test as I had done with the Acronis Startup Recovery Manager before, and this time I was able to restore that same directory with no corruption whatsoever (same hardware config). All files bitcompared exactly.

So this is consistent with other people's results: the linux-based Acronis Startup Recovery Manager writes corrupt NTFS data to my disk, whereas the Windows PE (XP preboot environment) based BartPE with the Acronis TrueImage v11 BartPE plugin writes correct NTFS data.

I will note one extremely scary thing I read while searching for info about all this. It seems that under some circumstances, Acronis running under BartPE (but NOT under the Startup Recovery Manager) will erase your entire disk if you check "Validate Backup Archive Before Restoration" and you cancel the restore during the Validate phase (yes, the validate phase, not the restore phase). See post #6 and #7 from starsfan:

https://www.wilderssecurity.com/showthread.php?t=147253

He reported this in September 2006 but I don't see any response at all from Acronis. What I am not clear on is whether this happens only when doing a restore of the whole partition or if it would even happen when only restoring a handful of files. Anyway I am very glad I let the whole Validate complete!

In general you would think that Validating is a good idea for the EXACT reason that you don't want to hose the drive UNTIL you know the archive is OK, as stated here:

https://www.wilderssecurity.com/archive/index.php/t-138445.html

However this bug removes that as an option. I guess we have to validate separately first using the validate facility in the GUI, then do a restore separately.

--

Here are some notes about the Acronis TrueImage v11 BartPE plugin that might be of use to people trying to do the same as me.

The "main" document about how to set this up, which is now a $1.99 mandatory "donation" to Mustang (though his stuff does seem to work and he seems pretty diligent about helping people), is here:

https://www.wilderssecurity.com/showthread.php?t=162424
http://www.mechrest.com/plugins/

Here is an example smattering of the many other threads about making BartPE images:

https://www.wilderssecurity.com/showthread.php?t=217994
https://www.wilderssecurity.com/showthread.php?t=214513

I could not find the actual Acronis TrueImage v11 BartPE plugin anywhere in the software from Acronis. On Acronis' website it says the plugin is included in all versions from 9 onward:

http://www.acronis.com/enterprise/support/bartpe/

and that you need to check the option for it in the installer. For my v11 install, I had no such option at all (not even an "X" option that I could change to an "install" option).

Looks like they either pulled it, or they do not let you try the plugin in the trial.

So I decided to pay $4.99 to Mustang to get his "enhanced" Acronis True Image Home 11.0 BartPE Plugin.

http://www.mechrest.com/plugins/

I followed the directions he sent with the plugin, which are reasonable. At first I tried the Reatogo version of BartPE as Mustang suggests. Mustang says Reatogo is easier and has more bundled stuff. I found Reatogo to be an utterly bug-ridden, incredibly unintuitive jumble of buttons, most of which did not work at all. I was not even able to launch its basic the driver importer--it would say "launching driver tool," hang for 5 seconds, then go back to the orginal app without launching anything. Same thing happened with the winshades config and almost everything else. I tried many path/curdir combinations and nothing worked. I gave up. Reatogo was like the control panels on the set of Star Trek--lots of nifty flashing lights and delicious splash screens, but none of it works.

So then I just decided to use the normal pebuilder program that comes with BartPE:

http://www.nu2.nu/pebuilder/

and include the Acronis True Image Home 11.0 BartPE Plugin as explained in Mustang's instructions that came with his $4.99 plugin.

This failed because Mustang's scripts hung. A white window popped up with no text and just hung.

After debugging his .CMD files, this turned out to be because the CHCP program, which Mustang's scripts call (in C:\pebuilder\plugin\TrueImageHome11\PRE\FUNCs.CMD) to change the current windows codepage for international text display, was hanging. This in turn was because of an intermittent, unresolved bug in windows XP which has no relation whatsoever to Acronis or BartPE:

http://www.google.com/search?q=chcp...firefox-a&rls=org.mozilla:en-US:official&sa=2

http://hackage.haskell.org/trac/ghc/ticket/1483

Some reports say that running CHCP redirected to prompt (CHCP | prompt) fixes the problem. This is not the case. CHCP|prompt hangs for me intermittently. CHCP>nul, which Mustang does, also hangs intermittently. So there is no reliable script workaround for this bug.

There is a Microsoft HotFix that may fix the problem:

http://support.microsoft.com/kb/925271

but I instead "fixed" it by running CHCP from a shell several times to "shake it up" and get the CHCP called from Mustang's script to work. Sigh.

Finally, I got a functioning BartPE, that could run and see my external drive.

...NOT.

BartPE and Acronis could not see my laptop's internal SATA hard drive!

On to another 4-5 hours of surfing web pages like these:

http://www.911cd.net/forums//index.php?showtopic=21807
http://www.911cd.net/forums//index.php?showtopic=10662
http://radified.com/cgi-bin/yabb2/YaBB.pl?num=1194575131
http://www.911cd.net/forums//index.php?showtopic=21226
http://www.mydigitallife.info/2007/...d-find-any-sata-hard-disk-drive-on-ahci-mode/
http://driverpacks.net/DriverPacks/DriverPack.php?pag=m
http://users.pandora.be/jtdoom/basetute/BartPE/OverFlow/DPs_BartPE_HelpFile.htm
http://www.google.com/search?hl=en&...l&hs=Gqj&q=bartpe slipstream ahci&btnG=Search
http://www.911cd.net/forums//lofiversion/index.php/t20417.html

As you can see, these threads are bringing us in a frightening direction of downloading heavy driver packs with lots of drivers that may or may not work on your system, then running YET ANOTHER half-working hokey GUI to "convert" the drivers to BartPE plugins. Noooooooooo!!!! The pain!!!! Make it stooooooop!!!

Fortunately, then I noticed this post (see Post #8 from Scopacetic):

https://www.wilderssecurity.com/showthread.php?t=147253

He tells us of a relatively simple way to install the one mass storage driver we actually need. And he further points us to here:

http://www.nu2.nu/pebuilder/help/english/drivers.htm

where the "relatively simple" procedure is explained.

I found my correct driver by

1) bringing up the System control panel, Hardware Tab, Device Manager
2) seeing what I had under "IDE ATA/ATAPI controllers"
3) doing Properties...Driver Tab...Driver Details on each one
4) seeing the driver name
5) doing a windows Search for that filename (without the extension) in the driver CD/folder that came with my laptop.
4) making sure that only one driver matches that filename.
6) comparing the versions to make sure they are the same.

That got me the one driver I needed, which I put in to BartPE (as explained in the pebuilder link above), rebuilt, and it now seems to have full functionality with Acronis.

Whew!

Do we actually expect non-engineers to USE this software?

I don't get it. This must mean that very few, if any, people use Acronis to restore complete hard drive images. Or maybe they use the "sector-by-sector method" to (knowingly or unknowingly) bypass all the NTFS bugs?

It's a huge shame because in my opinion this is the #1 valuable feature of Acronis that sets it apart from the competition. Restore everything, data and OS and settings, all at once. Too bad it's busted.

 

But, in ten words or less, how do really feel about it?

 

Outrageous!! You had to spend $6.98.

 

lsemprini:

I agree about the version of NTFS used in the Acronis Linux environment; it doesn't understand NTFS well enough to work reliably for file writes. But I hear good things about the latest NTFS-3g that is being used in some Linux distributions. Perhaps when Acronis switches to using NTFS-3g then these problems will be solved.

Also, the problem with NTFS corruption only occurs when restoring individual files in the recovery environment from a backup archive to a different folder than their original location. The basic core competency of TI, making and restoring images of complete partitions, seems to be rock solid.

The absolute best recovery environment that I've used with Acronis products is VistaPE. Much better than BartPE. Give it a try.

 

Thank goodness I always do restores using a recovery CD, usually the TI one but sometimes the Bart PE version.
So I have never run into the Windows recovery environment problems.
I have always advised against the use of the Acronis Start up Recovery Manager, not because I was aware of any problems but because in a worst case scenario one would have to use a recovery CD since the SRM would not be available so practice for an emergency each time one restores.

Xpilot

 

Xpilot:

It's not the Windows recovery environment that's at issue here. It's the Linux-based recovery environment whether started from the Acronis recovery CD or from the ASRM in the secure zone.

You probably only restore partitions, so you won't have run into the issue. The issue only occurs when you restore individual files to a different location in the file system. For example, boot into the recovery CD and copy a file from one of your archives to the desktop. The file should be one that is not currently on the desktop. Better yet, don't actually do this. Sometimes the restored file is corrupt; sometimes it isn't. Sometimes you can't delete the file without going to extraordinary measures because of errors in the MFT or because of some NTFS permissions issue.

Individual file restores to the same location in the file system have always worked correctly, in my experience.

 

Mark thanks for the explanation.
I had understood from a lot of the foregoing that the problems were mainly happening when starting a recovery with the SRM.

You are quite right I only image and restore partitions.
If I want to find an old file I mount the relevant image and make a copy of it. I cannot foresee the need ever to restore individual files or groups of files when copying from a mounted image is so easy and in my experience foolproof.

One of the problems with TI is that there is a huge gamut of options ,some of them work and some don't. I have tried over the years to just use the ones that work and avoid all else.

Xpilot

 

I know the previous threads have said this, and I respect that you all are experienced with the app, but forgive me if I'm a bit skeptical about any assumption that the bug will only surface with alternate directory restores.

I think it is highly unlikely that this problem is limited to restoring to a different directory than the backup directory, for the following reason: Remember that the problem is at the low NTFS filesystem level in the linux kernel. The piece of code with the bug in it has no concept of Acronis or backups or anything: when it creates a new folder or file that was not on the disk before, it has no way of telling (and it does not care) whether that file is new because:

1. the user had specified a different restore directory, or
2. this is the original restore directory, but the user had deleted the file or folder from the hard drive since the last backup

So I suspect it's going to produce the same corruption in either of those cases.

I would love to test this, but unfortunately I do not have any spare hard drives that I can corrupt.

If anyone else wants to try, then I'd recommend this procedure:

1. in windows, create a folder c:\foo with lots of files and folders
2. in windows, make a second copy of c:\foo as c:\baz (for later comparison)
3. use a recursive diff progam (such as Araxis Merge; make sure to set Araxis to do a full bit comparison of all files) to verify that all files bit-compare
4. in windows, use Acronis to make a backup of c:\
5. in Acronis Recovery Manager, restore c:\foo to a different directory, say c:\bar, and
6. boot into windoze and verify that there IS corruption in c:\bar (that is, the bug that everyone has reported). do a recursive diff of c:\foo and c:\bar to verify some files have changed.
7. in windows, delete the original c:\foo
8. go back into Acronis Recovery Manager and restore c:\foo to c:\foo
9. do a recursive diff of c:\foo and c:\baz to see if files are corrupted

I'll bet that there is now corruption in c:\foo too.

I suppose it's remotely possible that the bug causes the Recovery Manager to write NTFS data that is valid if the file is still in the same directory and invalid otherwise, but this seems very far-fetched--the NTFS metadata for a file doesn't include the full path to that file. The NTFS metadata may include the sector offset of the directory, but this does NOT guarantee that restoring to the same directory will work---a directory can move (in particular if it is deleted and recreated with the same name)!

 

You are probably right. For now I just avoid the issue and never use the Linux-mode version of the program to restore individual files or folders. If you always do this in Windows then you will use the Windows NTFS drivers and will not have these problems. In general I don't trust using Linux to write to an NTFS file system.

I've heard that NTFS-3G is pretty good, however, but I have no experience with it other than I'm using it to read NTFS partitions on my Linux machine.

 

You could make an image of the partition that you want to experiment with first. Then do your tests. Afterwards, restore the image to eliminate the corrupt files.

 

A reasonable suggestion, unfortunately:

• I have only 2 disks (160GB and 700GB), both nearly full of unique unreplaceable data, neither one with enough space to store an image of the other.
• There's still the issue of trust. I would kill myself if I tried this experiment and lost my data due to another bug. I'm not willing to risk that even for a supposedly "image-only" backup. I continue to be amazed that the state-of-the-art of PC backup software (I see an astounding number of data corruption/erasure bug reports about many vendors' software, not just Acronis) is is this bad. You would think that backup software would be more reliable and less dangerous than other software, but this does not at all seem to be the case. It seems that this market needs one adult company to come in and wipe out the competition with a backup product that Does No Harm (even saying "cannot complete the operation" is better than producing corrupt files or erasing one's drive).

 

clarification:

neither of which has enough space to store an extra image of the other (for a total of two images), which is what I would need to do to run the experiment, if I trusted the software enough to do it!

 

I hope these are fully backed up somewhere, and if the data has real value, that the backups are stored off-site. On-site backups offer no protection against theft, fire and other disasters unless they are stored in a fireproof safe that cannot be stolen.

 

Indeed they are---the smaller disk is currently backed up onto the larger disk using another, much older backup program--one that does not have any boot-based restore, but which I trust to restore files correctly. Then there is also an offsite backup of both disks--but right now it is literally on the other side of the planet!! Right now I am traveling for some time and the "offsite" backup is nowhere nearby. When I return there I will have access to the backup disks and be able to try this experiment. I'm hoping someone might be interested to try it sooner though as I am curious if it fails in the same way.

Internet backup is also interesting theoretically, unfortunately many of the places I travel have completely crappy bandwidth (just above 56k modem speed), so that is just not an option for me.

 

Still no word from Acronis or anyone on my original questions, though I did find a better way to delete the file!

I found this on another thread in this forum, but unfortunately I lost the link to the other thread.

This method can work if your corrupted file is not in the root directory of a drive.

1. say your file is in a folder c:\foo
2. in windows, move all the non-corrupted files out of c:\foo to some other safe place
3. boot into the (linux-based) Acronis Startup Recovery Manager (not a BartPE environment: it is important that you be using the same buggy linux environment)
4. click the UI button to begin a restore in Acronis. You will get a screen where you are supposed to identify the image to restore from, and another screen where you are supposed to identify the files to restore. Notice that, on one or both of these screen, there is a "Delete" button near the top of the window. That button becomes clickable whenever you use the mouse to point to a folder (but not a file, for some reason). Point to c:\foo and click Delete. Acronis is able to delete this directory and its contents even though some of the contents are corrupt.

The obvious disadvantage of this method is that you are again trusting the buggy code that screwed up your hard drive in the first place to not screw up as it deletes a whole folder. However I think this method is no less dodgy than the linux boot CD methods proposed in the threads quoted in my original post.

So far I have not noticed any further NTFS corruption messages from NT. CHKDSK is not really meaningful here since it doesn't necessarily report an errror even when there is file corruption, but I ran it for the heck of it and it reported and "fixed" several minor errors (sadly it does not say what files it is fixing).

So, Acronis, can you provide us with any further information on exactly when this bug happens and does not happen? Anything from the engineer triage so far would be useful. It can at least help us hone down when the bug could happen and when it could not.

I am about to go on the road again but I look forward to seeing some new info on this thread when I return in a week or so.

 

Hello lsemprini and everyone interested,

Thank you for choosing Acronis Disk Backup Software.

We are sorry for delayed response.

Our Development team reports that the problem is fixed starting with Acronis True Image 2009 Home.

The cause of the problem is Linux drivers handling some Alternate Data Streams (ADS) incorrectly. So, the problem only affects some of those files/folders that have ADS, and are restored using Acronis Bootable Rescue Media to NTFS partitions. No other files/folders or other filesystem types are affected.

Thank you.
--
Marat Setdikov

 

When will True Image 2009 Home be available?

 

This suggests that those who purchased version 11, or updates to version 11 recently have been sold a product known by the manufacturer to be faulty or unreliable in so far as its main purpose is concerned, and that there is no intention of issuing fixes for the problem within the version purchased. Will Acronis therefore be issuing Acronis True Image 2009 Home as a free replacement to those of us who currently can't use version 11 because of these problems?

 

You can always hope. Since it only affects the rescue CD one would think it would be easy to release it as an update to TI11.

 

Very sad that bug fixes are only available via a paid upgrade.

This fix, and others, should be applied at least to version 11 and possibly earlier versions OR the upgrade to version 2009 should be free.

After all, don't we have the right to software that performs at least its basic functions correctly? We shouldn't have to pay for bug fixes - new features, yes, bug fixes, no!!!