> Basically, there is one way to do this: Use migration. You do your > backups to disk based volumes, and later migrate to tape. > > You'll probably need more disk space, though, as that pool has to hold > at least one complete backup. No automatic spooling/despooling sequence... > Maybe he could fake this by getting more disk space and making the spool size several hundred GB. Possibly this way he can have spooling all night and then he will be able to swap in a few tapes during the day. However I admit this would be difficult to optimize.
I would still work very hard to try to figure out what is causing the tape to write at 1/4 to 1/2 of its native speed. One thing you can to to track that down is to use get a new blank tape and use dd. Something like dd if=/dev/sda of=/dev/nst0 bs=1M count=128 And see the speed you get here. I used /dev/sda here as the source instead of /dev/zero because the hardware compression will make that next to nothing and you will get a false result. Also /dev/random will not work because I find the random numbers will not be generated fast enough to keep up with the drive. John ------------------------------------------------------------------------- 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-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
