Another one with the dreaded E00070004 error

I just bought a new E6600 system (P5B deluxe MB P965 chipset) Tried to restore an image and also got the error E00070004, and Acronis says I have no hard drives installed! So damn annoying
I now have to reformat and start again.
I am using the latest build of v9.

Acronis....is this problem going to be fixed on future builds?
What is causing the problem? Is it the P965 chipset? I am not using raid, just standard sata drives

So many are experiencing this error message....please fix it or tell me how to restore my image

Mal Sellars

 

I am a little confused by your post...

Why do you have to reformat? What are you trying to restore?

 

I bought the new computer about a week ago. Spent 2 full days tweaking and loading programs and data however one of my programs (Gigastudio) seemed to be imcompatible with the new system and corrupted Windows. I tried to do a repair from the Windows installation CD but it would not let me. I had backed up an image file in Acronis prior to my installation of Gigastudio, and expected to be able to restore my system from that. That is when i got the error message and had to start again. Hence 2 full days lost because Acronis would not do its job, so my only alternative was to reformat and start again
If anyone from Acronis reads this, please fix this problem because at the moment Acronis is more than a waste of time....it gives people false comfort thinking that their precious data is backed up..

Mal

 

No matter what you are doing, you always need to test. For that specific reason ATI has the functionality to "Mount Image" whereby you can do a "virtual" restore of a partition. I have never yet experienced a situation where an image would mount but would not restore.

If you created your image using the "Files & Folders" option (as opposed to the partition option) then you can do a test restore of selected files and folders to check that the image will restore.

It is not reasonable to simply assume that something works. You must run tests. This is especially valid when you are using something for the first time.

It is regretable that you have had a bad experience. But, on the positive side, this could have happened a year from now which would have been much more catastrophic if you had lost a year's worth of data, your programs and your OS.

So in a way it has been a good thing. From now on remember not to rely 100% on technology. The human factor is still important.

 

Thanks for the reply Tablva
After I did the Acronis image I did verify it, and all was well. I just naturally presumed that I could do a restore from the .tib file.
Acronis keeps saying I have no drives installed (how ridiculous) and gives the error message E00070004
It seems that many people who use Acronis have a similar experience when trying to restore. Surely the technical guys can work out a fix for this. Hopefully they are aware of the problem and will come up with a solution.


Mal

 

Hi Mal

Verifying is not testing. Think for a moment what verifying is actually doing. When you run a file verification you are essentially comparing 2 files by seeing if the checksums agree. If they do then the files verify. For data this is fine. However, verification is no guarantee that a system image, when restored, will provide you with a bootable environment. It does not matter whether you are using True Image, Ghost, Copy Commander or the next gee-whiz imaging software. The principle remains the same. The only way to be absolutely sure that you have a bootable system disk is to create a bootable system disk. Anything else is akin to Russian roulette.

What the software is telling you is that it does not recognise anything on your system as a disk or drive. There can be any number of reasons for this, none of which may be related to ATI.

Whether you are working within Windows or from the Linux boot CD, the principle remains the same - the OS is in control. Only in special circumstances (e.g. games) does software communicate directly with hardware. 99% of the time it is the OS that forms the communication link between hardware and software. Somewhere along the line this communication is breaking down. A bit of investigation on your side might reveal the cause.

 

Really appreciate your help here Tablva
Anyway it appears the problem was caused by a corruption in Windows (caused by a "buggy" software program called Gigastudio). After a reformat, and clean install of XP I am able to backup the drive, and the "Mount Image" functionality you mentioned is working
I hadn't heard of this feature before...is it just new to build 3677? Anyway it is comforting to know that in your experience, this is fairly certain to ensure my image will restore if needed. Just to be on the safe side, I also cloned the drive to another hard drive...better safe than sorry

thanks again for the advice Tabvla

Mal

 

Glad to be of help

Just one thing.... the Clone functionality in ATI should not be used as part of an ongoing backup routine.

The Clone utility was developed by Acronis to provide some users with the ability to migrate a complete system from a "small" disk to a "big" disk. The users that Acronis had in mind were essentially non-technial users who did not have the knowledge or confidence to install, format and partition a disk and then setup Track 0, the MBR, the Active partition and prepare the disk for a system. If you are not technical, and don't have the experience this is a difficult job and one that can go wrong. For these users the Clone utility provides a relatively simple means to do all of the above. Technical users would probably seldom (if ever) use the Clone utility because they would have the necessary experience and tools to do all of the above. (The Clone utility does have some serious disadvantages).

Therefore, a good disaster recovery plan should use the image (disk, partition or files & folders) utility as the ongoing method to create backup archives, not only for data files but also for the operating system partition.

 

Hi Mal7
I think Tabvla is correct as far as he goes. What I see here frequently are situations, especially with the new hardware, where TI functions that work under Windows fail under Linux (The recovery disk). That is because it takes the Linux community quite a while to develop drivers for new hardware, so the restore dies because Linux can't communicate with new disk drives, chipsets, USB devices, etc. If I had your new hardware I would boot using the recovery disk and make sure that the Linux system could see all my disk drives and could verify my backup image. If it can't then I would spend the time required to create a BartPE disk so I could run any necessary recoveries in a Windows environment.

 

I understand what you are saying Tablva, and I will still do backup images, but to ensure my data is always there and available if needed I will clone to another hard drive as well. I have about 200GB of extemely important data (my own music)which has taken many years to accomplish and if it were lost I'd be devastated As you said cloning is a very simple procedure, and if ever my C drive fails I can always just change the jumpers on my D drive and make that the new system.

 

Thanks for that OldITguy
Further to my last posts I have now thoroughly examined my 3 computers to see how Acronis functions with them.

Computer 1> AMDx2 4400+ Gigabyte K8NUltra-9 mb. sata drives....Acronis restore funtion works perfectly in Windows as well as recovery disk

Computer 2> AMDx2 4400+ Asus A8N.SLI deluxe mb. Sata drives...Acronis also functions perfectly in Windows and recovery disk

Computer 3> E6600 Core 2, Asus P5B deluxe (965 chipset) Sata drives...Acronis functions perfectly in Windows BUT when I try to do a restore with recovery disk I get error message and it doesn't recognise disks.
Is it a simple matter to create the BartPE disk? Any other workaround?
I presume Acronis will be working on a new build to solve this problem, as the new Core 2 CPU's will be everywhere soon..

Mal

 

Update to my last post. Computer 3 (E6600) will not only not not work from the back up CD, it also wont do a normal restore. I had used the mount image function, and that had worked so I presumed all was well....however to be sure I decided to try a full backup from a .tib file I had saved on drive D
All went well(it recognized my drives) etc, but it would not wipe the partition on C and continue.....I got an error message saying the operation was copmpleted with errors. In fact it had not completed the operation
It appears that the current build 3677 of v9 is incompatible with the new E6600. P5B deluxe

 

It depends on how technically knowledgable and experienced you are - particularly your knowledge of Windows. Before you start it would be wise to read up exactly what you have to do and make sure that you are comfortable with every step. Some members of this Forum are experienced BartPE users so you will find support here.

Suggest that you log a call with Acronis Support. This is unusual behavior. Remember that communication between components is under the orchestration of the OS (Windows or Linux). The OS in turn communicates with the components via drivers - hence the fact that ATI will often work perfectly under Windows but not under the Linux shell because the Linux community has not yet developed a driver.

The expectation is that if the OS can communicate with the component then there should not be a problem with the application - in this case ATI. However, because ATI deals with data in a different way to Windows you may well find that problems arise because of extraneous influences such as timing differences.

Windows deals with data in big chunks with a lot of inbuilt redundancy. When you open a file under Windows there will inevitably be lots of errors in that file, but you will never see them because of the redundancy factor. ATI deals with data on a bit-by-bit basis and as such is much more "sensitive" to even the smallest of errors.

If you ever want to check the validity of the above statement then take a system that is working perfectly and run an in-depth disk-checker (such as SpinRite) over the disk. In a system that is working perfectly, you will find many thousands of errors on the disk - typically somewhere between 30,000 and 60,000 errors. The system is designed to tolerate a large number of errors - this is redundancy.

ATI in contrast is looking for near-perfection and is not very tolerant of errors within its own communication protocol. When ATI restores an image it is looking to restore a near-perfect duplicate, if errors, even small ones, occur in that process, ATI's validity checker will terminate with errors.

 

So, isn't this a critical design flaw? I am growing increasingly concerned about relying on TI for more than convenience. While being able to quickly restore an image of, say, my system drive, to get back up and running in minutes rather than hours or days is great, I am less convinced that TI is robust enough, and has the built-in security measures to trust it with my valuable data (original photographs, in my case).

I purchased TI backup software thinking that I was buying a safety net to sling beneath my trapeze...yet I keep encountering, personally, and from reading the experiences of others in these forums, times when the TI net doesn't catch us after a fall.

Presumably, in most cases, TI does its job, and the data is all intact. But what about when it doesn't? I know of no way to reliably check the complete results of an Acronis restore...if TI reports a restore operation as successful, or, an archive as valid, then, it should be. How are we to locate any specific files with errors in them?

And, Acronis, if you really expect to be able to function in a PC environment with such few errors (one corrupt byte can ruin an archive, I'm told), wouldn't you then be releasing consistently error-free builds? Perhaps it's time to rethink fault tolerance. I for one would welcome even much larger archives, even as one of several options, that afford true, lasting & reliable data security. And a way to access and restore any less-than-intact Archives, should they occur, thru no fault of anyone but this complex hardware/software environment we all operate in.

And I'll risk including another suggestion that may ensure a trip to the wish list, but, then, no discussion is welcome there, so, who knows?

Why not build into TI an automated process to test the entire system, on 1st install (and with each TI build/update or system change), to verify that the system works fully with True Image? Create a small archive on a (temporary) partition on each hard drive. In Windows, in Linux, with SATA hardware & drivers, USB chipsets, and the system's boot environment. Boot into Rescue mode, and test drive access. Restore the archives. Test them fully for functionality. Burn media at TI speed. Reboot, and verify that the system will boot properly. Or, undo the changes. Then, report to the user that things are either 100% functional, or, suggest steps to take to remedy any errors discovered. So, if we create an Archive with TI, we know TI can, and will, restore that image on our current system, when we need it. When we fall off the trapeze.

 

I do use a backup program to capture my valuable data (the stuff I created and can't be bought elsewhere like your photos) automatically in the middle of the night. However, I also copy, yes just a Windows copy, the files to another location and I also burn them to DVD at some interval. IMO, introducing another program to reformat data files just adds another thing to fail or no longer be available down the road. TI is best for imaging OS disks and that is my primary use for it.

Don't forget this forum isn't really a "I'm happy" forum; posts are here because it didn't work in the vast majority of cases. Also, a lot of the posts are here because the poster never tested to see if the recovery method worked. Then there is the issue of doing backups for ever and ever after the first full test and never doing a restore again. That said, my experience with both Drive Image and TI is that if it works and the hardware remains good it will continue to work. I will temper that with it being a good idea to run chkdsk from time to time to make sure your file system is good and to validate the archive which gives a degree of confidence it can be read properly. We all know this substitutes quite well for a HW diagnostic.

In terms of an image backup, I'm not sure this is a significant problem with TI. Like every other app on a PC, TI relies on the hardware doing its job properly. It assumes if it reads good data it will write good data. Probably the only check after a restore is chkdsk to ensure the file structure makes sense.

I would welcome a "best possible restore" function but the results would indeed be unpredictable because it would depend on where the bad bits were located in the image. If I were Acronis I would also be nervous about this feature because a lot of non-technical people would use it and then start bad-mouthing TI for poor data integrity.

Disk data reliability is increased by writing error-correcting code with each sector. This ECC can correct up to a certain number of errors in the data so there is increased probabiltiy the data presented from the disk controller is correct. You could probably do the same with the TI data in memory but it could be a real processing load to do it; it likely would increase the archive size significantly. However, what you are doing is trying to make up for a fault in the memory - why not fix the memory instead?

That would be a good thing since too many people think just a successful archive creation gives them 100% reliability.

 

From reading many posts on these forums, and also my experience with my new Core 2 hardware, I am feeling very shakey about trusting TI (or any other backup software) to my valuable data.
(I have written to Acronis Tech help explining the problem)
My thoughts now are to clone the disk to another drive, then remove this drive to a safe location. This way the data would not have to be reformatted, with a .tib file created....just cloned, and I presume this would be a safer and more reliable way to backup. Any thoughts on this ?

 

Seekforever,

Thank you for your reasonable and thorough reply. I appreciate your views, and think that used properly TI is a very useful program. For such time consuming chores as restoring system partitions. What I am struggling with is the notion that TI is fallible, and that it, like all other software and hardware, cannot be counted on as the sole line of defense for data protection. I think I'm just about to make peace with that.

Of course, users who are running TI smoothly on their systems aren't likely to visit these forums, though, I wonder how many are faithfully making archives and trusting the restoration process to work when it's needed. I've learned thru these forums just how important it is to understand and test each step of the Archive creation and restoration process on our systems. I've also found that to be a weak link in other rescue programs in the past.

Will Chkdsk reveal any errors such as corrupt files? Chkdsk has, on my system, shown directory errors after a Files and Folders restore from Boot Mode. I have another Thread open on that topic:

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

Yes, I imagine this is true. Powerful tools can make a mess in the wrong hands, and rarely does one read about how poorly the user handled the program. The alternative, though, of keeping our data in proprietary .tib files that only Acronis software can access, and then only if they are fully intact, seems to leave us with much less security than is ideal.

No, I don't want corrupt images restored as intact. But, in the instance where corruption does occur, and that overnight backup is my only recourse to important data, I would like to be able to save and recover as much as posssible. Perhaps this process could be built to yeild clearly designated emergency data, rather than normal restored partitions or files.

I wonder though, if this feature isn't included for the very reason that it would admit that TI might need such a safety measure. Perhaps that's also why a detailed change log isn't forthcoming. No point admitting flaws that might otherwise not be apparent.

I don't understand the technical side of this, and appreciate your explanation. Would ECC be a real option to save TI archives that now corrupt, due to such things as USB chipsets, or even DVD write speeds? Your Tabvla's earlier comments about the inherent error rate of hard drives prompt me to think that some type of error correction might be helpful here.

On the subject of memory: I have two 512 MB PC 2100 DDR non-ECC RAM modules, one single-sided and one double-sided. I've run Memtest in boot mode for 12 hours with zero errors. But wonder, could these non-matching RAM modules cause any qlitches, such as when TI runs in Linux mode? And, is ECC RAM worth the tradeoffs?

Since TI depends on both Windows mode and Linux mode to do its work, it would be prudent to build-in a test ensuring compatibiliy, before reporting any "Operation Successful." Rather than relying on users to make that leap. There are a lot of possible scenarios to test, and Acronis should be able to design a testing process that would clearly pass or fail a given system. Again, I wonder, is this not done to leave off any implication that TI isn't compatible with all systems? Marketing over quality, a common debate.

And, in Acronis' defense, I realize that unlike every other hardware and software vendor I know of, Acronis is in the unfortunate position of not being able to rely on that all too familiar warning: Before installing, be sure to backup all your data.

 

I have yielded to the temptation to add a few of my thoughts, worries and solutions to the whole concept of securing a computer and all it contains.

My main hard drive IS EVERYTHING. If it were to fail in whole or in part I would be totally lost as would be my irreplaceable data. My requirement from any backup system is to be able to have a working hard drive 100% of the time. The other requirement is that all the operations should be failsafe and risk free.

I do not use any of the TI enhancements such as file and folders backups or backing up individual partitions because my prime objective is to secure the whole of my hard drive and thus there is no question of getting any thing out of Sync. Cloning is also not on my agenda as that process itself introduces some albeit small risk.

Because I want to have the possibility of rolling my system back in time I keep several generations of whole drive images on a second internal drive. This secondary drive is not backed up per se but I do keep some separately prepared images on a USB drive.

I do not use the optional validation processes at creation or restoration of my backup images. My reasoning is that these validations are only a means to raise one's level of confidence that a restore will be successful. It is much better to actually do a restore but to another hard drive. The backup image is thus proved by making a successful restore.

This is what happens day by day. Full drive images run automatically to a schedule. When I get back to the computer I shut it down and swap over hard drives so I can run a restore to bring the replacement up to the same state as the the swapped out drive. That is it, job done in about 10 to 15 minutes of my time. That is the crux of my method; I run restores before the inevitable disaster rather than after it.

To get to this happy state I use the best features of TI and leave out the bits I don't need. Swapping of hard drives using removable drive drawers is nearly as easy as swapping a CD.

 

I don't think anybody can say TI is totally infallible but what is in the PC world? Your standard PC looks fairly flimsy compared to a proprietary industrial control computer where reliability and fault-tolerance is everything.

Chkdsk: I don't really have a good understanding of the extent it checks data; the /r switch seems to be the most complete test option where it checks the whole partition for bad sectors, however, I don't think it really cares whether or not the segments of a file are properly linked. That could be taken care of in the other file system tests. I just don't know.

Acronis tibs: Yes, it means you are totally reliable on TI but on the other hand it is extremely unlikely anybody is going to stuff a virus into a tib file. There really is no way to create an archive without having it rely on a special program. This is why I said for backing up your personal data files you can just copy them to another device. Like Xpilot, I only use TI for its imaging capability.

Corrupt Restore: I agree that a special restore would be nice and just leave it is a data recovery operation, ie, not try to run the restored bad image.

ECC: ECC can only do so much, if you wrote corresponding ECC data and the data including the ECC really got mangled by bad chipsets, memory or whatever then it won't help. For ECC you see specs like "can correct 11 errors in a burst of 512 bytes" so the capability isn't infinite. Also, this method is used when writing CD/DVDs so you can see that it indeed is not infallible but without it most optical disks would be totally unuseable. When testers do a proper check of optical reliability they have a special reader without the ECC enabled so they can examine the error rate before correction.

I didn't make the comment about HD error rates but I assume, if correct, that is without the ECC in-use.

If your memory is working and you can validate TI archives without any problems then why argue with success. That said, they usually do specify that memory should be of the same type and spec. Don't worry if it works. There shouldn't be any difference whether or not the machine is running in Linux or Windows since the memory timing is the same. However, Linux may use a certain location for critical data that Windows doesn't and this could cause a problem; it could also work the other way around.

You can't put ECC memory into a non-ECC machine. Higher-end servers and workstations use ECC. Interestingly, a lot of older machines used parity memory where it would flag a memory error but couldn't correct it. I think the improvement in memory chip technology was such that it was seen as no longer worth doing it.

Testing: It would no doubt be beneficial if TI had a "first-time run" test that validated all was well but it may not be simple. I have often said before that trying to support the myriad of hardware configurations, software configuration and "end-user people" configurations is nothing but a nightmare. It is virtually impossible to test all the scenarios and as soon as you do another disk controller or motherboad comes on the market and creates a problem. This is why it is so important for people to do a restore on their system.

The use of Linux in the recovery environment with its lack of drivers plus the inability to add drivers at the user level generates a significant proportion of the problems on this forum.

What you said about Acronis not being able to say "back up your system before installing" is so very true although one can back up the precious personal files by copying them.

I guess that is my advice to anybody who is nervous about losing files, backup your personal files by a straight Windows copy to another device as redundancy. You can always reinstall Windows or whatever if that gets screwed up.

While I'm pontificating on backups, Xpilot's method of running the backup so you are testing it before you need it is hard to argue with if you are the nervous type. Also, from reading this forum I have come to the conclusion there is a lot of sloppy PC users out there but at least the ones on this forum see the need for backing up which puts them ahead of most others. Where they are sloppy, IMO (no flames please) they don't manage their software resources. They download programs they become dependent on but don't keep a copy somewhere they can find it, they get issued important serial numbers but they don't keep them safe, they have crucial data in only one place, they don't keep any historical backups in case the most recent one doesn't work - if you have a problem with your system how do you know what it has screwed before you discovered it. As said before, use redundancy on very important files, back them up using a different method and this can just be a simple copy.

 

Xpilot...your method seems the best for my situation. I was thinking along similar lines with TI's clone function, but as you mentioned there is still a small risk. But the idea of being able to continually test your backups is indeed the smart thing to do IMO.
What method do you use to copy one disk to another?

 

I do not copy from one disk to another. Instead I restore the latest backup image having first swapped over the main hard drives.

My method of working gives me two identical main hard drives at the point of swapping them over. Yesterday's hard drive has become Today's while the original Today's drive is now the off site backup until Tomorrow when the cycle is repeated.

Obviously this imaging and restore process can be done at any interval one chooses it does not have to be daily. The main consideration is that the main drives are swapped over right after the imaging process so that there have not been any changes in the meantime.

I hope this has helped to clarify the method...........
I really should try to hire Menorcaman as a Ghost writer. You will have seen that he has the ability to make a complicated process simple whilst I tend to do the reverse

 

Hello mal7,

Thank you for choosing Acronis Disk Backup Software.

Please accept our apologies for the delay with the response.

Please note that the issue you have experienced may be cased for different reasons. Such as, if you are using Acronis True Image in Windows environment and get the error message after you start the program that Acronis True Image cannot find any hard drives this means that SnapAPI module which is responsible for input/outpput operations in Acronis True Image (check post #10 and #12 of this thread for details) was not installed correctly for some reasons (some software may prevent the module from installing correctly). In this case you could download the latest version of Acronis drivers, install it with disabled logging and see if the problem still persists.

If the issue persists, please enable logging by SnapAPI program, reproduce the program failure and send us the "snapapi.log" file which is located at C:\. You can also use Windows Search tool (available in Start menu) to find this file. Please also create Acronis Report as it is described in Acronis Help Post. This would provide us with detailed information on the hard disk partition structure and how the SnapAPI module works on you system.

Another issue is related to the standalone version of Acronis True Image. You may receive the same error message either when you load the full version of Acronis True Image from the Acronis True Image Bootable CD or when you try to restore the system partition. Please note that if you restore the system partition to the original location Acronis True Image reboots the computer to the standalone mode which is Linux based. The full version of Acronis True Image is also based on Linux. In this case most likely that the standalone version either does not contain the appropriate drivers for the particular hard drive controllers or these drivers do not properly used. In order to investigate the issue in this case please create Acronis Report and Linux system information (sysinfo.txt) as it is described in Acronis Help Post. Also provide us with the exect model and vendor of the hard drives you use.

When all the necessary files and information is collected please submit a request for technical support. Attach all the collected files and information to your request along with the step-by-step description of the actions taken before the problem appears. We will investigate the problem and try to provide you with a solution.

Thank you.
--
Aleksandr Isakov