On Sun, May 31, 2009 at 11:22:13AM -0400, Stephane Rouleau wrote: > Pieter Wuille wrote: > > > > 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 might > > 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.
Some numbers: * backup server has 1TB of RAID1 storage * contains amonst others a 400GiB XFS volume for backuppc * daily/weekly backups of +- 195GiB of data * contains 256GiB of backups (expected to increase significantly still) * contains 16.8 million inodes * according to LVM snapshot usage, avg. 1.5 GiB of data blocks change on this volume daily * offsite backup server has 2x 500GB of non-RAID storage * twice a week, the whole 400GiB volume is sent over a 100Mbps connection (at +- 8.1MiB/s) * that's a huge waste for maybe 5GiB of changed data, but the bandwidth is generously provided by the university * we hope to have a more efficient blockdevice-level synchronisation system in a few months PS: sorry for the strange subject earlier - i used a wrong 'from' address first and forwared it -- Pieter ------------------------------------------------------------------------------ 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@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/