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 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. > 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. > 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. -- 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.
