On Tuesday 05 December 2006 11:04, Rudolf Cejka wrote: > Arno Lehmann wrote (2006/12/01): > > On 11/30/2006 9:24 PM, Per Andreas Buer wrote: > > > Amanda has a feature I really like. When the correct tape is missing, > > > broken or full Amanda just spools everything. If you have a large spool, > > > backup can run for days without hick up. So, when one has fixed the > > > tape, one just runs amflush and all is well. How does Bacula react to > > > having its tape drive missing? > > I think that it is mainly about policy, which do you want to use. I used > Amanda in the past too, but I was very disappointed with it. There were > two main problems: Inability to split one backup over more tapes (I hope > that it is solved in Amanda now, but after very very long time since it > has been planned and implementation has been started) and inability to > restore small number of files from a big backup jobs in acceptable time > (it was really absolutely unusable to read full backup job for restore > of just one file).
Well, the ability to split over multiple tapes seems to be resolved now that Zmanda has entered the picture, but then they injected $5 million. Getting back to files quickly on tape would seem to me to be one of their fundamental limitations as long as they use system tools such as tar, which to the best of my knowledge don't keep sufficient info to be able to seek to particular files. > > I used the staging in Amanda too, but since I switched to Bacula (with > mid-step over afbackup), I do not want it anymore. You cited why you didn't like Amanda, but I would be interested to know why you didn't like afbackup, and for the other users who have answered this thread, I would be very interested to know why you don't like Areika. Having this information always helps ... > > > > As LTO3 has a really, really high throughput > > > (80MB/s, if I recall) I don't see much chance in using both drives in > > > parallel. > > Why? I did some testing on my configuration (currently Oveerland 4200 > with two LTO3 drives) with dd-ing of uncompressable datas to both drives > and the speeds to both tapes were the same about 72 MB/s, as in case of > just one tape drive. System load was about 15 %, which was mainly > generated by a process producing datas at so high rate. Parallel reading > to /dev/null was even happier, where both speeds were about 75 MB/s. > ... I think that the native speed of LTO3 is 80 000 000 B/s, so in my > counts I expect that native speed of LTO3 drive is 76 MB/s. Who knows... > > > It will work, but in most cases will be severely slowed down. As you > > note, the throughput of one LTO-3 drive alone is enough to saturate > > todays computers bus bandwith. You can push the limit by using the right > > I'm afraid that main problem is in Bacula computing CRC32 between reads > from disk and writes to tape. Interesting, but not too surprising since LTO-3 is really fast and maybe CPUs are not quite up to it yet. With technology like LTO-3, perhaps it is time to consider giving the user the ability to turn off the CRC32 generation and comparison. Regards, Kern > I believe that LTO3 drives have something > like Digital Speed Matching, which means that they measure delays between > write requests to the tape multiplied with data block sizes and from this > result it tries to commit the incoming datas in somewhat slower rate, so > that there is guaranteed rate of an incoming stream - initiator side has > to always wait. Minimally, but wait, because in other case there would > be stream gaps, which is for tapes always a problem. > > If I have one drive connected over 320 MB/s SCSI bus and the second drive > connected over 160 MB/s SCSI bus, dd-ing rate, where read-write loop is > very tight, is totally the same for both drives around 75 MB/s. When they > are accessed from Bacula, write speed to one drive is around 75 MB/s, but > write speed to the second drive is 65 MB/s. > > > hardware, but it will be hard to find a (more or less) normal server > > that can handle moving data from the network to LTO-3 and from another > > LTO-3 drive to the network simultaneously. You'll most likely need > > higher-end server systems with multiple PCI-X or PCIe busses and lots of > > memory, CPU, bus and network bandwidth. > > Main problem seems to be in RAID system, which has to be used for spooling > area. A critical measurement is how fast it can give read data stream, > when there are several write streams at particular data rate. For example, > if I have income rate around 20 MB/s, I still can read at rate 75 MB/s. > But when there is an income around 40 MB/s, read rate slows down to > 40 MB/s too, which is good minimal rate for LTO3 drive, but it should > not go below it.. > > -- > Rudolf Cejka <cejkar at fit.vutbr.cz> http://www.fit.vutbr.cz/~cejkar > Brno University of Technology, Faculty of Information Technology > Bozetechova 2, 612 66 Brno, Czech Republic > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
