Restoring backups

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@backuphostname.yourdomain.local"

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
 >> Stay informed about: Restoring backups 

On Sat, 2 Feb 2008 20:15:54 UTC, Keve Nagy
wrote:

(snip)

While it's an interesting method, why not just use 'dump' which is
generally reckoned to be one of the best ways? No need for all the
zeroing, and it can be restored to any disk. Also, it (backup) has to be
done on a quiescent system; the zeroing might cause something else to
fail due to the file system being full.

My backups are pretty simple; 'dump' on each filesystem, gzipped and
sent to whichever backup medium I'm using. No great need for a copy of
the 'fdisk' stuff as that doesn't change. Of course, 'dump' uses a
snapshot so the machine doesn't have to be quiescent (thanks, Kirk!).

Each machine has a 'recovery folder' which is a physical plastic folder
with a suitable boot CD or floppies, including FIXIT. Also in there are
details of partitions and disklabels in printed and electronic form, and
a step by step restore guide (a) in case I'm not around and SWMBO has to
do it (b) because it's easy to make mistakes at times of stress.

Essentially, a restore is a CD boot into FIXIT mode, then a simple
fdisk, disklabel and a set of restore runs.
--
Bob Eager
UNIX since v6..
http://tinyurl.com/2xqr6h
 >> Stay informed about: Restoring backups 

Bob Eager wrote:

> While it's an interesting method, why not just use 'dump'

Because the OP is already comfortable with a dump/restore based solution and
he was specifically asking for something else, which he called "bare metal
restores" and that matches what I presented.

Bob, if you don't read or pay attention to the original post you end up
asking silly questions.
Besides this carelessness of yours, I completely agree with your points. I
never said that my solution is any better than dump/restore. I just
presented an alternative because that is what the OP was interested in.
In fact, I even pointed out myself that my sector-level solution has the
weaknesses you noted while dump/restore is free of those (and has others).

I use this sector-level method to clone a system to 120 other computers with
the exact same configuration. This includes GRUB, WinXP, Linux and FreeBSD
on the same harddisk. For this, the sector-level method is significantly
better. For other uses, everybody can decide.

Regards,
Keve

--
if you need to reply directly:
keve(at)mail(dot)poliod(dot)hu
 >> Stay informed about: Restoring backups 

On Sun, 3 Feb 2008 11:35:44 UTC, Keve Nagy
wrote:

> Bob Eager wrote:
>
> > While it's an interesting method, why not just use 'dump'
>
> Because the OP is already comfortable with a dump/restore based solution and
> he was specifically asking for something else, which he called "bare metal
> restores" and that matches what I presented.
>
> Bob, if you don't read or pay attention to the original post you end up
> asking silly questions.

Not at all. I was specifically asking why you were doing it that
way....nothing to
do with the OP. I wondered what compelling reasons there were, that I
might have missed. I realised it's what the OP asked - but was curious
as to why you used it.

> I use this sector-level method to clone a system to 120 other computers with
> the exact same configuration. This includes GRUB, WinXP, Linux and FreeBSD
> on the same harddisk. For this, the sector-level method is significantly
> better. For other uses, everybody can decide.

Of course, for cloning it is the right approach.

--
Bob Eager
UNIX since v6..
http://tinyurl.com/2xqr6h
 >> Stay informed about: Restoring backups 

>>>>> "Keve" == Keve Nagy writes:

Keve> Because the OP is already comfortable with a dump/restore
Keve> based solution and he was specifically asking for something
Keve> else, which he called "bare metal restores" and that matches
Keve> what I presented.

Sorry, all, for the confusion, but I was looking for better ways to
restore my backups on a computer that doesn't already have an
operating system (which is why I used the term "bare metal").

Keve: Thanks for the good ideas, but disk cloning isn't precisely what
I'm after, although since you and others have mentioned it, I think
that I'm going to begin backing up the disk label along with the file
systems.

Best wishes,
Matthew

--
I slashread your textcast about jargon and nodnodnod with your cyber-sentiment.
- gad_zuki! (http://science.slashdot.org/comments.pl?sid=215746&cid=17517040)
 >> Stay informed about: Restoring backups 

>>>>> "Keve" == Keve Nagy writes:

Keve> An interesting and efficient solution could be created by
Keve> combining my basic principles with your idea, replacing my
Keve> "FTP" with your "SSH" and my "GZIP" with your "BZIP2
Keve> -9". Let me know if you achieve something like that!

Thanks a lot for sharing your methods. I really appreciate it!

Best wishes,
Matthew

--
I slashread your textcast about jargon and nodnodnod with your cyber-sentiment.
- gad_zuki! (http://science.slashdot.org/comments.pl?sid=215746&cid=17517040)
 >> Stay informed about: Restoring backups 

On 2008-02-04, Matthew X. Economou wrote:

> Sorry, all, for the confusion, but I was looking for better ways to
> restore my backups on a computer that doesn't already have an
> operating system (which is why I used the term "bare metal").

I keep my backup dumps on a separate machine. To do a "bare metal"
restore, I boot from the "Freesbie" live CD, connect to the remote
machine and restore over the network. Works fine here.

--

John (john@os2.dhs.org)
 >> Stay informed about: Restoring backups 

Bob Eager wrote:

>> Bob, if you don't read or pay attention to the original post you end up
>> asking silly questions.
>
> Not at all. I was specifically asking why you were doing it that
> way....nothing to do with the OP.

My apologies then!
I was limited by my own understanding and perception.
I guess, this is what the "Think outside the box!" expression is for.


Regards,
Keve

--
if you need to reply directly:
keve(at)mail(dot)poliod(dot)hu
 >> Stay informed about: Restoring backups 

On Tue, 5 Feb 2008 14:38:09 UTC, Keve Nagy
wrote:

> Bob Eager wrote:
>
> >> Bob, if you don't read or pay attention to the original post you end up
> >> asking silly questions.
> >
> > Not at all. I was specifically asking why you were doing it that
> > way....nothing to do with the OP.
>
> My apologies then!
> I was limited by my own understanding and perception.
> I guess, this is what the "Think outside the box!" expression is for.
>

No problems!

--
Bob Eager
UNIX since v6..
http://tinyurl.com/2xqr6h
 >> Stay informed about: Restoring backups