> On Thu Jul 01 1999 at 10:46, Robert Risch wrote in the Tom's RootBoot
> mailing list:
>
>> I than can leave a tomsrtbt restore disk with a automatic
>> restore script for him. If something gets broken, he put
>> the disk and CDR I created into the PC and starts.
> Perhaps, but I wouldn't do what you are suggesting for the purposes
> that you describing - it's too inflexable.
>> If the CD has a filesystem:
>> mount /dev/hdc /cdrom
>> dd if=/cdrom/imageofw95 | gzip -d9v | dd of=/dev/hda
>> Or if a raw write to the CDR is possible and there is
>> no filesystem nessesary:
>> dd if=/dev/hdc | gzip -d9v | dd of=/dev/hda
> I wouldn't do it like this myself, but I'd like to know if anyone has
> actually been successful doing anything like this.
I've done things like this. However I usually do it in two
step. I create a back of the MBR (boot loader and partition
table) using a command like: 'dd if=/dev/hda of=/tmp/mbr.bin
count=1 bs=512' and separately create the filesystems (using
a script like 'for i in 1 3 5 6 7; do mke2fs -c /dev/hda$i;
done'). Then I extract the desired contents using tar.
I did have to do a patch to fdisk (I added a -r
--reread-partition-table option to force a partition re-read
without requiring a reboot. It was about twenty minutes of
hacking on its sources).
Why? Well, it is more flexible. I can test the integrity
of the MBR and just fix that. Then I can test the integrity
of each file system. I can check for badblocks while
making filesystems. I can use the same CD for auditing
a system (I use 'tar df' to detect differences between
members of my tar files and directories and files extent
on a given filesystem).
Here's a rough script for "scorched earth recovery":
mount -r ro -t iso9660 /dev/hdc /mnt/cdrom
# restore the passwd and group files!
cd /tmp
tar xpzf /mnt/cdrom/root.tgz etc/passwd etc/group
cp -p etc/passwd /etc
cp -p etc/group /etc
dd if=/mnt/cdrom of=/dev/hda
fdisk -r /dev/hda
for i in 1 3 5 6 7; do mke2fs -c /dev/hda$i; done
mkswap -c /dev/hda2
mount /dev/hda1 /mnt/new
cd /mnt/new || exit 1
for i in boot usr var u1; do mkdir $i; done
mount /dev/hda3 /mnt/new/boot
mount /dev/hda5 /mnt/new/usr
mount /dev/hda6 /mnt/new/var
mount /dev/hda7 /mnt/new/u1
tar xpzf /mnt/cdrom/root.tgz
tar xpzf /mnt/cdrom/boot.tgz
tar xpzf /mnt/cdrom/usr.tgz
tar xpzf /mnt/cdrom/var.tgz
tar xpzf /mnt/cdrom/u1.tgz
sync; sync; sync
lilo -R /mnt/new
cd /
for i in u1 var usr boot ; do umount /mnt/new/$i; done
umount /mnt/new
umount /mnt/cdrom
eject /dev/hdc
shutdown -r now
You can have an additional script that connects
to a server to restore data files using your
favorite technique. Just link a reference into
that into your rc scripts. Something like:
[ -x /root/tmp/executeme ] && {
/root/tmp/executeme
rm -f /root/tmp/executeme
}
... should do the trick (assuming you have "safe"
permissions on /root/tmp/executeme).
(You can reasonably leave this "executeme"
reference in your rc scripts for other special
purposes if you like).
Caveat lector! Make sure your 'eject' command
works before using this script. (Otherwise you'll
go into an endless cycle of re-installing your
OS from scratch).
Naturally you can mix in mkdosfs and restoration
of MS-DOS/Win '9x files and dd extractions of
raw NTFS and other filesystems to your heart's
content.
--
Jim Dennis [EMAIL PROTECTED]
Linuxcare: Linux Corporate Support Team: http://www.linuxcare.com
