Note: This web page was automatically created from a PalmOS "pedit32" memo.

Unix and Linux filesystem recovery, without LVM or other volume management


The raw device method (should work on about any unix or linux, but is far more effective with text files. It could easily be adapted to work almost as well with binary files though). seki-root> fdisk -l Disk /dev/sda: 80.0 GB, 80026361856 bytes 255 heads, 63 sectors/track, 9729 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 13 104391 83 Linux /dev/sda2 14 9729 78043770 8e Linux LVM Disk /dev/sdb: 250.0 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdb1 * 1 30401 244196001 83 Linux Tue May 10 09:41:11 seki-root> df /dev/sdb1 Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb1 240362656 212178756 15974100 93% /sdb1 Tue May 10 09:41:22 seki-root> reblock -e $(expr 244196001) $(expr 128 \* 1024) 300 </dev/sdb1 | slowdown 0.01 egrep --binary-files=text -i -A 4096 -B 4096 'means to buffer the lines, to get accurate estimates' >/tmp/count-hits stdin seems seekable, but file length is 0 - no exact percentages Estimated filetransfer size is 250056705024 bytes Estimated percentages will only be as accurate as your size estimate (estimate: 0.0% 0s 42m 7h 1d) Kbytes: 129920.0 Mbits/s: 16.7 Gbytes/hr: 7.3 min: 1.0 (estimate: 0.1% 20s 23m 7h 1d) Kbytes: 259072.0 Mbits/s: 16.8 Gbytes/hr: 7.4 min: 2.0 (estimate: 0.1% 0s 15m 7h 1d) Kbytes: 289280.0 Mbits/s: 16.9 Gbytes/hr: 7.4 min: 2.2 In the command above, we're: 1) Using reblock to get throughput and percent complete estimates 2) Telling reblock the size of the raw device with -e. The huge number was obtained from fdisk -l 3) The 128 * 1024 tells reblock that we want to use 128 kilobyte blocks 4) < /dev/sdb1 is a non-LVM2 partition that we want to search through 5) The "slowdown 0.01" is to keep this search from rendering a system painful to use, due to the extremely high I/O load 6) The GNU egrep is of course searching for a long pattern that is likely to occur only in the script that I'm trying to recover 7) The "--binary-files=text" tells egrep to output the text of matches, not to just say "binary file matches". 8) The -A and -B are telling GNU egrep to output 4096 lines on either side of the matches, which should be plenty of lines for this script


Back to Dan's palm memos