> Would this work if a job is larger than the available disk storage? If you set the disk volume size to a reasonable number (usually something that would fit on one tape), set your number of concurrent jobs to more than 1, and have a way of triggering a migration job quickly, then it should work for any size backup as long as you have enough space to store at least one full disk volume and another one (or more) to be filling while you migrate the full one. Preallocating a set of disk-based volumes also lets you control the maximum amount of disk space used by a backup at any time.
> What is the difference if I first spool the data to disk and write it > then to tape or doing a backup to disk and then migrate it to tape? Disk is usually your fastest medium. If the backup goes to disk-based volumes, all the data (metadata and file data) are committed to the database as quickly as possible and releases the client as quickly as possible (migration is purely a server-side operation) so the director can get on to another client. The job isn't over until both data and metadata are completely written, so the throughput of backup jobs is gated on the speed of your devices. > Where would I save time for a single job? (I've never use migration, > please forgive me my ignorance). You can define as many disk-based "devices" as you want (within reason), so you can have a lot of simultaneous jobs running dumping to volumes in the disk pool, and batch the dumps to tape w/o having to wait on clients or have clients wait on you. If you truly only have one big job, it won't matter much. If you have lots of jobs and lots of clients, the approach I'm suggesting reduces contention for the physical tape drives and reduces wear/tear by minimizing stop/start on the tape (you generally mount a volume, write a LOT of data, dismount, repeat) instead of the load/mount/write/unmount/unload/repeat cycle for multiple jobs straight to tape. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
