a close one
June 6th, 2004whew.
that was nearly the end of the webserver. i was trying to make a backup of it when I mistyped da1 instead of da2 when doing what the handbook chapter on adding a disk suggest I do to prepare the disk:
dd if=/dev/zero of=/dev/da1 bs=1k count=1
actually, i used bs=512k and count=2 which might be the source of my problem, or at least the reason that fdisk -b 32 /dev/da1 doesn’t seem to fix anything.
so, i thought, i’d better be careful, I could lose a lot of important data! …I should re-mount this disk read only so I don’t overwrite anything.
but then….
niagara:/root# mount /1
mount: /dev/da1e on /1: incorrect super block
“OH NO!” (well maybe i didn’t say exactly that, but you get the idea)
I should stop here and point out that never did it enter my mind that everything was not going to be just fine. I guess part of the reason I didn’t really panic was I knew that I had only deleted the first 1048576 bytes of the disk. That isn’t even enough for a very big file. Well, it was enough, because in the documentation for newfs says:
Note that changing any of these values from their defaults will make it impossible for fsck(8) to find the alternate superblocks if the standard superblock is lost.
Now is not the optimal time to realize that using -m0 to squeeze an extra 8% out of disks is probably not worth it, but whatever, now is not the time.
I’m not sure why I decided to try it, but I figured if mounting /dev/da1e wouldn’t work, mounting /dev/da1 just might. Maybe. (it did!)
pwhew! now I am able to take a backup of that disk using dump like this:
niagara# mount /dev/da2e /2
niagara# cd /2
niagara# dump 0af - /dev/da1 | restore vxf -
Edit: Don’t forget to newfs /dev/da#e before you restore … and cutting out the “v” option can make things go much faster, depending on your terminal speed.
and this backup works such that I could mount /dev/da1 to /1 or /dev/da2e to /1 and both contain *all* of the webserver data. Of course, they’ll fall out of synch pretty quickly, but it is at least comforting to know that I have a backup for the more common cases of failure.
Next to do would be to script this to happen regularly (daily? weekly?) and try to make an offline-browsable version of the server’s data.
Filed under: FreeBSD
