Tag Info

New answers tagged

0

In any case I'd stop working on the device being used as soon as possible to avoid any disk writes, and boot into a dedicated recovery OS, like SystemRescueCd, which is a Live-CD so you can mount your disk read-only in order to prevent further data loss. Those distros include a lot of recovery tools mentioned by others, and you can install most missing. I ...


0

Possibility to recover file hardly depends on filesystem. Some filesystems have recovery options and others (most) are very limited. For ext3/ext4 (most used filesystems) there is extundelete. Though, even success recovery of mysql directory cannot guarantee consistency of recovered database. It can be consistent only if data files were flushed by MySQL to ...


-1

btrfs is a next-gen filesystem - it encompasses many of the same purposes as past layering models handled between them. btrfs is a formiddably extensive stack as well - the faq recommends it be written out to an unpartitioned disk*[s]* and that all partitioning, quotas, compression, imaging, striping, copy-on-write, deduplication, and probably 10 other ...


0

I just don't buy such arguments that disks regularly have unreported errors and chalk it up to FUD. Yes, if you throw enough random data at the error detecting code, it will sometimes report the data is correct when it isn't. Here's the thing though: the drive isn't trying to read random data. It is reading data that has mostly been written and read back ...


3

Disks can and do silently corrupt data. See http://storagemojo.com/2007/09/19/cerns-data-corruption-research/ for just one example of research on this.


0

Yes, it doesn't trust the device to report errors or to store the correct data in the first place. Whether this is actually necessary is another question entirely. It's not something anyone worries about, usually, and things just work. If you have a disk that does not report errors, you have a huge problem anyway; it's not only filesystems that rely on such ...


1

Assuming you have GNU sed, you can try (not really tested): hdparm --read-sector $SECTOR /dev/sdb | \ sed -r -e "0,/succeeded/d" -e 's/(\S\S)(\S\S)/\2\1/g' | \ xxd -r -p >> bindata.bin The sed call deletes everything up to the succeeded line and then byte-swaps the output. The xxd -r -p call translates plain hexadecimal code to binary data.


5

The traditional way is to copy all files elsewhere and see which one triggers a read error. Of course, this does not answer the question at all if the error is hidden by the redundancy of the RAID layer. Apart from that I only know the manual approach. Which is way too bothersome to actually go through with, and if there is a tool that does this magic for ...


0

Recovering data from formatted drive or from a deleted partition is a bit of possible thing. But recovering data from drive which was formatted and then written upon is not possible, since data might be overwritten and accessing the old data is impossible now. Though you could try your luck with testdisk utility. But sorry, as far as my knowledge it won't ...


0

It seems the RAID metadata got damaged somehow. How did that happen? Once you've fixed any misconfigurations, errant scripts, hardware problems, etc., try to mount read-only: mkdir /mnt/{sdb1,sdc1} mount -o ro,loop,offset=$((2048*512)) /dev/sdb1 /mnt/sdb1 mount -o ro,loop,offset=$((2048*512)) /dev/sdc1 /mnt/sdc1 See if either one mounts, verify files of ...


4

You can run strings as root on your filesystem: sudo strings -n 6 /dev/sda Adjust the number 6 to the minimum of the lengths of your login name and password (smaller number gives more stuff to wade through). You can store the output to a file and search through that, or directly pipe into grep with before and after lines displayed: sudo strings -n 6 ...



Top 50 recent answers are included