Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

Backup created in Symantec System Recovery will not restore - ED800012

Created: 31 Jan 2013 | 48 comments

Hi,

  I am currently testing backups with Symantec System Recovery 2013 and cannot restore images.

During the restore with the boot disc I get an error:

Error ED800012: The internal structure of the recovery point file (CRC Validation) is invalid, damaged or unsupported.

Error ED800012: The internal structure of the recovery point file (CRC Validation) is invalid, damaged or unsupported.

 

I'm not sure what to do now. I have tried various things. I even started from scratch by creating a new base image, but still the same issue. When I first installed the application I managed to create a backup that would restore, after opening the command prompt on the boot disc and running clean on both my HDDs. But now it just keeps failing.

 

Any thoughts? Much appreciated.

 

Jon

Comments 48 CommentsJump to latest comment

Markus Koestler's picture

The created recovery point is simply corrupt and can't be used ! Make sure you enable the verify option in the backup job !

*** Please mark thread as solved if you consider this to have answered your question(s) ***

jonnob's picture

Hmm. I don't understand why though.

I even tried a whole new base image to a new removable drive, which results in the same issue.

Is there a problem with backing up to NAS drives?

Cheers.

jonnob's picture

And I have now ticked the verify option, and will create a new backup.

Hopefully that solves the issue.

jonnob's picture

Update
----------

I did recently import some registry file I found online to speed up the backup to a NAS drive, and split up the image into 5068MB chunks. Is this likely to cause an issue?

It's just interesting because when I first run the backup with default settings it worked fine. Now it just keeps on failing. Hopefully this backup I am taking now with the verify thing enabled will resolve that, but it is a bit concerning...

Markus Koestler's picture

It could be the case, yes

*** Please mark thread as solved if you consider this to have answered your question(s) ***

Chris Riley's picture

Please keep us updated with progress.

Enabling verify will slow the backup down, so be aware of this.

If the backup is successful with verify enabled and you still see the same error on restore, please let us know. This would need looking at if you saw this.

Are you referring to the improve performance registry keys?

jonnob's picture

"Are you referring to the improve performance registry keys?"

Yep, that's the one.

The backup is currently at 50%, with verify enabled. Hopefully I can update soon.

jonnob's picture

Okay, the next update.

The full backup is at 62%, but it has been stuck at this % for nearly an hour.

Oh my, this really is not good.The time left to complete jumped up to about 108 minutes and has not moved.

jonnob's picture

Still stuck at 62% and the time has now gone up to 112 minutes.

Hmmm. Is this verify thing causing an issue now?

Really not good...

Chris Riley's picture

The verify process should be done after the backup is complete - so right at the end.

Personally I would say leave it and let it finish, if you can.

We need to see if the backup fails or not. As restores are failing with a corrupt message, I would expect a backup with verify enabled to also fail.

jonnob's picture

Okay. It's now gone up by 1% to 63%. It has been stuck at that for about 25 minutes.

But the time remaining has also jumped to 2 hours. It just seems to be stuck, is there any way to find out what it's trying to do at the moment?

I can leave it, just seems like it could continue like this forever. When verify is not enabled it seems to complete, not sure what is different about this apart from the verify bit (as you say, at the end).

Thanks...

jonnob's picture

Also, looking at the backup folder the size of the data stored in it has not changed for nearly 2 hours now.

It has stayed at 86.176GB

jonnob's picture

Up to 64% now. Seems to be taking about an hour per every 1%. Seems crazy, the whole drive is only using 90GB. I had a look at the data in the backup folder and nothing seems to have been changed since 11:26am this morning (about 1hr 40 minutes ago). Hmm...

I hope it speeds up soon. Could take days if it continues like this, and that would be a bit difficult as it's a live server I need to get backed up.

jonnob's picture

Now that is weird. It just jumped right up and has now completed. Not sure why it got stuck at the 62-64% for so long.

It has failed to backup. I get the following message:

Error EC8F17B7: Cannot create recovery points for job: Full Server Backup (Daily).
Error ED800012: The internal structure of the recovery point file (CRC Validation) is invalid, damaged or unsupported. (UMI:V-281-3215-6071)

Details:
Source: Symantec System Recovery

Hope this will help determine what iswrong here?

Chris Riley's picture

OK, so that tells is the image is corrupt and cannot be used for restore. At least verify is doing it's job here.

I will need to test those registry keys here once you confirm what your backup destination is.

Can you also confirm you are using these ones for 2013:

http://www.symantec.com/docs/TECH171456

Chris Riley's picture

Can you confirm what you are using as a backup destination. Nas, network share etc?

jonnob's picture

Hi,
I am using a NAS Drive as the backup destination.

And yep, I used the AltPerformance1.reg

Many thanks.

Chris Riley's picture

I'm in the process of testing this although I don't have access to a NAS so am just using a network share.

Are you able to test again (with verify enabled) once you have switched back to default mode (DefaultPerformance-x86.reg or DefaultPerformance-x64.reg)?

Chris Riley's picture

Can you also confirm the following please:

  • What operating system is this you are backing up?
  • What level of compression is set in the backup job?
  • Is the backup job using any encryption? If yes, what level?
  • How big are the volumes you are backing up? I need size and approx free space on each volume being backed up

Thanks in advance.

jonnob's picture

Windows Small Business Server 2011 (Server 2008 R2)
Compression set to normal
No encryption
2 volumes backed up. C: = 100GB, D: = 15GB

Both volumes are 1.5TB in total

I've just been on the phone to Symantec as well, and they have got me to re-create the backup job. They also said I may need to run chkdsk due to bad sectors on the HDD?

I can try the other registry file next...

Cheers.

Jon

Chris Riley's picture

What is your case number?

Re-creating the job is unlikely to help in my opinion.

If there are bad sectors, that may explain why the job fails when verify is enabled. BUT, you mentioned earlier that you only see the issue when using the performance registry keys. If this is true, the next step would be to revert the keys back to default and try again.

jonnob's picture

Hi. The case number is 03559968 Thanks JonAn

And I'm not sure it the registry key is the issue, it's the only thing I can think it could be though? I agree with you, I can try that next.

Cheers.

 

jonnob's picture

Okay. I've run the backup again, based on the fixes provided by Symantec on the phone, and it seems as if the same thing is going to happen again.

It's got stuck at 60% for about 30 minutes now. I can see it staying stuck between 60-64% for the next 2 hours, then jumping to the end and throwing an error again.

I can try reverting the registry settings back to the default again next, see if that helps. Not ideal though to be honest, I remember it taking about 13 hours prior to importing the modified registry settings. I'm not 100% sure if it worked after this, but I guess it's worth a try.

Other than this could the local HDDs have bad sectors, or possibly the HDDs in the NAS drive?

Thanks

Jon

jonnob's picture

Update
--------

I just had a look at the logs on my Netgear ReadyNAS and found this:

Reallocated sector count has increased in the last day.

Disk 4:
Previous count: 0
Current count: 8

Growing SMART errors indicate a disk that may fail soon. If the errors continue to increase, you should be prepared to replace the disk.

Could this potentially be causing the issue? Or is this normal with all the data that is getting shifted about, hmmm.

Markus Koestler's picture

I think this could be the very reason

*** Please mark thread as solved if you consider this to have answered your question(s) ***

jonnob's picture

Hi Markus,

  That is very interesting. What could possibly cause this to happen. I only installed the HDDs about 3 months ago. I admit I have tested backups on it quite heavily, deleting and moving folders about, but thought it would be more robust than this. I have been using X-RAID2. Funny enough I did remember some random things happening on the NAS drive the other day, like backups folder re-appearing after I deleted them, and some backup data appearing in folders I had previously deleted etc.

 

I have managed to fully format all 4 of the HDDs now, and rebuilt the RAID. The backup is currently at 53% with verify enabled, so hopefully it gets past 60-64% this time.

 

It just concerns me quite a bit, not sure how I can avoid this happening in the future. Or is it just an unlucky situation...

jonnob's picture

Update

--------

 

That didn't solve the problem. It got stuck at 62% again. Interestingly, it seems to fail at the verify stage for the C: Drive. I am backing up the C: and D: drive.

 

When I look in the backup folder, when it is at 62%, I can see all of the files I would expect to see there for the C: drive (not D: though). It just sits there for ages, then it jumps up to 82%. At the point it jumps up I can see the backup files being deleted from the folder, leaving an empty folder once it hits 100% a few minutes later.

 

Oh my :-(

Markus Koestler's picture

So I really recommend you to run a checkdisk on C: as the error seems to originate from there.

*** Please mark thread as solved if you consider this to have answered your question(s) ***

jonnob's picture

Okay. I've ran chkdsk. Now i'm running a full backup again.

The chkdsk log is below. Do you think this reveals any thing problematic. Cannot see any issue here?

Thanks...

Checking file system on D:
The type of the file system is NTFS.
Volume label is Exchange Server.

A disk check has been scheduled.
Windows will now check the disk.

CHKDSK is verifying files (stage 1 of 5)...
768 file records processed. File verification completed.
0 large file records processed. 0 bad file records processed. 0 EA records processed. 0 reparse records processed. CHKDSK is verifying indexes (stage 2 of 5)...
832 index entries processed. Index verification completed.
0 unindexed files scanned. 0 unindexed files recovered. CHKDSK is verifying security descriptors (stage 3 of 5)...
768 file SDs/SIDs processed. Cleaning up 42 unused index entries from index $SII of file 0x9.
Cleaning up 42 unused index entries from index $SDH of file 0x9.
Cleaning up 42 unused security descriptors.
Security descriptor verification completed.
33 data files processed. CHKDSK is verifying Usn Journal...
36075840 USN bytes processed. Usn Journal verification completed.
CHKDSK is verifying file data (stage 4 of 5)...
752 files processed. File data verification completed.
CHKDSK is verifying free space (stage 5 of 5)...
362450333 free clusters processed. Free space verification is complete.
Windows has checked the file system and found no problems.

1465103359 KB total disk space.
15155012 KB in 124 files.
52 KB in 34 indexes.
0 KB in bad sectors.
146959 KB in use by the system.
65536 KB occupied by the log file.
1449801336 KB available on disk.

4096 bytes in each allocation unit.
366275839 total allocation units on disk.
362450334 allocation units available on disk.

Internal Info:
00 03 00 00 aa 00 00 00 a6 00 00 00 00 00 00 00 ................
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Markus Koestler's picture

Did you run the checkdisk on D: ? Because the output suggests that !

*** Please mark thread as solved if you consider this to have answered your question(s) ***

Chris Riley's picture

If you believe there are issues with the volumes being backed up, you can always use the 'Ignore Bad Sectors' option within the backup job.

However, your earlier comments suggested that either a) the issue is specific to using the performance registry keys (you have not said yet if setting back to default has helped unless I missed that somewhere) or b) there are disk problems on the NAS you are backing up to.

Also, as you are backing up C and D here; why not try backing up just C and check the results. Then backup just D and check the results. If one fails and one works, that tells you where the problem is likely to be.

jonnob's picture

Hi Chris. The HDDs in the NAS drive seem to be fine. I performed a factory reset on the NAS drive though, and formatted them. The Netgear RAIDar suggests all 4 HDDs are now in full working order.

I'm not sure about the registry issue. I am going to try that next. Do I need to reboot after applying this?

Then I may try backing up to a USB removable HDD

Then just the C: drive I guess Cheers.

Chris Riley's picture

If you can reboot, I would recommend it although I don't think it's necessary.

jonnob's picture

Okay cool. I have also installed the software on a Client PC. Could try running it from that to see if it throws back an error? I wonder if that would help determine if the NAS drive does have an issue that isn't being reported by RAIDar...

 

I still do wonder about the registry tweak though. It worked before this and I was able to perform a full restore.

Chris Riley's picture

I still do wonder about the registry tweak though. It worked before this and I was able to perform a full restore.

This is the point I've been trying to make! Until you test the same machine with the default registry settings, we won't know for sure if this is the cause. Please test it so we can at least rule it out as a possible cause.

jonnob's picture

Update
----------

I have just tried the following.

Installed System Recovery on a standard Windows 7 PC - Leaving defaults set.

I then run a full backup to the same NAS drive. It got to 78% and failed with the following message:

Error EC8F17B7: Cannot create recovery points for job: Drive Backup of (C:\).
Error ED800012: The internal structure of the recovery point file (CRC Validation) is invalid, damaged or unsupported. (UMI:V-281-3215-6071)

Details:
Source: Symantec System Recovery

It's exactly the same message? Does this confirm that the registry tweak is not the problem here? I am starting to think the NAS drive is faulty, even though the RAIDar monitoring utility says it is fine.

Markus Koestler's picture

I agree, have a look at the NAS device !

*** Please mark thread as solved if you consider this to have answered your question(s) ***

Chris Riley's picture

Yes, that would suggest the problem is with the NAS and not with the registry settings or with the source volumes being backed up.

Can you try backing up the same machine to a different location? Network share or USB disk for example?

jonnob's picture

It's an interesting one. If I look at the NAS drive it seems happy.

Green lights on every thing. The interface page says all 4 HDDs are fine. It just makes no sense.

I think the next thing I can do is run the backup to a USB HDD. See what that does...

jonnob's picture

I have now run the backup to local storage, and it completes just fine with no errors (verifies as well).

Not sure what to do now. It's crazy to be honest, the software provided by Netgear suggests the device and installed HDDs are perfectly fine.

I've got one of these: http://www.scan.co.uk/products/netgear-readynas-nv...

Is it just not man enough for the job, or is there actually a fault. I've lost a bit of confidence in this Netgear product now, it doesn't provide any warning that there is an issue, and i'm still none the wiser what is wrong with it.

Hmm

Markus Koestler's picture

You could try to throttle the network bandwith in the ssr console to slow done writting to the nas device - this could ease the burden on the nas.

*** Please mark thread as solved if you consider this to have answered your question(s) ***

Markus Koestler's picture

You could try to throttle the network bandwith in the ssr console to slow done writting to the nas device - this could ease the burden on the nas.

*** Please mark thread as solved if you consider this to have answered your question(s) ***

Chris Riley's picture

Are you able to contact Netgear support and find out what file system is configured on the NAS?

jonnob's picture

Okay, that's an interesting idea.

Do you have any ideas what I would throttle it at though. The network is gigabit throughout - about 8 client PCs and a server. Nothing major as such...

Markus Koestler's picture

Does the issue still come up ?

*** Please mark thread as solved if you consider this to have answered your question(s) ***

rpspiker's picture

If this is still open, I have a SBS2011 Server in an VMWare host (5.1) with four virtual servers and four physical servers.  I am using SSR to backup 5 of those servers.  I HAVE NOT APPLIED ANY REGISTRY KEYS. I have SSR 2013 on one physical and one virtual server.  All server backup to a dedicated SSR PC running XP Pro SP3 with a 6TB share (4 2TB drives in a RAID 5 configuration).  All of my backup have checked "Verify Recovery Point After Creation".

Only the SBS2011 server running SSR 2013 is getting the:

Date: 2/15/2013 11:14:33 AM

Notification Type: Error

Priority: High

Description: Error EC8F17B7: Cannot create recovery points for job: Drive Backup of System Reserved (*:\), (C:\), DATA (E:\).

                Error ED800012: The internal structure of the recovery point file (CRC Validation) is invalid, damaged or unsupported.

Details: 0xED800012

Once again, only the SBS2011 using SSR2013 is getting this error. 

I have not run CHKDSK on the SBS2011 server yet.  Since it is a portion of the Server datastore (Windows 2008 R2 server with the Storage Manager for SANS and iSCSI Target) and none of the other servers sharing this SANs have disk issues; I have not taken the SBS2011 off line for the time it would take to run CHKDSK on the to drives.

NOTE: Full backups of SBS2011 using Backup Exec 2012 Rev 14 complete successfully writing to a different disk array.

Has any come up with a resolution for this yet.

rpspiker
There is no right way to do a wrong thing! <><

Chris Riley's picture

@ rpspiker

Please start a new forum thread for this.

I would suggest you start by splitting the job into separate volumes (one for C and another for E). If C is success (with verify enabled) and E is a failure (or vice versa), we'll know straight away if the problem is specific to one of the volumes (or not).