Error ED800012: The internal structure of the image file (CRC Check or Frame Header) is invalid...

[Andreas_Horlach]

I am gathering information about this error and trying to find similarities using this forum. If you are experiencing this error, will you please add your comment about how you are attempting to create and/or restore an image when you get this error, what you have done to troubleshoot it and/or get around the error, and if you have solved the problem, what the solution is.

Any data you provide will be invaluable in determining the nature of this error.

[AJJCPA]

BESR 8 Desktop - We concluded that the verify option in job setup caused disk backup to fail.  To reach that conclusion, we tried other combinations that succeeded.  Individual file backups and full disk backup with no verify were successful.

[Periwinkle]

We use BESR to make base backup sets daily to a network share on a USB drive.  The destination works for our backup sets created with LiveState version 6 and some of our BESR version 8 servers, but it does not work with our 2 Windows 2000 servers running BESR 8 and database/mail servers. One runs Exchange 2000 server the other SQL 2000 server.  I can confirm problems with these servers using the verify option, but I do not know if it is due to a bug in the verify option or an actual failure to make a clean image of these servers. It could be due to a compatibility problem with BESR and the database software or .NET on Windows 2000. Both of these serves also have IIS installed, their hosting websites( an intranet and OWA) and Microsoft IIS http scrubbing security tool.

[Phil1]

Hi Andreas,

Thanks for contacting me re this problem.

I had given up on it.  It started in BESR 7 and I had hoped that BESR 8 would fix it, but it didn't.

My scenario - I use BESR 6.5, 7 and 8 on 6 different servers.  It works perfectly on all but one server, which has BESR 8 on it.  The troublesome server has a MegaRAID adapter, with 1 logical drive (70 GB).  The server runs Windows 2000 Server SP4, and has 2GB memory.  There is a C: drive (5GB) for the OS and Program_Files etc, and a D: drive (65GB) for data.  This server runs MS SQL Server 2000 - the executables and the data are on the D: drive.

I can create a BESR job to back up the C: drive with no problems, and I do this every night - a FULL backup every Friday night, and an INCREMENTAL backup every other night.  Works 100% of the time.

But if I add the D: drive to the job, or create a new job that just backs up the D: drive, it (almost) always aborts at the end of the job, with the error message -  

"The Internal structure of the image file (CRC Check) is invalid, damaged or unsupported"

I do NOT use the Verify option.

I suspected that SQL Server might be causing the problem, so I stopped the SQL Svr services, and tried the backup then, but it still fell over with the same error message.

Strangely enough, it WILL work OK occasionally - I have only ever had a successul BESR backup of the D: drive of this server twice (out of several hundred attempts).  I don't know why it worked these 2 times.

I use the same techniques and job options as I use on my other servers, some of which have similar hardware, OS, drive set up, and even SQL Server 2000.  All other servers work flawlessly.

I had given up on this troublesome server, and decided that it must be the unusual RAID card that was cauing the problem.

I will be VERY interested to hear of any progress, or if you would like me to try any new techniques or BESR 8 patches etc.

Thanks,

Phil.

[Markus_Koestler]

In our environment the error occurs since BESR 7, with BESR 6 and LSR 3 and 6 there wasn't this problem. We are now using BESR 7.03 on most of our servers and 8.0.2 bzw. 8.0.1 on a small number of servers. Our servers run windows 2000 SP4. The servers have a C: drive for the OS and programfiles and a D: drive for user and program data. The destination for our backups is a 1 TB Buffallo TeraStation Pro/TeraStation Pro II. We run daily incremental backups and weekly full backups. We use the verify option to check the backups after creation. One thing we managed to find out is, that when setting to option of splitting the backup files into 100MB,250MB chunks the failure rate increases dramatically.

[Yves_Kleikers]

Hello,

I use BESR 8 desktop edition (50 clients) and BESR 8 server edition (2 servers) in a Microsoft Domain (Active Directory) environment. I have never used the verify option with BESR 7 before so I don't know if the issue would have happened with v. 7.

Anyway, with BESR 8 (8.0.1 and 8.0.2) I started using the verify option at the end of a backup job. Following will happen :

- Backup job with verify option > backup location = network share > standard compression > Error ED800012, image file not created.

- Backup job without verify option > backup location = network share > standard compression > No Error ED800012, image file created ... but if I run a manual verify later (with the recovery point browser) the error will appear. So the created image is invalid anyway.

- Backup job with verify option > backup location = local > standard compression> NO Error ED800012, image file created > manual verify later = OK.

- Backup job with verify option > backup location = network share > NO compression > NO Error ED800012, image file created > manual verify later = OK.

Workaround for me at this time:

Either have a local backup location or have no compression of the backup image file. Having either a network share backup location or the standard compression will result in invalid image file.

I am not sure if the verify option will cause the issue at all. Even if I create a backup image file without verify on a network share, the image file will be created successfully (apparently) but I won't be able to restore this backup image at a later point. Also a later manual "verify" will display the error message.

Symantec employee has been trying to help for 3 weeks without any result !!!

Thanks,

Yves

[Andreas_Horlach]

I have a small file (20k) that contains some registry changes that modify the way we communicate over the network. Please SEND ME AN EMAIL at andreas_horlacher@symantec.com and allow me to send you this file and the instructions on how to use it. 

[Skipsargent]

I am experiencing the same error. I am trying to evaluate this product for use in our production environment, so I purchased a retail box copy of BESR 8 Desktop. I installed it on my workstation running XP Pro SP2. I am imaging to an internal 1TB Seagate SATAII drive. Anytime I create an initial recovery point snapshot of my entire drive and I have the verify option enabled it fails with this error. I followed your link, the primary drive and destination drives are both NTFS formatted and the compression is set to none. Any other ideas? I tried to call into to technical support, but I was told that since I bought a retail off the shelf box instead of a volume business package I was not entitled to technical phone support. I'm thinking that was the last nickle I am spending with Symantec.

[Andreas_Horlach]

Skipsargent -  thanks for your post. First, drop me an email (andreas_horlacher@symantec.com) and I'll send you the download you can try. I would post the link directly here, but I'm tracking the error directly before making a general release.

Second, you are the first customer I've had this happen to when saving to a local drive that was not USB, so finding a solution is vital. Can you briefly describe your system hardware configuration? Can you try saving to a different location, such as another internal drive or a USB drive?

[Skipsargent]

You should have my info in your inbox. Thank you for the prompt reply.

[Roxer]

I am having the same issue.  We take snapshots of our running VMware VMs every four hours.  We also keep the base for four weeks before deleting.  I have tried to restore one of the VMs several times using all four Bases and each one fails with the "internal structure" error.  This is part of our DR strategy where we have to certify the backups quarterly.  The backups are performed over the network to a Windows share.  The server failing the backup is a Win2K3 box with a 300GB D: drive.

[mjm01010101]

Andreas I emailed you and no response.  Any chance you can post the files here or a link here? 

[Andreas_Horlach]

Hmmmm. Resend me the email. Make sure it goes to andreas_horlacher@symantec.com. I'll respond today.

[Andreas_Horlach]

Good news - the fix has built into 8.03, scheduled to be released shortly. Once released, please LiveUpdate to this build, or https://fileconnect.symantec.com/LangSelection.jsp.

Message Edited by Andreas_ on 08-13-2008 10:27 AM

[louis11]

I am in desperate need of this fix! Is it released yet? I am using version 8.02, and Liveupdate reports there are no updates. The link you gave shows only 8.02 available.

Help Please!

[Andreas_Horlach]

Drop me an email and I may be able to upload it to your site.

andreas_horlacher (at) Symantec (dot) com 

[louis11]

Do I need to rerun the backups after updating the registry with your fix?

I'm getting this error when I try to do disaster recovery from a bootable CD. If I manually verify the backups in windows they verify OK. However, I CANNOT restore these same backups from bootable CD b/c of this error.

[louis11]

Ok I've found what caused the error in my case. I was testing disaster recovery on different hardware, and the Intel Server I used gave me this error every single time.

I tried it on another computer and it worked. For some reason it is descriminating against the one Intel Server I tried. This is the only computer of the 4 that I've tried that could not restore the backup.

[DaveT]

All,
 

I believe this error is given for several varied reasons:

     Backing up to a mapped network drive, with or without compression, and/or backing up to a network

          share, with or without compression.

     There are a ton of variables in any given network:
          The OS/SP version on the source system,
          The OS/SP version on the target system,
          The actual speed of the LAN (100 Mbps vs Gigabit or higher)
          The speed of the actual target drives themselves (SCSI, SAS, SATA, USB, FireWire, etc),
          Whether or not more than one backup job is sending to the target drive at any given time.
          etc, etc, etc.         

Every network is it's own beast and has it's own characteristics, so you may have to experiment.
 

I also believe that using more than one specific version of BESR can cause this error.  For example: I use BESR to send PC backups across the LAN to a Server.  If I use BESR on the Server itself to open the images, I get the error.  This is because the version of BESR on the Server itself is older than the version on the PCs.

An important detail is the version of BESR on the SRD versus the version of BESR that was used to create the backup image in the first place.  If you upgrade BESR after the install, you should create a new SRD for the system.  I tend to create the BESR SRD .iso's at least once a month, and/or after any upgrade.  I have always presumed that I need to create BESR SRD's to match the specific version of BESR that is installed on the source machine.  Since an older version of BESR won't open an image that was created with a newer version of BESR (like trying to open the PC image files on the Server itself), I presume an older version of an SRD will not recognize the newer image version, either - therefore the Recovery SRD is worthless and the Recovery will not work.  I have not tested this, and frankly don't care; it's too easy to create the SRD's and not quibble about version changes.

These are just a few observations I've made.  As always, your mileage may vary.
 
Respectfully,

Dave T.

[Jacob_A]

DaveT,

I will pass your thoughts on up, thank you.