📜 ⬆️ ⬇️

Acronis True Image vs R.Saver, or "Two Fellows on a Dead Man's Hard Disk"

A tale about how not to save data from a half-dead hard drive

Be gentle with hard drives!

Recently brought the Samsung NP-N210 in poor condition. They were playing football or conducting military actions - the story is silent, but the German XP refused to be loaded on it flatly.

The required result is “at least family fotos to pick out of it.”

image
')
Well, with the worked-out motion we spin the back of the laptop, remove the hard drive, connect it to the interface converter (pictured above), wait ...

The disk was recognized, the sections are visible, the data is the same too, but ... The disk is covered with bad sectors, like a dog - with fleas. Of course, a lot of system files got it, so the operating system can’t be saved anymore (citizens, have pity on the technique - if you hammer nails with it, then at least turn it off first!).

Attempts to simply rewrite most of the "family fotochek" on the working disk systematically fail, and the only result of this approach is the dead hovering of the disk.

After the disconnection, the partitions on the disk are no longer visible - apparently, the disk is on the last gasp. We take out Acronis True Image Home (Trial) from wide trousers of the Internet, play it on a disk in the hope of reading sectors into an image and then working with the image.

A hardworking True Image gets down to business ... A day passes ... The sector is still being read ... The second day ... Third ... And here it is - the error of the resident of your humble servant - the disk resource is not enough to tidy and hardworking, with many repeated attempts (hello to Acronis ) read every bad sector . The disk tightly veils the system (and this is via USB!). After the reboot, the patient finally stops giving any signs of life.

Well, we have on hand a dead hard drive and a piece of TIB image - about 10 gigabytes. Browsing in a hex editor inspires hope:

image

Fortunately, the disk image was made complete, sector-wise and uncompressed, so the data can apparently be used (after all, optimists are happy people).

We will not dwell on the numerous attempts to mount this bit of a file system fragment in order to read anything worthwhile from it. True Image Home confidently said “not mine”, various third-party utilities did not see anything useful in the ten-gigabyte file either. Search for a description of the TIB format on the Internet has not brought results.

Isn't it time to remember the useful and sensible program - R.Saver from R.LAB? We are inciting her on the archive, and - NOW-THAT ... Hope dies.

image

A few days have passed. One morning, another enlightenment brought a fresh thought - to carry out the so-called "investigative experiment." We uncover the main weapon - Windows XP Mode. Who does not know - this is a virtual XP, closely integrated with the host Windows 7.

We create a small 50 megabyte disk on this virtual machine (so that the experiment does not take an eternity), format it in NTFS, drop some files on it so that at least some sectors are not solid zeros. Install on the same virtualku True Image Home and Disk Editor. The first of them creates a tib file for us, the second - a complete sector-wide image without any headers and other excesses. Then we install Beyond Compare, the first software creature that the authors claim is good at comparing binary files. Well, check.

image

image

The comparison immediately reveals the file header and some regular data blocks of 68 bytes, which are in the TIB and are missing in the sector image. Here it is, the secret weapon of Acronis! It is these blocks that break down the archive structure and prevent R.Saver from concentrating on finding leftover files. I suppose that these blocks are something like a checksum or some markers, since they are inserted after every 256 kilobytes (or 512 sectors). It is unlikely that we will learn the truth from the creators of True Image, but if someone from respected readers can clarify what these data blocks are and why they are needed - you are welcome to comment.

So, it makes sense to remove these blocks and the title, and offer what remains to the R.Saver program - in the hope of the best.

It is well known that a normal person will just do, and the programmer will automate first. In this case, automation makes sense, because cut out from a ten-gigabyte archive blocks of 68 bytes, located every 256 kilobytes - an occupation for VERY patient - for a minute, about 40 thousand operations are obtained.

Since the task itself, although very tedious, is very simple, the search for something already existing will take guaranteed more time than writing a modest bike.

Stocking coffee ... In general, the coffee did not even have time to cool. Actually, here is the entire listing:

My bike
#include <stdio.h> #include <stdlib.h> #define BUFSIZE 262144 int main(int argc, char* argv[]) { if(argc < 5) { printf("tibclean <src> <trg> <protection record size> <header size>"); return 0; } printf("arg1==%s\targ2==%s\targ3==%s", argv[1], argv[2], argv[3]); off64_t protectionRecSize = atoi(argv[3]); off64_t headerSize = atoi(argv[4]); FILE* sf = fopen64(argv[1], "rb"); if(NULL==sf) { return 1; } FILE* df = fopen64(argv[2], "wb"); if(NULL==df) { fclose(sf); return 2; } off64_t offs = headerSize; fseeko64(sf, offs, SEEK_SET); char fbuf[BUFSIZE]; unsigned int readbytes; unsigned int writtenbytes; off64_t divbuff; int lastmbytes = 0; int mbytes = 0; while(!feof(sf)) { fseeko64(sf, protectionRecSize, SEEK_CUR); readbytes = fread(fbuf, 1, BUFSIZE, sf); if(0==readbytes) { break; } writtenbytes = fwrite(fbuf, 1, readbytes, df); if(writtenbytes!=BUFSIZE) { break; } //reporting divbuff = ftello64(sf); divbuff = divbuff / 1048576; mbytes = (int)divbuff; if(mbytes!=lastmbytes) { printf("%d mbytes ready\n", mbytes); lastmbytes = mbytes; } } fclose(sf); fclose(df); return 0; } 



The length of the header and the length of the block to be cut is set from the command line, since in the test tib file and in the one that was inherited from the untimely dead hard drive, the size of the inserted block was different - 68 bytes in the test image, and, surprisingly, only 12 bytes - in the "inheritance".

Well, we start our microutility:

 TIBClean.exe drive_c_full_b1_s1_v1.tib cleaned.img 12 28 


Attempt number two - R.Saver eagerly snaps at a slightly thinner file, and - oh, a miracle - finds in it the file system, although it is damaged.

image

image

Then everything is simple - select all the files of interest, and try to save them. Unfortunately, 10 gigabytes is not all spaces of the former data section, so not a very large part of the family photo archive is restored, alas.

findings

Do not use Acronis True Image with disks on which there are A LOT of bad sectors - this wonderful utility is intended for other tasks! Broken sectors immerse it in thought, which does not contribute to improving the health of a dying hard drive.

For such cases, use R.Saver - the best of free programs designed specifically for emergency rescue of your data acquired by overwork if the remaining life of a disk is in hours.

To prevent such cases, do not play laptops in football and tennis, and do not use them as a personal weapon.

Make backup copies of your data.

Disclaimer

I am not an employee of R.LAB and have nothing to do with it. Also, I am not a spiteful scandal or a competitor of Acronis, and I don’t blame anyone except myself for its product in this particular case.

Happy end

After a couple of weeks of rest, the "corpse" partially came to life in the drawer of the table - with terrible brakes, but it was detected in the system, although the sections on it were still not visible. Taught by previous bitter experience, the author of this opus immediately used R. Saver and the saving power of prayer . It was possible to save more than 80 percent of the “family photo archive” of my friends who are interested in nailing with a laptop.

Source: https://habr.com/ru/post/362655/


All Articles