The backup is corrupted
ATIH 2011
I created a nightly "version chain" backup to backup my data drive (D:). it appears to have backed up twice so far, both full backups. This morning I noticed that it has a note attached to the "My Backups" list saying the backup is corrupted. However, if I "explore all versions" both backups say they are ready to be restored, with no reference to corrupted data.
I have several questions:
(1) What is actually corrupted, and how do I find out?
(2) Is there any way to purge corrupted versions without deleting the entire chain and all related settings? It seems to be an all-or-nothing function here. All the choices for removing or deleting tell me that I will have absolutely nothing left if I say "yes". Shouldn't there be a way to remove corrupted versions and then let it continue its nightly routine?
(3) if I do absolutely nothing, will tonight's backup give me another FULL backup rather than some sort of incremental addition to the corrupted version?
What are you backing up to, internal disk, external disk etc?
In addition to Scott's comments you should try the validation from the Rescue CD as this uses Linux which is the OS that is used when restoring whether you restore from within Windows or from the CD.
I ran the validation. The log says it completed ok, but the front page still says backup is corrupt. I don't know what to believe.
Why does the log not say why the backup is corrupt? Isn't that the point of having a log?
I'm backing up to a home network drive.
Also, at this point, when I "explore all versions" it will not let me select the prior version.
Why is it acting differently than before?
I understand the value of testing the Rescue CD per se.
But I do not see how that would change the Validation of the archive. It's either good or bad. And either validation routine should be able to tell.
The problem is that nothing is explaining the error message I have on the main list.
Did you run the validation from both the rescue CD (the important one) as well as from within Windows?
The Windows one may correct the error appearing in the task information, whilst the Linux one will assure you that the image isn't corrupt and is restorable.
So far I have only had time to run the validation from Windows. It did NOT correct the error appearing in the task info.
But I do not understand your explanation. Are you telling me that the Windows verify does NOT actually verify the integrity of the backup? If it does not, then why do they call it "verify?" and if it does, they why do I need to run the Linux version in order to be assured that it is not corrupt?
By all means Ignore the log and the front page -- the interface needs a fix that is hopefully coming soon. If the file validated, then it's okay. YOu can remove the backup listing from the list by right clicking and choose remove from list. This will leave the backup file in place. Then you can explore for backups from the front page and when you navigate to the one in question, it will add it to the list -- hopefully correctly.
If yoou boot form the BootCD I'm betting you will be able to restore this backup file jsut fine.
I ran the validation. The log says it completed ok, but the front page still says backup is corrupt. I don't know what to believe.
Why does the log not say why the backup is corrupt? Isn't that the point of having a log?
I'm backing up to a home network drive.Also, at this point, when I "explore all versions" it will not let me select the prior version.
Why is it acting differently than before?
So far I have only had time to run the validation from Windows. It did NOT correct the error appearing in the task info.
But I do not understand your explanation. Are you telling me that the Windows verify does NOT actually verify the integrity of the backup? If it does not, then why do they call it "verify?" and if it does, they why do I need to run the Linux version in order to be assured that it is not corrupt?
It is important that you test the Rescue CD, if you have a crash and the rescue CD cannot "see" your backup then you are in trouble. It is recommended that you restore your backup to either a new drive or to a different partition, or at least start the restore process and cancel out when you get to the proceed button. If this doesn't work download the iso from your account and burn it to CD, it has more up to date drivers than that burnt from within TI
You say that you haven't had time to run the Rescue CD validation but how much time will it take you to restore your data etc. if the Linux drivers can't see your backup drive?
You say that you haven't had time to run the Rescue CD validation but how much time will it take you to restore your data etc. if the Linux drivers can't see your backup drive?
Surely you're not suggesting that someone who does daily backups should reboot from the rescue disc every day and validate his backup?
Not trying to be a wise-guy, but this is not a good answer. Validating using the boot disc may be a wise thing to do on occasion, but if so, I'd have to agree with the user's question, what's the purpose of the "validate backup" function from the UI?
I'm starting to kick myself for immediately jumping on the bandwagon by installing this release over my ATIH2010. Every major version of software (all software, not just Acronis) adds complexity and bugs. For something as important as backup software, I should have probably waited for the 3rd update and let everyone else be the beta testers...
I did not infer that you should validate every backup from the Rescue Disk although many of us only use the Rescue Disk to backup our OS disks in any case.
The OP complained his backups are corrupt, I suggested that he should check the backups by booting from the Rescue Disk, as numerous other posters in previous threads in this and the previous forum have suggested. It has been known for a backup validated from Windows that has been reported as corrupt has validated correctly when validated from the Rescue Disk.
As any restore is carried out by using the Linux OS it is imperative that you check that the drivers on the Rescue Disk can validate the backup and see all your hardware, it is too late if your OS disk goes belly up and you can't use the Rescue Disk to restore it.
David,
I agree that an algorithm is an algorithm and therefore whether it is compiled for a MS or Linux system the result should be the same.
However, as the MS operating system is designed to be used via it's API's there is always the possibility that another program or Windows itself is causing or causes a different set of results to those by an offline OS such as the Linux restore environment (A Windows PE environment would also work in this regard).
The other point to note is that annoyingly the Acronis error messages are somewhat terse and can cover a multitude of sins, it is possible that the validation failure pops up, when it is something else causing TI to hiccup, the rescue CD being off line will give you better certainty. Sometimes it is the Linux version that comes up with the dreaded corrupt image message rather than the Windows version, and as no matter where your start a restore from, it will always be the Linux version that runs the restore unless PE versions have been made.
It might be worthwhile looking in the actual task script and see if the validation entry is recorded here. If it is, then the entry could be deleted and hopefully the GUI will now report everything as it is.
It is important that you test the Rescue CD, if you have a crash and the rescue CD cannot "see" your backup then you are in trouble. It is recommended that you restore your backup to either a new drive or to a different partition, or at least start the restore process and cancel out when you get to the proceed button. If this doesn't work download the iso from your account and burn it to CD, it has more up to date drivers than that burnt from within TIYou say that you haven't had time to run the Rescue CD validation but how much time will it take you to restore your data etc. if the Linux drivers can't see your backup drive?
It would be helpful to me if you would stay with the conversation. I have every intention of testing the Rescue CD. That is not the problem we are discussing here.
I agree that an algorithm is an algorithm and therefore whether it is compiled for a MS or Linux system the result should be the same.
However, as the MS operating system is designed to be used via it's API's there is always the possibility that another program or Windows itself is causing or causes a different set of results to those by an offline OS such as the Linux restore environment (A Windows PE environment would also work in this regard).
Thank you Colin for that insight. It's not really what I wanted to hear, but I sort of get what you are saying. At the same time, it is a bit strange to think I cannot count on a program to read what is on the disk and report it accurately. That part doesn't make a lot of sense.
When I went to look at the Backup list today, the error message was gone, apparently due to last night's differential backup. I guess my next step is to boot up the Rescue disc and run the validate for all 3 dates and see what it comes up with.
David,
I am having the same problem.
Often, right after I run a version backup the screen says the backup is corrupted. If I close acronis TI and then restart it, the messages are gone. Go figure.
Cliff
The archive corrupt message means that TI can't read the archive file into memory and perfectly re-create the 4000 checksums/GB of archive. A single bad bit in one checksum will trigger the corrupt message. So anything that interferes with the read/calculate process will cause the problem. This can be, but not limited to: bad disk sector, bad disk cable, controller, RAM, CPU (yes, it happened), or in other words just about anything. TI, given the amount of data at high speed and with rigid data checking, will often show up hardware problems that don't manifest themselves with normal PC operation.
The Linux recovery environment which is the important one since it is used to recover the archive in case of a HD failure can have a driver that is poorly matched to the hardware and thus show up problems that aren't present with Windows which usually has better drivers for a piece of hardware usually newer hardware.
Of course, there can be programming errors in TI but as a rule the checksum calculation routines are good. The case of an error message that goes away when the program is restarted (which I assume means program restarted and the archive validated) sounds like a possible coding error. There were cases in a previous versions where a validate that was done immediatelay after archive creation in a task erroneously reported a corrupt archive - doing it independently of the archive creation worked fine.
OK,
thanks for the input.
Cliff
Well, I think this thread answers my question too. First time (and backup) with 2011 and I notice the 'backup corrupt' message displayed beneath the backup. Examining the log indicates the backup of all partitions completed successfully. If you're gonna label something corrupt, please add an entry into the log too.
rkh,
Did you Validate the backup to make sure TI could read it successfully?
Yes and it was OK
Yes. Pretty impressive. Guess it's a CRC check of some sort because the read was at a constant 110-120mbps. Now it's green with "The backup is valid".
A contributor to the problem may be a log entry from 11:22am yesterday. That's about the time I defined the initial backup and then scheduled it to run that night at 10pm. The log entry shows analyze partitions followed by the specified file does not exist. Almost like it tried to do a validate before the backup had ever run.
The log is 'pretty' but I can't copy from it to 'paste' into emails or forum posts. Is there an ascii or xml version of it on disk somewhere?
I would like to handout kudo's for making the log easily accessible from the help menu AND remembering the size of the window. Much improved over the 2010 logging.
There is a bug in True Image Home for Netbook (build 6021).
Completed a backup, the main screen shows "Backup corrupt. View log." The log shows "Process succeeded."
First: This is a"bug." The two "reports" should agree.
Second, the backup was truly corrupt due to some problem with the external hard drive. Backup went OK when using a different external drive.
SOFTWARE BUG NEEDS TO BE FIXED!!!!!!!!!!!!!!!