-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Les Mikesell wrote: > Christopher Derr wrote: >> Alternatively, I could go the more extensible route: multiple, slightly >> less buff memory-wise backuppc servers, backing up to a large SAN, even >> at the same time. For an environment where I may be backing up data in >> the terabytes, would multiple backuppc head nodes backing up to a SAN >> over iSCSI/fiber be a good bet? > > That's going to depend on the layout of the disks in the SAN. You'll > want the volumes to be completely independent, not grouped in an array > that share drives, then split into volumes. And it will be more > expensive (but perhaps more convenient)than just putting a couple of big > SATA drives in the backuppc server case.
It sounds like you might have missed the point. You should work out what is the limiting factor in your current situation (most people are suggesting the primary factor is disk access speed), so depending on the config of your SAN it may not improve disk access speed from backuppc at all, and hence is no advantage. Perhaps getting faster disks, or optimising the mount options for your filesystem, or choosing a different filesystem, or changing some raid parameters would make enough of a difference. Recently some optimisations were discussed that made a significant difference: 1) Mount your filesystem with noatime or equivalent so every time backuppc looks at a file it doesn't need to write the new atime. The atime is not relevant to backuppc anyway. You might also be able to disable the atime update for directories nodiratime 2) There was mention of disabling some feature of RAID5 (maybe bitmaps or something) which I recall giving a 20% improvement. 3) When the filesystem is created (if using ext3) then apparently there are some extra options/care that should be used when putting it on a RAID5 array so that one drive doesn't get all of the <something> on it. Hmmm, is there a page on the wiki for performance enhancing backuppc? Is there a disk section on that? Can someone who knows the answers to the above add some bits to it, it would likely help a number of people. Oh, then there is the rsync performance improving checksum-cache or similar which might also help you if you are not already using it. Hope some of that helps.... Some of those (noatime and checksum-cache should be very easy to change and make a big improvement to performance. Regards, Adam - -- Adam Goryachev Website Managers Ph: +61 2 8304 0000 [EMAIL PROTECTED] Fax: +61 2 8304 0001 www.websitemanagers.com.au Please note, all email from me sent after August 2007 will be signed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHzJUhGyoxogrTyiURAsUhAKDQAEMy82FxkQIxMgn39mSg1Y5qowCgrp24 v43IBk8nYodrQN0bZ1pNTmQ= =66OL -----END PGP SIGNATURE----- ------------------------------------------------------------------------- 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 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/
