Actually I was under the impression that this was a vanilla on-disk backup - ie, something akin to dumping tgz's onto a server with reliable disks (hence RAID5)..
I must say though that I am surprised that a tape feeder is faster than disks to the point of having to maintain a large buffer, but then the last time I was responsible for any tape system was with a single DDS4 tape drive.. backup management is the curse of systems admin imho, so I avoid it at all costs - it's horribly mundane and prone to break at will (but we all thank the great bit keeper when we need them!) I was also under the (unreasearched) opinion that incremental change analysis was performed on the client side, not the backup server side, although I suppose that backing a large number of similar servers would result in a lot of the same files being written a lot of times (eg /lib), so it would be smart to only have one copy of the file and a reference for each backup that includes this file.. this would certaintly be done on the server side... but really the point of the above is that you're almost certaintly right if you're talking about enterprise backup solutions, and that more to the point, the precise backup solution/software chosen will drastically change how you tune the server, which is actually what we were both saying, so it's a case in point On Sat, Sep 6, 2008 at 11:03 AM, Daniel Pittman <[EMAIL PROTECTED]> wrote: > "Tony Sceats" <[EMAIL PROTECTED]> writes: > > > Performance depends specifically on the job at hand, and whilst short on > > detail, I would suspect that you want fast file systems and disks > optimised > > for write speed, > > For backups? Often you need very fast reads, either to feed a modern > tape streamer at the 30 to 80 MB per second of data it wants[1], or to > be able to perform "read and compare" operations on existing data for > comparison or pooling purposes (or even just the metadata of millions of > files, really.) > > Fast writes are typically the least important part of the backup > system. They matter, sure, for beating your backup window, but the > actual performance problems often pop up on the read side. In my > experience, anyhow. :) > > Regards, > Daniel > > Footnotes: > [1] ...and more if you have two or three of these drives attached to a > single server, which is more common as we have individual machines > with one to two tapes capacity each -- even for the 800MB native > LTO4 devices. > > -- > SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ > Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html > -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
