backup verification?

Is it possible to have TI do a verification step to ensure that the created image is an exact replica of the source data? Is this what the "Check created backup archive file when its creation complete" option does?

On a related note, how about verification after a restore operation? I don't see any option analogous to the one above which suggests how to verify that the restored data is an exact replica of the backup image data.

In case there's a better way to achieve my goals, I'll mention that I want to copy many GB of data from one drive to another (but not clone the original drive) and would like to be sure that nothing is corrupted in the copy. How best to use TI9 to do this?

Thanks for your help.

 

Assuming you mean data - not including programs - personally I would simply copy the data over to the other drive. If you want some kind of compression to save space, try using WinZip or WinRar. True Image is more suited for backing up an entire drive.

 

Yes but simply copying files in e.g. Windows Explorer does not, to my knowledge, perform any verification of copy accuracy either. Leaving aside the distinction of backing up individual files/folders vs. an entire drive, how do I know when I restore an image that there hasn't been a transcription error in some random bit? This is the sort of verification that I'm looking for.

 

If you copy files (not creating TI images) then you can verify the copy by using a checksum utility such as AccuHash (www.accuhash.com/).

Most home computers use nonECC memory, which means no checksum is done to ensure that the memory is not faulty. So, as you suggest, it is possible that faulty memory will cause errors when a TI image is restored to disk.
Aside from replacing your motherboard with one which supports ECC memory, you could:
- always use the TI check image / verify option as images are created with checksums. So if you have faulty memory then it is likely TI will report that the image is corrupted.
- occasionally use memtest86 (www.memtest86.com/) to test your memory.
- if you really want to be certain that 'random' errors have not occured during an image restore then you could do the restore to two separate partitions (or disks) and use AccuHash to do a partition checksum.

Of course, faulty memory is not the only way in which data corruption can occur - faulty disk controller or driver for example.

 

Hello pan2,

Thank you for choosing Acronis Disk Backup Software.

Could you please clarify what exact purposes you want to copy the data from one hard drive to another for?

Please also let us know what you mean exactly by the "exact replica of the source data"?

Do you want to create an exact copy of the actual data (files and folders) or an exact copy of all hard drive's sectors including unused ones (so-called "free" and "unallocated" space).

Thank you.
--
Alexey Popov

 

Hi Alexey,

I want to create an exact copy of the actual data, i.e., the files and folders. By exact copy, I mean that I want to perform some sort of verification step (or steps) to ensure that the copied file is byte-for-byte identical to the source file.

I know that TI9 will create an image file of directory structures and will restore that image to a new location with the directory structure intact. My only remaining question is whether TI9 can verify after both recording and restoring an image that the output is indeed byte-for-byte identical to the input. (With the intent to guard against very rare memory or drive errors that might otherwise produce corrupted files.)

 

Hello pan2,

I would like to note that the Check Image tool does not compare the image with the files which were backed up byte-for-byte. It compares their checksums. These checksums are calculated by some of the files' parameters (not the files' data byte-for-byte content).

Please also pay attention that this tool is the same as the verification of an image archive after its creation.

Thank you.
--
Kirill Omelchenko

 

Kirill,
Are you able to say a bit more about what you mean by the "parameters"?
Thanks

 

Hi there tachyon42,

Recommend you use memtest86+ from http://www.memtest.org/ rather than the original memtest86 as it's much more up to date (better hardware support, etc).

Regards

 

Yes, please. Is the checksum something like a CRC check where one can be quite confident that the copy is good if the check passes?

 

Good recommendation, Plus is not just a nice to have version. Friend of mine had a fit when he got all sorts of errors on a new board and memory. Problem was memtest86 isn't able to handle the new technology. Plus version is required.

I always run a memory diagnostic on new memory and record the version of the program and the results so I know if I it shows up faults that they are real and not just the diagnostic not working properly.

 

Thanks for the info.

When I first searched for a memory checker I discovered both programs.
At that time the original memtest86 was at version 3.2 which had been upgraded to incorporate "support for a large number of additional chipsets (from Memtest86+ v1.30)". It also had "Updated CPU detection for newer AMD, Intel and Cyrix CPUs". So it appeared to be the more up to date program. That, combined with the fact that memtest86+ is based upon the original memtest86 source code, meant that I settled on using memtest86. I've regularly checked for updates to memtest86 but neglected to look at memtest86+ again.

Following your recommendation I've now checked memtest86+ again and discovered that the current memtest86+ version 1.65 now supports more recent hardware than the current version 3.2 of memtest86 which was released 11/Nov/2004.

I checked my current SDRAM about a week ago using memtest86 and it didn't find any problem. I'll now test it again with memtest86+ to see what it reports. Given that my system is about 3 years old the recent hardware support isn't an issue however it will be interesting to see if there is any difference as a result of bugs or features in the two programs.
I also have some faulty memory modules so I might compare the results of running both programs with them.

(Apologies to the owner of the thread and the Moderators if this thread is getting slightly off topic. However, given the critical nature of RAM and how it may relate to the ongoing issue of TI corrupt image verification, I hope you don't mind).

 

Hello all,

I'm sorry for not being clear enough in my previous explanation.

I'm afraid that I cannot tell what exact parameters are included into the checksum. But I can clarify that the checking procedure does not compare the original data with the backup. It verifies the integrity of the image file only. This procedure allows you to identify whether you are able to restore the created image file or not.

Thank you.
--
Kirill Omelchenko