Failed Backups of C Drive
I am continuing to have failed backups.
First I had a problem with my external drive not being tightly connected. Fixing that seemed to solve the problem for a while.
Then I discovered by accident that that the problem I was now having with doing validation, occurred only when Zone Alarm Extreme Security was running. When I closed Zone Alarm, I was able to do the validation of my backup.
After installing a new version of Zone Alarm Extreme Security, and the latest build of TIH 6868, I was able to get one good backup, but only after I turned ZA off completely.
Now I am not able to get any good backups at all, even if ZA is totally off.
The only error message I am getting is a generic "Error occurred while writing the file. Click Browse to specify another location, Retry to try again, or click Cancel"
When I had the first problem of the poorly connected external drive, I checked both disks and they came out clean. Good idea though, as I have found that TIH can cause indexing errors on the target drive after a failed backup attempt. I'll check it (F Switch) and let you know.
Thanks again, Grover.
I did the DSKCHK/F on my target drive; all OK. Then I uninstalled Zone Alarm completely and cleaned up the uninstall with their cleanup tool. Voila, I was able to do a successful backup and validation!
While it was running, I remember seeing a question about running TIH without installing it. Then I thought, I'll ask Grover if I can just do a backup from the recovery CD, and in the Linux environment. That would eliminate any Windows-related interference.
When I looked at your post, I was very happy to see your comment!
I'll give it a try.
I tried the backup from the recovery CD. The backup failed with an error message "unable to write to sector "so & so". The second part of the error message was more cryptic: "Linux Device Node With Internal Number 3 Not Found (0x1000FF)."
Nonetheless, I ran Western Digital's extended diagnostic on the target drive. Came back "Failed-too many bad sectors". Something untoward must have happened to the drive between now and when I ran a check on it a couple of months ago.
I like the idea of doing the backup with the CD. Also, I understand the validation is more reliable in the Linux environment.
Well, off to get an RMA for the bad drive.
I'm glad you found a solution.
After your restore you backup to the new disk, the first thing you should thing you should do is to run a disk check on the new disk after the restore. There may have been some bad sector residue inside the backup and running the check will start you with a clean slate. Be sure and use the "/R" (Chkdsk c: /R). The R factor checks the disk for errors whereas the /F only checks files for errors--not disk errors. The results of the check are displayed inside the events section under applications.
You might find this link helpful to see where all the options are listed. This is a 2010 guide but applicable to 2011.
I you decide to work within Windows, create a new task for TI to start fresh.
Not sure I understand your post. The drive that has the errors is the external backup drive, so I will not be restoring anything when I get a new one. Rather, I will check the drive for errors before I try to back up to it. There are three good backups on the defective drive, and I wish I could somehow transfer them to another drive before I send this one back for replacement under warranty.
Also I don't understand your comment about where the results of chkdsk are to be found. They are usually directly reported unless the test was clean.
Is the link you are referring to "Grover's Index"?
Good advice on trying to update a failed backup, rather to start a new one. However, if I remove the failed backup from the list of backups, there will still be an empty backup folder on the target drive, which will have to be deleted.
Here is the link showing where chkdsk results are displayed inside Windows.
I would never delete a backup until I had proven that the replacement was valid and had the proper content.
I can understand why you did not understand. I was referring to the disk which was being backed up and you were talking about the disk used for storage. My mistake. The point I was trying to convey is that when a disk has bad sectors and that disk is being backed up, the bad sector settings are carried into the backup and restored onto a new disk if the backup is restored. Thus, new disk receiving the restore would need to have chkdsk run to remove the bad sector settings. As it was your storage disk that was bad, my comments were not applicable to your situation.
Yes, I would copy the backup to some type alternate location. You may even want to consider buying another storage disk so you will have an alternate for even more safety.
Thanks for the info on CHKDSK and on bad sector remnants. As far as deleting backups, I never delete one unless I have at least two additional validated ones on my backup drive. I am talking about deleting a failed backup, which will still appear on the TIH interface as not completed. My experience in the past is that it is not a good idea to try to complete one of these, but to start over with a new task. I can remove this uncompleted backup from this list, but this does not delete its empty folder from the target backup drive.
PS from a previous post. I have heard that a backup may not be truly validated in the Windows environment, but must be validated under Linux, i.e. with the recovery disc. Your comments?
As the TI Bootable Media Recovery CD is the preferred and recommended method for creating or restoring a system disk, it is the validation by the CD that carries the most weight. You want the CD not to have any issues with the restore or clone so for it would seem that a validation by the CD would be best. However, this may be a matter of opinion rather than fact. I have not seen any writings by Acronis that says one is better than the other. A validation by Windows would seem to have less validity due to ongoing background activity whereas a validation by the CD does not involve Windows.
Whenever I start a new task and have no need for a prior folder, if it is empty, I just delete it. If the backups have no value, I will delete first from within the task and do any cleanup manually. I make it a practice not to edit tasks--except maybe for a schedule change. Frankly, I am not an advocate of the current method of database control of backups but this is what comes with the current program until if & when they decide to make changes.