Pick a partition and it determines the start and stop blocks of data in that partition. In the end, I found other backups off this computer, that had the files that were lost.Īt the very start, TestDisk looks for all the drives, and when you pick one it looks for all the partitions on that drive. Many files were lost, but many more were retained - to my surprise. All I had to do was write the partition table that it had discovered. I then rebooted.I got a normal boot to GUI and was then able to run TestDisk. To do that, I copied the /etc/fstab file to a backup name and the edited the file to remove the automount line that mounts the problem partition (/dev/sdb1). Anyone know?ĭoes anyone know if TestDisk has used the back-up partition metadata to find the info shown?īefore using TestDisk, I had to stop the automatic emergency mode boot that CentOS was taking by stopping the mount of the partition /dev/sdb1. Now, I'm not sure what the correct "partition characteristics" should be for this 500GB sole partition. Should I copy these files somewhere first, before I create the MBR? Should I use PhotoRec before that to recover files. I listed the files some are marked as deleted, but a folder that holds all the files is marked as intact. Keys A: add partition, L: load backup, T: change type, P: list files,Įxt3 blocksize=4096 Large_file Sparse_SB, 500 GB / 465 GiB *=Primary bootable P=Primary L=Logical E=Extended D=Deleted Use Left/Right Arrow keys to CHANGE partition characteristics: Use Up/Down Arrow keys to select partition. Is that my best move forward? The data is certainly important, but not valuable for +1000$ required by recovery companies.I am using TestDisk to try to recover the a data hard drive (1 data partition) that I accidentally wrote on (4GB) with "dd". Thinking of doing a fresh attempt via ddrescue after photorec finishes as I have only two other drives of 4tb file size - one for image creation & one for file restoration from the image created. img file than testdisk (although testdisk retained the file structure, & was faster.) Why is that? Photorec seems to find more files on this. It does not even start the process when started from backwards (initially, when ran backwards, it would recover data 105kb/s estimating around 210 days for a 4tb drive) I had to reboot the system as ddrescue would show up as 'D' state in the Process Manager & would not close or be terminated.Ĭurrently using photorec to recover files of partial image file created by ddrescue. Yes, ddrescue seems to be my best bet, but unfortunately it freezes at 30% when a forward pass is run, with no progress showing up in the terminal window. Is that ok? Shouldn't unmounting a drive reduce the read errors (if not at all)? The Raw Read Error rate was 235 before copying files & went up to 531 after Testdisk completed the copying. I do not necessarily consider an increase of the "raw read errors" as harm to the drive.
The second run gave me errors at places where the first run succeeded. I remember modifying the ddrescue parameters, rerunning ddrescue into another rescue file. They both broke most probably due to my handling. I had two Samsung S1 Mini drives (1.8''-drives) that I used as mobile drives. If the "on time" used for recovery puts a broken drive under stress any strategy to minimize that time is good. Furthermore if the affected drive contains lots of small files, ddrescue could reduce the time needed to copy the files by copying the drive. The advantage of ddrescue is that it's minimizing head movements by reading sectors in a linear way unless it hits faulty sectors where it tries to jump over the affected area.
#Testdisk copy files to another drive software
I wanted to know whether Testdisk will cause more harm to the drive (like increasing the raw read errors) while copying the data while the faulty drive is unmounted?Īny access to a dammaged drive is risky and could cause more harm regardless of the software used. Thank you for your response the most important files is what I intend to do.as ddrescue is hanging with the drive being in 'D' state for hours, creating an image is becoming difficult.
0 kommentar(er)
