True Image 10 "corrupt archive" fiasco

After weeks of going back and forth with Acronis support due to "corrupt archive" and "insufficient resources to complete command" errors, they now insist that the disk I am trying to back up and restore from is formatted as "XENIX ROOT" and they don't support that. I know for sure that the disk was originally formatted as NTFS using Acronis True Image 9. Just to make sure, I just reformatted it with Windows Diskmgt utility. I deleted the partition completely and did a slow format as NTFS. But Acronis Report still shows the rport below. I'm not sure exactly what it means, but it seems to indicate a "XENIX ROOT" on my F: drive (a 320 GB Seagate drive on my secondary partition). WTF? Is this just an Acronis Report bug? Why would I have a Xenix root on a drive I just formatted as NTFS?

Speed IFace Hs-Bs-Tg Model
Num NT L9NO Size FSsize Free FS Type Label ABCHSV
---- ----- ---- ----- ----- ----- ------ --------------- ----------- ------
1- d(0) 112G 768K ATA 0-0-0
-1 p(1) --CC 112G 112G 97G NTFS 07 NTFS, HPFS ........... A-C---
7.8M free ------
2- d(1) 127G 1K ATA 0-1-0
MBR 02 Xenix root ----Sv
127G free ------
3- d(2) 466G 2.3M
7.8M free ------
-2 table 0F Extended LBA A-----
-5 p(1) --DD 466G 466G 842M NTFS 07 NTFS, HPFS GIGA....... --C---

 

Did you just reformat the first partition or the second?

If the MBR is in partition 2 as seems to be indicated, are you able to boot OK.

Might be worth downloading the demo version of DD10 and see what disk director says - I don't think the demo allows you to make alterations, but at least you'll get a further confirmation on what partition editors think they are seeing.

Colin

 

Hello jweisbin,

Thank you for choosing Acronis Disk Backup Software.

We are sorry for the delayed response.

Please note that as far as I can see our support engineers are working on this issue. Since investigation of this issue requires report, log files and screen shot from you it will be easy to continue it via e-mail. You are welcome to post the results of the investigation here.

At this moment I would recommend that you do the following:

- Download SnapAPI.dll

- Replace C:\WINDOWS\system32\snapapi.dll with the downloaded one

- Reproduce the issue and collect the log file.

The log file will be created on the C:\ partition. The name of this file will be snapapi[date-time].log

Then attach the collected log file to your request. We will investigate the problem and try to provide you with a solution.

Thank you.
--
Aleksandr Isakov

 

I'm getting the same system resources problems with True Image, but intermittently. Same message about not being able to read from the disk during the verification stage due to insufficient system resources. I'm running a machine with 2Gb RAM which I thought would be enough.

Up until now I had been thinking that when this validation step failed, my archive was toast (else what is the purpose of trying to validate the archive?), but this morning I went to manually validate an archive that did successfully validate during the automated backup. (This is a particulary important backup that I don't want to take any chance with.) I was shocked to see the validation fail! Lucky me, I was just about to ice my OS relying solely on this backup! So why did it fail this time, but not during the validation run at backup time? Got me thinking, so I rebooted and validated again. This time success.

So either, the archive is bad, and the validation failed twice (two successful validations - i.e., false pass), or the archive is good, and the validation failed once (false fail). I have a feeling it is the latter, which is good because it means that Acronis is working (i.e, the archive is copasetic), but the failing validation is a little bit of a concern. As mentioned above, I have 2Gb RAM (and no memory leaks that I am aware of), so I am wondering why this seems to fail every now and then.

The only other observation that I can provide is that the chance of validation failure seems to increase with the size of the archive, and also with the time the system has been running. Technically it shouldn't matter, but a reboot seemed to do the trick this time. I guess this does indicate some kind of memory leak, but I haven't seen issues with other memory intensive applications.

Anyway, off to ice my OS now. See if I regret it later I guess.

 

From experience, this is what I have found that's the cause of the "corrupt archive" when you restore from an image that was made recently to the destination computer.

Make sure the RAM on the destination computer is on the Vendor's motherboard's list of approved brand and model found in the motherboard's manual.

Usually, Kingston brand RAM works best. Anything other such as: Samsung, Fujitsu, Markvision, and some generic brand not listed as the Approved parts will cause this "corrupt archive" when you restore or create an image.

 

Does anyone have any data to support this? Has someone actually done the testing to verify that Kingston usually works best? That would be a godawful amount of testing.

For that matter, has anyone collected data re mem and ATI sufficient to say that branding is a better indicator than specs? Generally, if mem is within the mobo maker's specifications, it works fine. Would ATI be especially sensitive to mem problems? Should ATI replace memtest for detecting mem faults?

Okay, and now without my tongue in my cheack: I think one would at least want to run memtest before deciding that mem was at fault.

 

ATI seems to be pretty good at uncovering memory faults which isn't surprising since it is doing a lot of work reading, compressing/decompressing/formatting. I don't know its memory mapping strategy but I think it might hammer locations that most people who have a modern machine hardy ever access. Also, memory on regular machines isn't checked (no parity or ECC) so errors in non-critical locations won't even be noticed. For TI users most have probably found more errors first by running TI than memtest .

If the memory is within the MB spec it certainly should run with no problem. Most spec problems usually occur when the spec is new and the fault is usually marginal motherboard design rather than the memory sticks themselves although the sticks can have some property that offset problems with the MB such as maybe a faster response time than the spec requires which may make it work in some cases or less demanding voltage levels for proper operation or a bit more noise tolerance.

I have run both generic memory, Crucial and Corsair with no problems. Many years ago when I was involved with PCs we did find we had good results with Kingston RAM which was also reasonably priced but more expensive than the cheaper generics. A lot of time has passed so no comment on the current validity of the above.