After searching around in the FAQ-O-MATIC, current projects page, and in
the mailing list archives, I believe what I understand is that:

   - the largest filesystem backed up must be smaller than the size of
     the tapes used (possibly after compression is considered)

   - amanda can't do hardware compression without breaking easily

   - amanda doesn't do parallel backups under any circumstances

do I understand these points correctly? I have several issues this will
create for me and no idea how to solve them:

   - I have some filesystems that are LARGE and have no hope of fitting
     on a single tape, and no hope of fitting in a staging/holding area
     on a disk.  These are large logical volumes that span across
     multiple RAID arrays.  Amanda simply can't handle these because it
     can't span tapes, correct?

   - I have a nice fast compression ASIC in my tape drives which can
     probably compress at the drive's write speed, while my backup host
     is slow and intended mainly for IO.  Do I have it right that Amanda
     can't just write until EOT (allowing the drive to compress), rewind
     to last EOF, and move on to the next tape? Instead I have to use
     CPU in my backup server to do compression?

   - my library has 4 drives in it, which can all write at once.  Do I
     need to go out and buy 3 more backup hosts, split up my changer's
     SCSI bus and partition the library into 4 virtual libraries in
     order to actually do concurrent backups? Maybe I can run separate
     amdump instances that don't know anything about each other? ugh :)

A lot of the FAQs and stuff have $Id$ strings from eg 2000, so I'm
hoping that a lot of this is stale information and Amanda can actually
be used in shops with non-trivial backup requirements (after all if it
is used for a UMD, those folks must have huge backup requirements)...
Anyone know if I am mistaken, or have workarounds to address these
issues?

Any help or comments are greatly appreciated.