Markus <pet2001 <at> epbfi.com> writes:
> > I do remember that ages ago there was some discussion on that problem > > but I kind of lost track if it ever got fixed and if it did if that > > was before 5.2.13 was released on which our fork is based. > > > > It do remember it revolves all around the job_metadata.xml file stored > > as so called FT_RESTORE_FIRST which is some metadata used by VSS on > > restore. As the whole extra shebang of VSS stuff is closed source for > > bacula only some parts are implemented in the open. We are busy on writing > > some really open source VSS helpers but it could be we are still bitten > > by this bug. > > I did a quick search on the internet and it seems like that this bug > indeed has been around forever. There was a discussion in a Bacula > support forum on July 10, 2014 and the bug was still confirmed as of > that date. Even for Bacula's paying commercial customers! So Bareos also > inherited this bug (through the fork). Ok interesting but not really a big surprise. > Anyway, I am currently using a different software product under Windows > to do a D2D backup to the hard disk of my backup server. I'll use Bareos > the same way until one day we'll have a working VSS backup and compare. > I think VSS works for most things good enough today only not for specific VSS writers that generate metadata. > > Actually it is not "rewinding". I can tell from the sounds my tape drive > makes. A rewind to re-read the label would really be noticeable, > especially if you're filling up a tape with data. It takes time to > rewind to read the label and then skip 50 GByte forward to resume the > job. No, it's simple shoe shining (stop and go, rinse and repeat) which > is arkward, especially for a VolumeToCatalog verify job. I can tell that > my hard disk is "taking a nap" during most of the verify operation. It's > really just the director and the local sd for the tape which are > spinning their wheels. Looking at how things are programmed it seems the data for a VolumeToCatalog verify job is send to the FD that extracts the metadata it could be that the performance problem comes from that step. As we mostly implement D2D2T installs we are not restoring or verifying much from tape nowadays. Those jobs are using spooling right ? Otherwise it could be interleaving but also from that I wouldn't expect shoe-shining. It mostly happens when the client cannot keep up. > > I'll try with a dummy client and see what happenes. I know that once a > client is defined (and in Bacula that's mandatory), the director will > contact that client even if it does not need data from it to perform the > job. So if the client does not exist, the director will wait and > eventually terminate the job because of a connection problem to the > client. Correct I explained why it works like that in a reply to your other mail. You can however use any client here probably as its only "mis-used" for extracting the metadata. I don't think this will be changed any time soon however in Bareos. To little value for the programming effort if you ask me. -- Marco van Wieringen [email protected] Bareos GmbH & Co. KG Phone: +49-221-63069389 http://www.bareos.com Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646 Komplementär: Bareos Verwaltungs-GmbH Geschäftsführer: Stephan Dühr, M. Außendorf, J. Steffens, P. Storz, M. v. Wieringen -- You received this message because you are subscribed to the Google Groups "bareos-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
