7. Preparing to write data elsewhere
If you chose to go this route, you need to make sure you have a rescue
partition somewhere -- a place to write out new copies of the files you
recover. Hopefully, your system has several partitions on it: perhaps a
root, a /usr, and a /home. With all these to choose from,
you should have no problem: just create a new directory on one of these.
If you have only a root partition, and store everything on that, things are slightly more awkward. Perhaps you have an MS-DOS or Windows partition you could use? Or you have the ramdisk driver in your kernel, maybe as a module? To use the ramdisk (assuming a kernel more recent than 1.3.48), say the following:
# dd if=/dev/zero of=/dev/ram0 bs=1k count=2048
# mke2fs -v -m 0 /dev/ram0 2048
# mount -t ext2 /dev/ram0 /mnt
This creates a 2MB ramdisk volume, and mounts it on /mnt.
A short word of warning: if you use kerneld (or its replacement
kmod in 2.2.x and later 2.1.x kernels) to automatically load and unload
kernel modules, then don't unmount the ramdisk until you've copied any files
from it onto non-volatile storage. Once you unmount it, kerneld
assumes it can unload the module (after the usual waiting period), and once
this happens, the memory gets re-used by other parts of the kernel, losing
all the painstaking hours you just spent recovering your data.
If you have a Zip, Jaz, or LS-120 drive, or something similar, it would probably be a good choice for a rescue partition location. Otherwise, you'll just have to stick with floppies.
The other thing you're likely to need is a program which can read the
necessary data from the middle of the partition device. At a pinch, dd
will do the job, but to read from, say, 600 MB into an 800 MB partition,
dd insists on reading but ignoring the first 600 MB. This takes a not
inconsiderable amount of time, even on fast disks. My way round this was to
write a program which will seek to the middle of the partition. It's called
fsgrab; you can find the source package on
my website
or on
Metalab
(and mirrors). If you want to use this method, the rest of this mini-Howto
assumes that you have fsgrab.
If none of the files you are trying to recover were more than 12 blocks long
(where a block is usually one kilobyte), then you won't need fsgrab.
If you need to use fsgrab but don't want to download and build it, it
is fairly straightforward to translate an fsgrab command-line to one
for dd. If we have
fsgrab -c count -s skip device
then the corresponding (but typically much slower) dd command is
dd bs=1k if=device count=count skip=skip
I must warn you that, although fsgrab functioned perfectly for me, I can
take no responsibility for how it performs. It was really a very quick and
dirty kludge just to get things to work. For more details on the lack of
warranty, see the `No Warranty' section in the COPYING file included with
it (the GNU General Public Licence).
Next Previous Contents