Re: Restoring backups
- From: Keve Nagy <nospam@xxxxxxxxxxxxxxx>
- Date: Sat, 02 Feb 2008 21:15:54 +0100
Matthew X. Economou wrote:
Can anyone offer comments or advice on the following disaster recovery
plan? The "Backup Basics" section of the FreeBSD handbooks seems a
little dated, so I'm exploring my own method for restoring FreeBSD
file system dumps. I'm creating my backups with dump/ssh:
DATE=`/usr/bin/date "+%Y%m%d"`
ssh -c blowfish root@${HOSTNAME} \
"dump -0aLnu -f - / | bzip2 -9" > ${DATE}-root.bz2
ssh -c blowfish root@${HOSTNAME} \
"dump -0aLnu -f - /tmp | bzip2 -9" > ${DATE}-tmp.bz2
ssh -c blowfish root@${HOSTNAME} \
"dump -0aLnu -f - /var | bzip2 -9" > ${DATE}-var.bz2
ssh -c blowfish root@${HOSTNAME} \
"dump -0aLnu -f - /usr | bzip2 -9" > ${DATE}-usr.bz2
I would like to add commands that verify the contents of the backup,
something along these lines:
cat ${DATE}-root.bz2 | ssh -c blowfish root@${HOSTNAME} \
"cd /; bzcat | restore -rNf -"
If I ever need to restore a backup, I plan to re-install FreeBSD (just
the base file set), bring up basic networking and SSH, and run
commands similar to the ones used to verify the backups:
cat ${DATE}-root.bz2 | ssh -c blowfish root@${HOSTNAME} \
"cd /; bzcat | restore -rf -"
Aside from cleaning out stale PID or lock files after finishing the
restores, is there anything else I will need to do to ensure the
system is bootable?
Is there a better way to perform backups and restores? Even better
would be a way to do bare metal restores, but I didn't want waste my
time figuring out the logic required to write suitable boot blocks or
partition tables to disk, when I could zip through the FreeBSD
installation screens quickly enough.
Best wishes,
Matthew
Hi Matthew,
My time has come at last and finally I can see a chance to give something
back for all your helpful posts I was feeding on in the last two years. :-)
I am rewriting this from the top of my head because here at home I don't
have access to my production scripts, but I am confident this is pretty
much what I did with those. So, consider this script:
<sample_code>
#!/bin/sh
vSYSdsk="${vSYSdsk:-/dev/ad0}"
vSYSslc="${vSYSdsk}s1"
vFTPurl="ftp://backup_user_name:password@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
if [ "$1" == "backup" ]
then
##############
### BACKUP ###
##############
# Step B1. - Read disk HEAD to ftp-img:
dd if=$vSYSdsk bs=512 count=63 | gzip | ftp -u
${vFTPurl}/mysystem.diskhead.dd.gz -
# Step B2. - Overwrite FREE partition-space with zeroes:
vTMPfile=".ZeroesOnly.tmp"
for vMOUNTpoint in "/" "/var" "/tmp" "/usr"
do
dd if=/dev/zero of=${vMOUNTpoint}/$vTMPfile bs=16m
sync
rm ${vMOUNTpoint}/$vTMPfile
sync
done
# Step B3. - Fill up swap-space with zeroes:
swapoff -a
dd if=/dev/zero of=${vSYSslc}b bs=16m
# Step B4. - Read entire FreeBSD slice to ftp-img:
dd if=$vSYSslc bs=16m | gzip | ftp -u
${vFTPurl}/mysystem.fbsdslice.dd.gz -
# Step B5. - Re-enable swap:
swapon -a
fi
if [ "$1" == "restore" ]
then
###############
### RESTORE ###
###############
# Step R1. - Restore slice setup, boot manager, etc:
ftp -o "|gunzip|dd bs=512 of=$vSYSdsk" ${vFTPurl}/mysystem.diskhead.dd.gz
# Step R2. - Write ftp-img back to disk:
ftp -o "|gunzip|dd bs=16m of=$vSYSslc" ${vFTPurl}/mysystem.fbsdslice.dd.gz
fi
</sample_code>
I believe you don't need me to explain anything beyound the script above,
but once in a while I can afford to be the smartass in this newsgroup, so I
say a few clever things anyway. -for the shake of other interested readers.
:-)
The short comment is that my method backs up my MBR and my FreeBSD slice
(ad0s1) on a sector level. As long as the disk I backed up from (or a
replacement disk of the same type and size) is physically working, no
matter what I screwed up I can quickly restore the working FreeBSD system
(including partitioning, grub, everything). Even if I repartitioned,
reformatted the disk or erased everything with a low-level format, this
rebuilds everything in one automated step.
The long comments:
1., On an i386 system the first 63 sectors of the harddisk is the disk HEAD.
This contains the MBR as the very first 512 bytes, which among other things
holds the partition table defining the layout of at most four primary
partitions. The rest of the HEAD is where boot-managers and other
interesting code hide, if you use any of those at all. Step B1 backs this
up to a remote file on an ftp-server. If you write this file back to the
very beginning of a disk (step R1), you already have that disk set up with
the exact same partition layout and boot-manager the backed-up disk had.
While this is perfectly good when restoring to the same disk or to one
with the exact same type and size, restoring to a larger disk may work or
it may fail depending on the LBA and CHS characteristics of the disk, but
it is definitely going to fail restoring to a smaller disk.
The dump/restore method you approached with, will work perfectly even when
restoring to a smaller disk or partition, as long as there is enough room
for the actual files you are restoring. My solution works only if the
partition you are restoring to is exactly the same size you were backing up
from, regardless how much unused space there is/was.
2., The HEAD contains the definition of only the so-called primary
partitions and it has no information about logical disk units, like the
so-called logical partitions inside a DOS extended partition (anything
FreeBSD sees as ...s5, ...s6, or larger. Therefore the layout of those can
not be saved and restored this way.
3., Step B2 and B3 are very handy to keep my backup size as small as
possible. With B2 I create a temporary file on each of my UFS2 partitions
(usually ad0s1a, ad0s1d, ad0s1e and ad0s1f) and keep filling the file up
with zeroes until it stops with an error of no more disk space available.
Then I remove this file. This way, all my existing data on the partitions
remained completely unharmed, but every byte of free disk space that wasn't
occupied by an existing file has now been overwritten with zeroes. This
includes the space of deleted files too. With B3 I need to do something
similar with my swap-space at ad0s1b, which is somewhere in the middle of
ad0s1 (right between ad0s1a and ad0s1d). But as swap-space cannot be
mounted and have files written into, I simply overwrite the entire ad0s1b
partition with zeroes. So when I begin to back up the entire ad0s1 slice in
Step B4, I will read in a lot of consequtive zeroes from every unoccupied
place and the swap-area, which is very easy to compress. This way the size
of my backup file will never be larger than the ACTUAL USED SPACE inside my
partitions. A modified version of Step B3 is extremely important for me
because I use a GELI encrypted swap (ad0s1b.eli) which has been filled with
random data, and this would always increase my backup size with the size of
my swap-space, which is a considerable 512MB-1GB.
4., In practice, I always skip B1 and R1. Normally you only need to run B1
once in the lifetime of your system, because your partitioning doesn't
change. And R1 is needed only in extreme situations. Normaly R2 is
perfectly enough to restore everything.
5., When a disaster hits and I need to restore the system, I boot from the
FreeBSD Install CD and use FIXIT mode, or use a Frenzy CD. Then I mount my
pendrive or floppy holding the restore script, and everything is restored
from the ftp-server.
An interesting and efficient solution could be created by combining my basic
principles with your idea, replacing my "FTP" with your "SSH" and my "GZIP"
with your "BZIP2 -9". Let me know if you achieve something like that! :-)
Best regards,
Keve
--
if you need to reply directly:
keve(at)mail(dot)poliod(dot)hu
.
- Follow-Ups:
- Re: Restoring backups
- From: Matthew X. Economou
- Re: Restoring backups
- From: Bob Eager
- Re: Restoring backups
- References:
- Restoring backups
- From: Matthew X. Economou
- Restoring backups
- Prev by Date: Re: Does anybody from freebsd.org hang out here anymore?
- Next by Date: Re: Restoring backups
- Previous by thread: Restoring backups
- Next by thread: Re: Restoring backups
- Index(es):
Relevant Pages
|
