How Not To Lose Your Data
1 Regular Backups
While the tricks on this page are nice, they are not as good as a real backup solution. If, for whatever reason, you choose not to do regular backups, go to step 2.
2 Regular Backup of File System Metadata
The file system metadata is information about your data: which bits of the disk store which files, directory structure, filenames, and physical locations of file contents on the disk. e2image lets you make a copy all of this extra data into a sparse file and dumpe2fs gives you a human-readable dump of the superblock and block groups.
e2image has two different modes of operation: normal and raw. Read the e2image manpage to see what the difference is. (Basically, raw images are a bit-for-bit copy of your entire filesystem, except that they don't include the blocks containing data. The image is created as a sparse file, which means that the file doesn't actually take up as much space as ls -l or stat report. It does include the data blocks that contain directory information, so raw images contain slightly more information than standard images. Unfortunately, most e2fsprogs utilities can only work with standard images.) In both modes of operation, e2image creates sparse files, but I prefer to compress them with bzip2. Even though creating a compressed e2image with the -r (raw) option can take a very long time, it is really the only option if you want to copy these image files to a remote server for safe keeping. (Apparently I am wrong about that. You could probably use the --sparse option to rsync.)
dumpe2fs /dev/device | bzip2 > `date +%F`.dumpe2fs.bz2 # (because current versions of e2image like to perform random access on # the image file, it must be created before being compressed with bzip2) e2image /dev/device `date +%F`.e2image && bzip2 `date +%F`.e2image # raw image; takes much more time than the other two commands e2image -r /dev/device - | bzip2 > `date +%F`.raw.e2image.bz2
It's probably not a good idea to be writing to the device while executing these commands, but it should probably be okay to keep the device mounted and to read from it. (I've done it with no ill consequences.)
3 Wait for Catastrophe
4 Recover from Catastrophe
So lets say that your superblock or your inode tables or your group descriptors are horribly deformed by a disk error. You can use the metadata backups created by e2image to help you to recover the data.
# image must be decompressed first # cp is used to write the decompressed image as a sparse file bunzip2 -c YYYY-MM-DD.e2image.bz2 | cp --sparse=always /dev/stdin ./YYYY-MM-DD.e2image # tell debugfs to read metadata from the image file, but to read file contents from the device debugfs -d /dev/device -i YYYY-MM-DD.e2image # alternatively, you can tell e2image to overwrite the metadata on the # device using the metadata in your backup. # This performs permanent writes, while the debugfs command does not. # READ THE WARNING IN THE e2image MANPAGE ABOUT THIS FLAG! e2image -I /dev/device YYYY-MM-DD.e2image
NOTE: I have never been able to use e2image -I or debugfs as described above. When I tried them, both gave me errors reading the image file I had. I ended up creating a python program to manually overwrite the group descriptors, block bitmaps, inode bitmaps, and inode tables using the information stored in a raw image. I was able to recover the filesystem, but it would be nice to use official tools. I have no idea what was wrong with my image and would like to know whether feeding images to e2image -I or debugfs actually does work for somebody.