Acronis TI Echo image causes autochk program not found

I recently installed TI Echo Enterprise server to make images as a major part of my DR strategy at our company. Our setup is the typical server config with a Dell server with Raid adapter hosting a RAID 5 array.
After creating the images I rebooted one of the servers and got the dreaded "autochk program not found: skipping autocheck" which caused a continual reboot. Tech support at Acronis told me it was a known issue which was happened rarely(it happend to me twice in one week on two different servers). The proposed work around was to restore the C: partition from the image created by booting to the Rescue Media Boot CD. That didn't work. So after about 5 hours on the phone with them we finally tried restoring the MBR from the Image. Now it took less than a split second to do this and behold the system went pass that autochk error and allowed us to log in. It seems that The Acronis application affects the MBR when it makes images, a detail of which they don't seem to be aware.
Now I'm posting this for all of you who Tech Support could not help. I can't believe they couldnt tell me this knowing that their product caused this problem. This caused us to have 2 servers crash and loss of more than 24 hrs in loss of productivity. Hope this helps out somebody.

 

Hello,

thanks for your post.
I had the same Issue on 2 Servers running TI Echo Enterprise on Windows 2003.

Is there any official Announcement from Acronis about this?
Or is there a Fix for this?

Regards
Daniel Müller

 

hi,
thank you for posting this problem, this is serious issue, i just opened a thread asking for feedback about the new Acronis Echo enterprise, and then i saw yours, did the support solved this issue? is there any updates related to this problem?
i hope you can keep us update if they provide you with new update in regards of this issue, i think i will postponed my purchase for this software, and look more for other solutions.

thanks again for your post.

best regards,

 

Hello localhorst and fadihu,

Thank you for choosing Acronis Software.

We are sorry for delayed response.

Please be aware that this issue seems to happen only on some very rare combinations of hardware and software. So far, we weren't able to reproduce it ourselves or gain access to any computers where it's reproduced, so it's impossible to develop a fix yet.

If you encounter this issue, the workaround is to rewrite the disk's MBR. It can be done either by restoring just the MBR from the last image made before the problem appeared; or by creating a new image, wiping the drive completely, and restoring just the partitions from the image, without MBR (a generic MBR will be written in this case).

If you would like to help us find the solution to this problem, and have a non-critical machine where the problem is reproduced, so our Expert Team could work with it via remote access, please send a message to our Support Team with the reference to the problem #686632 and the link to this thread. We would very much appreciate your assistance on that matter.

Thank you.
--
Marat Setdikov

 

Hi
I have the same Problem on one of my machines. As workaround i deleted all partitions and restored them with testdisk.

I opened a ticket at the acronis support but i didn't hear a thing so far. Keep you up to date...

 

We're having this same problem, how did you restore it from image? We also tried the CD recovery but to no avail. Acronis support hasn't gotten back to us; we submitted 1 ticket and got 10 auto-reply notices with 10 unique ticket numbers? THanks in advance

PCGIT
www.pcgit.net

 

Hello all,

Thank you for your interesting in Acronis True Image

There are also Acronis utilities for MBR rewrite. You can download special Acronis utility from http://download.acronis.com/support/mbrautowrite_en.exe. Use it to create a floppy and boot the machine from the floppy.

If you prefer to a fix MBR using a CD, then please download special Acronis utility from http://download.acronis.com/support/mbrautowrite_en.iso. Use it to create a CD and boot the machine from the CD. The MBR will be rewritten once you boot the computer from the created media and confirm that you want to fix the MBR.

The best way to contact Acronis Support is Live Chat, use this link to contact Acronis live chat operator.

Best regards,
--
Dmitry Nikolaev

 

I had this problem back in October and ended up restoring the C: partition of the server allowing Acronis to create a generic MBR. (I didn't have access to restore an MBR from before the problem occured) Even though this fixed the "autochk not found" error initially and allowed the server to boot into Windows, running another backup using Acronis (In Windows) broke the MBR and produced the "Autochk not found" error the next time the server was restarted. In addition, I restored the image to a different hardware platform to make sure it wasn't hardware related and got the same result. At the time, I chalked this "rare error" up to an operating system I inherited so I reinstalled the server and moved on.

Although, that event was so painful that I decided to create an offline backup of any server using the Acronis boot CD before installing Acronis in Windows on future servers. (Just in case this "rare error" happened again) And now, of course, the error has occured on a completely different server. (Dell 2900 built in 7/2006)

Thankfully Acronis responded to this thread and seems willing to help. I tried the mbrautowrite CD ISO and boot floppy, but neither one worked. The only thing that worked was restoring the MBR from the offline backup I created before installing Acronis in Windows.

While trying to troubleshoot the issue with Acronis, they sent me a partition reporting tool that I ran while the system produced the autochk error and after I restored the original MBR. I sent these into Acronis today, but I've also attached the results to this post in case anyone is curious. You'll notice that something is changed before Sector 10 after Acronis runs a backup in Windows.

 

Well, you might think it's rare and you also might be unable to reproduce but I just downloaded and installed your 15-day Echo Eval and lo and behold, it's just screwed up one of our (redundant) main file servers (same autcheck error infinite loop.)

Now you're saying the hw/sw combo is so "rare"...

...for some reason I never thought our stock Dell PowerEdge 2950 w/ PERC5i and a Qlogic QLE 4 gig FC card, running Win 2003 R2 Storage Server is such a rarity...

Anyway, what's the next step? Did I just lose my whole setup for this crappy sw or is there a sure way to get it back? (No, I don't have any TI backup - as I said I just installed it.)

PS: right now we're trying this auto mbrwrite utility...

PS2: didn't help, thank you. Now what...?

 

Hello szlevi,

Thank you for your interest in Acronis Corporate Products

The problem could be in particular BIOS version. We've investigate an other similar case and discovered that HDD parameters written in BIOS differ for working and broken (after backup) configuration. One of possible solutions is to update BIOS on the machine. The following workaround can be used:

- Create a backup of the machine by means of Acronis True Image bootable CD.
- Recreate the partitions using for example Acronis True Image bootable CD ("add new HDD" feature).
- Restore partitions one by one from the created image (e.g. do not restore the whole disk at one time).

Thank you.

--
Oleg Lee

 

I'm seeing this as well on a Dell PE2600 with PERC 4/Di RAID. (BIOS/firmware and drivers are all current and have no affect.) We're running SBS2003 with Acronis TI SBS Echo. The server does have a DELL Tools/EISA config partition on it, if that makes any difference. Our disks are laid out as follows:

Disk0 RAID5 partitions
-----------------
DELL/OEM FAT16 (EISA config, hidden)
NTFS ACTIVE c: (boot/system)
NTFS ACTIVE d: (swap)

Disk1 RAID5 partitions
------------------
NTFS ACTIVE e: (exchange store)
------------------

Offline (rescue CD) Acronis images work perfectly; but if you attempt to run an image while booted into Windows, the MBR is hosed. I haven't felt like playing with it to figure out if the MBR is being hosed only when you try to back up the partition with the system drive on it, but either way it makes the Acronis software less than useless.

I've spent nearly 24 hours troubleshooting this problem before finding this thread and confirming that the Acronis software is causing the corruption of the MBR. We'd just backed up and expanded the system partition (using an offline image) so I thought the corruption had occurred then.

Restoring just the MBR from a good image does resolve the issue (thankfully). Too bad my last "good" backup was only of the c: volume, not the entire disk so it didn't have a good MBR in it Accidentally stumbled on the "restore just the partitions" solution, but didn't know that's what made it work.

---

Has there been any progress on reproducing/resolving this? If there's anything I can do to help troubleshoot it, let me know. This is a production server so can't get too crazy with troubleshooting, but if there are any logs I can send that will help, let me know.

As of now, we can't use the Acronis software at all except for offline imaging (not what we felt we were purchasing!) Going to have to look into what the refund policy is.

 

Hello all,

At the current step, the situation is being investigated by our Development Team and the cause is still unclear.

Somehow, our software changes MBR and filesystem type during the backup. Some cases revealed traces of RAID drivers in some sectors of HDD's, and it was the cause.

At this step, we have revealed one workaround:

please clean the value of registry key below

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute

Registry can be accessed from Start -> Run -> Regedit.

Please do not delete the key itself, just clean its values (if any).

Anyway, the investigation is in process and we will do our best to reproduce this situation.

Thank you all for the understanding!

--
Alexander Nikolsky

 

Thanks for the update Alexander,

I have just a few more questions if you have the time:

• First, what exactly does the registry change do? Am I right in thinking that this simply disables autochk from running at boot time? Does that mean the TI backup is still modifying the MBR/drive type during an image? Is the damage being caused by the initiation of the backup or when autochk is first run after a backup? Won't this registry change prevent a user-initiated chkdsk from running at boot time? (Just want to know what functionality I'm losing.)
  
  
• After the problem first occurs, DISKPART run from a Recovery Console still identifies the system partition format as NTFS, but doesn't have a drive letter for it (I can assign one manually to access the files). After a full-image restore of the last backup (including the bad MBR), I noticed that the restored partition type was "RAW" and I could no longer assign a drive letter to it -- is this also symptom of the same problem?
  
  
• Is it safe to take images of non-system drives or does any image creation cause the problem? Does it only occur on backups of the entire drive (i.e. ones that don't include the MBR) or does any image of the system drive cause the damage?
  
  
• Finally, are any other Acronis products affected by this? We have Recovery for Exchange SBS using continuous protection, but have turned it off in the wake of this problem. Is it safe to run this or should be hold off until a resolution is found?

Thanks for keeping us up to speed on this. I just want to fully understand the problem before using TI on a production server again.

-Todd


P.S. -- Given the severity of this issue for those few affected, it would be nice if it were at least acknowledged in the Acronis Support Knowledgebase instead of just on this forum. Having it documented as an open issue there as well would have saved me a lot of time while I researching this problem.

 

Hello tstout,

Thank you for your interesting in Acronis True Image

This is the registry entry used by Autochk to determine which volumes get checked at boot time. This is the default setting for Autochk and also the result of using Chkntfs /d to have all volumes checked at boot time.

The issue is under investigation so it hard to say for sure now what was the reason for it.

Best regards,
--
Dmitry Nikolaev

 

Hi,

I have 2 servers that are having the same issues. Has there been any resolution to this issue yet?!?!

Thx
Bryan

 

I've got a couple of clients looking for image-base backup solutions for SBS. I'm holding off on recommending Acronis until this issues has been resolved one way or another (the proposed work-around isn't a long term solution).

Has there been any movement on this issue?

 

Has this problem been resolved in the new version 10?

I can find lots of information on new features, but almost nothing on bug fixes.