Menu
▾
▴
[Bacula-bugs] [bacula 0001995]: Metadata of backuped file not stored in (postgresql) database
|
From: Mantis B. T. <no...@bu...> - 2013-05-22 06:35:24
|
The following issue requires your FEEDBACK. ====================================================================== http://bugs.bacula.org/view.php?id=1995 ====================================================================== Reported By: mkress Assigned To: ====================================================================== Project: bacula Issue ID: 1995 Category: Director Reproducibility: random Severity: minor Priority: low Status: feedback ====================================================================== Date Submitted: 2013-04-12 08:02 BST Last Modified: 2013-05-22 07:35 BST ====================================================================== Summary: Metadata of backuped file not stored in (postgresql) database Description: Filedeamon on SLES8 and SLES10, Director on SLES11 Sometimes (every few weeks with a daily backup, 3 backups in parallel, all Linux with SLES8, SLES10 and SLES11) a Verfiyjob (pins5) complains about a new file (erverytime a different file): 12-Apr 02:02 iss-dir JobId 499: New file: /usr/perl5/5.8.0/lib/unicore/lib/Ideograp.pl This file was not changed/added in the filesystem during backup or verify, it has no new timestamp or a new inode. The file was backuped/verified all days before without any problems. Metadata seems to be not stored in the bacula database (postgresql 9.2.3 on SLES11), because I can't restore it using the restore command. Using bextract it can restored. It seem it was not written to the database. The log of postgresql shows no errors/warnings. Steps to Reproduce: Can't reproduce, because it happend only 3 times on different servers with different files within of 8 weeks (120 backups). Additional Information: Using a older version of bacula 5.2.6 with postgresql 9.1.3 on SLES10 seems not to have this problem. Using the same configuration for postgres. Bacula using a small different configuration (no backups in parallel). ====================================================================== ---------------------------------------------------------------------- (0006656) ebollengier (administrator) - 2013-04-18 08:35 http://bugs.bacula.org/view.php?id=1995#c6656 ---------------------------------------------------------------------- Sorry you have problems with Bacula, however, it looks to be a support issue. To check if the "Metadata" is stored in the catalog, just run a restore, access to /usr/perl5/5.8.0/lib/unicore/lib, and type "dir". It should display the file, with owner/group/rights, etc... I advise you to contact the users list to get help with your problem. ---------------------------------------------------------------------- (0006662) mkress (reporter) - 2013-04-19 15:32 http://bugs.bacula.org/view.php?id=1995#c6662 ---------------------------------------------------------------------- I already tried a restore ("because I can't restore it using the restore command") and it was NOT in the database. So it still seems a bug in Bacula. In the first and second time when the problem occured, it was in both times in a directory which contains tech (not perl), but each time a different tech-file. All three times, the server was a new installed (testing)-server without productive users or productive files (only OS and some other static data). No other user was on the server. ---------------------------------------------------------------------- (0006699) kern (administrator) - 2013-05-10 09:33 http://bugs.bacula.org/view.php?id=1995#c6699 ---------------------------------------------------------------------- This is not something that we can reproduce here, and if we cannot reproduce it, we will probably not be able to fix it. You should carefully examine your PostgreSQL logs to see if some incompatibility has crept into it -- we have only tested on 9.1. If you can show that the problem does not exist on Bacula 5.2.5, with PostgreSQL 9.2x then we will take a careful look at the code changes. You might also explain what is being backed up in parallel -- is the same file/machine involved? ---------------------------------------------------------------------- (0006703) mkress (reporter) - 2013-05-10 10:50 http://bugs.bacula.org/view.php?id=1995#c6703 ---------------------------------------------------------------------- I have made about 80 backups without any problems since I've created this bug report. At the moment I don't decide to try a older Version of Bacula or Postgres, because the problem occures very seldom (only 3 times within of hundreds of backups). We have more than hundred installations of Bacula 5.2.6 with Postgres 9.1.3 which each made every day 2 backups and we have had older Version of Bacula and Postgres since 3 years and we had never a problem within thousends of backups. Now we want to migrate servers in our locations to VMware ESXI and using the same hardware (HP servers). I'm using the first time filedeamon-only systems and the newst Version of Bacula and Postgres. This new configuration is not productive until now. It's installed on test servers, without productive data and without users and with a very low usage. I made every weekday backups in parallel of 3 VM's on the same Hardware (starting about one o'clock at night). One VM running director, sd and fd, the 2 other VM's only fd. The tapedrive is connected using a pci-passthough SAS-card. The problem occours until now on the VM's which have only the fd installed. Conspicuous of first 2 occurrences was, that the missing file in the database was in the same directory. It were tech files which comes with the tech-package. The 3nd time it was a perl file from the perl package (and in a different VM). All three times, the missing file was a part of the system files. The files of the system are backuped before any other data is backuped. I do not using spooling. 1st time (on SLES 10): /usr/local/texlive/2009/texmf-dist/doc/latex/upmethodology/Changelog 2nd time (on SLES 10): /usr/local/texlive/2009/texmf-dist/doc/generic/pst-solides3d/doc-en/source/par-acknowledgements-en.tex 3rd time (on SLES 8): /usr/perl5/5.8.0/lib/unicore/lib/Ideograp.pl Between all 3 occurrences the VM ESXI and the VMs within were new installed. with a complete unattendend (scripted) auto installation. The VM's have no difference between the installations. Like I reported before, we have no Problem with the postgres installation. Logs are all ok. We're using the same postgres configuration (with a lower verion of postgres) on our hundered productive servers, which running perfectly. Bacula configuration between the testing and productive server differs only in the client configuration. Priorities were not used on our productive bacula (concurrences = 1). Only at the last occurrence with the perl-file I tried a restore using bextract. I was able to restore it using bextract. With the the restore command in bconsole, the file was not found. My tests will be go on and it will go productive in some weeks on hundred of servers. I hope to get more information I can provide here, but I sure, the problem is sitting not before the keyboard. ---------------------------------------------------------------------- (0006714) mkress (reporter) - 2013-05-21 08:10 http://bugs.bacula.org/view.php?id=1995#c6714 ---------------------------------------------------------------------- I tried in the last days 48 backups and verifies every 2h on vtapes (backup to files). All backups were ok, but got 6 times a verify error. It's not the same error as I got in my bug report. It seems not related to the problems in my bug report, but it's also very strange. I got every 6 times a "Volume data error" during verify, but the system have no Problems with the disks or any other errors (during backup and verify). All Logs are ok, also the log of the Raid controller. It's a HP server with 6 SAS Drives and Raid 5. It seems not to be a hardware error. FD-Daemon runs on a SLES10 and SD/DIR on a SLES11. Both are running on a VMWare ESXI-Server for HP Server with the newest Drivers. All Software and Hardware are certified by Suse and VMWare. I put this into the bug report for completeness. 18-May 11:15 iss-stor JobId 22: Forward spacing Volume "GLS_VTAPE-0036" to file:block 0:209. 18-May 11:15 iss-stor JobId 22: Error: block.c:334 Volume data error at 0:115283150! Block checksum mismatch in block=4776 len=64512: calc=c5a0196 blk=a9021e58 18-May 11:15 iss-stor JobId 22: Fatal error: fd_cmds.c:169 Command error with FD, hanging up. 18-May 11:15 iss-dir JobId 22: Warning: The following files are in the Catalog but not on the Volume(s): ---------------------------------------------------------------------- (0006715) kern (administrator) - 2013-05-22 07:35 http://bugs.bacula.org/view.php?id=1995#c6715 ---------------------------------------------------------------------- The error messages you posted in your last message very clearly indicate a hardware error. When Bacula reports a block checksum error as it did, you can be 100% sure you have some error external to Bacula most likely a hardware error: memory, OS drivers, disk drive, cables, controller, firmware, raid hardware card, raid software (particularly known for problems). I am 100% certain of the above, so please focus on that and not on other possibilities. It is highly likely that if you look back at your kernel logs, you will find the reason for the missing files. I am going to close this bug now, because as long as you have hardware errors, there is no use talking about Bacula problems. If you can fix your hardware errors and there are still problems, my suggestion is to shorten your reports to include the essential messages, from Bacula, the kernel logs and Postgres logs. Exact copies of oututput such as what you showed in the last report is what is most useful. For example, though you talk about Verify jobs, unless I missed something, I have seen nothing that "shows" the Verify jobs problem. Issue History Date Modified Username Field Change ====================================================================== 2013-04-12 08:02 mkress New Issue 2013-04-18 08:35 ebollengier Note Added: 0006656 2013-04-18 08:35 ebollengier Priority high => low 2013-04-18 08:35 ebollengier Severity major => minor 2013-04-19 15:32 mkress Note Added: 0006662 2013-05-10 09:33 kern Note Added: 0006699 2013-05-10 09:33 kern Status new => feedback 2013-05-10 10:50 mkress Note Added: 0006703 2013-05-10 10:50 mkress Status feedback => new 2013-05-21 08:10 mkress Note Added: 0006714 2013-05-22 07:35 kern Note Added: 0006715 2013-05-22 07:35 kern Status new => feedback ====================================================================== |