On 10/19/2014 11:39, Marco van Wieringen wrote: > Markus <pet2001 <at> epbfi.com> writes: > >> Dear Bareos Community, >> >> I'm in the process of transitioning from Bacula to Bareos for obvious >> reasons - nothing gets fixed anymore in Bacula. I have a few questions >> which I could not answer going through the Bareos release notes - so >> maybe one of you guys can help me out here - or point me to the right >> documentation: >> >> [1] Windows Backups & VSS >> I am using Bacula file daemon (Windows x64) version 5.2.10 (the last >> version available for free) and Bacula director version 5.2.6 (Linux >> x86) . This version has a nasty bug when backups using VSS are made. >> There is a miscount of "+1" between the files backed up and the number >> of files being reported as backed up. For example: if a job consists of >> 50 files, Bacula director ends up with 51 files in the catalog. If you >> run a VolumeToCatalog after that, the system ends up with an error >> (checked 50 files, expected 51) which leads either to a "verify failed" >> status or a director lockup. Has this problem been reported / resolved >> in Bareos? >> > 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). 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 also don't know a lot of people doing VolumeToCatalog Jobs so I think > you have to test if the problem still exists but it highly probably that > it does. > > The solution is probably handling the FT_RESTORE_FIRST stream better in > Volume to Catalog checks as those are written to the backup stream. > >> [2] Verify and Restore Performance >> My "backup server" (the machine holding the tape drive and running the >> director) is an older system (Pentium III) which is equipped with an >> Adaptec 39320 SCSI controller (Ultra 320 SCSI LVD), a DLT-1 Quantum Tape >> Drive (Ultra 160 SCSI LVD) and a Seagate Ultra 320 / 10000rpm harddisk. >> This configuration has no problem whatsoever backing up data from the >> harddisk to the tape. > A DLT1 doesn't really need that much data speed compared with the new > LTO5 and LTO6 which get to more then 100 MBps. Confirmed. During backups from the local hard disk to the DLT-1 tape Bacula director reports statistics of 10 MByte/sec and there is no shoe shining at all. > >> During restores and verifies, however, I experience a lot of shoe >> shining. I do understand that data spooling is not implemented for >> restores and verifies. However, as the system is perfectly capable of >> doing backups from the local harddisk to tape (without data spooling), I >> would think restores to the local harddisk should work as well - not to >> mention verifies (VolumeToCatalog) where the only job is reading the >> data from tape and calculating MD5 checksums. > It could be related to a bug Daniel Holtkamp reported is that after > each restore the label of the tape is read again which leads to rewinding. > The whole spooling sub system is something we want to change as now its > mostly a big hack. But that will take some time and we first have to clear > quite some other stuff in the development pipeline before starting anything > new. 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. >> Can somebody provide some information if Bareos is different in that >> matter or what I might have to change in my configuration to make at >> least VolumeToCatalog verifies work without shoe shining? > I guess this is a SD problem and in that respect we haven't changed > an enormous amount (other then refactoring quite a bit) but nothing > that I would expect to make this problem go away. >> [3] Verify Jobs and File Daemons >> For a "VolumeToCatalog" verify job, can someone please explain why I >> need a file daemon? Can I define the job without a file daemon? I am >> asking because I would like to be able to run verify jobs without the >> need to have the file daemon available which created the backup in the >> first place. > You probably run into the fact that Bacula has made the client a > required keyword so every Job needs one even when it makes little > sense for that particular Job type. In 14.2 (which is in beta) we > lifted that for Copy and Migration Jobs but as the Job assumes > everywhere there always is a Client it means you run from one crash > to an other. We could maybe add support for not needing it for this > particular JobType but I'm afraid we are then in for some freak show > again in unexpected crashes along the way. I think the client is not > used at all so you can do the same what was possible with Copy and > Migration Jobs e.g. use some "dummy" client. > 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. -- 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.
