Criando uma imagem_do_sistema

  • Post author:
  • Post category:Sem categoria

Neste artigo em ingl?s estaremos abordando como criar uma imagem de nosso sistema em plataforma Gnu/Linux:

Preparing to change inodes directly

My advice? Don’t do it this way. I really don’t think it’s wise to play with a file system at a low enough level for this to work. This method also has problems in that you can only reliably recover the first 12 blocks of each file. So if you have any long files to recover, you’ll normally have to use the other method anyway. (Although see section Will this get easier in future? for additional information.)

If you feel you must do it this way, my advice is to copy the raw partition data to an image on a different partition, and then mount this using loopback:

# cp /dev/hda5 /root/working
# mount -t ext2 -o loop /root/working /mnt

(Note that obsolete versions of mount may have problems with this. If your mount doesn’t work, I strongly suggest you get the latest version, or at least version 2.7, as some very old versions have severe security bugs.)

Using loopback means that if and when you completely destroy the file system, all you have to do is copy the raw partition back and start over.

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

Finding the deleted inodes

The next step is to ask the file system which inodes have recently been freed. This is a task you can accomplish with debugfs. Start debugfs with the name of the device on which the file system is stored:

# debugfs /dev/hda5

If you want to modify the inodes directly, add a -w option to enable writing to the file system:

# debugfs -w /dev/hda5

The debugfs command to find the deleted inodes is lsdel. So, type the command at the prompt:

debugfs: lsdel

After much wailing and grinding of disk mechanisms, a long list is piped into your favourite pager (the value of $PAGER). Now you’ll want to save a copy of this somewhere else. If you have less, you can type -o followed by the name of an output file. Otherwise, you’ll have to arrange to send the output elsewhere. Try this:

debugfs: quit
# echo lsdel | debugfs /dev/hda5 > lsdel.out

Now, based only on the deletion time, the size, the type, and the numerical permissions and owner, you must work out which of these deleted inodes are the ones you want. With luck, you’ll be able to spot them because they’re the big bunch you deleted about five minutes ago. Otherwise, trawl through that list carefully.

I suggest that if possible, you print out the list of the inodes you want to recover. It will make life a lot easier.

Obtaining the details of the inodes

debugfs has a stat command which prints details about an inode. Issue the command for each inode in your recovery list. For example, if you’re interested in inode number 148003, try this:

debugfs: stat <148003>
Inode: 148003 Type: regular Mode: 0644 Flags: 0x0 Version: 1
User: 503 Group: 100 Size: 6065
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 12
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x31a9a574 — Mon May 27 13:52:04 1996
atime: 0x31a21dd1 — Tue May 21 20:47:29 1996
mtime: 0x313bf4d7 — Tue Mar 5 08:01:27 1996
dtime: 0x31a9a574 — Mon May 27 13:52:04 1996
594810 594811 594814 594815 594816 594817

If you have a lot of files to recover, you’ll want to automate this. Assuming that your lsdel list of inodes to recover in is in lsdel.out, try this:

# cut -c1-6 lsdel.out | grep “[0-9]” | tr -d ” ” > inodes

This new file inodes contains just the numbers of the inodes to recover, one per line. We save it because it will very likely come in handy later on. Then you just say:

# sed ‘s/^.*$/stat < \0>/’ inodes | debugfs /dev/hda5 > stats

and stats contains the output of all the stat commands.