Brad> We will probably stick to a small scale for now (since we only Brad> have a test bed of a single machine), but hopefully, if we plan Brad> this right and write the APIs well, we'll be able to scale Brad> it. Either way we'll keep the enterprise solution in mind as we Brad> go. The architecture that I would suggest goes something like this. Though it would be easier on a blackboard to diagram. Do functional blocks for you high level layout. Be flexible. Think big. 64 bit pointers everywhere. Data is *not* getting smaller. - central server - talks to clients (which can be on the central server) - talks to device driver(s) both local and remote. - talks to index database server(s). - talks to media mover(s) - maintains backup schedules - controls indexes and their retention times. - labels tapes with control info. - device drivers - accept raw data from central server, spool to tape/disk/etc. - multiplexes data streams to device. - optimized for specific devices. - clients - runs on various OSes - reads various file systems and dumps data in intermediate form to central server. - index server - lets you keep online indexes off all files saved to which tape and when, for easy restores. - media mover - controls jukebox - can accept multiple commands at once and optimizes them. - requires funky per-jukebox with per-device command queues. Can you tell that this is something I've been thinking about? Look at the Amanda scheduler. It's an interesting idea, but it locks you into their way of doing things too much. Needs to be more general. John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies stoffel@lucent.com - http://www.lucent.com - 978-952-7548