BackupPC-users

Re: [BackupPC-users] [pieter.wuille AT gmail DOT com: Re: backup the backuppc pool with bacula]

2009-05-31 11:27:47
Subject: Re: [BackupPC-users] [pieter.wuille AT gmail DOT com: Re: backup the backuppc pool with bacula]
From: Stephane Rouleau <srouleau AT innobec DOT com>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Sun, 31 May 2009 11:22:13 -0400
Pieter Wuille wrote:
> On Tue, May 19, 2009 at 05:51:29PM +0200, Boniforti Flavio wrote:
>>> Hi,
>>>
>>> there is a regular discussion on how to backup/move/copy the 
>>> backuppc pool. Did anyone try to backup the pool with bacula?
>> Hello there...
>>
>> I don't know about bacula, but would like myself also to get a backup of
>> the BackupPC server: anybody got some suggestions and practical
>> examples?
> 
> 
> This is how we handle backups of the backuppc pool:
> * the pool itself is on a LUKS-encrypted XFS filesystem, on a LVM volume, on a
>   software RAID1 of 2 1TB disks.
> * twice a week following procedure in run:
>   * Freeze the XFS filesystem, sync, lvm-snapshot the encrypted volume
>   * Unfreeze 
>   * send the snapshot over ssh to an offsite server (which thus only ever sees
>     the encrypted data)
>   * remove the snapshot
> * The offsite server has 2 smaller disks (not in RAID), and snapshots are sent
>   in turn to one and to the other. This means we still have a complete pool if
>   something would goes wrong during the transfer (which takes +- a day)
> * The consistency of the offsite backups can be verified by exporting them
>   over NBD (network block device), and mounting them on the
>   normal backup server (which has the encryption keys)
>     
> We use a blockdevice-based solution instead of a filesystem-based one, because
> the many small files (16 million inodes and growing) makes those very disk-
> and cpu intensive. (simply doing a "find | wc -l" in the root takes hours).
> Furthermore it makes encryption easier.
> We are also working on a rsync-like system for block devices (yet that make
> still take some time...), which would bring the time for synchronising the
> backup server with the offsite one down to 1-2 hours.
> 
> Greetz,
> 

Pieter,

This sounds rather close to what I'd like to have over the coming months.  I 
just recently reset our backup pool, and rather stupidly did not select an 
encrypted filesystem (Otherwise we're on XFS, LVM, RAID1 2x1.5TB).  Figured I'd 
encrypt the offsite only, but I see now that it'd be much better to send data 
at the block level.  

You mention the capacity of your pool file system, but how much space is 
typically used on it?  Curious also what kind of connection speed you have with 
your offsite backup solution.

Thanks for detailing your setup,

--
Stephane



------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

<Prev in Thread] Current Thread [Next in Thread>