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.