dump / restore  commands for Linux Minix-FS  =  Written by Amit Margalit.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

This package contains a set of two utilities, performing the equivalent of
dump 0 under Ultrix for the Linux Minix FS. The dump/restore set are two
utilities that store the entire filesystem structure on the backup media,
including all device special files, FIFOs etc. The resulting copy differs
from dd in that it does not store unused blocks, whereas dd does. This
method of backup is good for someone who is backing up to save his ass in
case of disaster, and has the disadvantage of providing no means to restore
single files. Also, the restore has to be done onto a partition of an equal
size to the one the dump was taken from.

In my searches I have seen a comment about the GNU tar 1.11.2 which gets the
uid/gid wrong if they do not exist in /etc/passwd (as is the usual case when
disaster strikes and you need to restore from backups). Also, tar cannot 
store device-files, and not everybody's happy to use cpio.

On to the pressing matters (some more interesting info later):

** Standard disclaimer:

The author shall not be held responsible to any damage of any kind caused by
or brought about by the use or inability to use these programs. The programs
were written specifically to demonstrate the ability, and perhaps inspire
some more talented people to write such utilities for other filesystems.

Copying: This code is provided under the GNU CopyLeft terms, as described in
the GPL version 2, available as "COPYING" in prep.ai.mit.edu ...

-------------

Back to interesting stuff:

Compiling:

gcc -o dump dump.c            		# this will do, but
gcc -O2 -static -o dump dump.c		# is preferred

Substitute "restore" for each occurance of "dump" in the example above to
compile the restore command.

The included binaries were made under the following conditions:
Linux v1.1.20, libc-4.5.26.
Both are staticly linked, using the above command-line (with -O2 -static).
Dynamic linking reduces the sizes to about 9.5Kb!

Use:

dump [-f /dev/<dump_dev>] /dev/<minix_fs>
restore [-f /dev/<dump_dev>] /dev/<minix_fs>

<dump_dev> is the name of the file (or device file) where the data will be
written to. <minix_fs> is the name of a device containing a minix-fs.

The default <dump_dev> is /dev/rmt0, but you can recompile as you like.

How it works:

The dump command reads the superblock. If the fs does not have the valid
signature of a 14/30 character filename minix-fs, or the fs-state is not
clean, it will not be dumped. This means that you cannot dump a mounted fs.
IMPORTANT: Since the program copies only the blocks whose bitmap entries are
marked in use, it is very important that you fsck -r your fs prior to dump.
Any mismatches between the actual data blocks and the block-bitmap will
cause you to lose real file data!!!

After copying the boot sector and the superblock, the inode map and the
block bitmap are copied, followed by the inode-table. All of this is done in
a stream (all these blocks are contiguous), and are copied block by block.
Also, the bitmap is stored in memory for later reference.

About the inode-table: I do not optimize this part as this entire effort is
only to demonstrate the idea and not to be used. (Who uses minix fs these
days???). I could have checked to see if some of the inode-table blocks
contain only unused inodes and not copy them, but I didn't do that for the
above reasons.

After all of these, we have reached the data blocks area. All there is to do
is to read the bitmap, and start checking, byte by byte, in each byte going
from LSB to MSB. If the bit being checked is 1, read the next block from the
fs, and write it to the dump-device. If it is 0, seek 1024 bytes ahead. Then
check the next bit in the bitmap, until all bitmap bits have been checked.

No attempts are made to check if the fs is a device, or if the dump-dev is
or isn't a device. There is no support for dumping to stdout. The program
does minimal checks. Just to see that each operation performed (i.e. read(),
write(), lseek(), open() etc.) did not return with error. Also, restoring to
a smaller partition will fail with some error (I did not try this out).
While trying to restore to a bigger partition will work perfectly, but the
fs will only use the original size, since the superblock information does
not change. To stretch a fs you need to stretch the bitmap table (if not the
inode-table and maps too).

Testing: I have made the following test - (the commands output is not shown)
I created a 7Mb partition (/dev/sda7 on my SCSI disk). I zeroed it out:

$ dd if=/dev/zero of=/dev/sda7

I then created a 30-char filename filesystem on the partition:

$ mkfs.minix -n30 /dev/sda7 7152

I mounted the new fs under /mnt and copied the /etc tree into it:

$ mount /dev/sda7 /mnt
$ cp -a /etc /mnt

Then I dismounted the fs and took a copy of it, and dumped it to a file:

$ umount /dev/sda7
$ dd if=/dev/sda7 of=./sda7.before bs=1024
$ dump -f ./dmp /dev/sda7

After that, I zeroed-out the fs again and restored it:

$ dd if=/dev/zero of=/dev/sda7
$ restore -f ./dmp /dev/sda7

When the restore was done, I fsck'ed the fs, and it was 100% OK. I took
another copy of the fs:

$ dd if=/dev/sda7 of=./sda7.after bs=1024

Just to be sure, I diff'ed the two images (sda7.before & sda7.after), and
diff ended quietly meaning that they were the same (they had the same size
of course).

From checking the output of df, du, and the sizes of the dump files, I could
see that the numbers add up correctly.

Still - this was written in the hope that someday such utilities will exist
for ext2fs, since we need something that will be able to backup the
partitions with high reliability. Backing up just in order to be able to
restore an exact copy to the exact same size of partition need not be done
with utilities such as tar or cpio. dump is just the thing!

Note: The file minix_fs.h is a trimmed version of <linux/minix_fs.h> which
contains only the #defines and struct definitions, so be careful not to mix
them up!!!

To contact me:

InterNet: amit@tavis.enet.dec.com (for at least 2 more months), or you can
send to kobi@bimacs.biu.ac.il, or (preferably) tsvika@www-mail.huji.ac.il,
and ask to give me the message.

Snail-Mail:
Amit Margalit
34 Sheshet-Hayamim st.
Kefar-Sava, 44269
ISRAEL

VMS-Mail: TAVIS::AMIT or TAV02::AMIT
