Polarwave's OpenBSD
Tips and Tricks for Newbies
| Dump & Restore |
Dump & Restore
Mount Partitions to Restore Backups
The main thing I'm trying to accomplish here is to get people new to OpenBSD
to get used to backing up. After you've lost an installation a couple of times,
along with reading one of the first questions a reply to a lost data message will
be on the mailing list, which is "You do have a backup, right?", you'll start to
think, "Hey, maybe I should try that too!" ;)
So I asked myself, what do I do if a partition gets corrupted? Yeah, I do dumps
regularly to another disk, so I have good, recent backups. I simply do
$ sudo dump -0au -f /data/backups/usrlocal.dump /usr/local
Then I sit back and read a good man page, eat some pizza, or whatever. ;) But,
when you boot from an OpenBSD install cd there's no matching /dev/wd1d there.
There are no devices with wd1, only wd0. There's MAKEDEV but it says
that
the operation isn't permitted when I type
./MAKEDEV wd1d
What's going on here? I don't have to worry about being root, it's an installation
cd. Actually I've shelled out of the install routine. Let's do
$ ls -l
and see what we get. I'll be darned, MAKEDEV is not executable! To solve that
problem, I do:
$ chmod +x MAKEDEV
Once again, I type
$ ./MAKEDEV wd1d
and hit enter. This time there's no error message. Another quick
$ ls -l
shows all kinds of wd1 listings now including wd1d. Now I do
$ mount -r /dev/wd1d /mnt
and no error message. Let's see what mount shows:
$ mount
Here's the output for /dev/wd1d
/dev/wd1d on /data2 type ffs (local, nodev, nosuid)
Cool, wd1d is mounted! I do
$ ls -l /data
and sure enough, there's my /data/backups directory where the dumps are stored.
Now if a partition gets corrupted, all I have to do is boot up on the cd, make the
device, run newfs on the corrupted partition, mount the partition with the backups
on it as shown above, mount the newly formatted partition in write mode, change
directory into it and restore the appropriate dump. Life is good!
Someone may say you don't need the cd to boot from, you just boot the bsd.rd kernel,
and that's okay, that is, if your / partition isn't the corrupted one. Also, remember,
restore is in /sbin. I don't think there's anything wrong with using the cd to work
from, unless you didn't install off a cd and don't have one. I think it's a good idea to
keep one one hand.
This is probably kindergarden stuff for the devs on the OpenBSD mailing list, but for
me, it's like when the apple hit old Isaac on the head! It's a revelation! ;) I'm putting
this up here in hopes someday some poor newbie having the same problem googles
around and finds it. That'd be cool.
When I do a fresh install of OpenBSD, I also create a wd1a partition on a 2nd hard
drive (yes, as cheap as hard drives are anymore, there's not much excuse not have one
IMHO) the same size as my root partition on the primary hard drive and label it altroot.
In root's crontab, right below my env settings SHELL, PATH, and HOME, I enter
ROOTBACKUP=1
That way, every day the system will backup /root to /altroot. Alternately, you can edit
/etc/daily.local and enter the same ROOTBACKUP=1 line. And, you need to know
that in an initial install, /etc/daily.local isn't there, you have to create it like so:
$ sudo touch /etc/daily.local ; (or &&) sudo vim /etc/daily.local
Or, after the touch command alone:
$ sudo echo "ROOTBACKUP=1" >> /etc/daily.local
Actually, if /etc/daily.local didn't exist yet, you could shorten the process by just doing:
$ sudo echo "ROOTBACKUP=1" > /etc/daily.local
Notice there's one less >redirection delimiter there. When you redirect something to a
file name with just one >, it'll either create the file if it doesn't already exist, and if it
does exist, anything else in the file will be overwritten with the data you're redirecting.
When you use two >> redirection delimiters, it concatenates the data you're sending
onto the end of a file.
You also have to remember to enter the new altroot partition info in /etc/fstab. The
format is a little different too, than the format the others partitions use:
/dev/wd1a /altroot ffs xx 00
You can also make sure the partitions are checked on a daily basis with
$ CHECKFILESYSTEMS=1
either in root's crontab or in /etc/daily.local just as above.
==================================================
Addendum:
Sat Jan 24 00:57:38 CST 2009
I've been wanting to add this for folks like me who may be running short on hard drive
space and naturally still need to do backups. Here's how I use a combination of dump
and gzip to do it:
dump -0au -f - /var ¦gzip > /data2/backups/var.dmp.gz
Before going any further I want to put in an excerpt from the restore(8) man page:
-r Restore (rebuild) a file system. The target file system
should be made pristine with newfs(8), mounted, and the
user changed working directory into the pristine file system
before starting the restoration of the initial level 0 backup.
If the level restores successfully, the -r flag may be used to
restore any necessary incremental backups on top of the
level 0. The -r flag precludes an interactive file extraction
and can be detrimental to one's health (not to mention the
disk) if not used carefully.
An example:
# newfs /dev/rsd0g
# mount /dev&47;sd0g /mnt
# cd /mnt
# restore rf /dev/rst0
Note that restore leaves a file restoresymtable in the
root directory to pass information between incremental
restore passes. This file should be removed when the last
incremental has been restored.
restore, in conjunction with newfs(8) and dump(8), may
be used to modifyfile system parameters such as size or block size.
Okay, the worst has happened, you ran a rm -f * in the wrong place or your hard drive
just crashed, or some data got really corrupted, and now you need to restore your backup.
You've read the man page, you know you need to newfs(8) the partition before you restore
your backup and then mount it. Then:
cd /target/directory
zcat /path/to/dumpfile.gz ¦restore -rf -
Don't forget what you read in the man page concerning the restoresymtable file.
Don't forget to delete it. At this point you should be back in business.
==================================================
Addendum:
Wed Feb 11 15:57:14 CST 2009
If you have a *nix system at home and ssh connectivity to your your server, you
can use the following script to pull your backups down.
Special thanks to Jason Dixon on the misc@openbsd.org mailing list.
#!/bin/sh
# DayOfWeek
DOW=`date +%w`
DATE=`date +%Y%m%d`
ssh root@foobar.com "dump ${DOW}ufa - / | /usr/local/bin/bzip2" | \
dd of=/backups/dumps/colo2-root-${DOW}-${DATE}.bz2
ssh root@foobar.com "dump ${DOW}ufa - /home | /usr/local/bin/bzip2" | \
dd of=/backups/dumps/colo2-home-${DOW}-${DATE}.bz2
ssh root@foobar.com "dump ${DOW}ufa - /var | /usr/local/bin/bzip2" | \
dd of=/backups/dumps/colo2-var-${DOW}-${DATE}.bz2
Back to Tips and Tricks
Home
No affiliation between this site and the OpenBSD project exists or is implied.
