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