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).