On Mon, Jan 28, 2008 at 11:46:03AM -0600, R. Quenett wrote:
> One of the specifics I need to learn a lot more about is the verification
> of the data I am backing up. Do existing versions of backuppc make it
> possible for a user to attack this area from within backuppc itself? Is
> anyone using an approach involving, say, md5sum that they would be
> willing to share?
Monthly I manually generate tars of the last backups for different
hosts and shares and use tar -dzvf backup.tgz to compare it against
the bits on disk.
Note that this doesn't help the case mentioned in the Tao with people
intentionally damaging files here and there (been there and it's a
major pain). You need integrity checks at a higher level (or the
ability to tell the backup system that file X must always have a
certain cryptographic checksum, size, ...). Something like tripwire
fills that bill, or rpm verify if you use an rpm based system and
don't have non-rpm'ed files that need their integrity
checked. Although the history function of BackupPC can provide a
warning of unexpected data change.
However the tar -d run does do a decent job of seeing if you can get
the data out of your backups system that matches what was put in. So
something like:
sudo -u backup /tools/BackupPC/bin/BackupPC_tarCreate -h HOSTNAME \
-n -1 -s /var/log .| sudo tar -dvf - -C /var/log
produces:
...
./wtmp: Size differs
./wtmp.1
./yum.log
./yum.log.1
./yum.log.2
./nagios/.bash_history
./nagios/.ssh/
./nagios/.viminfo
./nagios/archives/
...
You will have discrepancies (e.g. wtmp, lastlog, files that get
updated/rotated after backups etc). But there is no way to get a full
system verify without some discrepancy unless you shut down the system
(or taking a full system snapshot if your filesystem supports it and
backup the snapshot) and running a backup/verify cycle before you
bring it up.
For backup offsite, I use filled incrementals on hosts co-located with
the backup server and rsync over the last backup directory tree. We
only have a handful of systems like that so it works fine. We will be
doing disk copies of the backuppc spool directory for deeper archival
storage (we are trying to keep 6 months of files in the spool
directory, so the monthly/bimonthly copies will provide backups > 6
months in the past.).
We have discussed using an encrypted filesystem for the backuppc pool,
but normal physical security of the drives has served us well so far,
and we are concerned about speed issues using an an encrypted drive.
--
-- rouilj
John Rouillard
System Administrator
Renesys Corporation
603-643-9300 x 111
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
