Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Feb 2002 12:15:07 -0600
From:      "Mike Meyer" <mwm-dated-1014142507.6765d0@mired.org>
To:        Mark Edwards <mark@antsclimbtree.com>
Cc:        questions@freebsd.org
Subject:   Re: Backup routine
Message-ID:  <15467.65195.233651.262438@guru.mired.org>
In-Reply-To: <54801113@toto.iv>

next in thread | previous in thread | raw e-mail | index | archive | help
Mark Edwards <mark@antsclimbtree.com> types:
> I've got an installation of FreeBSD 4.4 Stable running along quite nicely.
>    Now I'm trying to design a backup system for it.

The number of answers to this problem is roughly the same as the
number of sysadmins.

> This installation is mainly a personal server.  It's running on a Seagate 
> IV ATA HD, and it is a low-access server.  It runs my personal mail, and my 
> personal web site.
> I have a second identical HD that I'm intending to set up a nightly dump to.

> My questions:
> - Is that a decent backup scenario?

In general, yes. However, it doesn't provide a backup in the case
where the entire machine is fried. My solution to that was to throw in
a CDRW, and burn a copy of that on a regular basis. More details
below.

> - Is there a good reason I should use a tape drive instead?

Tape drives have a lower cost per byte, and make it possible to keep
long-term backups. But so does a CDRW. Almost every backup system I've
worked with dumps to local disk, then creates archives of that on a
removable media of some kind. That allows you to do restores of
accidently deleted files and the like from the on-disk copy, while
providing archival copies of the data as well.

> - Should I use something other than dump?

No. Everything else loses some of the file system information. Some of
them can't even back up devices properly.

> Does it make sense to create a bootable copy instead of a dump file
> (i.e. a dump | restore)?

Only if your configuration can't boot the rescue CD (#2 in the release
set).

> - Does it make sense to mount/unmount the backup HD as part of the backup 
> routine, so that it will not be evident to a hacker?

Note that you're just lowering the probability of a hacker finding it,
which is a good thing. However, it makes your backups a bit more
complicated. Personally, I don't - but I don't keep backups of the
web/mail server on that machine.

One thing you've overlooked is that dump doesn't happen
instantaniously. If files are changing when you run the dump, they
won't show up on the dump, or will be damaged if they do show up. I
therefore recommend doing level 0s with the system single user, and
running daily dumps via the periodic system to make sure that the
dumps don't wind up running at the same time as something else run
from the periodic system. That assumes that you're doing anything
critical via - like snapshotting a database - via the periodic system
as well.

My solution on hardware similar to yours is to take the system down to
single user mode and do a level 0 dump into CD sized chunks to the
second disk. If you've got a writable DVD, use that size instead. I
then bring the system back up, and burn those chunks to CD in an ISO
fs, check that the bits that are on the CDRW are the same as the ones
on the disk, and if that's true delete the copy on the disk and move
the CDs to offsite storage.

The automated script runs level 8s most days of the week to the second
disk, and level 4s monday morning, using a file name of the form
/backups/<level>/<data>/<fs>.dump.gz. After the level 4s, it burns and
verifies a CD of the level 4 dump directory. I make sure that worked,
and then unmount and label that CD before moving it to offsite
storage. When the level 4s get so large that only one fits on a CDRW,
I make a new set of level 0s. That way, if I lose the HD, I've got a
backup of everything to that morning. If I lose the entire machine,
I've got a backup of everything to the previous monday, which is an
acceptable risk for my machine.

	<mike
--
Mike Meyer <mwm@mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15467.65195.233651.262438>