You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(149) |
Jul
(77) |
Aug
(75) |
Sep
(181) |
Oct
(120) |
Nov
(109) |
Dec
(138) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(37) |
Feb
(111) |
Mar
(115) |
Apr
(90) |
May
(135) |
Jun
(116) |
Jul
(93) |
Aug
(63) |
Sep
(73) |
Oct
(100) |
Nov
(145) |
Dec
(90) |
2006 |
Jan
(54) |
Feb
(79) |
Mar
(159) |
Apr
(70) |
May
(55) |
Jun
(92) |
Jul
(33) |
Aug
(70) |
Sep
(68) |
Oct
(107) |
Nov
(34) |
Dec
|
2007 |
Jan
|
Feb
(76) |
Mar
(96) |
Apr
(126) |
May
(107) |
Jun
(90) |
Jul
(95) |
Aug
(94) |
Sep
(159) |
Oct
(143) |
Nov
(114) |
Dec
(46) |
2008 |
Jan
(110) |
Feb
(62) |
Mar
(81) |
Apr
(101) |
May
(49) |
Jun
(100) |
Jul
(112) |
Aug
(102) |
Sep
(88) |
Oct
(72) |
Nov
(121) |
Dec
(79) |
2009 |
Jan
(50) |
Feb
(93) |
Mar
(139) |
Apr
(110) |
May
(122) |
Jun
(114) |
Jul
(149) |
Aug
(117) |
Sep
(96) |
Oct
(118) |
Nov
(112) |
Dec
(25) |
2010 |
Jan
(45) |
Feb
(206) |
Mar
(123) |
Apr
(147) |
May
(121) |
Jun
(68) |
Jul
(84) |
Aug
(77) |
Sep
(50) |
Oct
(34) |
Nov
(49) |
Dec
(31) |
2011 |
Jan
(65) |
Feb
(74) |
Mar
(72) |
Apr
(62) |
May
(50) |
Jun
(25) |
Jul
(47) |
Aug
(43) |
Sep
(35) |
Oct
(58) |
Nov
(90) |
Dec
(67) |
2012 |
Jan
(82) |
Feb
(44) |
Mar
(95) |
Apr
(60) |
May
(77) |
Jun
(118) |
Jul
(53) |
Aug
(14) |
Sep
(88) |
Oct
(41) |
Nov
(53) |
Dec
(37) |
2013 |
Jan
(48) |
Feb
(66) |
Mar
|
Apr
(54) |
May
(50) |
Jun
(7) |
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
(64) |
Mar
(67) |
Apr
(40) |
May
(72) |
Jun
(42) |
Jul
(99) |
Aug
(40) |
Sep
(8) |
Oct
(3) |
Nov
(16) |
Dec
(10) |
2015 |
Jan
(9) |
Feb
(8) |
Mar
(10) |
Apr
(14) |
May
(27) |
Jun
(12) |
Jul
(38) |
Aug
(55) |
Sep
(27) |
Oct
(43) |
Nov
(11) |
Dec
(46) |
2016 |
Jan
(46) |
Feb
(37) |
Mar
(24) |
Apr
(3) |
May
(16) |
Jun
(17) |
Jul
(49) |
Aug
(7) |
Sep
|
Oct
(61) |
Nov
(11) |
Dec
(17) |
2017 |
Jan
(13) |
Feb
(12) |
Mar
(29) |
Apr
(5) |
May
(67) |
Jun
(21) |
Jul
(61) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
From: <bac...@li...> - 2004-12-29 17:56:54
|
A BUGNOTE has been added to this bug. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000173 ====================================================================== Reported By: gvan Assigned To: ====================================================================== Project: bacula Bug ID: 173 Category: Director Reproducibility: always Severity: major Priority: normal Status: feedback ====================================================================== Date Submitted: 11-22-2004 23:19 PST Last Modified: 12-29-2004 10:02 PST ====================================================================== Summary: The number of files mismatch! after verify? Description: After backup data I do Verify Volume to Catalog. If after that to make again backup data I receive a error, for example: Error: I canot write on Volume "u1-s3-v1" because: The number of files mismatch! Volume=26 Catalog=39 If before new backup I do restart bacula error does not occur and reserve copying passes normally on given volume. ====================================================================== ---------------------------------------------------------------------- kern - 11-23-2004 11:51 PST ---------------------------------------------------------------------- You will need to send me your bacula-dir.conf file (as an attachement), and include the output from your job log -- that is the output from the backup, the subsequent verify, and the output from the job that failed. Please attach that to the bug report as a .txt file. ---------------------------------------------------------------------- ArnoL - 11-23-2004 14:27 PST ---------------------------------------------------------------------- There was a thread on [Bacula-users] Verify error (VolumeToCatalog) after backup starting started Oct. 13. That looks like it's a similar problem - perhaps even the same? Then, Martin Simmons reported something similar with a long discussion with Kern following. That was "Tape with an empty file between sessions". I can't recall how this ended, but I *think* that Martin had some patch and everybody waited if the error was gone. ---------------------------------------------------------------------- gvan - 11-24-2004 01:53 PST ---------------------------------------------------------------------- To kern: I have uploaded necessary files. Inform, if something else is required. In case of need the errror can be tried to repeat once again with other conditions. To ArnoL: If the question is this message http://sourceforge.net/mailarchive/forum.php?thread_id=5755103&forum_id=8833 the given problem completely is solved. But in this case a problem completely another. edited on: 11-24-04 01:53 ---------------------------------------------------------------------- kern - 11-24-2004 09:39 PST ---------------------------------------------------------------------- Thanks for the output. It was *exactly* what I needed to "see" your problem. I haven't been able to duplicate this bug here, and looking at your bacula-sd.conf file, I think the problem is because you have: TWO EOF = yes I'm a bit surprised that btape "test" doesn't detect this. Could you do the following things? 1. Run btape "test" command from version 1.36.1 with your current configuration, and if it works, please send me the output, as it will indicate that my tests are not sufficiently good. 2. Remove the TWO EOF = yes, then run the btape "test" command again, and make sure it succeeds. 3. If http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000002 works, remove the TWO EOF = yes from your Ultrium Device conf (and perhaps also from your DAT Device conf), then run the backup, verify, and backup and see if it succeeds. 4. If http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000003 works, then do the same test again, but stop and restart Bacula after the first backup, then proceed with the other tests. ---------------------------------------------------------------------- gvan - 11-25-2004 00:07 PST ---------------------------------------------------------------------- For a long time in release notes of one of versions or even in the documentation it is told that for FreeBSD it was desirable to establish TWO EOF = yes. Since then it at me also is established in this value. Also at me it is in addition established for tape in start of server: /usr/bin/mt -f /dev/nsa1 seteotmodel 2 /usr/bin/mt -f /dev/nsa1 blocksize 0 /usr/bin/mt -f /dev/nsa0 seteotmodel 2 /usr/bin/mt -f /dev/nsa0 blocksize 0 >1. Run btape "test" command from version 1.36.1 with your current >configuration, and if it works, please send me the output, as it will indicate >that my tests are not sufficiently good. Test works fine. See result in btape-1.txt >2. Remove the TWO EOF = yes, then run the btape "test" command again, and make >sure it succeeds. See result in btape-2_1.txt. Test ends with one error and with one recomendation - "Backward Space Record = No". After I set recomendation test ends without error because read backwards test is skiped (result in btape-2_2.txt) >3. If 0000002 works, remove the TWO EOF = yes from your Ultrium Device conf >(and perhaps also from your DAT Device conf), then run the backup, verify, and >backup and see if it succeeds. Second backup after verify reproduce error (I have interrupted it then since and so it was already visible, that the error has repeated). Results in backup-3.txt, verify-3.txt, backup_next-3.txt. Modified bacula-sd.conf also is attached as bacula-sd.conf-mod Probably all the same it does not solve a problem in this case. Whether there are any else ideas on change of my configuration? ---------------------------------------------------------------------- kern - 11-25-2004 00:52 PST ---------------------------------------------------------------------- Hmm. Sorry, my error. I failed to notice that you are using FreeBSD, which means that in principle the Device configuration you have is correct. Just the same, for me it is a very poor way to run an LTO drive, which is quite intelligent. I would appreciate it if you would try the following Device configuration, which is also mentioned in the manual: Hardware End of Medium = no BSF at EOM = no Backward Space Record = no Backward Space File = no Fast Forward Space File = yes TWO EOF = no I recommend you start with the btape "test" command, and if that works, try the Backup/Verify sequence. If this doesn't work, I think I have an idea where the problem is, but I'll have to work on it after the release 1.36.1 in a few days. ---------------------------------------------------------------------- kern - 11-25-2004 00:56 PST ---------------------------------------------------------------------- Oh, sorry, I forgot to mention that you need to modify your tape drive parameters as follows prior to running with the new test Device configuration: mt -f /dev/nsa0 seteotmodel 1 and keep the other parameters you have already set. ---------------------------------------------------------------------- gvan - 11-25-2004 03:39 PST ---------------------------------------------------------------------- I have changed a configuration (a new file bacula-sd.conf-mod2). Has changed model: # mt -f /dev/nsa0 seteotmodel 1 /dev/nsa0: old model was 2 filemarks at EOT /dev/nsa0: new model is 1 filemark at EOT # mt -f /dev/nsa0 geteotmodel /dev/nsa0: the model is 1 filemark at EOT Has started the test btape (results in btape-4.txt, errors are not present). And has executed backup, verify and the second backup (see results in backup-4.txt, verify-4.txt and backup_next-4.txt). The error is same and has remained former:( ---------------------------------------------------------------------- kern - 12-03-2004 12:16 PST ---------------------------------------------------------------------- I really do not know what is going on here or why the Director thinks there are 4 files Please try yet another experiment. This time, do the following: 1 Do a "llist volume=Vol-name" where Vol-name is the volume you are going to write to, presumably empty. 2 Do the backup. 3 Do a "llist volume=Vol-name" "sql" "select * from JobMedia where JobId=nnn" " " (blank line) where nnn is the JobId of the backup Job. 4 Run the Verify 5 Re-do step 3 6 Run the second backup 5 Re-do step 3 Send me the output from step 1 and the 3 X step 3. Maybe I can see something in it as it looks like something is really out of sync. It looks like the Verify is adding a file. The above info will confirm or not this idea. ---------------------------------------------------------------------- gvan - 12-09-2004 03:09 PST ---------------------------------------------------------------------- I think, that a problem all the same another. Results of the test are in a file output-last.txt. As a result of often tests by me it has been revealed, what even backup of small sizes and then verify some times can cause the following mistake successively: 08-Dec 10:13 x1-sd: Volume "u1-s8-v1" previously written, moving to end of data. 08-Dec 10:13 x1-sd: Ready to append to end of Volume "u1-s8-v1" at file=2. 08-Dec 10:13 x1-sd: End of Volume "u1-s8-v1" at 3:0 on device /dev/nsa0. Write of 64512 bytes got 0. 08-Dec 10:13 x1-sd: End of medium on Volume "u1-s8-v1" Bytes=1,976,947,844 Blocks=30,645 at 08-Dec-2004 10:13. I.e. somehow occurs out of sync quantities of files after backup and the subsequent verifies. And then there is a mistake of record and bacula considers, that the tape is full, though size of a tape about 200 GB. If after each verifies before next backups to do restart bacula the given mistake does not arise. ---------------------------------------------------------------------- kern - 12-16-2004 14:10 PST ---------------------------------------------------------------------- I haven't yet looked at your latest output, but from your notes, it appears that there is some strange bug with the interaction of your OS tape driver and Bacula. Bacula should *never* get an error (as it did in your example) when trying to append to a tape. I'll still look at the output, but my best bet is a bug in the OS or the LTO tape driver that in some cases prohibits appending to a tape or gets a false end of tape when it is really not the end of the tape. If restarting Bacula clears the problem, then it points even more to the OS driver as being in an unstable state. It doesn't prove it, but it makes me lean in that direction. ---------------------------------------------------------------------- Dan Langille - 12-28-2004 06:01 PST ---------------------------------------------------------------------- Are you backing up to tape? FreeBSD 4.9-RELEASE contains a pthreads bug that will result in more data being written to the tape than can be stored on the tape. This problem arises only if the backup spans more than one tape. Did your backup involve more than one tape? If so, the above pthreads issue might explain why your backup held less data than the catalog expected. This bug is easily patched. See platforms/freebsd/pthreads-fix.txt for details. Please ask if you have any questions. ---------------------------------------------------------------------- gvan - 12-28-2004 06:08 PST ---------------------------------------------------------------------- No, I have patched version FreeBSD 4.9 (pthreads bug). The problem arises, even if backup involve one tape. ---------------------------------------------------------------------- kern - 12-29-2004 10:02 PST ---------------------------------------------------------------------- I've carefully looked over your last upload (output-last.txt), and it is very clear to me that either there is some *very* subtle bug in Bacula, or the OS is playing subtle tricks. If you are running with the Device configuration that I suggested in my bugnote of 11-25-04, then I have no idea what is going on. And about the only suggestion I have is try doing "unmount then mount" in the console when this happens. Bug History Date Modified Username Field Change ====================================================================== 11-22-04 23:19 gvan New Bug 11-22-04 23:19 gvan File Added: bacula-sd.conf 11-22-04 23:29 gvan Bug Monitored: gvan 11-23-04 11:51 kern Bugnote Added: 0000472 11-23-04 11:51 kern Status new => feedback 11-23-04 14:27 ArnoL Bugnote Added: 0000475 11-23-04 22:21 gvan File Added: backup.txt 11-23-04 22:21 gvan File Added: verify.txt 11-23-04 22:21 gvan File Added: backup_next.txt 11-23-04 22:22 gvan File Added: bacula-dir.conf 11-23-04 22:29 gvan Bugnote Added: 0000477 11-24-04 01:53 gvan Bugnote Edited: 0000477 11-24-04 09:39 kern Bugnote Added: 0000480 11-25-04 00:02 gvan File Added: btape-1.txt 11-25-04 00:02 gvan File Added: btape-2_1.txt 11-25-04 00:02 gvan File Added: btape-2_2.txt 11-25-04 00:03 gvan File Added: backup-3.txt 11-25-04 00:03 gvan File Added: verify-3.txt 11-25-04 00:04 gvan File Added: backup_next-3.txt 11-25-04 00:04 gvan File Added: bacula-sd.conf-mod 11-25-04 00:07 gvan Bugnote Added: 0000482 11-25-04 00:52 kern Bugnote Added: 0000483 11-25-04 00:56 kern Bugnote Added: 0000484 11-25-04 03:34 gvan File Added: bacula-sd.conf-mod2 11-25-04 03:34 gvan File Added: btape-4.txt 11-25-04 03:34 gvan File Added: backup-4.txt 11-25-04 03:35 gvan File Added: verify-4.txt 11-25-04 03:35 gvan File Added: backup_next-4.txt 11-25-04 03:39 gvan Bugnote Added: 0000485 12-03-04 12:16 kern Bugnote Added: 0000507 12-09-04 03:09 gvan Bugnote Added: 0000536 12-09-04 03:09 gvan File Added: output-last.txt 12-16-04 14:10 kern Bugnote Added: 0000551 12-28-04 06:01 Dan Langille Bugnote Added: 0000591 12-28-04 06:08 gvan Bugnote Added: 0000593 12-29-04 10:02 kern Bugnote Added: 0000597 ====================================================================== |
From: <bac...@li...> - 2004-12-29 17:44:12
|
A BUGNOTE has been added to this bug. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000209 ====================================================================== Reported By: abuehler Assigned To: ====================================================================== Project: bacula Bug ID: 209 Category: File Daemon Reproducibility: always Severity: crash Priority: normal Status: feedback ====================================================================== Date Submitted: 12-21-2004 09:53 PST Last Modified: 12-29-2004 09:49 PST ====================================================================== Summary: FD crash after sucessfull backup Description: After sucessfull completion of the backup the FD crash. See attached traceback. In output of the "status client=albundy-fd" the job is not listed, but appears in "list jobs". ====================================================================== ---------------------------------------------------------------------- kern - 12-21-2004 10:10 PST ---------------------------------------------------------------------- The traceback doesn't seem to show the FD crashing. I recommend that you manually run it under the debugger. Then when it crashes, enter the following command: thread apply all bt Hopefully that will show where the problem lies. I suspect that the status client is showing nothing because either the job never ran or the FD crashed. If it crashes, any running jobs are lost and not reported if the FD is restarted (i.e. they are only written to the job history at the end of the job). ---------------------------------------------------------------------- abuehler - 12-22-2004 07:22 PST ---------------------------------------------------------------------- I've checked out the cvs 1.37.1 (21Dec04) and ran it with gdb. It seems the FD is getting SIGUSR2. After entering "continue" (>100 times) in gdb the FD terminates with SIGSEGV (gdbout.txt). I got a email notifcation with a failed backup. Next I've tried runing FD in foreground, set the debug level to 150 and redirect stdout and stderr to a file (debug-150.txt, omitted serveral lines). This time I got email notification with a "Backup OK" (debug-email.txt) and a backtrace mail (debug-trace.txt). ---------------------------------------------------------------------- kern - 12-22-2004 09:25 PST ---------------------------------------------------------------------- Thanks for your efforts. Please try running the FD under the debugger again as follows: gdb bacula-fd run -s -f -c bacula-fd.conf when it comes back to the command prompt (after crashing), enter: thread apply all bt Hopefully that will show me where the problem is. From the -dxxx trace, it seems like it is dying in some utility thread because after the seg fault, sending of the data to the SD continues ... ---------------------------------------------------------------------- abuehler - 12-22-2004 11:44 PST ---------------------------------------------------------------------- The attached file "gdbout2.txt" contains the output of the gdb session. ---------------------------------------------------------------------- kern - 12-22-2004 12:58 PST ---------------------------------------------------------------------- The traceback does not clearly show where the seg fault occurs, but from previous similar reports, I can now make a guess (estimate 99% correct). You are probably either mixing old and new syntax FileSets, and for some reason, when you have old style includes/excludes, something gets confused and seg faults. Try switching to using all new style FileSet, and I am 99% sure your problem will go away. Please report back. ---------------------------------------------------------------------- kern - 12-24-2004 02:32 PST ---------------------------------------------------------------------- I believe that I have now found and fixed the FD crash problem (even if you use the old style include/excludes). It is now in the 1.37.1 CVS. I would appreciate it if you would try it -- assuming that you have not already converted your FileSet. I've also attached a 1.36.1 patch for users on 1.36.1. Note, this patch can also be applied to 1.37.1 ---------------------------------------------------------------------- abuehler - 12-29-2004 07:09 PST ---------------------------------------------------------------------- I've tried CVS 1.37.1 (LSMDATE 24Dec04) without success using the old-styled configuration. The result is same as seen in the previous version. I've got a successful E-Mail notification and a Bacula traceback. edited on: 12-29-04 07:09 ---------------------------------------------------------------------- kern - 12-29-2004 09:49 PST ---------------------------------------------------------------------- Please upload your traceback file (preferrably as a .txt file). I'll take a look at it. Are you able to make the FD work correctly by modifying your FileSet to use only the new style syntax? Bug History Date Modified Username Field Change ====================================================================== 12-21-04 09:53 abuehler New Bug 12-21-04 09:53 abuehler File Added: traceback.txt 12-21-04 10:10 kern Bugnote Added: 0000579 12-22-04 07:22 abuehler Bugnote Added: 0000581 12-22-04 07:23 abuehler File Added: gdbout.txt 12-22-04 07:23 abuehler File Added: debug-150.txt 12-22-04 07:24 abuehler File Added: debug-email.txt 12-22-04 07:24 abuehler File Added: debug-trace.txt 12-22-04 09:25 kern Bugnote Added: 0000583 12-22-04 09:25 kern Status new => feedback 12-22-04 11:40 abuehler File Added: gdbout2.txt 12-22-04 11:44 abuehler Bugnote Added: 0000586 12-22-04 12:58 kern Bugnote Added: 0000587 12-24-04 02:28 kern File Added: 1.36.1-fileset.patch 12-24-04 02:32 kern Bugnote Added: 0000588 12-24-04 02:32 kern Resolution open => fixed 12-24-04 02:32 kern Status feedback => closed 12-29-04 07:07 abuehler Bugnote Added: 0000595 12-29-04 07:07 abuehler Resolution fixed => reopened 12-29-04 07:07 abuehler Status closed => feedback 12-29-04 07:09 abuehler Bugnote Edited: 0000595 12-29-04 09:49 kern Bugnote Added: 0000596 ====================================================================== |
From: <bac...@li...> - 2004-12-29 15:01:43
|
The following bug has been REOPENED. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000209 ====================================================================== Reported By: abuehler Assigned To: ====================================================================== Project: bacula Bug ID: 209 Category: File Daemon Reproducibility: always Severity: crash Priority: normal Status: feedback ====================================================================== Date Submitted: 12-21-2004 09:53 PST Last Modified: 12-29-2004 07:07 PST ====================================================================== Summary: FD crash after sucessfull backup Description: After sucessfull completion of the backup the FD crash. See attached traceback. In output of the "status client=albundy-fd" the job is not listed, but appears in "list jobs". ====================================================================== ---------------------------------------------------------------------- kern - 12-21-2004 10:10 PST ---------------------------------------------------------------------- The traceback doesn't seem to show the FD crashing. I recommend that you manually run it under the debugger. Then when it crashes, enter the following command: thread apply all bt Hopefully that will show where the problem lies. I suspect that the status client is showing nothing because either the job never ran or the FD crashed. If it crashes, any running jobs are lost and not reported if the FD is restarted (i.e. they are only written to the job history at the end of the job). ---------------------------------------------------------------------- abuehler - 12-22-2004 07:22 PST ---------------------------------------------------------------------- I've checked out the cvs 1.37.1 (21Dec04) and ran it with gdb. It seems the FD is getting SIGUSR2. After entering "continue" (>100 times) in gdb the FD terminates with SIGSEGV (gdbout.txt). I got a email notifcation with a failed backup. Next I've tried runing FD in foreground, set the debug level to 150 and redirect stdout and stderr to a file (debug-150.txt, omitted serveral lines). This time I got email notification with a "Backup OK" (debug-email.txt) and a backtrace mail (debug-trace.txt). ---------------------------------------------------------------------- kern - 12-22-2004 09:25 PST ---------------------------------------------------------------------- Thanks for your efforts. Please try running the FD under the debugger again as follows: gdb bacula-fd run -s -f -c bacula-fd.conf when it comes back to the command prompt (after crashing), enter: thread apply all bt Hopefully that will show me where the problem is. From the -dxxx trace, it seems like it is dying in some utility thread because after the seg fault, sending of the data to the SD continues ... ---------------------------------------------------------------------- abuehler - 12-22-2004 11:44 PST ---------------------------------------------------------------------- The attached file "gdbout2.txt" contains the output of the gdb session. ---------------------------------------------------------------------- kern - 12-22-2004 12:58 PST ---------------------------------------------------------------------- The traceback does not clearly show where the seg fault occurs, but from previous similar reports, I can now make a guess (estimate 99% correct). You are probably either mixing old and new syntax FileSets, and for some reason, when you have old style includes/excludes, something gets confused and seg faults. Try switching to using all new style FileSet, and I am 99% sure your problem will go away. Please report back. ---------------------------------------------------------------------- kern - 12-24-2004 02:32 PST ---------------------------------------------------------------------- I believe that I have now found and fixed the FD crash problem (even if you use the old style include/excludes). It is now in the 1.37.1 CVS. I would appreciate it if you would try it -- assuming that you have not already converted your FileSet. I've also attached a 1.36.1 patch for users on 1.36.1. Note, this patch can also be applied to 1.37.1 ---------------------------------------------------------------------- abuehler - 12-29-2004 07:07 PST ---------------------------------------------------------------------- I've tried CVS 1.37.1 (LSMDATE 24Dec04) without success. The result is same as seen in the previous version. I've got a successful E-Mail notification and a Bacula traceback. Bug History Date Modified Username Field Change ====================================================================== 12-21-04 09:53 abuehler New Bug 12-21-04 09:53 abuehler File Added: traceback.txt 12-21-04 10:10 kern Bugnote Added: 0000579 12-22-04 07:22 abuehler Bugnote Added: 0000581 12-22-04 07:23 abuehler File Added: gdbout.txt 12-22-04 07:23 abuehler File Added: debug-150.txt 12-22-04 07:24 abuehler File Added: debug-email.txt 12-22-04 07:24 abuehler File Added: debug-trace.txt 12-22-04 09:25 kern Bugnote Added: 0000583 12-22-04 09:25 kern Status new => feedback 12-22-04 11:40 abuehler File Added: gdbout2.txt 12-22-04 11:44 abuehler Bugnote Added: 0000586 12-22-04 12:58 kern Bugnote Added: 0000587 12-24-04 02:28 kern File Added: 1.36.1-fileset.patch 12-24-04 02:32 kern Bugnote Added: 0000588 12-24-04 02:32 kern Resolution open => fixed 12-24-04 02:32 kern Status feedback => closed 12-29-04 07:07 abuehler Bugnote Added: 0000595 12-29-04 07:07 abuehler Resolution fixed => reopened 12-29-04 07:07 abuehler Status closed => feedback ====================================================================== |
From: <bac...@li...> - 2004-12-28 23:36:57
|
The following bug has been SUBMITTED. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000210 ====================================================================== Reported By: jamieff Assigned To: ====================================================================== Project: bacula Bug ID: 210 Category: File Daemon Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 12-28-2004 15:42 PST Last Modified: 12-28-2004 15:42 PST ====================================================================== Summary: bacula-fd on windows does not fail a backup on an error in ClientRunBefore Description: Bacula-fd does not fail the backup job when the ClientRunBefore program returns an error code when using a .bat file, or when the .bat file does not exist. The result is that critical pre-backup steps might fail, including DB dumps, but the admin is not notified. ====================================================================== Bug History Date Modified Username Field Change ====================================================================== 12-28-04 15:42 jamieff New Bug ====================================================================== |
From: <bac...@li...> - 2004-12-28 14:32:07
|
A BUGNOTE has been added to this bug. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000122 ====================================================================== Reported By: bootsy52 Assigned To: ====================================================================== Project: bacula Bug ID: 122 Category: Storage Daemon Reproducibility: always Severity: feature Priority: normal Status: feedback ====================================================================== Date Submitted: 09-24-2004 15:09 PDT Last Modified: 12-28-2004 06:37 PST ====================================================================== Summary: Make bacula server work on OpenBSD Description: I'm now trying quit a long time (from version to version again) to get Bacula on my OpenBSD box running. As Bacula runs on FreeBSD and obviously also on NetBSD I think it must basicly work OpenBSD as well. Because my main server runs OpenBSD it would be more than pleasent if bacula would run on it. The Tape is a DDS-3: HP C1537A, L907 So here is what I got so far: 1. Bacula compiles and installs just fine 2. btape test always fails either on the position test or at the append test (depends on which parameters I've set) With the following parameters it fails at the Write, rewind, position test, resulting in an infinite loop printing "Got EOF on tape." on the screen, directly after processing block 1:600. This refers as far as I found to subroutine read_again() in line 813 btape.c. My guess is that, the EOF found is followed by another EOF Device { Name = DDS-3 # Media Type = DDS-3 Archive Device = /dev/nrst0 AutomaticMount = yes; # when device opened, read it AlwaysOpen = yes; RemovableMedia = yes; RandomAccess = no; } Also setting it to a fixed blocksize with Minimum Block size = 65536 Maximum Block size = 65536 doesn't help, either with this test, nor with the append test ################################################ with the following parameters the postition test is passed, but it fails at the end on the append test with: "We should be in file 3. I am at file 0. This is NOT correct!!!!" Device { Name = DDS-3-BSD Description = "DDS-3 for FreeBSD" Media Type = DDS-3 Archive Device = /dev/nrst0 AutomaticMount = yes; # when device opened, read it AlwaysOpen = yes Offline On Unmount = no Hardware End of Medium = no BSF at EOM = yes Backward Space Record = no Fast Forward Space File = no TWO EOF = yes } ====================================================================== ---------------------------------------------------------------------- kern - 09-25-2004 02:50 PDT ---------------------------------------------------------------------- What I need to proceed is a copy of your man pages that describe the tape interface. They are usually in mtio or st (possibly both). In particular, I need to see the iotcl() calls that are supported, and if they have a description of the different tape modes they have implemented (e.g. variable block vs fixed block, ...). This is a good time to give me the info since I am just in the process of adding OS dependent ioctl()s to Bacula. ---------------------------------------------------------------------- Dan Langille - 09-25-2004 05:58 PDT ---------------------------------------------------------------------- The following URL has online man pages for FreeBSD, OpenBSD, NetBSD, Darwin, BSD386, HP-UX, Slackware, Minix, Red Hat, SuSE, SunOS, and XFree86 http://www.freebsd.org/cgi/man.cgi :) ---------------------------------------------------------------------- bootsy52 - 09-25-2004 08:59 PDT ---------------------------------------------------------------------- I've uploaded the man pages as ascii text files, all manpages are accessible through: http://www.openbsd.org/cgi-bin/man.cgi ---------------------------------------------------------------------- kern - 09-25-2004 13:00 PDT ---------------------------------------------------------------------- Please download the latest CVS 1.35.5 (25Sept04) and try it. If I made any mistakes or typos there may be a problem compiling dev.c. Then use the same parameters as for FreeBSD without the fixed block specifications. Try running btape "test" again. Thanks for the documents. I've deleted those that are not useful. The others I'll leave for possible future reference. ---------------------------------------------------------------------- bootsy52 - 09-25-2004 13:47 PDT ---------------------------------------------------------------------- No new dev.c there on cvs so far. However, I'm impressed how quick this issue resolved. I thought the whole time, that the developers got no first hand on OpenBSD and thus the issue wouldn't be resolved. But from searching, google, the mailinglist. It suddendly seemed to me that no one has tested this on OpenBSD or no one was willing to file a bug report. If I had known this before, I wouldn't have waited a half year testing from version to version seeing if this problem is resolved by chance. Also as I'm subscribed to the OpenBSD mailinglist, I will let the list know, once btape test runs successfully for me. Thanx ---------------------------------------------------------------------- Dan Langille - 09-25-2004 14:24 PDT ---------------------------------------------------------------------- It takes a while to get from the developer CVS to the public CVS. I got it via my login and you can grab it from here: http://beta.freshports.org/tmp/ Just add the file name. ---------------------------------------------------------------------- bootsy52 - 09-25-2004 15:42 PDT ---------------------------------------------------------------------- The Append test still fails with the same error, "We should be in file 3. I am at file 0. This is NOT correct!!!!" is dev.c the only new file needed or are there more ? The compilation went cleanly besides this two warnings which given during the build of section === lib ===. Don't know if they are to see on OpenBSD only. # 1 message.c: In function `void my_name_is(int, char **, const char *)': message.c:151: warning: array size (400) is smaller than minimum required (1024) message.c:153: warning: array size (400) is smaller than minimum required (1024) # 2 address_conf.c: In function `int sockaddr_to_ascii(const sockaddr *, char *, int)': address_conf.c:544: warning: sizeof(pointer) possibly incorrect in argument 4 I looked at dev.c (also I'm not yet a C Programmer) I found the comment in line 763. From past experiences I made with AFbackup, I've seen the symptom that when AFbackup ran and there was no tape in the drive. I got an I/O Error on every attempt to access the drive later on and the only resolution was to reboot the machine to have access to the tape drive again. Do I get it right, that the workaround there is meant exactly for cases like this ? ---------------------------------------------------------------------- Dan Langille - 09-25-2004 18:22 PDT ---------------------------------------------------------------------- The latest dev.c is now available via anonymous cvs. ---------------------------------------------------------------------- bootsy52 - 09-25-2004 18:34 PDT ---------------------------------------------------------------------- I've done complete checkout, but the error is still the same in the "Append" test. I've verified the version of dev.c and it is newest 1.90 I'm able to provide access to a OpenBSD box to you on next Friday. As I got a tape drive lying around here, and we got a few Pentium comuters lyning around in the company, which I could install OpenBSD on. ---------------------------------------------------------------------- kern - 09-26-2004 01:32 PDT ---------------------------------------------------------------------- Could you post the following things: 1. Your bacula-sd.conf file 2. The complete output from btape "test" showing the failure Thanks for pointing out the compile problems. I've fixed them as they were potential problems, but not in this case. In the btest case, you should start with a tape in the drive to void any secondary problems as you mention with AFBackup. As far as I know, Bacula should not hang or cause a system hang if no tape is initially in the drive, but this needs verification. The changes I've recently made are meant to put the drive in variable block mode so that it can properly forward space. I'm still in the process of implementing the improvements. The results of your above test should help me. ---------------------------------------------------------------------- bootsy52 - 09-26-2004 07:58 PDT ---------------------------------------------------------------------- I've uploaded the complete output of btape test and also bacula-sd.conf with the password string removed. I have always tested for the moment with a tape in the drive, for exactly the reason you mention. BTW, my way of solving the first compile warning in message.c was to simply set cpath[1024] and npath[1024] ;-) ---------------------------------------------------------------------- kern - 09-27-2004 05:20 PDT ---------------------------------------------------------------------- Well, you are going to have to play with the Device resource a bit to get it to work. The fact that the positioning test is successful is very encouraging. I'd recommend that you start with a Device resource the same as the one you have for DDS-3 (Solaris/Linux) and see what happens. The depending on the results, the test may automatically try a few variations -- otherwise, you will need to do it one step at a time depending on the failure. ---------------------------------------------------------------------- bootsy52 - 09-27-2004 05:26 PDT ---------------------------------------------------------------------- OK, the plain DDS-3 Resource runs into an endless loop printing "Got EOF on tape." on the screen as mentioned in the initial bugreport. I'll try out further with changing parameters. ---------------------------------------------------------------------- kern - 09-27-2004 05:34 PDT ---------------------------------------------------------------------- Add the -d200 option to btape when you run it. That may give you a better idea what is going on, and maybe not. ---------------------------------------------------------------------- bootsy52 - 09-27-2004 06:07 PDT ---------------------------------------------------------------------- With the latest CVS checkout (26-September-2004) I couldn't run any test anymore, with either configuration. The error is: btape: butil.c:258 Using device: "DDS-3" for writing. btape: dev.c:215 init_dev: tape=1 dev_name=/dev/nrst0 btape: block.c:122 Returning new block=3c034128 btape: device.c:265 start open_output_device() btape: device.c:286 Opening device. btape: dev.c:255 open_dev: tape=1 dev_name=/dev/nrst0 vol= btape: dev.c:259 open_dev: device is tape btape: dev.c:308 open_dev: tape 5 opened btape: device.c:293 open_dev /dev/nrst0 OK btape: butil.c:170 Device opened for read. btape: block.c:122 Returning new block=3c034428 btape: btape.c:335 open_dev /dev/nrst0 OK btape: block.c:159 free_block buffer 3c05c028 btape: block.c:161 free_block block 3c034428 btape: btape.c:269 Do tape commands [ ... === Write, rewind, and re-read test === ... ] btape: btape Fatal error: Attempt to write on read-only Volume. btape: btape.c:778 Error writing block to device. but tar c /etc for example works just fine, and I verified despite of that that the tape is not write locked. ---------------------------------------------------------------------- kern - 09-27-2004 14:54 PDT ---------------------------------------------------------------------- Sorry, the btape problems are my error. Please try pulling the latest CVS. I forgot to update btape to work with the new device drivers. I've patched btape to work for the "test" command, but there are still other commands such as "fill" that are badly broken. ---------------------------------------------------------------------- bootsy52 - 09-28-2004 09:38 PDT ---------------------------------------------------------------------- I'm still not able to test any setup on the tape, the error I got is (tar works just fine) also btape clear does not help. btape: dev.c:371 rewind_dev /dev/nrst0 btape: block.c:429 binbuf=64448 buf_len=64512 btape: btape Error: block.c:552 Write error at 0:0 on device /dev/nrst0. ERR=Input/output error. btape: block.c:563 === Write error. size=64512 rtn=-1 dev_blk=0 blk_blk=0 errno=5: ERR=Input/output error btape: dev.c:1164 weof_dev btape: block.c:686 dir_update_volume_info terminate writing -- OK btape: block.c:711 Leave terminate_writing_volume -- OK btape: dev.c:965 bsf_dev btape: dev.c:1069 bsr_dev btape: btape Error: Backspace record at EOT failed. ERR=Input/output error btape: btape.c:779 Error writing block to device. ---------------------------------------------------------------------- bootsy52 - 09-28-2004 09:40 PDT ---------------------------------------------------------------------- And when I use the BSD config then I get: btape: dev.c:371 rewind_dev /dev/nrst0 btape: block.c:429 binbuf=64448 buf_len=64512 btape: btape Error: block.c:552 Write error at 0:0 on device /dev/nrst0. ERR=Input/output error. btape: block.c:563 === Write error. size=64512 rtn=-1 dev_blk=0 blk_blk=0 errno=5: ERR=Input/output error btape: dev.c:1164 weof_dev btape: block.c:686 dir_update_volume_info terminate writing -- OK btape: dev.c:1164 weof_dev btape: block.c:711 Leave terminate_writing_volume -- OK btape: btape.c:779 Error writing block to device. ---------------------------------------------------------------------- kern - 09-28-2004 10:32 PDT ---------------------------------------------------------------------- Please run a tar, then a btape test command, and post the complete output of both here. There is something wrong if Bacula is getting I/O errors. It may be a question of maximum buffer sizes or something. Another thing to do is to start doing the 9 steps outlined in the Testing chapter of the manual. Please save the output from each step, and when you cannot make a step work, then post everything to this bug report. That will allow us to proceed step by step. ---------------------------------------------------------------------- kern - 10-04-2004 07:50 PDT ---------------------------------------------------------------------- I believe that Bacula can support OpenBSD in version 1.35.7, but I am unable to test it. If there are problems, please re-report. ---------------------------------------------------------------------- bootsy52 - 10-04-2004 17:49 PDT ---------------------------------------------------------------------- Tested today again with 1.35.8, but works less then before still Input/Output Errors, I'm in the process of doing steps 1.. 9 of the tape manual, but due to that I had Exams last week I was too busy to complete them. The results are so far, that 1. btape test => Input/Output Error 2. btape fill => Input/Output Error 3. mt -f /dev/nrst0 erase => Succeeds 4. tar cvf /dev/nrst0 /etc => Succeeds I'll give full details once I complete them all ---------------------------------------------------------------------- bootsy52 - 10-17-2004 16:22 PDT ---------------------------------------------------------------------- I've done cvs update today, but the error is still the same, tar, mt and the like work as expected, no errors. The uploaded file shows btape test with debugging option -d200. Also btape fill fails, I can provide you with details on that also ---------------------------------------------------------------------- kern - 10-18-2004 08:43 PDT ---------------------------------------------------------------------- Without the details of the btape "test" command, I cannot proceed. ---------------------------------------------------------------------- bootsy52 - 10-18-2004 10:34 PDT ---------------------------------------------------------------------- Hmmh, how could I give more details than in the attached file "Bacula-btape", which is btape test called with -d200 ??? ---------------------------------------------------------------------- kern - 10-18-2004 11:53 PDT ---------------------------------------------------------------------- Sorry, I failed to notice that you uploaded a file and that you mentioned it in your bugnote. The only way we are going to make this work is if I have access to an OpenBSD system since I have no idea why it is getting an I/O error, and it will take a lot of "playing around" to figure it out. Can you provide me ssh access to some system with an available tape drive? ---------------------------------------------------------------------- bootsy52 - 10-19-2004 09:07 PDT ---------------------------------------------------------------------- Kern, can you see my e-mail address from mantis ? If so mail me, so I'll give you ssh access ---------------------------------------------------------------------- bootsy52 - 10-19-2004 11:02 PDT ---------------------------------------------------------------------- Hi Kern, this seems to be the same problem I've experienced with AFbackup, despite of that I could do all stuff using tar and mt, I decided to reboot the machine, to exclude that it is not the same phenomen. After rebooting, the Input/Output Error is gone away, however the Append test still fails. I'm now trying out out different options ---------------------------------------------------------------------- kern - 10-19-2004 12:19 PDT ---------------------------------------------------------------------- Well, I'm happy to hear that Bacula isn't the only backup program to have problems. I could probably look through all the admin lists and find your email, but it is easier for you to email me at: kern at sibbald dot com or put your email address in one of these bug notes the same way. If you know how to set up a ssh login, below is my ssh public key. I prefer to login as kern, do not need root as long as you all me to access the tape drive, or put me in the group, or something similar. I'll need 80-100 MB of disk, and the standard stuff to build Bacula. If you have troubles setting up an ssh login directly, just send me the site address IP or domain name, my userid, and password, and I'll fix it to go in by ssh. ====== kern's public key ==== ssh-dss AAAAB3NzaC1kc3MAAACBAMUYzep4on+l/Yuf+pPixk8bRIQzeUe+4SuDonjJjV0Zc42u9w6u1vAZe8U9c04vraiXHysq510gmtfbq7T9feqnolfrwROWtb0+DGIoYG4d3GbgVBHY+6f6W2zb2+wrsA5tmeRFBD45AMBz5u20WEZ8p1Wcy2xms02av+0FeUVZAAAAFQCjVnz31coZzA5bm3sBe9wIDplh6wAAAIEAntKIZSn/Up/s652FCOe3PAtHZISr/UW2PFiA3Yumefg0xFA0cfIGIaaMj0U4dheU1il5zVeIfTcxi0RTXdYKLCMxgLAjGLjONbnKJYrEXshZNwNKkRMHMMLTbzL0O0XqRVAg/h9rXN/identqQ/ULzMzP3zyNgCNF7GFOgTyLegAAACBAKwFpQ9SvMaOh3lKnl0gH3+AlHTE/DnWVD5bsp20CyhC6KSkN9zGwan+38wuR1TqqM7WYhjErLfnkt44POOylbzPMIu1UaDm+d8jLV6SKfnDGdSSs208ZutALXSlV0jL49VBqm+HtsYlVCjQ3rMIbsICa+kY7B/NQGxrIFZ+Bqaz ke...@ru... ==== end public key === It should all be on one line ---------------------------------------------------------------------- Dan Langille - 12-28-2004 06:03 PST ---------------------------------------------------------------------- Kern: Did you get access to an OpenBSD system? If not, I'm sure we can arrange it. ---------------------------------------------------------------------- bootsy52 - 12-28-2004 06:37 PST ---------------------------------------------------------------------- He has access to my System. Currently OpenBSD-3.6 with all patches applied Bug History Date Modified Username Field Change ====================================================================== 09-24-04 15:09 bootsy52 New Bug 09-24-04 15:09 bootsy52 File Added: scsi_tape.h 09-25-04 02:50 kern Bugnote Added: 0000284 09-25-04 02:50 kern Status new => feedback 09-25-04 05:58 Dan Langille Bugnote Added: 0000286 09-25-04 08:57 bootsy52 File Added: mtio.4.txt 09-25-04 08:57 bootsy52 File Added: ioctl.2.txt 09-25-04 08:57 bootsy52 File Added: scsi.4.txt 09-25-04 08:58 bootsy52 File Added: st.4.txt 09-25-04 08:58 bootsy52 File Added: mtio.h 09-25-04 08:59 bootsy52 Bugnote Added: 0000287 09-25-04 12:56 kern File Deleted: scsi_tape.h 09-25-04 12:56 kern File Deleted: mtio.4.txt 09-25-04 12:56 kern File Deleted: ioctl.2.txt 09-25-04 12:56 kern File Deleted: scsi.4.txt 09-25-04 13:00 kern Bugnote Added: 0000291 09-25-04 13:47 bootsy52 Bugnote Added: 0000292 09-25-04 14:24 Dan Langille Bugnote Added: 0000293 09-25-04 15:42 bootsy52 Bugnote Added: 0000294 09-25-04 18:22 Dan Langille Bugnote Added: 0000295 09-25-04 18:34 bootsy52 Bugnote Added: 0000296 09-26-04 01:32 kern Bugnote Added: 0000297 09-26-04 07:54 bootsy52 File Added: btape.out 09-26-04 07:55 bootsy52 File Added: bacula-sd.conf 09-26-04 07:58 bootsy52 Bugnote Added: 0000299 09-27-04 05:20 kern Bugnote Added: 0000306 09-27-04 05:26 bootsy52 Bugnote Added: 0000307 09-27-04 05:34 kern Bugnote Added: 0000309 09-27-04 06:07 bootsy52 Bugnote Added: 0000311 09-27-04 14:54 kern Bugnote Added: 0000313 09-28-04 09:38 bootsy52 Bugnote Added: 0000316 09-28-04 09:40 bootsy52 Bugnote Added: 0000317 09-28-04 10:32 kern Bugnote Added: 0000319 10-04-04 07:50 kern Bugnote Added: 0000342 10-04-04 07:50 kern Resolution open => fixed 10-04-04 07:50 kern Status feedback => closed 10-04-04 17:49 bootsy52 Bugnote Added: 0000346 10-04-04 17:49 bootsy52 Resolution fixed => reopened 10-04-04 17:49 bootsy52 Status closed => feedback 10-17-04 16:20 bootsy52 File Added: Bacula-btape 10-17-04 16:22 bootsy52 Bugnote Added: 0000371 10-18-04 08:43 kern Bugnote Added: 0000377 10-18-04 10:34 bootsy52 Bugnote Added: 0000378 10-18-04 11:53 kern Bugnote Added: 0000380 10-19-04 09:07 bootsy52 Bugnote Added: 0000390 10-19-04 11:02 bootsy52 Bugnote Added: 0000391 10-19-04 12:19 kern Bugnote Added: 0000392 12-28-04 06:03 Dan Langille Bugnote Added: 0000592 12-28-04 06:37 bootsy52 Bugnote Added: 0000594 ====================================================================== |
From: <bac...@li...> - 2004-12-28 14:03:22
|
A BUGNOTE has been added to this bug. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000173 ====================================================================== Reported By: gvan Assigned To: ====================================================================== Project: bacula Bug ID: 173 Category: Director Reproducibility: always Severity: major Priority: normal Status: feedback ====================================================================== Date Submitted: 11-22-2004 23:19 PST Last Modified: 12-28-2004 06:08 PST ====================================================================== Summary: The number of files mismatch! after verify? Description: After backup data I do Verify Volume to Catalog. If after that to make again backup data I receive a error, for example: Error: I canot write on Volume "u1-s3-v1" because: The number of files mismatch! Volume=26 Catalog=39 If before new backup I do restart bacula error does not occur and reserve copying passes normally on given volume. ====================================================================== ---------------------------------------------------------------------- kern - 11-23-2004 11:51 PST ---------------------------------------------------------------------- You will need to send me your bacula-dir.conf file (as an attachement), and include the output from your job log -- that is the output from the backup, the subsequent verify, and the output from the job that failed. Please attach that to the bug report as a .txt file. ---------------------------------------------------------------------- ArnoL - 11-23-2004 14:27 PST ---------------------------------------------------------------------- There was a thread on [Bacula-users] Verify error (VolumeToCatalog) after backup starting started Oct. 13. That looks like it's a similar problem - perhaps even the same? Then, Martin Simmons reported something similar with a long discussion with Kern following. That was "Tape with an empty file between sessions". I can't recall how this ended, but I *think* that Martin had some patch and everybody waited if the error was gone. ---------------------------------------------------------------------- gvan - 11-24-2004 01:53 PST ---------------------------------------------------------------------- To kern: I have uploaded necessary files. Inform, if something else is required. In case of need the errror can be tried to repeat once again with other conditions. To ArnoL: If the question is this message http://sourceforge.net/mailarchive/forum.php?thread_id=5755103&forum_id=8833 the given problem completely is solved. But in this case a problem completely another. edited on: 11-24-04 01:53 ---------------------------------------------------------------------- kern - 11-24-2004 09:39 PST ---------------------------------------------------------------------- Thanks for the output. It was *exactly* what I needed to "see" your problem. I haven't been able to duplicate this bug here, and looking at your bacula-sd.conf file, I think the problem is because you have: TWO EOF = yes I'm a bit surprised that btape "test" doesn't detect this. Could you do the following things? 1. Run btape "test" command from version 1.36.1 with your current configuration, and if it works, please send me the output, as it will indicate that my tests are not sufficiently good. 2. Remove the TWO EOF = yes, then run the btape "test" command again, and make sure it succeeds. 3. If http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000002 works, remove the TWO EOF = yes from your Ultrium Device conf (and perhaps also from your DAT Device conf), then run the backup, verify, and backup and see if it succeeds. 4. If http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000003 works, then do the same test again, but stop and restart Bacula after the first backup, then proceed with the other tests. ---------------------------------------------------------------------- gvan - 11-25-2004 00:07 PST ---------------------------------------------------------------------- For a long time in release notes of one of versions or even in the documentation it is told that for FreeBSD it was desirable to establish TWO EOF = yes. Since then it at me also is established in this value. Also at me it is in addition established for tape in start of server: /usr/bin/mt -f /dev/nsa1 seteotmodel 2 /usr/bin/mt -f /dev/nsa1 blocksize 0 /usr/bin/mt -f /dev/nsa0 seteotmodel 2 /usr/bin/mt -f /dev/nsa0 blocksize 0 >1. Run btape "test" command from version 1.36.1 with your current >configuration, and if it works, please send me the output, as it will indicate >that my tests are not sufficiently good. Test works fine. See result in btape-1.txt >2. Remove the TWO EOF = yes, then run the btape "test" command again, and make >sure it succeeds. See result in btape-2_1.txt. Test ends with one error and with one recomendation - "Backward Space Record = No". After I set recomendation test ends without error because read backwards test is skiped (result in btape-2_2.txt) >3. If 0000002 works, remove the TWO EOF = yes from your Ultrium Device conf >(and perhaps also from your DAT Device conf), then run the backup, verify, and >backup and see if it succeeds. Second backup after verify reproduce error (I have interrupted it then since and so it was already visible, that the error has repeated). Results in backup-3.txt, verify-3.txt, backup_next-3.txt. Modified bacula-sd.conf also is attached as bacula-sd.conf-mod Probably all the same it does not solve a problem in this case. Whether there are any else ideas on change of my configuration? ---------------------------------------------------------------------- kern - 11-25-2004 00:52 PST ---------------------------------------------------------------------- Hmm. Sorry, my error. I failed to notice that you are using FreeBSD, which means that in principle the Device configuration you have is correct. Just the same, for me it is a very poor way to run an LTO drive, which is quite intelligent. I would appreciate it if you would try the following Device configuration, which is also mentioned in the manual: Hardware End of Medium = no BSF at EOM = no Backward Space Record = no Backward Space File = no Fast Forward Space File = yes TWO EOF = no I recommend you start with the btape "test" command, and if that works, try the Backup/Verify sequence. If this doesn't work, I think I have an idea where the problem is, but I'll have to work on it after the release 1.36.1 in a few days. ---------------------------------------------------------------------- kern - 11-25-2004 00:56 PST ---------------------------------------------------------------------- Oh, sorry, I forgot to mention that you need to modify your tape drive parameters as follows prior to running with the new test Device configuration: mt -f /dev/nsa0 seteotmodel 1 and keep the other parameters you have already set. ---------------------------------------------------------------------- gvan - 11-25-2004 03:39 PST ---------------------------------------------------------------------- I have changed a configuration (a new file bacula-sd.conf-mod2). Has changed model: # mt -f /dev/nsa0 seteotmodel 1 /dev/nsa0: old model was 2 filemarks at EOT /dev/nsa0: new model is 1 filemark at EOT # mt -f /dev/nsa0 geteotmodel /dev/nsa0: the model is 1 filemark at EOT Has started the test btape (results in btape-4.txt, errors are not present). And has executed backup, verify and the second backup (see results in backup-4.txt, verify-4.txt and backup_next-4.txt). The error is same and has remained former:( ---------------------------------------------------------------------- kern - 12-03-2004 12:16 PST ---------------------------------------------------------------------- I really do not know what is going on here or why the Director thinks there are 4 files Please try yet another experiment. This time, do the following: 1 Do a "llist volume=Vol-name" where Vol-name is the volume you are going to write to, presumably empty. 2 Do the backup. 3 Do a "llist volume=Vol-name" "sql" "select * from JobMedia where JobId=nnn" " " (blank line) where nnn is the JobId of the backup Job. 4 Run the Verify 5 Re-do step 3 6 Run the second backup 5 Re-do step 3 Send me the output from step 1 and the 3 X step 3. Maybe I can see something in it as it looks like something is really out of sync. It looks like the Verify is adding a file. The above info will confirm or not this idea. ---------------------------------------------------------------------- gvan - 12-09-2004 03:09 PST ---------------------------------------------------------------------- I think, that a problem all the same another. Results of the test are in a file output-last.txt. As a result of often tests by me it has been revealed, what even backup of small sizes and then verify some times can cause the following mistake successively: 08-Dec 10:13 x1-sd: Volume "u1-s8-v1" previously written, moving to end of data. 08-Dec 10:13 x1-sd: Ready to append to end of Volume "u1-s8-v1" at file=2. 08-Dec 10:13 x1-sd: End of Volume "u1-s8-v1" at 3:0 on device /dev/nsa0. Write of 64512 bytes got 0. 08-Dec 10:13 x1-sd: End of medium on Volume "u1-s8-v1" Bytes=1,976,947,844 Blocks=30,645 at 08-Dec-2004 10:13. I.e. somehow occurs out of sync quantities of files after backup and the subsequent verifies. And then there is a mistake of record and bacula considers, that the tape is full, though size of a tape about 200 GB. If after each verifies before next backups to do restart bacula the given mistake does not arise. ---------------------------------------------------------------------- kern - 12-16-2004 14:10 PST ---------------------------------------------------------------------- I haven't yet looked at your latest output, but from your notes, it appears that there is some strange bug with the interaction of your OS tape driver and Bacula. Bacula should *never* get an error (as it did in your example) when trying to append to a tape. I'll still look at the output, but my best bet is a bug in the OS or the LTO tape driver that in some cases prohibits appending to a tape or gets a false end of tape when it is really not the end of the tape. If restarting Bacula clears the problem, then it points even more to the OS driver as being in an unstable state. It doesn't prove it, but it makes me lean in that direction. ---------------------------------------------------------------------- Dan Langille - 12-28-2004 06:01 PST ---------------------------------------------------------------------- Are you backing up to tape? FreeBSD 4.9-RELEASE contains a pthreads bug that will result in more data being written to the tape than can be stored on the tape. This problem arises only if the backup spans more than one tape. Did your backup involve more than one tape? If so, the above pthreads issue might explain why your backup held less data than the catalog expected. This bug is easily patched. See platforms/freebsd/pthreads-fix.txt for details. Please ask if you have any questions. ---------------------------------------------------------------------- gvan - 12-28-2004 06:08 PST ---------------------------------------------------------------------- No, I have patched version FreeBSD 4.9 (pthreads bug). The problem arises, even if backup involve one tape. Bug History Date Modified Username Field Change ====================================================================== 11-22-04 23:19 gvan New Bug 11-22-04 23:19 gvan File Added: bacula-sd.conf 11-22-04 23:29 gvan Bug Monitored: gvan 11-23-04 11:51 kern Bugnote Added: 0000472 11-23-04 11:51 kern Status new => feedback 11-23-04 14:27 ArnoL Bugnote Added: 0000475 11-23-04 22:21 gvan File Added: backup.txt 11-23-04 22:21 gvan File Added: verify.txt 11-23-04 22:21 gvan File Added: backup_next.txt 11-23-04 22:22 gvan File Added: bacula-dir.conf 11-23-04 22:29 gvan Bugnote Added: 0000477 11-24-04 01:53 gvan Bugnote Edited: 0000477 11-24-04 09:39 kern Bugnote Added: 0000480 11-25-04 00:02 gvan File Added: btape-1.txt 11-25-04 00:02 gvan File Added: btape-2_1.txt 11-25-04 00:02 gvan File Added: btape-2_2.txt 11-25-04 00:03 gvan File Added: backup-3.txt 11-25-04 00:03 gvan File Added: verify-3.txt 11-25-04 00:04 gvan File Added: backup_next-3.txt 11-25-04 00:04 gvan File Added: bacula-sd.conf-mod 11-25-04 00:07 gvan Bugnote Added: 0000482 11-25-04 00:52 kern Bugnote Added: 0000483 11-25-04 00:56 kern Bugnote Added: 0000484 11-25-04 03:34 gvan File Added: bacula-sd.conf-mod2 11-25-04 03:34 gvan File Added: btape-4.txt 11-25-04 03:34 gvan File Added: backup-4.txt 11-25-04 03:35 gvan File Added: verify-4.txt 11-25-04 03:35 gvan File Added: backup_next-4.txt 11-25-04 03:39 gvan Bugnote Added: 0000485 12-03-04 12:16 kern Bugnote Added: 0000507 12-09-04 03:09 gvan Bugnote Added: 0000536 12-09-04 03:09 gvan File Added: output-last.txt 12-16-04 14:10 kern Bugnote Added: 0000551 12-28-04 06:01 Dan Langille Bugnote Added: 0000591 12-28-04 06:08 gvan Bugnote Added: 0000593 ====================================================================== |
From: <bac...@li...> - 2004-12-28 13:58:02
|
A BUGNOTE has been added to this bug. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000122 ====================================================================== Reported By: bootsy52 Assigned To: ====================================================================== Project: bacula Bug ID: 122 Category: Storage Daemon Reproducibility: always Severity: feature Priority: normal Status: feedback ====================================================================== Date Submitted: 09-24-2004 15:09 PDT Last Modified: 12-28-2004 06:03 PST ====================================================================== Summary: Make bacula server work on OpenBSD Description: I'm now trying quit a long time (from version to version again) to get Bacula on my OpenBSD box running. As Bacula runs on FreeBSD and obviously also on NetBSD I think it must basicly work OpenBSD as well. Because my main server runs OpenBSD it would be more than pleasent if bacula would run on it. The Tape is a DDS-3: HP C1537A, L907 So here is what I got so far: 1. Bacula compiles and installs just fine 2. btape test always fails either on the position test or at the append test (depends on which parameters I've set) With the following parameters it fails at the Write, rewind, position test, resulting in an infinite loop printing "Got EOF on tape." on the screen, directly after processing block 1:600. This refers as far as I found to subroutine read_again() in line 813 btape.c. My guess is that, the EOF found is followed by another EOF Device { Name = DDS-3 # Media Type = DDS-3 Archive Device = /dev/nrst0 AutomaticMount = yes; # when device opened, read it AlwaysOpen = yes; RemovableMedia = yes; RandomAccess = no; } Also setting it to a fixed blocksize with Minimum Block size = 65536 Maximum Block size = 65536 doesn't help, either with this test, nor with the append test ################################################ with the following parameters the postition test is passed, but it fails at the end on the append test with: "We should be in file 3. I am at file 0. This is NOT correct!!!!" Device { Name = DDS-3-BSD Description = "DDS-3 for FreeBSD" Media Type = DDS-3 Archive Device = /dev/nrst0 AutomaticMount = yes; # when device opened, read it AlwaysOpen = yes Offline On Unmount = no Hardware End of Medium = no BSF at EOM = yes Backward Space Record = no Fast Forward Space File = no TWO EOF = yes } ====================================================================== ---------------------------------------------------------------------- kern - 09-25-2004 02:50 PDT ---------------------------------------------------------------------- What I need to proceed is a copy of your man pages that describe the tape interface. They are usually in mtio or st (possibly both). In particular, I need to see the iotcl() calls that are supported, and if they have a description of the different tape modes they have implemented (e.g. variable block vs fixed block, ...). This is a good time to give me the info since I am just in the process of adding OS dependent ioctl()s to Bacula. ---------------------------------------------------------------------- Dan Langille - 09-25-2004 05:58 PDT ---------------------------------------------------------------------- The following URL has online man pages for FreeBSD, OpenBSD, NetBSD, Darwin, BSD386, HP-UX, Slackware, Minix, Red Hat, SuSE, SunOS, and XFree86 http://www.freebsd.org/cgi/man.cgi :) ---------------------------------------------------------------------- bootsy52 - 09-25-2004 08:59 PDT ---------------------------------------------------------------------- I've uploaded the man pages as ascii text files, all manpages are accessible through: http://www.openbsd.org/cgi-bin/man.cgi ---------------------------------------------------------------------- kern - 09-25-2004 13:00 PDT ---------------------------------------------------------------------- Please download the latest CVS 1.35.5 (25Sept04) and try it. If I made any mistakes or typos there may be a problem compiling dev.c. Then use the same parameters as for FreeBSD without the fixed block specifications. Try running btape "test" again. Thanks for the documents. I've deleted those that are not useful. The others I'll leave for possible future reference. ---------------------------------------------------------------------- bootsy52 - 09-25-2004 13:47 PDT ---------------------------------------------------------------------- No new dev.c there on cvs so far. However, I'm impressed how quick this issue resolved. I thought the whole time, that the developers got no first hand on OpenBSD and thus the issue wouldn't be resolved. But from searching, google, the mailinglist. It suddendly seemed to me that no one has tested this on OpenBSD or no one was willing to file a bug report. If I had known this before, I wouldn't have waited a half year testing from version to version seeing if this problem is resolved by chance. Also as I'm subscribed to the OpenBSD mailinglist, I will let the list know, once btape test runs successfully for me. Thanx ---------------------------------------------------------------------- Dan Langille - 09-25-2004 14:24 PDT ---------------------------------------------------------------------- It takes a while to get from the developer CVS to the public CVS. I got it via my login and you can grab it from here: http://beta.freshports.org/tmp/ Just add the file name. ---------------------------------------------------------------------- bootsy52 - 09-25-2004 15:42 PDT ---------------------------------------------------------------------- The Append test still fails with the same error, "We should be in file 3. I am at file 0. This is NOT correct!!!!" is dev.c the only new file needed or are there more ? The compilation went cleanly besides this two warnings which given during the build of section === lib ===. Don't know if they are to see on OpenBSD only. # 1 message.c: In function `void my_name_is(int, char **, const char *)': message.c:151: warning: array size (400) is smaller than minimum required (1024) message.c:153: warning: array size (400) is smaller than minimum required (1024) # 2 address_conf.c: In function `int sockaddr_to_ascii(const sockaddr *, char *, int)': address_conf.c:544: warning: sizeof(pointer) possibly incorrect in argument 4 I looked at dev.c (also I'm not yet a C Programmer) I found the comment in line 763. From past experiences I made with AFbackup, I've seen the symptom that when AFbackup ran and there was no tape in the drive. I got an I/O Error on every attempt to access the drive later on and the only resolution was to reboot the machine to have access to the tape drive again. Do I get it right, that the workaround there is meant exactly for cases like this ? ---------------------------------------------------------------------- Dan Langille - 09-25-2004 18:22 PDT ---------------------------------------------------------------------- The latest dev.c is now available via anonymous cvs. ---------------------------------------------------------------------- bootsy52 - 09-25-2004 18:34 PDT ---------------------------------------------------------------------- I've done complete checkout, but the error is still the same in the "Append" test. I've verified the version of dev.c and it is newest 1.90 I'm able to provide access to a OpenBSD box to you on next Friday. As I got a tape drive lying around here, and we got a few Pentium comuters lyning around in the company, which I could install OpenBSD on. ---------------------------------------------------------------------- kern - 09-26-2004 01:32 PDT ---------------------------------------------------------------------- Could you post the following things: 1. Your bacula-sd.conf file 2. The complete output from btape "test" showing the failure Thanks for pointing out the compile problems. I've fixed them as they were potential problems, but not in this case. In the btest case, you should start with a tape in the drive to void any secondary problems as you mention with AFBackup. As far as I know, Bacula should not hang or cause a system hang if no tape is initially in the drive, but this needs verification. The changes I've recently made are meant to put the drive in variable block mode so that it can properly forward space. I'm still in the process of implementing the improvements. The results of your above test should help me. ---------------------------------------------------------------------- bootsy52 - 09-26-2004 07:58 PDT ---------------------------------------------------------------------- I've uploaded the complete output of btape test and also bacula-sd.conf with the password string removed. I have always tested for the moment with a tape in the drive, for exactly the reason you mention. BTW, my way of solving the first compile warning in message.c was to simply set cpath[1024] and npath[1024] ;-) ---------------------------------------------------------------------- kern - 09-27-2004 05:20 PDT ---------------------------------------------------------------------- Well, you are going to have to play with the Device resource a bit to get it to work. The fact that the positioning test is successful is very encouraging. I'd recommend that you start with a Device resource the same as the one you have for DDS-3 (Solaris/Linux) and see what happens. The depending on the results, the test may automatically try a few variations -- otherwise, you will need to do it one step at a time depending on the failure. ---------------------------------------------------------------------- bootsy52 - 09-27-2004 05:26 PDT ---------------------------------------------------------------------- OK, the plain DDS-3 Resource runs into an endless loop printing "Got EOF on tape." on the screen as mentioned in the initial bugreport. I'll try out further with changing parameters. ---------------------------------------------------------------------- kern - 09-27-2004 05:34 PDT ---------------------------------------------------------------------- Add the -d200 option to btape when you run it. That may give you a better idea what is going on, and maybe not. ---------------------------------------------------------------------- bootsy52 - 09-27-2004 06:07 PDT ---------------------------------------------------------------------- With the latest CVS checkout (26-September-2004) I couldn't run any test anymore, with either configuration. The error is: btape: butil.c:258 Using device: "DDS-3" for writing. btape: dev.c:215 init_dev: tape=1 dev_name=/dev/nrst0 btape: block.c:122 Returning new block=3c034128 btape: device.c:265 start open_output_device() btape: device.c:286 Opening device. btape: dev.c:255 open_dev: tape=1 dev_name=/dev/nrst0 vol= btape: dev.c:259 open_dev: device is tape btape: dev.c:308 open_dev: tape 5 opened btape: device.c:293 open_dev /dev/nrst0 OK btape: butil.c:170 Device opened for read. btape: block.c:122 Returning new block=3c034428 btape: btape.c:335 open_dev /dev/nrst0 OK btape: block.c:159 free_block buffer 3c05c028 btape: block.c:161 free_block block 3c034428 btape: btape.c:269 Do tape commands [ ... === Write, rewind, and re-read test === ... ] btape: btape Fatal error: Attempt to write on read-only Volume. btape: btape.c:778 Error writing block to device. but tar c /etc for example works just fine, and I verified despite of that that the tape is not write locked. ---------------------------------------------------------------------- kern - 09-27-2004 14:54 PDT ---------------------------------------------------------------------- Sorry, the btape problems are my error. Please try pulling the latest CVS. I forgot to update btape to work with the new device drivers. I've patched btape to work for the "test" command, but there are still other commands such as "fill" that are badly broken. ---------------------------------------------------------------------- bootsy52 - 09-28-2004 09:38 PDT ---------------------------------------------------------------------- I'm still not able to test any setup on the tape, the error I got is (tar works just fine) also btape clear does not help. btape: dev.c:371 rewind_dev /dev/nrst0 btape: block.c:429 binbuf=64448 buf_len=64512 btape: btape Error: block.c:552 Write error at 0:0 on device /dev/nrst0. ERR=Input/output error. btape: block.c:563 === Write error. size=64512 rtn=-1 dev_blk=0 blk_blk=0 errno=5: ERR=Input/output error btape: dev.c:1164 weof_dev btape: block.c:686 dir_update_volume_info terminate writing -- OK btape: block.c:711 Leave terminate_writing_volume -- OK btape: dev.c:965 bsf_dev btape: dev.c:1069 bsr_dev btape: btape Error: Backspace record at EOT failed. ERR=Input/output error btape: btape.c:779 Error writing block to device. ---------------------------------------------------------------------- bootsy52 - 09-28-2004 09:40 PDT ---------------------------------------------------------------------- And when I use the BSD config then I get: btape: dev.c:371 rewind_dev /dev/nrst0 btape: block.c:429 binbuf=64448 buf_len=64512 btape: btape Error: block.c:552 Write error at 0:0 on device /dev/nrst0. ERR=Input/output error. btape: block.c:563 === Write error. size=64512 rtn=-1 dev_blk=0 blk_blk=0 errno=5: ERR=Input/output error btape: dev.c:1164 weof_dev btape: block.c:686 dir_update_volume_info terminate writing -- OK btape: dev.c:1164 weof_dev btape: block.c:711 Leave terminate_writing_volume -- OK btape: btape.c:779 Error writing block to device. ---------------------------------------------------------------------- kern - 09-28-2004 10:32 PDT ---------------------------------------------------------------------- Please run a tar, then a btape test command, and post the complete output of both here. There is something wrong if Bacula is getting I/O errors. It may be a question of maximum buffer sizes or something. Another thing to do is to start doing the 9 steps outlined in the Testing chapter of the manual. Please save the output from each step, and when you cannot make a step work, then post everything to this bug report. That will allow us to proceed step by step. ---------------------------------------------------------------------- kern - 10-04-2004 07:50 PDT ---------------------------------------------------------------------- I believe that Bacula can support OpenBSD in version 1.35.7, but I am unable to test it. If there are problems, please re-report. ---------------------------------------------------------------------- bootsy52 - 10-04-2004 17:49 PDT ---------------------------------------------------------------------- Tested today again with 1.35.8, but works less then before still Input/Output Errors, I'm in the process of doing steps 1.. 9 of the tape manual, but due to that I had Exams last week I was too busy to complete them. The results are so far, that 1. btape test => Input/Output Error 2. btape fill => Input/Output Error 3. mt -f /dev/nrst0 erase => Succeeds 4. tar cvf /dev/nrst0 /etc => Succeeds I'll give full details once I complete them all ---------------------------------------------------------------------- bootsy52 - 10-17-2004 16:22 PDT ---------------------------------------------------------------------- I've done cvs update today, but the error is still the same, tar, mt and the like work as expected, no errors. The uploaded file shows btape test with debugging option -d200. Also btape fill fails, I can provide you with details on that also ---------------------------------------------------------------------- kern - 10-18-2004 08:43 PDT ---------------------------------------------------------------------- Without the details of the btape "test" command, I cannot proceed. ---------------------------------------------------------------------- bootsy52 - 10-18-2004 10:34 PDT ---------------------------------------------------------------------- Hmmh, how could I give more details than in the attached file "Bacula-btape", which is btape test called with -d200 ??? ---------------------------------------------------------------------- kern - 10-18-2004 11:53 PDT ---------------------------------------------------------------------- Sorry, I failed to notice that you uploaded a file and that you mentioned it in your bugnote. The only way we are going to make this work is if I have access to an OpenBSD system since I have no idea why it is getting an I/O error, and it will take a lot of "playing around" to figure it out. Can you provide me ssh access to some system with an available tape drive? ---------------------------------------------------------------------- bootsy52 - 10-19-2004 09:07 PDT ---------------------------------------------------------------------- Kern, can you see my e-mail address from mantis ? If so mail me, so I'll give you ssh access ---------------------------------------------------------------------- bootsy52 - 10-19-2004 11:02 PDT ---------------------------------------------------------------------- Hi Kern, this seems to be the same problem I've experienced with AFbackup, despite of that I could do all stuff using tar and mt, I decided to reboot the machine, to exclude that it is not the same phenomen. After rebooting, the Input/Output Error is gone away, however the Append test still fails. I'm now trying out out different options ---------------------------------------------------------------------- kern - 10-19-2004 12:19 PDT ---------------------------------------------------------------------- Well, I'm happy to hear that Bacula isn't the only backup program to have problems. I could probably look through all the admin lists and find your email, but it is easier for you to email me at: kern at sibbald dot com or put your email address in one of these bug notes the same way. If you know how to set up a ssh login, below is my ssh public key. I prefer to login as kern, do not need root as long as you all me to access the tape drive, or put me in the group, or something similar. I'll need 80-100 MB of disk, and the standard stuff to build Bacula. If you have troubles setting up an ssh login directly, just send me the site address IP or domain name, my userid, and password, and I'll fix it to go in by ssh. ====== kern's public key ==== ssh-dss AAAAB3NzaC1kc3MAAACBAMUYzep4on+l/Yuf+pPixk8bRIQzeUe+4SuDonjJjV0Zc42u9w6u1vAZe8U9c04vraiXHysq510gmtfbq7T9feqnolfrwROWtb0+DGIoYG4d3GbgVBHY+6f6W2zb2+wrsA5tmeRFBD45AMBz5u20WEZ8p1Wcy2xms02av+0FeUVZAAAAFQCjVnz31coZzA5bm3sBe9wIDplh6wAAAIEAntKIZSn/Up/s652FCOe3PAtHZISr/UW2PFiA3Yumefg0xFA0cfIGIaaMj0U4dheU1il5zVeIfTcxi0RTXdYKLCMxgLAjGLjONbnKJYrEXshZNwNKkRMHMMLTbzL0O0XqRVAg/h9rXN/identqQ/ULzMzP3zyNgCNF7GFOgTyLegAAACBAKwFpQ9SvMaOh3lKnl0gH3+AlHTE/DnWVD5bsp20CyhC6KSkN9zGwan+38wuR1TqqM7WYhjErLfnkt44POOylbzPMIu1UaDm+d8jLV6SKfnDGdSSs208ZutALXSlV0jL49VBqm+HtsYlVCjQ3rMIbsICa+kY7B/NQGxrIFZ+Bqaz ke...@ru... ==== end public key === It should all be on one line ---------------------------------------------------------------------- Dan Langille - 12-28-2004 06:03 PST ---------------------------------------------------------------------- Kern: Did you get access to an OpenBSD system? If not, I'm sure we can arrange it. Bug History Date Modified Username Field Change ====================================================================== 09-24-04 15:09 bootsy52 New Bug 09-24-04 15:09 bootsy52 File Added: scsi_tape.h 09-25-04 02:50 kern Bugnote Added: 0000284 09-25-04 02:50 kern Status new => feedback 09-25-04 05:58 Dan Langille Bugnote Added: 0000286 09-25-04 08:57 bootsy52 File Added: mtio.4.txt 09-25-04 08:57 bootsy52 File Added: ioctl.2.txt 09-25-04 08:57 bootsy52 File Added: scsi.4.txt 09-25-04 08:58 bootsy52 File Added: st.4.txt 09-25-04 08:58 bootsy52 File Added: mtio.h 09-25-04 08:59 bootsy52 Bugnote Added: 0000287 09-25-04 12:56 kern File Deleted: scsi_tape.h 09-25-04 12:56 kern File Deleted: mtio.4.txt 09-25-04 12:56 kern File Deleted: ioctl.2.txt 09-25-04 12:56 kern File Deleted: scsi.4.txt 09-25-04 13:00 kern Bugnote Added: 0000291 09-25-04 13:47 bootsy52 Bugnote Added: 0000292 09-25-04 14:24 Dan Langille Bugnote Added: 0000293 09-25-04 15:42 bootsy52 Bugnote Added: 0000294 09-25-04 18:22 Dan Langille Bugnote Added: 0000295 09-25-04 18:34 bootsy52 Bugnote Added: 0000296 09-26-04 01:32 kern Bugnote Added: 0000297 09-26-04 07:54 bootsy52 File Added: btape.out 09-26-04 07:55 bootsy52 File Added: bacula-sd.conf 09-26-04 07:58 bootsy52 Bugnote Added: 0000299 09-27-04 05:20 kern Bugnote Added: 0000306 09-27-04 05:26 bootsy52 Bugnote Added: 0000307 09-27-04 05:34 kern Bugnote Added: 0000309 09-27-04 06:07 bootsy52 Bugnote Added: 0000311 09-27-04 14:54 kern Bugnote Added: 0000313 09-28-04 09:38 bootsy52 Bugnote Added: 0000316 09-28-04 09:40 bootsy52 Bugnote Added: 0000317 09-28-04 10:32 kern Bugnote Added: 0000319 10-04-04 07:50 kern Bugnote Added: 0000342 10-04-04 07:50 kern Resolution open => fixed 10-04-04 07:50 kern Status feedback => closed 10-04-04 17:49 bootsy52 Bugnote Added: 0000346 10-04-04 17:49 bootsy52 Resolution fixed => reopened 10-04-04 17:49 bootsy52 Status closed => feedback 10-17-04 16:20 bootsy52 File Added: Bacula-btape 10-17-04 16:22 bootsy52 Bugnote Added: 0000371 10-18-04 08:43 kern Bugnote Added: 0000377 10-18-04 10:34 bootsy52 Bugnote Added: 0000378 10-18-04 11:53 kern Bugnote Added: 0000380 10-19-04 09:07 bootsy52 Bugnote Added: 0000390 10-19-04 11:02 bootsy52 Bugnote Added: 0000391 10-19-04 12:19 kern Bugnote Added: 0000392 12-28-04 06:03 Dan Langille Bugnote Added: 0000592 ====================================================================== |
From: <bac...@li...> - 2004-12-28 13:56:23
|
A BUGNOTE has been added to this bug. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000173 ====================================================================== Reported By: gvan Assigned To: ====================================================================== Project: bacula Bug ID: 173 Category: Director Reproducibility: always Severity: major Priority: normal Status: feedback ====================================================================== Date Submitted: 11-22-2004 23:19 PST Last Modified: 12-28-2004 06:01 PST ====================================================================== Summary: The number of files mismatch! after verify? Description: After backup data I do Verify Volume to Catalog. If after that to make again backup data I receive a error, for example: Error: I canot write on Volume "u1-s3-v1" because: The number of files mismatch! Volume=26 Catalog=39 If before new backup I do restart bacula error does not occur and reserve copying passes normally on given volume. ====================================================================== ---------------------------------------------------------------------- kern - 11-23-2004 11:51 PST ---------------------------------------------------------------------- You will need to send me your bacula-dir.conf file (as an attachement), and include the output from your job log -- that is the output from the backup, the subsequent verify, and the output from the job that failed. Please attach that to the bug report as a .txt file. ---------------------------------------------------------------------- ArnoL - 11-23-2004 14:27 PST ---------------------------------------------------------------------- There was a thread on [Bacula-users] Verify error (VolumeToCatalog) after backup starting started Oct. 13. That looks like it's a similar problem - perhaps even the same? Then, Martin Simmons reported something similar with a long discussion with Kern following. That was "Tape with an empty file between sessions". I can't recall how this ended, but I *think* that Martin had some patch and everybody waited if the error was gone. ---------------------------------------------------------------------- gvan - 11-24-2004 01:53 PST ---------------------------------------------------------------------- To kern: I have uploaded necessary files. Inform, if something else is required. In case of need the errror can be tried to repeat once again with other conditions. To ArnoL: If the question is this message http://sourceforge.net/mailarchive/forum.php?thread_id=5755103&forum_id=8833 the given problem completely is solved. But in this case a problem completely another. edited on: 11-24-04 01:53 ---------------------------------------------------------------------- kern - 11-24-2004 09:39 PST ---------------------------------------------------------------------- Thanks for the output. It was *exactly* what I needed to "see" your problem. I haven't been able to duplicate this bug here, and looking at your bacula-sd.conf file, I think the problem is because you have: TWO EOF = yes I'm a bit surprised that btape "test" doesn't detect this. Could you do the following things? 1. Run btape "test" command from version 1.36.1 with your current configuration, and if it works, please send me the output, as it will indicate that my tests are not sufficiently good. 2. Remove the TWO EOF = yes, then run the btape "test" command again, and make sure it succeeds. 3. If http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000002 works, remove the TWO EOF = yes from your Ultrium Device conf (and perhaps also from your DAT Device conf), then run the backup, verify, and backup and see if it succeeds. 4. If http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000003 works, then do the same test again, but stop and restart Bacula after the first backup, then proceed with the other tests. ---------------------------------------------------------------------- gvan - 11-25-2004 00:07 PST ---------------------------------------------------------------------- For a long time in release notes of one of versions or even in the documentation it is told that for FreeBSD it was desirable to establish TWO EOF = yes. Since then it at me also is established in this value. Also at me it is in addition established for tape in start of server: /usr/bin/mt -f /dev/nsa1 seteotmodel 2 /usr/bin/mt -f /dev/nsa1 blocksize 0 /usr/bin/mt -f /dev/nsa0 seteotmodel 2 /usr/bin/mt -f /dev/nsa0 blocksize 0 >1. Run btape "test" command from version 1.36.1 with your current >configuration, and if it works, please send me the output, as it will indicate >that my tests are not sufficiently good. Test works fine. See result in btape-1.txt >2. Remove the TWO EOF = yes, then run the btape "test" command again, and make >sure it succeeds. See result in btape-2_1.txt. Test ends with one error and with one recomendation - "Backward Space Record = No". After I set recomendation test ends without error because read backwards test is skiped (result in btape-2_2.txt) >3. If 0000002 works, remove the TWO EOF = yes from your Ultrium Device conf >(and perhaps also from your DAT Device conf), then run the backup, verify, and >backup and see if it succeeds. Second backup after verify reproduce error (I have interrupted it then since and so it was already visible, that the error has repeated). Results in backup-3.txt, verify-3.txt, backup_next-3.txt. Modified bacula-sd.conf also is attached as bacula-sd.conf-mod Probably all the same it does not solve a problem in this case. Whether there are any else ideas on change of my configuration? ---------------------------------------------------------------------- kern - 11-25-2004 00:52 PST ---------------------------------------------------------------------- Hmm. Sorry, my error. I failed to notice that you are using FreeBSD, which means that in principle the Device configuration you have is correct. Just the same, for me it is a very poor way to run an LTO drive, which is quite intelligent. I would appreciate it if you would try the following Device configuration, which is also mentioned in the manual: Hardware End of Medium = no BSF at EOM = no Backward Space Record = no Backward Space File = no Fast Forward Space File = yes TWO EOF = no I recommend you start with the btape "test" command, and if that works, try the Backup/Verify sequence. If this doesn't work, I think I have an idea where the problem is, but I'll have to work on it after the release 1.36.1 in a few days. ---------------------------------------------------------------------- kern - 11-25-2004 00:56 PST ---------------------------------------------------------------------- Oh, sorry, I forgot to mention that you need to modify your tape drive parameters as follows prior to running with the new test Device configuration: mt -f /dev/nsa0 seteotmodel 1 and keep the other parameters you have already set. ---------------------------------------------------------------------- gvan - 11-25-2004 03:39 PST ---------------------------------------------------------------------- I have changed a configuration (a new file bacula-sd.conf-mod2). Has changed model: # mt -f /dev/nsa0 seteotmodel 1 /dev/nsa0: old model was 2 filemarks at EOT /dev/nsa0: new model is 1 filemark at EOT # mt -f /dev/nsa0 geteotmodel /dev/nsa0: the model is 1 filemark at EOT Has started the test btape (results in btape-4.txt, errors are not present). And has executed backup, verify and the second backup (see results in backup-4.txt, verify-4.txt and backup_next-4.txt). The error is same and has remained former:( ---------------------------------------------------------------------- kern - 12-03-2004 12:16 PST ---------------------------------------------------------------------- I really do not know what is going on here or why the Director thinks there are 4 files Please try yet another experiment. This time, do the following: 1 Do a "llist volume=Vol-name" where Vol-name is the volume you are going to write to, presumably empty. 2 Do the backup. 3 Do a "llist volume=Vol-name" "sql" "select * from JobMedia where JobId=nnn" " " (blank line) where nnn is the JobId of the backup Job. 4 Run the Verify 5 Re-do step 3 6 Run the second backup 5 Re-do step 3 Send me the output from step 1 and the 3 X step 3. Maybe I can see something in it as it looks like something is really out of sync. It looks like the Verify is adding a file. The above info will confirm or not this idea. ---------------------------------------------------------------------- gvan - 12-09-2004 03:09 PST ---------------------------------------------------------------------- I think, that a problem all the same another. Results of the test are in a file output-last.txt. As a result of often tests by me it has been revealed, what even backup of small sizes and then verify some times can cause the following mistake successively: 08-Dec 10:13 x1-sd: Volume "u1-s8-v1" previously written, moving to end of data. 08-Dec 10:13 x1-sd: Ready to append to end of Volume "u1-s8-v1" at file=2. 08-Dec 10:13 x1-sd: End of Volume "u1-s8-v1" at 3:0 on device /dev/nsa0. Write of 64512 bytes got 0. 08-Dec 10:13 x1-sd: End of medium on Volume "u1-s8-v1" Bytes=1,976,947,844 Blocks=30,645 at 08-Dec-2004 10:13. I.e. somehow occurs out of sync quantities of files after backup and the subsequent verifies. And then there is a mistake of record and bacula considers, that the tape is full, though size of a tape about 200 GB. If after each verifies before next backups to do restart bacula the given mistake does not arise. ---------------------------------------------------------------------- kern - 12-16-2004 14:10 PST ---------------------------------------------------------------------- I haven't yet looked at your latest output, but from your notes, it appears that there is some strange bug with the interaction of your OS tape driver and Bacula. Bacula should *never* get an error (as it did in your example) when trying to append to a tape. I'll still look at the output, but my best bet is a bug in the OS or the LTO tape driver that in some cases prohibits appending to a tape or gets a false end of tape when it is really not the end of the tape. If restarting Bacula clears the problem, then it points even more to the OS driver as being in an unstable state. It doesn't prove it, but it makes me lean in that direction. ---------------------------------------------------------------------- Dan Langille - 12-28-2004 06:01 PST ---------------------------------------------------------------------- Are you backing up to tape? FreeBSD 4.9-RELEASE contains a pthreads bug that will result in more data being written to the tape than can be stored on the tape. This problem arises only if the backup spans more than one tape. Did your backup involve more than one tape? If so, the above pthreads issue might explain why your backup held less data than the catalog expected. This bug is easily patched. See platforms/freebsd/pthreads-fix.txt for details. Please ask if you have any questions. Bug History Date Modified Username Field Change ====================================================================== 11-22-04 23:19 gvan New Bug 11-22-04 23:19 gvan File Added: bacula-sd.conf 11-22-04 23:29 gvan Bug Monitored: gvan 11-23-04 11:51 kern Bugnote Added: 0000472 11-23-04 11:51 kern Status new => feedback 11-23-04 14:27 ArnoL Bugnote Added: 0000475 11-23-04 22:21 gvan File Added: backup.txt 11-23-04 22:21 gvan File Added: verify.txt 11-23-04 22:21 gvan File Added: backup_next.txt 11-23-04 22:22 gvan File Added: bacula-dir.conf 11-23-04 22:29 gvan Bugnote Added: 0000477 11-24-04 01:53 gvan Bugnote Edited: 0000477 11-24-04 09:39 kern Bugnote Added: 0000480 11-25-04 00:02 gvan File Added: btape-1.txt 11-25-04 00:02 gvan File Added: btape-2_1.txt 11-25-04 00:02 gvan File Added: btape-2_2.txt 11-25-04 00:03 gvan File Added: backup-3.txt 11-25-04 00:03 gvan File Added: verify-3.txt 11-25-04 00:04 gvan File Added: backup_next-3.txt 11-25-04 00:04 gvan File Added: bacula-sd.conf-mod 11-25-04 00:07 gvan Bugnote Added: 0000482 11-25-04 00:52 kern Bugnote Added: 0000483 11-25-04 00:56 kern Bugnote Added: 0000484 11-25-04 03:34 gvan File Added: bacula-sd.conf-mod2 11-25-04 03:34 gvan File Added: btape-4.txt 11-25-04 03:34 gvan File Added: backup-4.txt 11-25-04 03:35 gvan File Added: verify-4.txt 11-25-04 03:35 gvan File Added: backup_next-4.txt 11-25-04 03:39 gvan Bugnote Added: 0000485 12-03-04 12:16 kern Bugnote Added: 0000507 12-09-04 03:09 gvan Bugnote Added: 0000536 12-09-04 03:09 gvan File Added: output-last.txt 12-16-04 14:10 kern Bugnote Added: 0000551 12-28-04 06:01 Dan Langille Bugnote Added: 0000591 ====================================================================== |
From: <bac...@li...> - 2004-12-28 13:50:05
|
A BUGNOTE has been added to this bug. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000187 ====================================================================== Reported By: rmenzing Assigned To: ====================================================================== Project: bacula Bug ID: 187 Category: bconsole Reproducibility: always Severity: major Priority: normal Status: feedback ====================================================================== Date Submitted: 12-01-2004 08:23 PST Last Modified: 12-28-2004 05:55 PST ====================================================================== Summary: No Restore possibe Description: I want to restore a file called "Bewerbungen - Kösling AG - Hr.Hohberger.xls" the file will be restored alway with the size 0 Bytes. In the restore menu i can see the file with the correct size. I mark the file with mark "Bewerbungen - K*" in the directory. ====================================================================== ---------------------------------------------------------------------- kern - 12-01-2004 15:09 PST ---------------------------------------------------------------------- I suspect that you are having a code page problem with accented characters. With the information that you have provided, there is nothing that I can do. Possibly the best solution is for you to use the wx-windows program that graphically shows the files. ---------------------------------------------------------------------- rmenzing - 12-03-2004 01:57 PST ---------------------------------------------------------------------- Hello Kern, i have tried to restore the file with the windows client, but the same thing happens. The file will be restored with the size 0 bytes. Do you have a idea what i can do to get the file back? Thanks Richard ---------------------------------------------------------------------- kern - 12-03-2004 02:53 PST ---------------------------------------------------------------------- My suggestion was to use wx-windows, which is a console program that runs on Unix systems. It is a graphical interface and not related to a Windows client. Why are you talking about a Windows client? I am unable to answer your question about getting the file back because I am having trouble understanding the problem. At first, I thought you were having a problem *selecting* the file. Now, you are indicating that you can select it but it is restored as a zero size file? So, I am confused. To go further, I need actual console output that shows what you are doing, what file you selected, and a "dir" type listing of the file in the catalog, and how the file is restored, including the output of the Bacula restore job. If you include any attachments, please upload them as <some-filename>.txt so that they can be read online. ---------------------------------------------------------------------- rmenzing - 12-12-2004 03:47 PST ---------------------------------------------------------------------- Hello Kern, i tried a restore with the wx-console but there is the same result. The restored file has the size 0Byte. After i restored the file with the following statements cd /etc/bacula include-list /home/sheidrich/Excel bextract -i include-list -V Daily01 /data/baculastore /tmp now it was possible to restore the file correct. Thanks Richard ---------------------------------------------------------------------- Dan Langille - 12-28-2004 05:55 PST ---------------------------------------------------------------------- So is everyone happy now? Is there anything more to resolve with this bug? Bug History Date Modified Username Field Change ====================================================================== 12-01-04 08:23 rmenzing New Bug 12-01-04 15:09 kern Bugnote Added: 0000492 12-01-04 15:09 kern Status new => feedback 12-02-04 07:26 rmenzing Bug Monitored: rmenzing 12-03-04 01:57 rmenzing Bugnote Added: 0000502 12-03-04 02:53 kern Bugnote Added: 0000503 12-12-04 03:47 rmenzing Bugnote Added: 0000539 12-28-04 05:55 Dan Langille Bugnote Added: 0000590 ====================================================================== |
From: <bac...@li...> - 2004-12-24 10:30:25
|
The following bug has been CLOSED ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000205 ====================================================================== Reported By: chemical Assigned To: ====================================================================== Project: bacula Bug ID: 205 Category: Storage Daemon Reproducibility: always Severity: major Priority: normal Status: closed ====================================================================== Date Submitted: 12-16-2004 07:57 PST Last Modified: 12-24-2004 02:35 PST ====================================================================== Summary: I am not able to restore files from backups Description: I have an autochanger with 10 LTOs connected to a Celeron Machine. btape test run through successfully on all tests. ====================================================================== ---------------------------------------------------------------------- kern - 12-16-2004 14:01 PST ---------------------------------------------------------------------- The job is not list 5 times in the database, there are just 5 tape files associated with the job. This is not a problem. Please attach include the *full* listing of how you were restoring your files. In the partial listing you include, I don't see that you selected any files. Also, please attach your bootstrap file (restore.bsr), but as restore.bsr.txt. ---------------------------------------------------------------------- chemical - 12-17-2004 00:27 PST ---------------------------------------------------------------------- Ok, lets do it again Sam: Stopped bacula, empty'd /var/bacula. Erased all tapes (again). Here are the job definitions of the client which will be saved+restored: -- JobDefs { Name = "ueun47Job" Type = Backup Level = Incremental Client = ueun47-fd FileSet = "Full Set ueun47" Schedule = "FlexCycle" Storage = LTO-10way Messages = Standard Pool = Default Priority = 10 } Job { Name = "ueun47" JobDefs = "ueun47Job" Write Bootstrap = "/var/bacula/ueun47.bsr" } FileSet { Name = "Full Set ueun47" Include { Options { signature = MD5 } File = / File = /home File = /usr File = /var File = /boot } Exclude { File = /proc File = /tmp File = /.journal File = /.fsck } } Client { Name = ueun47-fd Address = ueun47 FDPort = 9102 Catalog = MyCatalog Password = "xxx" # password for FileDaemon File Retention = 30 days # 30 days Job Retention = 3 months # six months AutoPrune = yes # Prune expired Jobs/Files } -- Now recreated bacula database+tables. Started bacula, "label barcodes" -> OK, all 10 Media label'd and added to Pool 'Default' Now, 'run': Select Job resource: ueun47 Run Backup job JobName: ueun47 FileSet: Full Set ueun47 Level: Incremental Client: ueun47-fd Storage: LTO-10way Pool: Default When: 2004-12-17 08:36:25 Priority: 10 OK to run? (yes/mod/no): yes ...... (no prior backup found, upgraded to full backup, loaded media 1, backupped all files) -- Backup OK, here is the log: -- 17-Dec 08:36 ueun47-dir: Created new FileSet record "Full Set ueun47" 2004-12-17 08:36:45 17-Dec 08:36 ueun47-dir: No prior Full backup Job record found. 17-Dec 08:36 ueun47-dir: No prior or suitable Full backup found. Doing FULL backup. 17-Dec 08:36 ueun47-dir: Start Backup JobId 1, Job=ueun47.2004-12-17_08.36.43 17-Dec 08:36 ueun47-sd: 3301 Issuing autochanger "loaded drive 0" command. 17-Dec 08:36 ueun47-sd: 3302 Autochanger "loaded drive 0", result is Slot 10. 17-Dec 08:36 ueun47-sd: 3303 Issuing autochanger "unload slot 10, drive 0" command. 17-Dec 08:37 ueun47-sd: 3304 Issuing autochanger "load slot 1, drive 0" command. 17-Dec 08:37 ueun47-sd: 3305 Autochanger "load slot 1, drive 0", status is OK. 17-Dec 08:38 ueun47-sd: Wrote label to prelabeled Volume "Volume01" on device "/dev/nst0" 17-Dec 09:00 ueun47-dir: Bacula 1.36.1 (24Nov04): 17-Dec-2004 09:00:13 JobId: 1 Job: ueun47.2004-12-17_08.36.43 Backup Level: Full (upgraded from Incremental) Client: ueun47-fd FileSet: "Full Set ueun47" 2004-12-17 08:36:45 Pool: "Default" Storage: "LTO-10way" Start time: 17-Dec-2004 08:36:45 End time: 17-Dec-2004 09:00:13 FD Files Written: 252,742 SD Files Written: 252,742 FD Bytes Written: 3,986,435,774 SD Bytes Written: 4,019,105,767 Rate: 2831.3 KB/s Software Compression: None Volume name(s): Volume01 Volume Session Id: 1 Volume Session Time: 1103267392 Last Volume Bytes: 4,030,576,870 Non-fatal FD errors: 0 SD Errors: 0 FD termination status: OK SD termination status: OK Termination: Backup OK 17-Dec 09:00 ueun47-dir: Begin pruning Jobs. 17-Dec 09:00 ueun47-dir: No Jobs found to prune. 17-Dec 09:00 ueun47-dir: Begin pruning Files. 17-Dec 09:00 ueun47-dir: No Files found to prune. 17-Dec 09:00 ueun47-dir: End auto prune. --- verify: * list jobs +-------+--------+---------------------+------+-------+----------+---------------+-----------+ | JobId | Name | StartTime | Type | Level | JobFiles | JobBytes | JobStatus | +-------+--------+---------------------+------+-------+----------+---------------+-----------+ | 1 | ueun47 | 2004-12-17 08:36:45 | B | F | 252,742 | 3,986,435,774 | T | +-------+--------+---------------------+------+-------+----------+---------------+-----------+ -- this is ok. now we're restoring from the backup: *restore To select the JobIds, you have the following choices: 1: List last 20 Jobs run 2: List Jobs where a given File is saved 3: Enter list of comma separated JobIds to select 4: Enter SQL list command 5: Select the most recent backup for a client 6: Select backup for a client before a specified time 7: Enter a list of files to restore 8: Enter a list of files to restore before a specified time 9: Cancel Select item: (1-9): 5 Automatically selected Client: ueun47-fd Automatically selected FileSet: Full Set ueun47 +-------+-------+----------+---------------------+------------+-----------+--------------+----------------+ | 1 | F | 252,742 | 2004-12-17 08:36:45 | Volume01 | 0 | 1 | 1,103,267,392 | | 1 | F | 252,742 | 2004-12-17 08:36:45 | Volume01 | 1 | 1 | 1,103,267,392 | | 1 | F | 252,742 | 2004-12-17 08:36:45 | Volume01 | 2 | 1 | 1,103,267,392 | | 1 | F | 252,742 | 2004-12-17 08:36:45 | Volume01 | 3 | 1 | 1,103,267,392 | | 1 | F | 252,742 | 2004-12-17 08:36:45 | Volume01 | 4 | 1 | 1,103,267,392 | +-------+-------+----------+---------------------+------------+-----------+--------------+----------------+ You have selected the following JobId: 1 Building directory tree for JobId 1 ... +++++++++++++++++++++++++++++++++++++++++++++++ 1 Job, 239,555 files inserted into the tree. You are now entering file selection mode where you add (mark) and remove (unmark) files to be restored. No files are initially added, unless you used the "all" keyword on the command line. Enter "done" to leave this mode. cwd is: / $ cd usr cwd is: /usr/ $ mark local 63 files marked. $ cd /home cwd is: /home/ $ mark roland 23 files marked. $ done Bootstrap records written to /var/bacula/restore.bsr The job will require the following Volumes: Volume01 86 files selected to be restored. Run Restore job JobName: RestoreFiles Bootstrap: /var/bacula/restore.bsr Where: / Replace: always FileSet: Full Set ueun47 Client: ueun47-fd Storage: LTO-10way When: 2004-12-17 09:03:25 Catalog: MyCatalog Priority: 10 OK to run? (yes/mod/no): (modified where from / to /tmp/test-restore) started job. Job started. JobId=2 .... Job told me, Restore OK: -- 17-Dec 09:04 ueun47-dir: Start Restore Job RestoreFiles.2004-12-17_09.04.15 17-Dec 09:06 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 17-Dec 09:06 ueun47-sd: Forward spacing to file:block 0:1. 17-Dec 09:06 ueun47-sd: Got EOF at file 1 on device /dev/nst0, Volume "Volume01" 17-Dec 09:06 ueun47-sd: Reposition from (file:block) 1:1 to 2:0 17-Dec 09:07 ueun47-sd: Got EOF at file 2 on device /dev/nst0, Volume "Volume01" 17-Dec 09:07 ueun47-sd: Got EOF at file 3 on device /dev/nst0, Volume "Volume01" 17-Dec 09:07 ueun47-sd: Reposition from (file:block) 3:1 to 3:0 17-Dec 09:08 ueun47-sd: Got EOF at file 2 on device /dev/nst0, Volume "Volume01" 17-Dec 09:08 ueun47-sd: Got EOF at file 3 on device /dev/nst0, Volume "Volume01" 17-Dec 09:08 ueun47-sd: End of Volume at file 3 on device /dev/nst0, Volume "Volume01" 17-Dec 09:08 ueun47-sd: End of all volumes. 17-Dec 09:08 ueun47-dir: Bacula 1.36.1 (24Nov04): 17-Dec-2004 09:08:35 JobId: 2 Job: RestoreFiles.2004-12-17_09.04.15 Client: ueun47-fd Start time: 17-Dec-2004 09:04:17 End time: 17-Dec-2004 09:08:35 Files Expected: 86 Files Restored: 0 Bytes Restored: 0 Rate: 0.0 KB/s FD Errors: 0 FD termination status: OK SD termination status: OK Termination: Restore OK -- warning file count mismatch 17-Dec 09:08 ueun47-dir: Begin pruning Jobs. 17-Dec 09:08 ueun47-dir: No Jobs found to prune. 17-Dec 09:08 ueun47-dir: Begin pruning Files. 17-Dec 09:08 ueun47-dir: No Files found to prune. 17-Dec 09:08 ueun47-dir: End auto prune. -- This is the content of my restore.bsr: -- ueun47:/var/bacula # cat restore.bsr Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=0 VolBlock=1-15499 FileIndex=73528-73550 FileIndex=73576 Count=24 Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=2 VolBlock=0-15499 FileIndex=137194-137256 Count=63 Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=3 VolBlock=0-15499 FileIndex=249701 Count=1 ueun47:/var/bacula # I hope that helps. What am I doing wrong? Has the fileset too many directories? Isn't it necessary to specify each "mount"/parition on that machine on a single "File = " entry? ---------------------------------------------------------------------- chemical - 12-17-2004 00:29 PST ---------------------------------------------------------------------- Before I forgot, here is the content of "ueun47.bsr": -- Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=0-0 VolBlock=1-15499 FileIndex=1-74439 Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=1-1 VolBlock=0-15499 FileIndex=74439-107081 Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=2-2 VolBlock=0-15499 FileIndex=107081-159432 Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=3-3 VolBlock=0-15499 FileIndex=159432-250436 Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=4-4 VolBlock=0-478 FileIndex=250436-252742 -- ---------------------------------------------------------------------- chemical - 12-17-2004 00:39 PST ---------------------------------------------------------------------- A, I forgot the partition/mount list of the machine: ueun47:/var/bacula # df -k Filesystem 1K-blocks Used Available Use% Mounted on /dev/md2 4192764 1022916 3169848 25% / tmpfs 241484 24 241460 1% /dev/shm /dev/md0 38792 13437 23352 37% /boot /dev/md4 3140508 33560 3106948 2% /home /dev/md3 5244952 2986780 2258172 57% /usr /dev/md5 25405876 239832 25166044 1% /var ueun47:/var/bacula # ---------------------------------------------------------------------- chemical - 12-17-2004 02:07 PST ---------------------------------------------------------------------- The next interesting thing: I changed the order of the Include-File-Statements in the File Set Resource of "Full Set ueun47" (listed above) from: Include { Options { signature = MD5 } File = / File = /home File = /usr File = /var File = /boot } to: Include { Options { signature = MD5 } File = /home File = /usr File = /var File = /boot File = / } Bacula did a full backup again (ok). Now the SAME restore job (like listed above, first mark /home/roland, 23 files, then mark /usr/local, 63 files) does the following: The files marked in /home" were restored successfully, complete. The files in /usr were NOT restored! So it looks to me that bacula is only able to recover from the FIRST file of a file set. Like already said, the btape test worked successfully, no problems at all. Here is the restore.bsr of this run: -- Volume="Volume01" VolSessionId=2 VolSessionTime=1103273991 VolFile=5 VolBlock=0-15499 FileIndex=71-93 FileIndex=119 Count=24 Volume="Volume01" VolSessionId=2 VolSessionTime=1103273991 VolFile=6 VolBlock=0-15499 FileIndex=63737-63799 Count=63 Volume="Volume01" VolSessionId=2 VolSessionTime=1103273991 VolFile=7 VolBlock=0-15499 FileIndex=176244 Count=1 -- The result message of the restore: -- 17-Dec 10:51 ueun47-dir: Start Restore Job RestoreFiles.2004-12-17_10.51.03 17-Dec 10:51 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 17-Dec 10:51 ueun47-sd: Forward spacing to file:block 5:0. 17-Dec 10:54 ueun47-sd: Reposition from (file:block) 5:11 to 6:0 ueun47-fd: drwxr-xr-x 2 roland users 48 2004-12-09 15:36:50 /tmp/test-restore/home/roland/bin/ ueun47-fd: -rw-r--r-- 1 roland users 1106 2004-12-09 15:36:50 /tmp/test-restore/home/roland/Documents/.directory ueun47-fd: drwxr-xr-x 2 roland users 80 2004-12-09 15:36:50 /tmp/test-restore/home/roland/Documents/ ueun47-fd: -rw-r--r-- 1 roland users 1124 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.exrc ueun47-fd: -rw-r--r-- 1 roland users 1286 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.bashrc ueun47-fd: -rw-r--r-- 1 roland users 164 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.kermrc ueun47-fd: -rw-r--r-- 1 roland users 6148 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.muttrc ueun47-fd: -rw-r--r-- 1 roland users 48 2004-12-09 15:36:50 /tmp/test-restore/home/roland/public_html/.directory ueun47-fd: drwxr-xr-x 2 roland users 80 2004-12-09 15:36:50 /tmp/test-restore/home/roland/public_html/ ueun47-fd: -rw-r--r-- 1 roland users 311 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.urlview ueun47-fd: -rw-r--r-- 1 roland users 1033 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.xemacs/init.el ueun47-fd: drwxr-xr-x 2 roland users 72 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.xemacs/ ueun47-fd: -rw------- 1 roland users 5 2004-12-15 15:11:32 /tmp/test-restore/home/roland/.bash_history ueun47-fd: -rwxr-xr-x 1 roland users 3055 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.xinitrc.template ueun47-fd: -rw-r--r-- 1 roland users 934 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.profile ueun47-fd: -rw-r--r-- 1 roland users 7913 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.xcoralrc ueun47-fd: -rw-r--r-- 1 roland users 1637 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.emacs ueun47-fd: drwxr-xr-x 2 roland users 48 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.fonts/ ueun47-fd: -r--r--r-- 1 roland users 16035 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.gnu-emacs ueun47-fd: -rwxr-xr-x 1 roland users 7189 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.xim.template ueun47-fd: -rw-r--r-- 1 roland users 119 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.xtalkrc ueun47-fd: -rw-r--r-- 1 roland users 208 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.dvipsrc ueun47-fd: drwxr-xr-x 7 roland users 568 2004-12-09 15:36:50 /tmp/test-restore/home/roland/ ueun47-fd: drwxr-xr-x 9 root root 200 2004-12-16 10:39:55 /tmp/test-restore/home/ 17-Dec 10:55 ueun47-sd: Got EOF at file 7 on device /dev/nst0, Volume "Volume01" 17-Dec 10:55 ueun47-sd: Reposition from (file:block) 7:1 to 7:0 17-Dec 10:56 ueun47-sd: Got EOF at file 7 on device /dev/nst0, Volume "Volume01" 17-Dec 10:56 ueun47-sd: Got EOF at file 8 on device /dev/nst0, Volume "Volume01" 17-Dec 10:56 ueun47-dir: Bacula 1.36.1 (24Nov04): 17-Dec-2004 10:56:29 JobId: 5 Job: RestoreFiles.2004-12-17_10.51.03 Client: ueun47-fd Start time: 17-Dec-2004 10:51:05 End time: 17-Dec-2004 10:56:29 Files Expected: 86 Files Restored: 24 Bytes Restored: 48,315 Rate: 0.1 KB/s FD Errors: 0 FD termination status: OK SD termination status: OK Termination: Restore OK -- warning file count mismatch 17-Dec 10:56 ueun47-dir: Begin pruning Jobs. 17-Dec 10:56 ueun47-dir: No Jobs found to prune. 17-Dec 10:56 ueun47-dir: Begin pruning Files. 17-Dec 10:56 ueun47-dir: No Files found to prune. 17-Dec 10:56 ueun47-dir: End auto prune. ---------------------------------------------------------------------- chemical - 12-18-2004 00:38 PST ---------------------------------------------------------------------- Ok, first I thought that this is a problem with the tape drive. I experimented several hours with starting all over every time (except the config), thought that the blocksize would not be 0 (but it was), that Forward Spacing perhaps does not find the correct mark, and stuff. Tried several things. Read manual, buglist, manual again. Now the following: Device { Name = LTO-10way # Media Type = LTO-10way Two EOF = Yes; BSF at EOM = Yes; Archive Device = /dev/nst0 AutomaticMount = yes; # when device opened, read it AutoChanger = yes; AlwaysOpen = yes; # drive wird von bacula-sd "gelockt" RemovableMedia = yes; RandomAccess = no; Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d" Changer Device = /dev/sg0 Alert Command = "sh -c 'tapeinfo -f /dev/sg1 |grep TapeAlert|cat'" } My current Deviceresource. Although I'm not sure the 'Two EOF' 'BSF at EOM' are needed or correct, nothing really changed anyway since adding them (and starting all over). Look at this: (above fileset, above jobdef, above machine, clean tapes, clean database) doing full backup of local machine. ok restoring via mark (cd home; mark roland; cd /var; mark log; done). restoring (worked perfectly!! whow! I did it! (at least I thought)). to be sure, restored from every 'file' in my fileset. ok, next one: restoring via mark (mark boot; mark home; cd var; mark log; cd /usr; mark local; done). it restored: /home. in the restore log I can see several Repositions and 'got EOF'. nothing more. Huh? Ok, lets try the first restore job again (exact the same!): restoring via mark (cd home; mark roland; cd /var; mark log; done). restored home/roland ok, then 'got EOF' and finished with warning? WTF? Hm. I seem to have serious compatibility error with my drive, or what is that? I remind: btape test runs ok with 0 errors!! Anyone else is using the Exabyte 110L LTO1 Autoloader on a SuSE 9.2 (disabled /lib/tls)? PS: Why is btape using 64k blocks every time? Is it possible to test with "variable" blocksizes here? Or did I get something wrong? ---------------------------------------------------------------------- kern - 12-18-2004 05:11 PST ---------------------------------------------------------------------- These are the kinds of problems that drive me crazy since they should *never* happen. You did a nice job of explaining what you did. On one point, I am, however, a bit confused. Did you try running your drive with freshly WEOFed tapes without the Two EOF = Yes; BSF at EOM = Yes; I suspect that you started without these. If not, please remove them and try again. In any case, if your drive passes the btape test without them, it is *much* better to leave them out. Can you start simpler to see if the basic functions work? Do the following: 1. Ensure you have a fresh tape (i.e. mt -f /dev/xxx rewind; mt -f /dev/xxx weof) 2. Ensure the above two directives are not in your Device resource. 3. Trim your FileSet down to one directory. 4. Backup 5. Try restoring. 6. If it fails, go back to step 3, trim it down to a smaller directory. 7. If at that point, you get no where, there is probably some compatibility problem with your drive, and we need to turn on debug during the restore. 8. If you are able to restore more than once, please experiment with increasing the number of directories in your fileset and see if the problem comes back. Maybe by incrementing up to the problem, we can isolate it. ---------------------------------------------------------------------- chemical - 12-19-2004 11:50 PST ---------------------------------------------------------------------- Device { Name = LTO-10way # Media Type = LTO-10way Archive Device = /dev/nst0 AutomaticMount = yes; # when device opened, read it AutoChanger = yes; AlwaysOpen = yes; # drive wird von bacula-sd "gelockt" RemovableMedia = yes; RandomAccess = no; Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d" Changer Device = /dev/sg0 Alert Command = "sh -c 'tapeinfo -f /dev/sg1 |grep TapeAlert|cat'" } running btape test - OK, no errors running btape fill - OK, no errors created database fileset changed to only one dir: /usr/src started bacula label barcodes estimated job 2000 OK estimate files=19991 bytes=241,080,300 -- FD Files Written: 19,991 SD Files Written: 19,991 FD Bytes Written: 241,080,300 SD Bytes Written: 243,730,860 -- job save ok restore to /tmp/xx1 mark usr; done Files Expected: 19,991 Files Restored: 19,991 ok restoring the same again to /tmp/xx2 Files Expected: 19,991 Files Restored: 19,991 ok adding full save behind first on same tape 19-Dec 18:12 ueun47-sd: 3302 Autochanger "loaded drive 0", result is Slot 1. 19-Dec 18:12 ueun47-sd: Volume "Volume01" previously written, moving to end of data. 19-Dec 18:12 ueun47-sd: Ready to append to end of Volume "Volume01" at file=1. FD Files Written: 19,991 SD Files Written: 19,991 FD Bytes Written: 241,080,300 SD Bytes Written: 243,730,860 saved again. restoring from second full job to /tmp/xx3 Files Expected: 19,991 Files Restored: 19,991 ok restoring /usr/src/linux-2.6.8-24-obj/i386/debug/scripts/bin2c from first and second full job list jobs. full backups are on jobid 1 and 4 restore, 3, jobid 1 mark /usr/src/linux-2.6.8-24-obj/i386/debug/scripts/bin2c; done restoring to /tmp/xx4 Files Expected: 2 Files Restored: 2 ok (2 files because hardlinked to linux-2.6.8-24-obj/i386/smp/scripts/bin2c, good work!) restore, 3, jobid 4 marking, done. restoring to /tmp/xx5 'Forward spacing to file:block 1:0' Files Expected: 2 Files Restored: 2 ok now adding second dir to fileset resource appending "/var/log" AFTER "/usr/src" in bacula-dir.conf reload run 19-Dec 18:29 ueun47-dir: Created new FileSet record "Full Set ueun47" 2004-12-19 18:29:04 19-Dec 18:29 ueun47-dir: No prior Full backup Job record found. 19-Dec 18:29 ueun47-dir: No prior or suitable Full backup found. Doing FULL backup. 19-Dec 18:29 ueun47-dir: Start Backup JobId 8, Job=ueun47.2004-12-19_18.29.02 19-Dec 18:29 ueun47-sd: 3301 Issuing autochanger "loaded drive 0" command. 19-Dec 18:29 ueun47-sd: 3302 Autochanger "loaded drive 0", result is Slot 1. 19-Dec 18:29 ueun47-sd: Volume "Volume01" previously written, moving to end of data. 19-Dec 18:29 ueun47-sd: Ready to append to end of Volume "Volume01" at file=2. FD Files Written: 20,047 SD Files Written: 20,047 FD Bytes Written: 245,124,904 SD Bytes Written: 247,780,677 job OK now restoring the above mentioned file from job 1 and 4 again (just to be sure). restoring from jobid 1: 19-Dec 18:34 ueun47-sd: Forward spacing to file:block 0:1. OK restoring from jobid 4: 19-Dec 18:37 ueun47-sd: Forward spacing to file:block 1:0. OK restoring the file from the new 2-dir job (jobid 8) 19-Dec 18:39 ueun47-sd: Forward spacing to file:block 2:0. OK restoring via "restore, 5" cd usr; mark src; 19,991 files marked. cd /; mark var; 56 files marked. relocate to /tmp/xx6 19-Dec 18:43 ueun47-sd: Forward spacing to file:block 2:0. Files Expected: 20,047 Files Restored: 20,047 OK the SAME again. restoring via "restore, 5" marking.. relocate to xx7 19-Dec 18:48 ueun47-sd: Forward spacing to file:block 2:0. Files Expected: 20,047 Files Restored: 20,047 OK the same again, but marking in reverse order. restore ,5 mark var; 56 files marked. cd /; cd usr; mark src; 19,991 files marked. relocate to /tmp/xx7 Files Expected: 20,047 Files Restored: 20,047 OK restoring /usr/src/linux from first full (jobid 1), just to be sure. restore, 3, jobid 1 cd usr; cd src; mark linux; 1 files marked. 19-Dec 19:00 ueun47-sd: Forward spacing to file:block 0:1. Files Expected: 1 Files Restored: 1 OK restoring /var/log (second fileset from last full): restore, 5 cd var; mark log; 56 files marked. relocate to /tmp/xx8 19-Dec 19:02 ueun47-sd: Forward spacing to file:block 2:0. Files Expected: 56 Files Restored: 56 OK Now adding "/" to fileset resource AFTER "/var/log": File = /usr/src File = /var/log File = / run full backup 19-Dec 19:04 ueun47-dir: Start Backup JobId 17, Job=ueun47.2004-12-19_19.04.29 19-Dec 19:04 ueun47-sd: 3301 Issuing autochanger "loaded drive 0" command. 19-Dec 19:04 ueun47-sd: 3302 Autochanger "loaded drive 0", result is Slot 1. 19-Dec 19:04 ueun47-sd: Volume "Volume01" previously written, moving to end of data. 19-Dec 19:04 ueun47-sd: Ready to append to end of Volume "Volume01" at file=3. ran incremental with 12 new files. damn. forgot to reload. ok, reload, same again. 19-Dec 19:06 ueun47-dir: Created new FileSet record "Full Set ueun47" 2004-12-19 19:06:05 19-Dec 19:06 ueun47-dir: No prior Full backup Job record found. 19-Dec 19:06 ueun47-dir: No prior or suitable Full backup found. Doing FULL backup. 19-Dec 19:06 ueun47-dir: Start Backup JobId 18, Job=ueun47.2004-12-19_19.06.03 FD Files Written: 93,502 SD Files Written: 93,502 OK Now restoring /var/log (in second fileset) from last full: restore, 5 cd var; mark log; 56 files marked. relocate to /tmp/xx9 19-Dec 19:32 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 19-Dec 19:32 ueun47-sd: Forward spacing to file:block 4:0. Files Expected: 56 Files Restored: 56 OK Now restoring /etc/ (in third fileset) from last full: restore, 5 mark etc; 4,117 files marked. relocate to /tmp/xx10 19-Dec 19:37 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 19-Dec 19:37 ueun47-sd: Forward spacing to file:block 4:0. Files Expected: 4,117 Files Restored: 4,117 OK Restoring /etc (3rd fileset) and /usr/src/linux (first fileset) from last full restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx11 19-Dec 19:40 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 19-Dec 19:40 ueun47-sd: Forward spacing to file:block 4:0. 19-Dec 19:41 ueun47-sd: Got EOF at file 5 on device /dev/nst0, Volume "Volume01" 19-Dec 19:41 ueun47-dir: Bacula 1.36.1 (24Nov04): 19-Dec-2004 19:41:07 Files Expected: 4,118 Files Restored: 0 Ok, there we have it. Restoring same files from last job in reverse order: cd usr; cd src; mark linux; 1 files marked. cd /; mark etc; 4,117 files marked. relocate to /tmp/xx12 19-Dec 19:46 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 19-Dec 19:46 ueun47-sd: Forward spacing to file:block 4:0. Files Expected: 4,118 Files Restored: 4,118 HUH? So if I mark the files as they are in order on the tape, it works - else, it does not. (IF there is a File in my fileset, that "includes" a directory from another File in that fileset?) I mean, if I save / I will get all mountpoints (like var or usr in my case) as empty directories in that fileset - but they are saved seperatly in different files). Could this be the problem? Just an assumption. Just to be sure. Reproducing: Restoring /etc (3rd fileset) and /usr/src/linux (first fileset) from last full restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx13 19-Dec 19:54 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 19-Dec 19:54 ueun47-sd: Forward spacing to file:block 4:0. Files Expected: 4,118 Files Restored: 4,118 WTF????? Why does it work now?? SAME again... restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx13 19-Dec 19:59 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 19-Dec 19:59 ueun47-sd: Forward spacing to file:block 4:0. 19-Dec 19:59 ueun47-sd: Got EOF at file 5 on device /dev/nst0, Volume "Volume01" Files Expected: 4,118 Files Restored: 0 Oh my. Where's that EOF coming from? And again.. restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx14 Files Expected: 4,118 Files Restored: 4,118 And again.. restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx15 Files Expected: 4,118 Files Restored: 0 And again.. restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx15 Files Expected: 4,118 Files Restored: 4,118 I'm scared how regular this is. Again? restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx15 Files Expected: 4,118 Files Restored: 4,118 ... I think we need to debug the tape somewhat. Should I try to run several btape tests in a row?? Perhaps it happens there, too. Perhaps the drive is not OK? But its a new one. ---------------------------------------------------------------------- kern - 12-21-2004 01:26 PST ---------------------------------------------------------------------- It looks to me like there is either a bug in Bacula (I don't see it here), or your drive (more likely your OS driver) has some strange problem of keeping track of where it is so Bacula gets positioned into the wrong file. I recommend as a start, the following: - Try to get the simplest case where it fails. The one you already have is probably OK. - Run the SD with -d100 - When it works, capture the output (one time), and upload it here as an attachment with a name like working.txt (the .txt is most important). - When it fails, then do the same, upload as fail.txt or something like that. This debug output should give us a better idea of what kind of detailed tape movement operations are being used. If you can, pull down the current version of 1.37.1 from the CVS, build it. This will allow me to make changes to the code and transmit them to you easier. Also, there is a new Device directive that *may* help you. Try running the same test on the same tape, with the same Device resource, but add: UseMTIOCGET = no This is implemented only on 1.37.1 and is *totally* experimental, but should be interesting to try. ---------------------------------------------------------------------- chemical - 12-22-2004 07:29 PST ---------------------------------------------------------------------- After several more tests I believe this is a non-software issue. As I'm not at work until Jan, 3rd I will have to wait. Kern: Thanks for your help. I will report back after I got the tape drive working cleanly. (After setting the drive and bacula into fixed mode (64K), I receive several floods into my /var/log/warn and bacula hangs during restore.) Dec 22 16:14:24 ueun47 kernel: st0: Error with sense data: Info fld=0x1, ILI Current st0: sense = f0 2b Dec 22 16:14:24 ueun47 kernel: Additional sense: Data phase error Dec 22 16:14:24 ueun47 kernel: st0: Error with sense data: Info fld=0x1, ILI Current st0: sense = f0 2b Dec 22 16:14:24 ueun47 kernel: Additional sense: Data phase error Dec 22 16:14:24 ueun47 kernel: st0: Error with sense data: Info fld=0x1, ILI Current st0: sense = f0 2b Dec 22 16:14:24 ueun47 kernel: Additional sense: Data phase error Dec 22 16:14:24 ueun47 kernel: st0: Error with sense data: Info fld=0x1, ILI Current st0: sense = f0 2b Dec 22 16:14:24 ueun47 kernel: Additional sense: Data phase error I'm currently not aware how to interpret the error. Bad Cable? Too long cable? Bad Device settings? Faulty Tape Drive? At least I'm sure this is not the fault of bacula. Even a clean tape will fail with: tar cWf /dev/st0 /usr After several files it stops with "Read failed" (with blocksize 0). Though I find it rather inconvenient that btape 'test' works perfectly. I report back if you want (next year). ---------------------------------------------------------------------- kern - 12-22-2004 09:32 PST ---------------------------------------------------------------------- Yes, please do report back. btape test may work because it doesn't write enough data. Another thing to try is a btape "fill" command. That should definitely stress the drive. Concerning the errors in the log. That is not a good sign. I'm not a hardware expert, so I don't know how to interpret it. Have a good holiday season. ---------------------------------------------------------------------- kern - 12-24-2004 02:35 PST ---------------------------------------------------------------------- Given that your drive doesn't work even for tar, I'm assuming that this is a hardware problem. If after getting your drive fixed, and verifing the 9 steps in the Testing chapter of the manual, you are still having problems doing restored, please either re-open this bug report, or open a new one. Bug History Date Modified Username Field Change ====================================================================== 12-16-04 07:57 chemical New Bug 12-16-04 08:12 chemical Bug Monitored: chemical 12-16-04 14:01 kern Bugnote Added: 0000549 12-16-04 14:01 kern Status new => feedback 12-17-04 00:27 chemical Bugnote Added: 0000553 12-17-04 00:29 chemical Bugnote Added: 0000554 12-17-04 00:39 chemical Bugnote Added: 0000555 12-17-04 02:07 chemical Bugnote Added: 0000556 12-18-04 00:38 chemical Bugnote Added: 0000559 12-18-04 05:11 kern Bugnote Added: 0000566 12-19-04 11:50 chemical Bugnote Added: 0000567 12-21-04 01:26 kern Bugnote Added: 0000569 12-22-04 07:29 chemical Bugnote Added: 0000582 12-22-04 09:32 kern Bugnote Added: 0000585 12-24-04 02:35 kern Bugnote Added: 0000589 12-24-04 02:35 kern Resolution open => not a bug 12-24-04 02:35 kern Status feedback => closed ====================================================================== |
From: <bac...@li...> - 2004-12-24 10:27:17
|
The following bug has been CLOSED ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000209 ====================================================================== Reported By: abuehler Assigned To: ====================================================================== Project: bacula Bug ID: 209 Category: File Daemon Reproducibility: always Severity: crash Priority: normal Status: closed ====================================================================== Date Submitted: 12-21-2004 09:53 PST Last Modified: 12-24-2004 02:32 PST ====================================================================== Summary: FD crash after sucessfull backup Description: After sucessfull completion of the backup the FD crash. See attached traceback. In output of the "status client=albundy-fd" the job is not listed, but appears in "list jobs". ====================================================================== ---------------------------------------------------------------------- kern - 12-21-2004 10:10 PST ---------------------------------------------------------------------- The traceback doesn't seem to show the FD crashing. I recommend that you manually run it under the debugger. Then when it crashes, enter the following command: thread apply all bt Hopefully that will show where the problem lies. I suspect that the status client is showing nothing because either the job never ran or the FD crashed. If it crashes, any running jobs are lost and not reported if the FD is restarted (i.e. they are only written to the job history at the end of the job). ---------------------------------------------------------------------- abuehler - 12-22-2004 07:22 PST ---------------------------------------------------------------------- I've checked out the cvs 1.37.1 (21Dec04) and ran it with gdb. It seems the FD is getting SIGUSR2. After entering "continue" (>100 times) in gdb the FD terminates with SIGSEGV (gdbout.txt). I got a email notifcation with a failed backup. Next I've tried runing FD in foreground, set the debug level to 150 and redirect stdout and stderr to a file (debug-150.txt, omitted serveral lines). This time I got email notification with a "Backup OK" (debug-email.txt) and a backtrace mail (debug-trace.txt). ---------------------------------------------------------------------- kern - 12-22-2004 09:25 PST ---------------------------------------------------------------------- Thanks for your efforts. Please try running the FD under the debugger again as follows: gdb bacula-fd run -s -f -c bacula-fd.conf when it comes back to the command prompt (after crashing), enter: thread apply all bt Hopefully that will show me where the problem is. From the -dxxx trace, it seems like it is dying in some utility thread because after the seg fault, sending of the data to the SD continues ... ---------------------------------------------------------------------- abuehler - 12-22-2004 11:44 PST ---------------------------------------------------------------------- The attached file "gdbout2.txt" contains the output of the gdb session. ---------------------------------------------------------------------- kern - 12-22-2004 12:58 PST ---------------------------------------------------------------------- The traceback does not clearly show where the seg fault occurs, but from previous similar reports, I can now make a guess (estimate 99% correct). You are probably either mixing old and new syntax FileSets, and for some reason, when you have old style includes/excludes, something gets confused and seg faults. Try switching to using all new style FileSet, and I am 99% sure your problem will go away. Please report back. ---------------------------------------------------------------------- kern - 12-24-2004 02:32 PST ---------------------------------------------------------------------- I believe that I have now found and fixed the FD crash problem (even if you use the old style include/excludes). It is now in the 1.37.1 CVS. I would appreciate it if you would try it -- assuming that you have not already converted your FileSet. I've also attached a 1.36.1 patch for users on 1.36.1. Note, this patch can also be applied to 1.37.1 Bug History Date Modified Username Field Change ====================================================================== 12-21-04 09:53 abuehler New Bug 12-21-04 09:53 abuehler File Added: traceback.txt 12-21-04 10:10 kern Bugnote Added: 0000579 12-22-04 07:22 abuehler Bugnote Added: 0000581 12-22-04 07:23 abuehler File Added: gdbout.txt 12-22-04 07:23 abuehler File Added: debug-150.txt 12-22-04 07:24 abuehler File Added: debug-email.txt 12-22-04 07:24 abuehler File Added: debug-trace.txt 12-22-04 09:25 kern Bugnote Added: 0000583 12-22-04 09:25 kern Status new => feedback 12-22-04 11:40 abuehler File Added: gdbout2.txt 12-22-04 11:44 abuehler Bugnote Added: 0000586 12-22-04 12:58 kern Bugnote Added: 0000587 12-24-04 02:28 kern File Added: 1.36.1-fileset.patch 12-24-04 02:32 kern Bugnote Added: 0000588 12-24-04 02:32 kern Resolution open => fixed 12-24-04 02:32 kern Status feedback => closed ====================================================================== |
From: <bac...@li...> - 2004-12-22 20:53:45
|
====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000209 ====================================================================== Reported By: abuehler Assigned To: ====================================================================== Project: bacula Bug ID: 209 Category: File Daemon Reproducibility: always Severity: crash Priority: normal Status: feedback ====================================================================== Date Submitted: 12-21-2004 09:53 PST Last Modified: 12-22-2004 12:58 PST ====================================================================== Summary: FD crash after sucessfull backup Description: After sucessfull completion of the backup the FD crash. See attached traceback. In output of the "status client=albundy-fd" the job is not listed, but appears in "list jobs". ====================================================================== ---------------------------------------------------------------------- kern - 12-21-2004 10:10 PST ---------------------------------------------------------------------- The traceback doesn't seem to show the FD crashing. I recommend that you manually run it under the debugger. Then when it crashes, enter the following command: thread apply all bt Hopefully that will show where the problem lies. I suspect that the status client is showing nothing because either the job never ran or the FD crashed. If it crashes, any running jobs are lost and not reported if the FD is restarted (i.e. they are only written to the job history at the end of the job). ---------------------------------------------------------------------- abuehler - 12-22-2004 07:22 PST ---------------------------------------------------------------------- I've checked out the cvs 1.37.1 (21Dec04) and ran it with gdb. It seems the FD is getting SIGUSR2. After entering "continue" (>100 times) in gdb the FD terminates with SIGSEGV (gdbout.txt). I got a email notifcation with a failed backup. Next I've tried runing FD in foreground, set the debug level to 150 and redirect stdout and stderr to a file (debug-150.txt, omitted serveral lines). This time I got email notification with a "Backup OK" (debug-email.txt) and a backtrace mail (debug-trace.txt). ---------------------------------------------------------------------- kern - 12-22-2004 09:25 PST ---------------------------------------------------------------------- Thanks for your efforts. Please try running the FD under the debugger again as follows: gdb bacula-fd run -s -f -c bacula-fd.conf when it comes back to the command prompt (after crashing), enter: thread apply all bt Hopefully that will show me where the problem is. From the -dxxx trace, it seems like it is dying in some utility thread because after the seg fault, sending of the data to the SD continues ... ---------------------------------------------------------------------- abuehler - 12-22-2004 11:44 PST ---------------------------------------------------------------------- The attached file "gdbout2.txt" contains the output of the gdb session. ---------------------------------------------------------------------- kern - 12-22-2004 12:58 PST ---------------------------------------------------------------------- The traceback does not clearly show where the seg fault occurs, but from previous similar reports, I can now make a guess (estimate 99% correct). You are probably either mixing old and new syntax FileSets, and for some reason, when you have old style includes/excludes, something gets confused and seg faults. Try switching to using all new style FileSet, and I am 99% sure your problem will go away. Please report back. Bug History Date Modified Username Field Change ====================================================================== 12-21-04 09:53 abuehler New Bug 12-21-04 09:53 abuehler File Added: traceback.txt 12-21-04 10:10 kern Bugnote Added: 0000579 12-22-04 07:22 abuehler Bugnote Added: 0000581 12-22-04 07:23 abuehler File Added: gdbout.txt 12-22-04 07:23 abuehler File Added: debug-150.txt 12-22-04 07:24 abuehler File Added: debug-email.txt 12-22-04 07:24 abuehler File Added: debug-trace.txt 12-22-04 09:25 kern Bugnote Added: 0000583 12-22-04 09:25 kern Status new => feedback 12-22-04 11:40 abuehler File Added: gdbout2.txt 12-22-04 11:44 abuehler Bugnote Added: 0000586 12-22-04 12:58 kern Bugnote Added: 0000587 ====================================================================== |
From: <bac...@li...> - 2004-12-22 19:39:53
|
A BUGNOTE has been added to this bug. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000209 ====================================================================== Reported By: abuehler Assigned To: ====================================================================== Project: bacula Bug ID: 209 Category: File Daemon Reproducibility: always Severity: crash Priority: normal Status: feedback ====================================================================== Date Submitted: 12-21-2004 09:53 PST Last Modified: 12-22-2004 11:44 PST ====================================================================== Summary: FD crash after sucessfull backup Description: After sucessfull completion of the backup the FD crash. See attached traceback. In output of the "status client=albundy-fd" the job is not listed, but appears in "list jobs". ====================================================================== ---------------------------------------------------------------------- kern - 12-21-2004 10:10 PST ---------------------------------------------------------------------- The traceback doesn't seem to show the FD crashing. I recommend that you manually run it under the debugger. Then when it crashes, enter the following command: thread apply all bt Hopefully that will show where the problem lies. I suspect that the status client is showing nothing because either the job never ran or the FD crashed. If it crashes, any running jobs are lost and not reported if the FD is restarted (i.e. they are only written to the job history at the end of the job). ---------------------------------------------------------------------- abuehler - 12-22-2004 07:22 PST ---------------------------------------------------------------------- I've checked out the cvs 1.37.1 (21Dec04) and ran it with gdb. It seems the FD is getting SIGUSR2. After entering "continue" (>100 times) in gdb the FD terminates with SIGSEGV (gdbout.txt). I got a email notifcation with a failed backup. Next I've tried runing FD in foreground, set the debug level to 150 and redirect stdout and stderr to a file (debug-150.txt, omitted serveral lines). This time I got email notification with a "Backup OK" (debug-email.txt) and a backtrace mail (debug-trace.txt). ---------------------------------------------------------------------- kern - 12-22-2004 09:25 PST ---------------------------------------------------------------------- Thanks for your efforts. Please try running the FD under the debugger again as follows: gdb bacula-fd run -s -f -c bacula-fd.conf when it comes back to the command prompt (after crashing), enter: thread apply all bt Hopefully that will show me where the problem is. From the -dxxx trace, it seems like it is dying in some utility thread because after the seg fault, sending of the data to the SD continues ... ---------------------------------------------------------------------- abuehler - 12-22-2004 11:44 PST ---------------------------------------------------------------------- The attached file "gdbout2.txt" contains the output of the gdb session. Bug History Date Modified Username Field Change ====================================================================== 12-21-04 09:53 abuehler New Bug 12-21-04 09:53 abuehler File Added: traceback.txt 12-21-04 10:10 kern Bugnote Added: 0000579 12-22-04 07:22 abuehler Bugnote Added: 0000581 12-22-04 07:23 abuehler File Added: gdbout.txt 12-22-04 07:23 abuehler File Added: debug-150.txt 12-22-04 07:24 abuehler File Added: debug-email.txt 12-22-04 07:24 abuehler File Added: debug-trace.txt 12-22-04 09:25 kern Bugnote Added: 0000583 12-22-04 09:25 kern Status new => feedback 12-22-04 11:40 abuehler File Added: gdbout2.txt 12-22-04 11:44 abuehler Bugnote Added: 0000586 ====================================================================== |
From: <bac...@li...> - 2004-12-22 17:27:35
|
A BUGNOTE has been added to this bug. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000205 ====================================================================== Reported By: chemical Assigned To: ====================================================================== Project: bacula Bug ID: 205 Category: Storage Daemon Reproducibility: always Severity: major Priority: normal Status: feedback ====================================================================== Date Submitted: 12-16-2004 07:57 PST Last Modified: 12-22-2004 09:32 PST ====================================================================== Summary: I am not able to restore files from backups Description: I have an autochanger with 10 LTOs connected to a Celeron Machine. btape test run through successfully on all tests. ====================================================================== ---------------------------------------------------------------------- kern - 12-16-2004 14:01 PST ---------------------------------------------------------------------- The job is not list 5 times in the database, there are just 5 tape files associated with the job. This is not a problem. Please attach include the *full* listing of how you were restoring your files. In the partial listing you include, I don't see that you selected any files. Also, please attach your bootstrap file (restore.bsr), but as restore.bsr.txt. ---------------------------------------------------------------------- chemical - 12-17-2004 00:27 PST ---------------------------------------------------------------------- Ok, lets do it again Sam: Stopped bacula, empty'd /var/bacula. Erased all tapes (again). Here are the job definitions of the client which will be saved+restored: -- JobDefs { Name = "ueun47Job" Type = Backup Level = Incremental Client = ueun47-fd FileSet = "Full Set ueun47" Schedule = "FlexCycle" Storage = LTO-10way Messages = Standard Pool = Default Priority = 10 } Job { Name = "ueun47" JobDefs = "ueun47Job" Write Bootstrap = "/var/bacula/ueun47.bsr" } FileSet { Name = "Full Set ueun47" Include { Options { signature = MD5 } File = / File = /home File = /usr File = /var File = /boot } Exclude { File = /proc File = /tmp File = /.journal File = /.fsck } } Client { Name = ueun47-fd Address = ueun47 FDPort = 9102 Catalog = MyCatalog Password = "xxx" # password for FileDaemon File Retention = 30 days # 30 days Job Retention = 3 months # six months AutoPrune = yes # Prune expired Jobs/Files } -- Now recreated bacula database+tables. Started bacula, "label barcodes" -> OK, all 10 Media label'd and added to Pool 'Default' Now, 'run': Select Job resource: ueun47 Run Backup job JobName: ueun47 FileSet: Full Set ueun47 Level: Incremental Client: ueun47-fd Storage: LTO-10way Pool: Default When: 2004-12-17 08:36:25 Priority: 10 OK to run? (yes/mod/no): yes ...... (no prior backup found, upgraded to full backup, loaded media 1, backupped all files) -- Backup OK, here is the log: -- 17-Dec 08:36 ueun47-dir: Created new FileSet record "Full Set ueun47" 2004-12-17 08:36:45 17-Dec 08:36 ueun47-dir: No prior Full backup Job record found. 17-Dec 08:36 ueun47-dir: No prior or suitable Full backup found. Doing FULL backup. 17-Dec 08:36 ueun47-dir: Start Backup JobId 1, Job=ueun47.2004-12-17_08.36.43 17-Dec 08:36 ueun47-sd: 3301 Issuing autochanger "loaded drive 0" command. 17-Dec 08:36 ueun47-sd: 3302 Autochanger "loaded drive 0", result is Slot 10. 17-Dec 08:36 ueun47-sd: 3303 Issuing autochanger "unload slot 10, drive 0" command. 17-Dec 08:37 ueun47-sd: 3304 Issuing autochanger "load slot 1, drive 0" command. 17-Dec 08:37 ueun47-sd: 3305 Autochanger "load slot 1, drive 0", status is OK. 17-Dec 08:38 ueun47-sd: Wrote label to prelabeled Volume "Volume01" on device "/dev/nst0" 17-Dec 09:00 ueun47-dir: Bacula 1.36.1 (24Nov04): 17-Dec-2004 09:00:13 JobId: 1 Job: ueun47.2004-12-17_08.36.43 Backup Level: Full (upgraded from Incremental) Client: ueun47-fd FileSet: "Full Set ueun47" 2004-12-17 08:36:45 Pool: "Default" Storage: "LTO-10way" Start time: 17-Dec-2004 08:36:45 End time: 17-Dec-2004 09:00:13 FD Files Written: 252,742 SD Files Written: 252,742 FD Bytes Written: 3,986,435,774 SD Bytes Written: 4,019,105,767 Rate: 2831.3 KB/s Software Compression: None Volume name(s): Volume01 Volume Session Id: 1 Volume Session Time: 1103267392 Last Volume Bytes: 4,030,576,870 Non-fatal FD errors: 0 SD Errors: 0 FD termination status: OK SD termination status: OK Termination: Backup OK 17-Dec 09:00 ueun47-dir: Begin pruning Jobs. 17-Dec 09:00 ueun47-dir: No Jobs found to prune. 17-Dec 09:00 ueun47-dir: Begin pruning Files. 17-Dec 09:00 ueun47-dir: No Files found to prune. 17-Dec 09:00 ueun47-dir: End auto prune. --- verify: * list jobs +-------+--------+---------------------+------+-------+----------+---------------+-----------+ | JobId | Name | StartTime | Type | Level | JobFiles | JobBytes | JobStatus | +-------+--------+---------------------+------+-------+----------+---------------+-----------+ | 1 | ueun47 | 2004-12-17 08:36:45 | B | F | 252,742 | 3,986,435,774 | T | +-------+--------+---------------------+------+-------+----------+---------------+-----------+ -- this is ok. now we're restoring from the backup: *restore To select the JobIds, you have the following choices: 1: List last 20 Jobs run 2: List Jobs where a given File is saved 3: Enter list of comma separated JobIds to select 4: Enter SQL list command 5: Select the most recent backup for a client 6: Select backup for a client before a specified time 7: Enter a list of files to restore 8: Enter a list of files to restore before a specified time 9: Cancel Select item: (1-9): 5 Automatically selected Client: ueun47-fd Automatically selected FileSet: Full Set ueun47 +-------+-------+----------+---------------------+------------+-----------+--------------+----------------+ | 1 | F | 252,742 | 2004-12-17 08:36:45 | Volume01 | 0 | 1 | 1,103,267,392 | | 1 | F | 252,742 | 2004-12-17 08:36:45 | Volume01 | 1 | 1 | 1,103,267,392 | | 1 | F | 252,742 | 2004-12-17 08:36:45 | Volume01 | 2 | 1 | 1,103,267,392 | | 1 | F | 252,742 | 2004-12-17 08:36:45 | Volume01 | 3 | 1 | 1,103,267,392 | | 1 | F | 252,742 | 2004-12-17 08:36:45 | Volume01 | 4 | 1 | 1,103,267,392 | +-------+-------+----------+---------------------+------------+-----------+--------------+----------------+ You have selected the following JobId: 1 Building directory tree for JobId 1 ... +++++++++++++++++++++++++++++++++++++++++++++++ 1 Job, 239,555 files inserted into the tree. You are now entering file selection mode where you add (mark) and remove (unmark) files to be restored. No files are initially added, unless you used the "all" keyword on the command line. Enter "done" to leave this mode. cwd is: / $ cd usr cwd is: /usr/ $ mark local 63 files marked. $ cd /home cwd is: /home/ $ mark roland 23 files marked. $ done Bootstrap records written to /var/bacula/restore.bsr The job will require the following Volumes: Volume01 86 files selected to be restored. Run Restore job JobName: RestoreFiles Bootstrap: /var/bacula/restore.bsr Where: / Replace: always FileSet: Full Set ueun47 Client: ueun47-fd Storage: LTO-10way When: 2004-12-17 09:03:25 Catalog: MyCatalog Priority: 10 OK to run? (yes/mod/no): (modified where from / to /tmp/test-restore) started job. Job started. JobId=2 .... Job told me, Restore OK: -- 17-Dec 09:04 ueun47-dir: Start Restore Job RestoreFiles.2004-12-17_09.04.15 17-Dec 09:06 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 17-Dec 09:06 ueun47-sd: Forward spacing to file:block 0:1. 17-Dec 09:06 ueun47-sd: Got EOF at file 1 on device /dev/nst0, Volume "Volume01" 17-Dec 09:06 ueun47-sd: Reposition from (file:block) 1:1 to 2:0 17-Dec 09:07 ueun47-sd: Got EOF at file 2 on device /dev/nst0, Volume "Volume01" 17-Dec 09:07 ueun47-sd: Got EOF at file 3 on device /dev/nst0, Volume "Volume01" 17-Dec 09:07 ueun47-sd: Reposition from (file:block) 3:1 to 3:0 17-Dec 09:08 ueun47-sd: Got EOF at file 2 on device /dev/nst0, Volume "Volume01" 17-Dec 09:08 ueun47-sd: Got EOF at file 3 on device /dev/nst0, Volume "Volume01" 17-Dec 09:08 ueun47-sd: End of Volume at file 3 on device /dev/nst0, Volume "Volume01" 17-Dec 09:08 ueun47-sd: End of all volumes. 17-Dec 09:08 ueun47-dir: Bacula 1.36.1 (24Nov04): 17-Dec-2004 09:08:35 JobId: 2 Job: RestoreFiles.2004-12-17_09.04.15 Client: ueun47-fd Start time: 17-Dec-2004 09:04:17 End time: 17-Dec-2004 09:08:35 Files Expected: 86 Files Restored: 0 Bytes Restored: 0 Rate: 0.0 KB/s FD Errors: 0 FD termination status: OK SD termination status: OK Termination: Restore OK -- warning file count mismatch 17-Dec 09:08 ueun47-dir: Begin pruning Jobs. 17-Dec 09:08 ueun47-dir: No Jobs found to prune. 17-Dec 09:08 ueun47-dir: Begin pruning Files. 17-Dec 09:08 ueun47-dir: No Files found to prune. 17-Dec 09:08 ueun47-dir: End auto prune. -- This is the content of my restore.bsr: -- ueun47:/var/bacula # cat restore.bsr Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=0 VolBlock=1-15499 FileIndex=73528-73550 FileIndex=73576 Count=24 Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=2 VolBlock=0-15499 FileIndex=137194-137256 Count=63 Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=3 VolBlock=0-15499 FileIndex=249701 Count=1 ueun47:/var/bacula # I hope that helps. What am I doing wrong? Has the fileset too many directories? Isn't it necessary to specify each "mount"/parition on that machine on a single "File = " entry? ---------------------------------------------------------------------- chemical - 12-17-2004 00:29 PST ---------------------------------------------------------------------- Before I forgot, here is the content of "ueun47.bsr": -- Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=0-0 VolBlock=1-15499 FileIndex=1-74439 Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=1-1 VolBlock=0-15499 FileIndex=74439-107081 Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=2-2 VolBlock=0-15499 FileIndex=107081-159432 Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=3-3 VolBlock=0-15499 FileIndex=159432-250436 Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=4-4 VolBlock=0-478 FileIndex=250436-252742 -- ---------------------------------------------------------------------- chemical - 12-17-2004 00:39 PST ---------------------------------------------------------------------- A, I forgot the partition/mount list of the machine: ueun47:/var/bacula # df -k Filesystem 1K-blocks Used Available Use% Mounted on /dev/md2 4192764 1022916 3169848 25% / tmpfs 241484 24 241460 1% /dev/shm /dev/md0 38792 13437 23352 37% /boot /dev/md4 3140508 33560 3106948 2% /home /dev/md3 5244952 2986780 2258172 57% /usr /dev/md5 25405876 239832 25166044 1% /var ueun47:/var/bacula # ---------------------------------------------------------------------- chemical - 12-17-2004 02:07 PST ---------------------------------------------------------------------- The next interesting thing: I changed the order of the Include-File-Statements in the File Set Resource of "Full Set ueun47" (listed above) from: Include { Options { signature = MD5 } File = / File = /home File = /usr File = /var File = /boot } to: Include { Options { signature = MD5 } File = /home File = /usr File = /var File = /boot File = / } Bacula did a full backup again (ok). Now the SAME restore job (like listed above, first mark /home/roland, 23 files, then mark /usr/local, 63 files) does the following: The files marked in /home" were restored successfully, complete. The files in /usr were NOT restored! So it looks to me that bacula is only able to recover from the FIRST file of a file set. Like already said, the btape test worked successfully, no problems at all. Here is the restore.bsr of this run: -- Volume="Volume01" VolSessionId=2 VolSessionTime=1103273991 VolFile=5 VolBlock=0-15499 FileIndex=71-93 FileIndex=119 Count=24 Volume="Volume01" VolSessionId=2 VolSessionTime=1103273991 VolFile=6 VolBlock=0-15499 FileIndex=63737-63799 Count=63 Volume="Volume01" VolSessionId=2 VolSessionTime=1103273991 VolFile=7 VolBlock=0-15499 FileIndex=176244 Count=1 -- The result message of the restore: -- 17-Dec 10:51 ueun47-dir: Start Restore Job RestoreFiles.2004-12-17_10.51.03 17-Dec 10:51 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 17-Dec 10:51 ueun47-sd: Forward spacing to file:block 5:0. 17-Dec 10:54 ueun47-sd: Reposition from (file:block) 5:11 to 6:0 ueun47-fd: drwxr-xr-x 2 roland users 48 2004-12-09 15:36:50 /tmp/test-restore/home/roland/bin/ ueun47-fd: -rw-r--r-- 1 roland users 1106 2004-12-09 15:36:50 /tmp/test-restore/home/roland/Documents/.directory ueun47-fd: drwxr-xr-x 2 roland users 80 2004-12-09 15:36:50 /tmp/test-restore/home/roland/Documents/ ueun47-fd: -rw-r--r-- 1 roland users 1124 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.exrc ueun47-fd: -rw-r--r-- 1 roland users 1286 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.bashrc ueun47-fd: -rw-r--r-- 1 roland users 164 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.kermrc ueun47-fd: -rw-r--r-- 1 roland users 6148 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.muttrc ueun47-fd: -rw-r--r-- 1 roland users 48 2004-12-09 15:36:50 /tmp/test-restore/home/roland/public_html/.directory ueun47-fd: drwxr-xr-x 2 roland users 80 2004-12-09 15:36:50 /tmp/test-restore/home/roland/public_html/ ueun47-fd: -rw-r--r-- 1 roland users 311 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.urlview ueun47-fd: -rw-r--r-- 1 roland users 1033 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.xemacs/init.el ueun47-fd: drwxr-xr-x 2 roland users 72 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.xemacs/ ueun47-fd: -rw------- 1 roland users 5 2004-12-15 15:11:32 /tmp/test-restore/home/roland/.bash_history ueun47-fd: -rwxr-xr-x 1 roland users 3055 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.xinitrc.template ueun47-fd: -rw-r--r-- 1 roland users 934 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.profile ueun47-fd: -rw-r--r-- 1 roland users 7913 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.xcoralrc ueun47-fd: -rw-r--r-- 1 roland users 1637 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.emacs ueun47-fd: drwxr-xr-x 2 roland users 48 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.fonts/ ueun47-fd: -r--r--r-- 1 roland users 16035 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.gnu-emacs ueun47-fd: -rwxr-xr-x 1 roland users 7189 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.xim.template ueun47-fd: -rw-r--r-- 1 roland users 119 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.xtalkrc ueun47-fd: -rw-r--r-- 1 roland users 208 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.dvipsrc ueun47-fd: drwxr-xr-x 7 roland users 568 2004-12-09 15:36:50 /tmp/test-restore/home/roland/ ueun47-fd: drwxr-xr-x 9 root root 200 2004-12-16 10:39:55 /tmp/test-restore/home/ 17-Dec 10:55 ueun47-sd: Got EOF at file 7 on device /dev/nst0, Volume "Volume01" 17-Dec 10:55 ueun47-sd: Reposition from (file:block) 7:1 to 7:0 17-Dec 10:56 ueun47-sd: Got EOF at file 7 on device /dev/nst0, Volume "Volume01" 17-Dec 10:56 ueun47-sd: Got EOF at file 8 on device /dev/nst0, Volume "Volume01" 17-Dec 10:56 ueun47-dir: Bacula 1.36.1 (24Nov04): 17-Dec-2004 10:56:29 JobId: 5 Job: RestoreFiles.2004-12-17_10.51.03 Client: ueun47-fd Start time: 17-Dec-2004 10:51:05 End time: 17-Dec-2004 10:56:29 Files Expected: 86 Files Restored: 24 Bytes Restored: 48,315 Rate: 0.1 KB/s FD Errors: 0 FD termination status: OK SD termination status: OK Termination: Restore OK -- warning file count mismatch 17-Dec 10:56 ueun47-dir: Begin pruning Jobs. 17-Dec 10:56 ueun47-dir: No Jobs found to prune. 17-Dec 10:56 ueun47-dir: Begin pruning Files. 17-Dec 10:56 ueun47-dir: No Files found to prune. 17-Dec 10:56 ueun47-dir: End auto prune. ---------------------------------------------------------------------- chemical - 12-18-2004 00:38 PST ---------------------------------------------------------------------- Ok, first I thought that this is a problem with the tape drive. I experimented several hours with starting all over every time (except the config), thought that the blocksize would not be 0 (but it was), that Forward Spacing perhaps does not find the correct mark, and stuff. Tried several things. Read manual, buglist, manual again. Now the following: Device { Name = LTO-10way # Media Type = LTO-10way Two EOF = Yes; BSF at EOM = Yes; Archive Device = /dev/nst0 AutomaticMount = yes; # when device opened, read it AutoChanger = yes; AlwaysOpen = yes; # drive wird von bacula-sd "gelockt" RemovableMedia = yes; RandomAccess = no; Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d" Changer Device = /dev/sg0 Alert Command = "sh -c 'tapeinfo -f /dev/sg1 |grep TapeAlert|cat'" } My current Deviceresource. Although I'm not sure the 'Two EOF' 'BSF at EOM' are needed or correct, nothing really changed anyway since adding them (and starting all over). Look at this: (above fileset, above jobdef, above machine, clean tapes, clean database) doing full backup of local machine. ok restoring via mark (cd home; mark roland; cd /var; mark log; done). restoring (worked perfectly!! whow! I did it! (at least I thought)). to be sure, restored from every 'file' in my fileset. ok, next one: restoring via mark (mark boot; mark home; cd var; mark log; cd /usr; mark local; done). it restored: /home. in the restore log I can see several Repositions and 'got EOF'. nothing more. Huh? Ok, lets try the first restore job again (exact the same!): restoring via mark (cd home; mark roland; cd /var; mark log; done). restored home/roland ok, then 'got EOF' and finished with warning? WTF? Hm. I seem to have serious compatibility error with my drive, or what is that? I remind: btape test runs ok with 0 errors!! Anyone else is using the Exabyte 110L LTO1 Autoloader on a SuSE 9.2 (disabled /lib/tls)? PS: Why is btape using 64k blocks every time? Is it possible to test with "variable" blocksizes here? Or did I get something wrong? ---------------------------------------------------------------------- kern - 12-18-2004 05:11 PST ---------------------------------------------------------------------- These are the kinds of problems that drive me crazy since they should *never* happen. You did a nice job of explaining what you did. On one point, I am, however, a bit confused. Did you try running your drive with freshly WEOFed tapes without the Two EOF = Yes; BSF at EOM = Yes; I suspect that you started without these. If not, please remove them and try again. In any case, if your drive passes the btape test without them, it is *much* better to leave them out. Can you start simpler to see if the basic functions work? Do the following: 1. Ensure you have a fresh tape (i.e. mt -f /dev/xxx rewind; mt -f /dev/xxx weof) 2. Ensure the above two directives are not in your Device resource. 3. Trim your FileSet down to one directory. 4. Backup 5. Try restoring. 6. If it fails, go back to step 3, trim it down to a smaller directory. 7. If at that point, you get no where, there is probably some compatibility problem with your drive, and we need to turn on debug during the restore. 8. If you are able to restore more than once, please experiment with increasing the number of directories in your fileset and see if the problem comes back. Maybe by incrementing up to the problem, we can isolate it. ---------------------------------------------------------------------- chemical - 12-19-2004 11:50 PST ---------------------------------------------------------------------- Device { Name = LTO-10way # Media Type = LTO-10way Archive Device = /dev/nst0 AutomaticMount = yes; # when device opened, read it AutoChanger = yes; AlwaysOpen = yes; # drive wird von bacula-sd "gelockt" RemovableMedia = yes; RandomAccess = no; Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d" Changer Device = /dev/sg0 Alert Command = "sh -c 'tapeinfo -f /dev/sg1 |grep TapeAlert|cat'" } running btape test - OK, no errors running btape fill - OK, no errors created database fileset changed to only one dir: /usr/src started bacula label barcodes estimated job 2000 OK estimate files=19991 bytes=241,080,300 -- FD Files Written: 19,991 SD Files Written: 19,991 FD Bytes Written: 241,080,300 SD Bytes Written: 243,730,860 -- job save ok restore to /tmp/xx1 mark usr; done Files Expected: 19,991 Files Restored: 19,991 ok restoring the same again to /tmp/xx2 Files Expected: 19,991 Files Restored: 19,991 ok adding full save behind first on same tape 19-Dec 18:12 ueun47-sd: 3302 Autochanger "loaded drive 0", result is Slot 1. 19-Dec 18:12 ueun47-sd: Volume "Volume01" previously written, moving to end of data. 19-Dec 18:12 ueun47-sd: Ready to append to end of Volume "Volume01" at file=1. FD Files Written: 19,991 SD Files Written: 19,991 FD Bytes Written: 241,080,300 SD Bytes Written: 243,730,860 saved again. restoring from second full job to /tmp/xx3 Files Expected: 19,991 Files Restored: 19,991 ok restoring /usr/src/linux-2.6.8-24-obj/i386/debug/scripts/bin2c from first and second full job list jobs. full backups are on jobid 1 and 4 restore, 3, jobid 1 mark /usr/src/linux-2.6.8-24-obj/i386/debug/scripts/bin2c; done restoring to /tmp/xx4 Files Expected: 2 Files Restored: 2 ok (2 files because hardlinked to linux-2.6.8-24-obj/i386/smp/scripts/bin2c, good work!) restore, 3, jobid 4 marking, done. restoring to /tmp/xx5 'Forward spacing to file:block 1:0' Files Expected: 2 Files Restored: 2 ok now adding second dir to fileset resource appending "/var/log" AFTER "/usr/src" in bacula-dir.conf reload run 19-Dec 18:29 ueun47-dir: Created new FileSet record "Full Set ueun47" 2004-12-19 18:29:04 19-Dec 18:29 ueun47-dir: No prior Full backup Job record found. 19-Dec 18:29 ueun47-dir: No prior or suitable Full backup found. Doing FULL backup. 19-Dec 18:29 ueun47-dir: Start Backup JobId 8, Job=ueun47.2004-12-19_18.29.02 19-Dec 18:29 ueun47-sd: 3301 Issuing autochanger "loaded drive 0" command. 19-Dec 18:29 ueun47-sd: 3302 Autochanger "loaded drive 0", result is Slot 1. 19-Dec 18:29 ueun47-sd: Volume "Volume01" previously written, moving to end of data. 19-Dec 18:29 ueun47-sd: Ready to append to end of Volume "Volume01" at file=2. FD Files Written: 20,047 SD Files Written: 20,047 FD Bytes Written: 245,124,904 SD Bytes Written: 247,780,677 job OK now restoring the above mentioned file from job 1 and 4 again (just to be sure). restoring from jobid 1: 19-Dec 18:34 ueun47-sd: Forward spacing to file:block 0:1. OK restoring from jobid 4: 19-Dec 18:37 ueun47-sd: Forward spacing to file:block 1:0. OK restoring the file from the new 2-dir job (jobid 8) 19-Dec 18:39 ueun47-sd: Forward spacing to file:block 2:0. OK restoring via "restore, 5" cd usr; mark src; 19,991 files marked. cd /; mark var; 56 files marked. relocate to /tmp/xx6 19-Dec 18:43 ueun47-sd: Forward spacing to file:block 2:0. Files Expected: 20,047 Files Restored: 20,047 OK the SAME again. restoring via "restore, 5" marking.. relocate to xx7 19-Dec 18:48 ueun47-sd: Forward spacing to file:block 2:0. Files Expected: 20,047 Files Restored: 20,047 OK the same again, but marking in reverse order. restore ,5 mark var; 56 files marked. cd /; cd usr; mark src; 19,991 files marked. relocate to /tmp/xx7 Files Expected: 20,047 Files Restored: 20,047 OK restoring /usr/src/linux from first full (jobid 1), just to be sure. restore, 3, jobid 1 cd usr; cd src; mark linux; 1 files marked. 19-Dec 19:00 ueun47-sd: Forward spacing to file:block 0:1. Files Expected: 1 Files Restored: 1 OK restoring /var/log (second fileset from last full): restore, 5 cd var; mark log; 56 files marked. relocate to /tmp/xx8 19-Dec 19:02 ueun47-sd: Forward spacing to file:block 2:0. Files Expected: 56 Files Restored: 56 OK Now adding "/" to fileset resource AFTER "/var/log": File = /usr/src File = /var/log File = / run full backup 19-Dec 19:04 ueun47-dir: Start Backup JobId 17, Job=ueun47.2004-12-19_19.04.29 19-Dec 19:04 ueun47-sd: 3301 Issuing autochanger "loaded drive 0" command. 19-Dec 19:04 ueun47-sd: 3302 Autochanger "loaded drive 0", result is Slot 1. 19-Dec 19:04 ueun47-sd: Volume "Volume01" previously written, moving to end of data. 19-Dec 19:04 ueun47-sd: Ready to append to end of Volume "Volume01" at file=3. ran incremental with 12 new files. damn. forgot to reload. ok, reload, same again. 19-Dec 19:06 ueun47-dir: Created new FileSet record "Full Set ueun47" 2004-12-19 19:06:05 19-Dec 19:06 ueun47-dir: No prior Full backup Job record found. 19-Dec 19:06 ueun47-dir: No prior or suitable Full backup found. Doing FULL backup. 19-Dec 19:06 ueun47-dir: Start Backup JobId 18, Job=ueun47.2004-12-19_19.06.03 FD Files Written: 93,502 SD Files Written: 93,502 OK Now restoring /var/log (in second fileset) from last full: restore, 5 cd var; mark log; 56 files marked. relocate to /tmp/xx9 19-Dec 19:32 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 19-Dec 19:32 ueun47-sd: Forward spacing to file:block 4:0. Files Expected: 56 Files Restored: 56 OK Now restoring /etc/ (in third fileset) from last full: restore, 5 mark etc; 4,117 files marked. relocate to /tmp/xx10 19-Dec 19:37 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 19-Dec 19:37 ueun47-sd: Forward spacing to file:block 4:0. Files Expected: 4,117 Files Restored: 4,117 OK Restoring /etc (3rd fileset) and /usr/src/linux (first fileset) from last full restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx11 19-Dec 19:40 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 19-Dec 19:40 ueun47-sd: Forward spacing to file:block 4:0. 19-Dec 19:41 ueun47-sd: Got EOF at file 5 on device /dev/nst0, Volume "Volume01" 19-Dec 19:41 ueun47-dir: Bacula 1.36.1 (24Nov04): 19-Dec-2004 19:41:07 Files Expected: 4,118 Files Restored: 0 Ok, there we have it. Restoring same files from last job in reverse order: cd usr; cd src; mark linux; 1 files marked. cd /; mark etc; 4,117 files marked. relocate to /tmp/xx12 19-Dec 19:46 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 19-Dec 19:46 ueun47-sd: Forward spacing to file:block 4:0. Files Expected: 4,118 Files Restored: 4,118 HUH? So if I mark the files as they are in order on the tape, it works - else, it does not. (IF there is a File in my fileset, that "includes" a directory from another File in that fileset?) I mean, if I save / I will get all mountpoints (like var or usr in my case) as empty directories in that fileset - but they are saved seperatly in different files). Could this be the problem? Just an assumption. Just to be sure. Reproducing: Restoring /etc (3rd fileset) and /usr/src/linux (first fileset) from last full restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx13 19-Dec 19:54 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 19-Dec 19:54 ueun47-sd: Forward spacing to file:block 4:0. Files Expected: 4,118 Files Restored: 4,118 WTF????? Why does it work now?? SAME again... restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx13 19-Dec 19:59 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 19-Dec 19:59 ueun47-sd: Forward spacing to file:block 4:0. 19-Dec 19:59 ueun47-sd: Got EOF at file 5 on device /dev/nst0, Volume "Volume01" Files Expected: 4,118 Files Restored: 0 Oh my. Where's that EOF coming from? And again.. restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx14 Files Expected: 4,118 Files Restored: 4,118 And again.. restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx15 Files Expected: 4,118 Files Restored: 0 And again.. restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx15 Files Expected: 4,118 Files Restored: 4,118 I'm scared how regular this is. Again? restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx15 Files Expected: 4,118 Files Restored: 4,118 ... I think we need to debug the tape somewhat. Should I try to run several btape tests in a row?? Perhaps it happens there, too. Perhaps the drive is not OK? But its a new one. ---------------------------------------------------------------------- kern - 12-21-2004 01:26 PST ---------------------------------------------------------------------- It looks to me like there is either a bug in Bacula (I don't see it here), or your drive (more likely your OS driver) has some strange problem of keeping track of where it is so Bacula gets positioned into the wrong file. I recommend as a start, the following: - Try to get the simplest case where it fails. The one you already have is probably OK. - Run the SD with -d100 - When it works, capture the output (one time), and upload it here as an attachment with a name like working.txt (the .txt is most important). - When it fails, then do the same, upload as fail.txt or something like that. This debug output should give us a better idea of what kind of detailed tape movement operations are being used. If you can, pull down the current version of 1.37.1 from the CVS, build it. This will allow me to make changes to the code and transmit them to you easier. Also, there is a new Device directive that *may* help you. Try running the same test on the same tape, with the same Device resource, but add: UseMTIOCGET = no This is implemented only on 1.37.1 and is *totally* experimental, but should be interesting to try. ---------------------------------------------------------------------- chemical - 12-22-2004 07:29 PST ---------------------------------------------------------------------- After several more tests I believe this is a non-software issue. As I'm not at work until Jan, 3rd I will have to wait. Kern: Thanks for your help. I will report back after I got the tape drive working cleanly. (After setting the drive and bacula into fixed mode (64K), I receive several floods into my /var/log/warn and bacula hangs during restore.) Dec 22 16:14:24 ueun47 kernel: st0: Error with sense data: Info fld=0x1, ILI Current st0: sense = f0 2b Dec 22 16:14:24 ueun47 kernel: Additional sense: Data phase error Dec 22 16:14:24 ueun47 kernel: st0: Error with sense data: Info fld=0x1, ILI Current st0: sense = f0 2b Dec 22 16:14:24 ueun47 kernel: Additional sense: Data phase error Dec 22 16:14:24 ueun47 kernel: st0: Error with sense data: Info fld=0x1, ILI Current st0: sense = f0 2b Dec 22 16:14:24 ueun47 kernel: Additional sense: Data phase error Dec 22 16:14:24 ueun47 kernel: st0: Error with sense data: Info fld=0x1, ILI Current st0: sense = f0 2b Dec 22 16:14:24 ueun47 kernel: Additional sense: Data phase error I'm currently not aware how to interpret the error. Bad Cable? Too long cable? Bad Device settings? Faulty Tape Drive? At least I'm sure this is not the fault of bacula. Even a clean tape will fail with: tar cWf /dev/st0 /usr After several files it stops with "Read failed" (with blocksize 0). Though I find it rather inconvenient that btape 'test' works perfectly. I report back if you want (next year). ---------------------------------------------------------------------- kern - 12-22-2004 09:32 PST ---------------------------------------------------------------------- Yes, please do report back. btape test may work because it doesn't write enough data. Another thing to try is a btape "fill" command. That should definitely stress the drive. Concerning the errors in the log. That is not a good sign. I'm not a hardware expert, so I don't know how to interpret it. Have a good holiday season. Bug History Date Modified Username Field Change ====================================================================== 12-16-04 07:57 chemical New Bug 12-16-04 08:12 chemical Bug Monitored: chemical 12-16-04 14:01 kern Bugnote Added: 0000549 12-16-04 14:01 kern Status new => feedback 12-17-04 00:27 chemical Bugnote Added: 0000553 12-17-04 00:29 chemical Bugnote Added: 0000554 12-17-04 00:39 chemical Bugnote Added: 0000555 12-17-04 02:07 chemical Bugnote Added: 0000556 12-18-04 00:38 chemical Bugnote Added: 0000559 12-18-04 05:11 kern Bugnote Added: 0000566 12-19-04 11:50 chemical Bugnote Added: 0000567 12-21-04 01:26 kern Bugnote Added: 0000569 12-22-04 07:29 chemical Bugnote Added: 0000582 12-22-04 09:32 kern Bugnote Added: 0000585 ====================================================================== |
From: <bac...@li...> - 2004-12-22 17:23:21
|
The following bug has been CLOSED ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000190 ====================================================================== Reported By: abuehler Assigned To: ====================================================================== Project: bacula Bug ID: 190 Category: configure/build process Reproducibility: always Severity: block Priority: normal Status: closed ====================================================================== Date Submitted: 12-02-2004 08:14 PST Last Modified: 12-22-2004 09:27 PST ====================================================================== Summary: Comile src/lib/bnet.c failes, missing protodefs for inet_aton() Description: The g++ version is 2.95.2. ------------------------------------ g++ -c -I/usr/local/include -I. -I.. -I/usr/local/include bnet.c bnet.c: In function `class dlist * bnet_host2ipaddrs(const char *, int, const char **)': bnet.c:620: implicit declaration of function `int inet_aton(...)' gmake[1]: *** [bnet.o] Error 1 ------------------------------------ There are also problems with inet_ntop(), because it is used in conjunction with ipv6, which is not supported by Solaris 2.6. ====================================================================== ---------------------------------------------------------------------- abuehler - 12-03-2004 01:29 PST ---------------------------------------------------------------------- The bnet.diff adds the function inet_aton(). HAVE_OLD_SOCKOPT is only set on Solaris 2.6, as far as I know. ---------------------------------------------------------------------- abuehler - 12-03-2004 01:40 PST ---------------------------------------------------------------------- The no_ipv6.diff adds preprocessor definitions for HAVE_IPV6 in bnet_server.c and address_conf.c. These two diffs allow for a successful compilation on Solaris 2.6. I will try a functionality test today. Please set the severity level to minor. ---------------------------------------------------------------------- kern - 12-03-2004 12:28 PST ---------------------------------------------------------------------- I am willing to take the bnet.diff, because it is probably reasonable that if one has the old sockopt one is not likely to have inet_aton(), though it *really* should be keyed on HAVE_INET_ATON. I am not prepared to take the second patch because you remove calls to several subroutines and error messages and key it on IPv6. This will break the code on most machines. The correct ifdefing is already present as far as I can tell. If the ifdefs are not correctly detected on your system, i.e. you do not have inet_ntop or inet_ntoa, then you will need to supply corrections to autoconf/configure.in or one of the other modules. ---------------------------------------------------------------------- abuehler - 12-03-2004 14:42 PST ---------------------------------------------------------------------- Setting a HAVE_INET_ATON or maybe a NEED_INET_ATON would be good idea, but I don't known much about setting up configure.in. The other patch has nothing to do with a wrong dectection of the inet_ntop function (which is present and working under Solaris 2.6). Configure detects the inet_ntop function right. But the parameters of the inet_ntop use ipv6 related structs or definitions. These are not present on Solaris 2.6. That was the reason why I choose the combination of the ifdefs in the no_ipv6.diff. In the no_ipv6.patch.txt I separate these ifdefs and use the inet_ntop. ---------------------------------------------------------------------- kern - 12-18-2004 03:07 PST ---------------------------------------------------------------------- I've added your replacement for inet_aton(), but put it in address_conf.c since it seems more logical there. I also started modifying the inet_ntop() code for another bug report (bad argument), then starting adding your code. In the end, to do it correctly, the #ifdefing became *really* messy and impossible to read, so I moved all the code into address_conf.c This simplified things enormously. The results are now in the CVS dated (18Nov04). If you could pull down the code and test it, I would appreciate it since I don't have any way to test the "old" networking code here. If the new code breaks or there are #ifdef problems, please reopen the bug report. ---------------------------------------------------------------------- abuehler - 12-21-2004 08:15 PST ---------------------------------------------------------------------- I have checked out the cvs and tried to compile the source. Two errors appeared: 1) typo error, *** address_conf.c.orig Mon Dec 20 11:09:40 2004 --- address_conf.c Mon Dec 20 11:33:11 2004 *************** *** 572,578 **** (void*)&(((struct sockaddr_in*)sa)->sin_addr) : (void*)&(((struct sockaddr_in6*)sa)->sin6_addr), # else ! (void*)&(((struct sockaddr_in*)sa)->sin_addr) : # endif /* HAVE_IPV6 */ buf, len); #else --- 572,578 ---- (void*)&(((struct sockaddr_in*)sa)->sin_addr) : (void*)&(((struct sockaddr_in6*)sa)->sin6_addr), # else ! (void*)&(((struct sockaddr_in*)sa)->sin_addr), # endif /* HAVE_IPV6 */ buf, len); #else 2) e.g. on linking bacula-fd ld: fatal: symbol `inet_aton(char const *, in_addr *)' is multiply defined: (file ../lib/libbac.a(bnet.o) and file ../lib/libbac.a(address_conf.o)); It seems that the inet_aton code is still present in bnet.c After correcting the mentioned typo and removing the inet_aton function from bnet.c the code compiles fine. Backup would run but the file daemon crashes afterwards. Should I raise a new bug report with the traceback? ---------------------------------------------------------------------- kern - 12-21-2004 09:00 PST ---------------------------------------------------------------------- Thanks for the fixes. I've now corrected them and put them in the CVS. It will take a few hours for them to be updated in the public CVS. If the crash in the FD occurs because of my changes and did not occur before, then please attach the traceback to this bug report (with extension .txt). If the crash in the FD has always been there, then please open a new bug report as it is probably not related to these changes. ---------------------------------------------------------------------- abuehler - 12-22-2004 02:03 PST ---------------------------------------------------------------------- The cvs version 1.37.1 (21Dec04) compiles fine now. Only some compiler warnings: "aggregate has a partly bracketed initializer" which also appeared in previous versions. I don't think the crashes where related to these changes, so I raised a new bug report http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000209. ---------------------------------------------------------------------- kern - 12-22-2004 09:27 PST ---------------------------------------------------------------------- OK, based on your last bug note, I'm closing this bug report. Thanks for helping me get the code working correctly. Fixed in 1.37.1 Bug History Date Modified Username Field Change ====================================================================== 12-02-04 08:14 abuehler New Bug 12-03-04 01:27 abuehler File Added: bnet.diff 12-03-04 01:29 abuehler Bugnote Added: 0000500 12-03-04 01:29 abuehler File Added: no_ipv6.diff 12-03-04 01:40 abuehler Bugnote Added: 0000501 12-03-04 12:28 kern Bugnote Added: 0000508 12-03-04 12:28 kern Description Updated 12-03-04 12:28 kern Status new => feedback 12-03-04 13:44 abuehler File Added: no_ipv6.patch.txt 12-03-04 14:42 abuehler Bugnote Added: 0000513 12-18-04 03:07 kern Bugnote Added: 0000561 12-18-04 03:07 kern Resolution open => fixed 12-18-04 03:07 kern Status feedback => closed 12-18-04 03:07 kern version 1.36.0 => 1.36.1 12-21-04 08:15 abuehler Bugnote Added: 0000576 12-21-04 08:15 abuehler Resolution fixed => reopened 12-21-04 08:15 abuehler Status closed => feedback 12-21-04 09:00 kern Bugnote Added: 0000577 12-22-04 02:03 abuehler Bugnote Added: 0000580 12-22-04 09:27 kern Bugnote Added: 0000584 12-22-04 09:27 kern Resolution reopened => fixed 12-22-04 09:27 kern Status feedback => closed ====================================================================== |
From: <bac...@li...> - 2004-12-22 17:20:52
|
The following bug requires your FEEDBACK. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000209 ====================================================================== Reported By: abuehler Assigned To: ====================================================================== Project: bacula Bug ID: 209 Category: File Daemon Reproducibility: always Severity: crash Priority: normal Status: feedback ====================================================================== Date Submitted: 12-21-2004 09:53 PST Last Modified: 12-22-2004 09:25 PST ====================================================================== Summary: FD crash after sucessfull backup Description: After sucessfull completion of the backup the FD crash. See attached traceback. In output of the "status client=albundy-fd" the job is not listed, but appears in "list jobs". ====================================================================== ---------------------------------------------------------------------- kern - 12-21-2004 10:10 PST ---------------------------------------------------------------------- The traceback doesn't seem to show the FD crashing. I recommend that you manually run it under the debugger. Then when it crashes, enter the following command: thread apply all bt Hopefully that will show where the problem lies. I suspect that the status client is showing nothing because either the job never ran or the FD crashed. If it crashes, any running jobs are lost and not reported if the FD is restarted (i.e. they are only written to the job history at the end of the job). ---------------------------------------------------------------------- abuehler - 12-22-2004 07:22 PST ---------------------------------------------------------------------- I've checked out the cvs 1.37.1 (21Dec04) and ran it with gdb. It seems the FD is getting SIGUSR2. After entering "continue" (>100 times) in gdb the FD terminates with SIGSEGV (gdbout.txt). I got a email notifcation with a failed backup. Next I've tried runing FD in foreground, set the debug level to 150 and redirect stdout and stderr to a file (debug-150.txt, omitted serveral lines). This time I got email notification with a "Backup OK" (debug-email.txt) and a backtrace mail (debug-trace.txt). ---------------------------------------------------------------------- kern - 12-22-2004 09:25 PST ---------------------------------------------------------------------- Thanks for your efforts. Please try running the FD under the debugger again as follows: gdb bacula-fd run -s -f -c bacula-fd.conf when it comes back to the command prompt (after crashing), enter: thread apply all bt Hopefully that will show me where the problem is. From the -dxxx trace, it seems like it is dying in some utility thread because after the seg fault, sending of the data to the SD continues ... Bug History Date Modified Username Field Change ====================================================================== 12-21-04 09:53 abuehler New Bug 12-21-04 09:53 abuehler File Added: traceback.txt 12-21-04 10:10 kern Bugnote Added: 0000579 12-22-04 07:22 abuehler Bugnote Added: 0000581 12-22-04 07:23 abuehler File Added: gdbout.txt 12-22-04 07:23 abuehler File Added: debug-150.txt 12-22-04 07:24 abuehler File Added: debug-email.txt 12-22-04 07:24 abuehler File Added: debug-trace.txt 12-22-04 09:25 kern Bugnote Added: 0000583 12-22-04 09:25 kern Status new => feedback ====================================================================== |
From: <bac...@li...> - 2004-12-22 15:24:58
|
A BUGNOTE has been added to this bug. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000205 ====================================================================== Reported By: chemical Assigned To: ====================================================================== Project: bacula Bug ID: 205 Category: Storage Daemon Reproducibility: always Severity: major Priority: normal Status: feedback ====================================================================== Date Submitted: 12-16-2004 07:57 PST Last Modified: 12-22-2004 07:29 PST ====================================================================== Summary: I am not able to restore files from backups Description: I have an autochanger with 10 LTOs connected to a Celeron Machine. btape test run through successfully on all tests. ====================================================================== ---------------------------------------------------------------------- kern - 12-16-2004 14:01 PST ---------------------------------------------------------------------- The job is not list 5 times in the database, there are just 5 tape files associated with the job. This is not a problem. Please attach include the *full* listing of how you were restoring your files. In the partial listing you include, I don't see that you selected any files. Also, please attach your bootstrap file (restore.bsr), but as restore.bsr.txt. ---------------------------------------------------------------------- chemical - 12-17-2004 00:27 PST ---------------------------------------------------------------------- Ok, lets do it again Sam: Stopped bacula, empty'd /var/bacula. Erased all tapes (again). Here are the job definitions of the client which will be saved+restored: -- JobDefs { Name = "ueun47Job" Type = Backup Level = Incremental Client = ueun47-fd FileSet = "Full Set ueun47" Schedule = "FlexCycle" Storage = LTO-10way Messages = Standard Pool = Default Priority = 10 } Job { Name = "ueun47" JobDefs = "ueun47Job" Write Bootstrap = "/var/bacula/ueun47.bsr" } FileSet { Name = "Full Set ueun47" Include { Options { signature = MD5 } File = / File = /home File = /usr File = /var File = /boot } Exclude { File = /proc File = /tmp File = /.journal File = /.fsck } } Client { Name = ueun47-fd Address = ueun47 FDPort = 9102 Catalog = MyCatalog Password = "xxx" # password for FileDaemon File Retention = 30 days # 30 days Job Retention = 3 months # six months AutoPrune = yes # Prune expired Jobs/Files } -- Now recreated bacula database+tables. Started bacula, "label barcodes" -> OK, all 10 Media label'd and added to Pool 'Default' Now, 'run': Select Job resource: ueun47 Run Backup job JobName: ueun47 FileSet: Full Set ueun47 Level: Incremental Client: ueun47-fd Storage: LTO-10way Pool: Default When: 2004-12-17 08:36:25 Priority: 10 OK to run? (yes/mod/no): yes ...... (no prior backup found, upgraded to full backup, loaded media 1, backupped all files) -- Backup OK, here is the log: -- 17-Dec 08:36 ueun47-dir: Created new FileSet record "Full Set ueun47" 2004-12-17 08:36:45 17-Dec 08:36 ueun47-dir: No prior Full backup Job record found. 17-Dec 08:36 ueun47-dir: No prior or suitable Full backup found. Doing FULL backup. 17-Dec 08:36 ueun47-dir: Start Backup JobId 1, Job=ueun47.2004-12-17_08.36.43 17-Dec 08:36 ueun47-sd: 3301 Issuing autochanger "loaded drive 0" command. 17-Dec 08:36 ueun47-sd: 3302 Autochanger "loaded drive 0", result is Slot 10. 17-Dec 08:36 ueun47-sd: 3303 Issuing autochanger "unload slot 10, drive 0" command. 17-Dec 08:37 ueun47-sd: 3304 Issuing autochanger "load slot 1, drive 0" command. 17-Dec 08:37 ueun47-sd: 3305 Autochanger "load slot 1, drive 0", status is OK. 17-Dec 08:38 ueun47-sd: Wrote label to prelabeled Volume "Volume01" on device "/dev/nst0" 17-Dec 09:00 ueun47-dir: Bacula 1.36.1 (24Nov04): 17-Dec-2004 09:00:13 JobId: 1 Job: ueun47.2004-12-17_08.36.43 Backup Level: Full (upgraded from Incremental) Client: ueun47-fd FileSet: "Full Set ueun47" 2004-12-17 08:36:45 Pool: "Default" Storage: "LTO-10way" Start time: 17-Dec-2004 08:36:45 End time: 17-Dec-2004 09:00:13 FD Files Written: 252,742 SD Files Written: 252,742 FD Bytes Written: 3,986,435,774 SD Bytes Written: 4,019,105,767 Rate: 2831.3 KB/s Software Compression: None Volume name(s): Volume01 Volume Session Id: 1 Volume Session Time: 1103267392 Last Volume Bytes: 4,030,576,870 Non-fatal FD errors: 0 SD Errors: 0 FD termination status: OK SD termination status: OK Termination: Backup OK 17-Dec 09:00 ueun47-dir: Begin pruning Jobs. 17-Dec 09:00 ueun47-dir: No Jobs found to prune. 17-Dec 09:00 ueun47-dir: Begin pruning Files. 17-Dec 09:00 ueun47-dir: No Files found to prune. 17-Dec 09:00 ueun47-dir: End auto prune. --- verify: * list jobs +-------+--------+---------------------+------+-------+----------+---------------+-----------+ | JobId | Name | StartTime | Type | Level | JobFiles | JobBytes | JobStatus | +-------+--------+---------------------+------+-------+----------+---------------+-----------+ | 1 | ueun47 | 2004-12-17 08:36:45 | B | F | 252,742 | 3,986,435,774 | T | +-------+--------+---------------------+------+-------+----------+---------------+-----------+ -- this is ok. now we're restoring from the backup: *restore To select the JobIds, you have the following choices: 1: List last 20 Jobs run 2: List Jobs where a given File is saved 3: Enter list of comma separated JobIds to select 4: Enter SQL list command 5: Select the most recent backup for a client 6: Select backup for a client before a specified time 7: Enter a list of files to restore 8: Enter a list of files to restore before a specified time 9: Cancel Select item: (1-9): 5 Automatically selected Client: ueun47-fd Automatically selected FileSet: Full Set ueun47 +-------+-------+----------+---------------------+------------+-----------+--------------+----------------+ | 1 | F | 252,742 | 2004-12-17 08:36:45 | Volume01 | 0 | 1 | 1,103,267,392 | | 1 | F | 252,742 | 2004-12-17 08:36:45 | Volume01 | 1 | 1 | 1,103,267,392 | | 1 | F | 252,742 | 2004-12-17 08:36:45 | Volume01 | 2 | 1 | 1,103,267,392 | | 1 | F | 252,742 | 2004-12-17 08:36:45 | Volume01 | 3 | 1 | 1,103,267,392 | | 1 | F | 252,742 | 2004-12-17 08:36:45 | Volume01 | 4 | 1 | 1,103,267,392 | +-------+-------+----------+---------------------+------------+-----------+--------------+----------------+ You have selected the following JobId: 1 Building directory tree for JobId 1 ... +++++++++++++++++++++++++++++++++++++++++++++++ 1 Job, 239,555 files inserted into the tree. You are now entering file selection mode where you add (mark) and remove (unmark) files to be restored. No files are initially added, unless you used the "all" keyword on the command line. Enter "done" to leave this mode. cwd is: / $ cd usr cwd is: /usr/ $ mark local 63 files marked. $ cd /home cwd is: /home/ $ mark roland 23 files marked. $ done Bootstrap records written to /var/bacula/restore.bsr The job will require the following Volumes: Volume01 86 files selected to be restored. Run Restore job JobName: RestoreFiles Bootstrap: /var/bacula/restore.bsr Where: / Replace: always FileSet: Full Set ueun47 Client: ueun47-fd Storage: LTO-10way When: 2004-12-17 09:03:25 Catalog: MyCatalog Priority: 10 OK to run? (yes/mod/no): (modified where from / to /tmp/test-restore) started job. Job started. JobId=2 .... Job told me, Restore OK: -- 17-Dec 09:04 ueun47-dir: Start Restore Job RestoreFiles.2004-12-17_09.04.15 17-Dec 09:06 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 17-Dec 09:06 ueun47-sd: Forward spacing to file:block 0:1. 17-Dec 09:06 ueun47-sd: Got EOF at file 1 on device /dev/nst0, Volume "Volume01" 17-Dec 09:06 ueun47-sd: Reposition from (file:block) 1:1 to 2:0 17-Dec 09:07 ueun47-sd: Got EOF at file 2 on device /dev/nst0, Volume "Volume01" 17-Dec 09:07 ueun47-sd: Got EOF at file 3 on device /dev/nst0, Volume "Volume01" 17-Dec 09:07 ueun47-sd: Reposition from (file:block) 3:1 to 3:0 17-Dec 09:08 ueun47-sd: Got EOF at file 2 on device /dev/nst0, Volume "Volume01" 17-Dec 09:08 ueun47-sd: Got EOF at file 3 on device /dev/nst0, Volume "Volume01" 17-Dec 09:08 ueun47-sd: End of Volume at file 3 on device /dev/nst0, Volume "Volume01" 17-Dec 09:08 ueun47-sd: End of all volumes. 17-Dec 09:08 ueun47-dir: Bacula 1.36.1 (24Nov04): 17-Dec-2004 09:08:35 JobId: 2 Job: RestoreFiles.2004-12-17_09.04.15 Client: ueun47-fd Start time: 17-Dec-2004 09:04:17 End time: 17-Dec-2004 09:08:35 Files Expected: 86 Files Restored: 0 Bytes Restored: 0 Rate: 0.0 KB/s FD Errors: 0 FD termination status: OK SD termination status: OK Termination: Restore OK -- warning file count mismatch 17-Dec 09:08 ueun47-dir: Begin pruning Jobs. 17-Dec 09:08 ueun47-dir: No Jobs found to prune. 17-Dec 09:08 ueun47-dir: Begin pruning Files. 17-Dec 09:08 ueun47-dir: No Files found to prune. 17-Dec 09:08 ueun47-dir: End auto prune. -- This is the content of my restore.bsr: -- ueun47:/var/bacula # cat restore.bsr Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=0 VolBlock=1-15499 FileIndex=73528-73550 FileIndex=73576 Count=24 Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=2 VolBlock=0-15499 FileIndex=137194-137256 Count=63 Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=3 VolBlock=0-15499 FileIndex=249701 Count=1 ueun47:/var/bacula # I hope that helps. What am I doing wrong? Has the fileset too many directories? Isn't it necessary to specify each "mount"/parition on that machine on a single "File = " entry? ---------------------------------------------------------------------- chemical - 12-17-2004 00:29 PST ---------------------------------------------------------------------- Before I forgot, here is the content of "ueun47.bsr": -- Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=0-0 VolBlock=1-15499 FileIndex=1-74439 Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=1-1 VolBlock=0-15499 FileIndex=74439-107081 Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=2-2 VolBlock=0-15499 FileIndex=107081-159432 Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=3-3 VolBlock=0-15499 FileIndex=159432-250436 Volume="Volume01" VolSessionId=1 VolSessionTime=1103267392 VolFile=4-4 VolBlock=0-478 FileIndex=250436-252742 -- ---------------------------------------------------------------------- chemical - 12-17-2004 00:39 PST ---------------------------------------------------------------------- A, I forgot the partition/mount list of the machine: ueun47:/var/bacula # df -k Filesystem 1K-blocks Used Available Use% Mounted on /dev/md2 4192764 1022916 3169848 25% / tmpfs 241484 24 241460 1% /dev/shm /dev/md0 38792 13437 23352 37% /boot /dev/md4 3140508 33560 3106948 2% /home /dev/md3 5244952 2986780 2258172 57% /usr /dev/md5 25405876 239832 25166044 1% /var ueun47:/var/bacula # ---------------------------------------------------------------------- chemical - 12-17-2004 02:07 PST ---------------------------------------------------------------------- The next interesting thing: I changed the order of the Include-File-Statements in the File Set Resource of "Full Set ueun47" (listed above) from: Include { Options { signature = MD5 } File = / File = /home File = /usr File = /var File = /boot } to: Include { Options { signature = MD5 } File = /home File = /usr File = /var File = /boot File = / } Bacula did a full backup again (ok). Now the SAME restore job (like listed above, first mark /home/roland, 23 files, then mark /usr/local, 63 files) does the following: The files marked in /home" were restored successfully, complete. The files in /usr were NOT restored! So it looks to me that bacula is only able to recover from the FIRST file of a file set. Like already said, the btape test worked successfully, no problems at all. Here is the restore.bsr of this run: -- Volume="Volume01" VolSessionId=2 VolSessionTime=1103273991 VolFile=5 VolBlock=0-15499 FileIndex=71-93 FileIndex=119 Count=24 Volume="Volume01" VolSessionId=2 VolSessionTime=1103273991 VolFile=6 VolBlock=0-15499 FileIndex=63737-63799 Count=63 Volume="Volume01" VolSessionId=2 VolSessionTime=1103273991 VolFile=7 VolBlock=0-15499 FileIndex=176244 Count=1 -- The result message of the restore: -- 17-Dec 10:51 ueun47-dir: Start Restore Job RestoreFiles.2004-12-17_10.51.03 17-Dec 10:51 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 17-Dec 10:51 ueun47-sd: Forward spacing to file:block 5:0. 17-Dec 10:54 ueun47-sd: Reposition from (file:block) 5:11 to 6:0 ueun47-fd: drwxr-xr-x 2 roland users 48 2004-12-09 15:36:50 /tmp/test-restore/home/roland/bin/ ueun47-fd: -rw-r--r-- 1 roland users 1106 2004-12-09 15:36:50 /tmp/test-restore/home/roland/Documents/.directory ueun47-fd: drwxr-xr-x 2 roland users 80 2004-12-09 15:36:50 /tmp/test-restore/home/roland/Documents/ ueun47-fd: -rw-r--r-- 1 roland users 1124 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.exrc ueun47-fd: -rw-r--r-- 1 roland users 1286 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.bashrc ueun47-fd: -rw-r--r-- 1 roland users 164 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.kermrc ueun47-fd: -rw-r--r-- 1 roland users 6148 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.muttrc ueun47-fd: -rw-r--r-- 1 roland users 48 2004-12-09 15:36:50 /tmp/test-restore/home/roland/public_html/.directory ueun47-fd: drwxr-xr-x 2 roland users 80 2004-12-09 15:36:50 /tmp/test-restore/home/roland/public_html/ ueun47-fd: -rw-r--r-- 1 roland users 311 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.urlview ueun47-fd: -rw-r--r-- 1 roland users 1033 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.xemacs/init.el ueun47-fd: drwxr-xr-x 2 roland users 72 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.xemacs/ ueun47-fd: -rw------- 1 roland users 5 2004-12-15 15:11:32 /tmp/test-restore/home/roland/.bash_history ueun47-fd: -rwxr-xr-x 1 roland users 3055 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.xinitrc.template ueun47-fd: -rw-r--r-- 1 roland users 934 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.profile ueun47-fd: -rw-r--r-- 1 roland users 7913 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.xcoralrc ueun47-fd: -rw-r--r-- 1 roland users 1637 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.emacs ueun47-fd: drwxr-xr-x 2 roland users 48 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.fonts/ ueun47-fd: -r--r--r-- 1 roland users 16035 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.gnu-emacs ueun47-fd: -rwxr-xr-x 1 roland users 7189 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.xim.template ueun47-fd: -rw-r--r-- 1 roland users 119 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.xtalkrc ueun47-fd: -rw-r--r-- 1 roland users 208 2004-12-09 15:36:50 /tmp/test-restore/home/roland/.dvipsrc ueun47-fd: drwxr-xr-x 7 roland users 568 2004-12-09 15:36:50 /tmp/test-restore/home/roland/ ueun47-fd: drwxr-xr-x 9 root root 200 2004-12-16 10:39:55 /tmp/test-restore/home/ 17-Dec 10:55 ueun47-sd: Got EOF at file 7 on device /dev/nst0, Volume "Volume01" 17-Dec 10:55 ueun47-sd: Reposition from (file:block) 7:1 to 7:0 17-Dec 10:56 ueun47-sd: Got EOF at file 7 on device /dev/nst0, Volume "Volume01" 17-Dec 10:56 ueun47-sd: Got EOF at file 8 on device /dev/nst0, Volume "Volume01" 17-Dec 10:56 ueun47-dir: Bacula 1.36.1 (24Nov04): 17-Dec-2004 10:56:29 JobId: 5 Job: RestoreFiles.2004-12-17_10.51.03 Client: ueun47-fd Start time: 17-Dec-2004 10:51:05 End time: 17-Dec-2004 10:56:29 Files Expected: 86 Files Restored: 24 Bytes Restored: 48,315 Rate: 0.1 KB/s FD Errors: 0 FD termination status: OK SD termination status: OK Termination: Restore OK -- warning file count mismatch 17-Dec 10:56 ueun47-dir: Begin pruning Jobs. 17-Dec 10:56 ueun47-dir: No Jobs found to prune. 17-Dec 10:56 ueun47-dir: Begin pruning Files. 17-Dec 10:56 ueun47-dir: No Files found to prune. 17-Dec 10:56 ueun47-dir: End auto prune. ---------------------------------------------------------------------- chemical - 12-18-2004 00:38 PST ---------------------------------------------------------------------- Ok, first I thought that this is a problem with the tape drive. I experimented several hours with starting all over every time (except the config), thought that the blocksize would not be 0 (but it was), that Forward Spacing perhaps does not find the correct mark, and stuff. Tried several things. Read manual, buglist, manual again. Now the following: Device { Name = LTO-10way # Media Type = LTO-10way Two EOF = Yes; BSF at EOM = Yes; Archive Device = /dev/nst0 AutomaticMount = yes; # when device opened, read it AutoChanger = yes; AlwaysOpen = yes; # drive wird von bacula-sd "gelockt" RemovableMedia = yes; RandomAccess = no; Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d" Changer Device = /dev/sg0 Alert Command = "sh -c 'tapeinfo -f /dev/sg1 |grep TapeAlert|cat'" } My current Deviceresource. Although I'm not sure the 'Two EOF' 'BSF at EOM' are needed or correct, nothing really changed anyway since adding them (and starting all over). Look at this: (above fileset, above jobdef, above machine, clean tapes, clean database) doing full backup of local machine. ok restoring via mark (cd home; mark roland; cd /var; mark log; done). restoring (worked perfectly!! whow! I did it! (at least I thought)). to be sure, restored from every 'file' in my fileset. ok, next one: restoring via mark (mark boot; mark home; cd var; mark log; cd /usr; mark local; done). it restored: /home. in the restore log I can see several Repositions and 'got EOF'. nothing more. Huh? Ok, lets try the first restore job again (exact the same!): restoring via mark (cd home; mark roland; cd /var; mark log; done). restored home/roland ok, then 'got EOF' and finished with warning? WTF? Hm. I seem to have serious compatibility error with my drive, or what is that? I remind: btape test runs ok with 0 errors!! Anyone else is using the Exabyte 110L LTO1 Autoloader on a SuSE 9.2 (disabled /lib/tls)? PS: Why is btape using 64k blocks every time? Is it possible to test with "variable" blocksizes here? Or did I get something wrong? ---------------------------------------------------------------------- kern - 12-18-2004 05:11 PST ---------------------------------------------------------------------- These are the kinds of problems that drive me crazy since they should *never* happen. You did a nice job of explaining what you did. On one point, I am, however, a bit confused. Did you try running your drive with freshly WEOFed tapes without the Two EOF = Yes; BSF at EOM = Yes; I suspect that you started without these. If not, please remove them and try again. In any case, if your drive passes the btape test without them, it is *much* better to leave them out. Can you start simpler to see if the basic functions work? Do the following: 1. Ensure you have a fresh tape (i.e. mt -f /dev/xxx rewind; mt -f /dev/xxx weof) 2. Ensure the above two directives are not in your Device resource. 3. Trim your FileSet down to one directory. 4. Backup 5. Try restoring. 6. If it fails, go back to step 3, trim it down to a smaller directory. 7. If at that point, you get no where, there is probably some compatibility problem with your drive, and we need to turn on debug during the restore. 8. If you are able to restore more than once, please experiment with increasing the number of directories in your fileset and see if the problem comes back. Maybe by incrementing up to the problem, we can isolate it. ---------------------------------------------------------------------- chemical - 12-19-2004 11:50 PST ---------------------------------------------------------------------- Device { Name = LTO-10way # Media Type = LTO-10way Archive Device = /dev/nst0 AutomaticMount = yes; # when device opened, read it AutoChanger = yes; AlwaysOpen = yes; # drive wird von bacula-sd "gelockt" RemovableMedia = yes; RandomAccess = no; Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d" Changer Device = /dev/sg0 Alert Command = "sh -c 'tapeinfo -f /dev/sg1 |grep TapeAlert|cat'" } running btape test - OK, no errors running btape fill - OK, no errors created database fileset changed to only one dir: /usr/src started bacula label barcodes estimated job 2000 OK estimate files=19991 bytes=241,080,300 -- FD Files Written: 19,991 SD Files Written: 19,991 FD Bytes Written: 241,080,300 SD Bytes Written: 243,730,860 -- job save ok restore to /tmp/xx1 mark usr; done Files Expected: 19,991 Files Restored: 19,991 ok restoring the same again to /tmp/xx2 Files Expected: 19,991 Files Restored: 19,991 ok adding full save behind first on same tape 19-Dec 18:12 ueun47-sd: 3302 Autochanger "loaded drive 0", result is Slot 1. 19-Dec 18:12 ueun47-sd: Volume "Volume01" previously written, moving to end of data. 19-Dec 18:12 ueun47-sd: Ready to append to end of Volume "Volume01" at file=1. FD Files Written: 19,991 SD Files Written: 19,991 FD Bytes Written: 241,080,300 SD Bytes Written: 243,730,860 saved again. restoring from second full job to /tmp/xx3 Files Expected: 19,991 Files Restored: 19,991 ok restoring /usr/src/linux-2.6.8-24-obj/i386/debug/scripts/bin2c from first and second full job list jobs. full backups are on jobid 1 and 4 restore, 3, jobid 1 mark /usr/src/linux-2.6.8-24-obj/i386/debug/scripts/bin2c; done restoring to /tmp/xx4 Files Expected: 2 Files Restored: 2 ok (2 files because hardlinked to linux-2.6.8-24-obj/i386/smp/scripts/bin2c, good work!) restore, 3, jobid 4 marking, done. restoring to /tmp/xx5 'Forward spacing to file:block 1:0' Files Expected: 2 Files Restored: 2 ok now adding second dir to fileset resource appending "/var/log" AFTER "/usr/src" in bacula-dir.conf reload run 19-Dec 18:29 ueun47-dir: Created new FileSet record "Full Set ueun47" 2004-12-19 18:29:04 19-Dec 18:29 ueun47-dir: No prior Full backup Job record found. 19-Dec 18:29 ueun47-dir: No prior or suitable Full backup found. Doing FULL backup. 19-Dec 18:29 ueun47-dir: Start Backup JobId 8, Job=ueun47.2004-12-19_18.29.02 19-Dec 18:29 ueun47-sd: 3301 Issuing autochanger "loaded drive 0" command. 19-Dec 18:29 ueun47-sd: 3302 Autochanger "loaded drive 0", result is Slot 1. 19-Dec 18:29 ueun47-sd: Volume "Volume01" previously written, moving to end of data. 19-Dec 18:29 ueun47-sd: Ready to append to end of Volume "Volume01" at file=2. FD Files Written: 20,047 SD Files Written: 20,047 FD Bytes Written: 245,124,904 SD Bytes Written: 247,780,677 job OK now restoring the above mentioned file from job 1 and 4 again (just to be sure). restoring from jobid 1: 19-Dec 18:34 ueun47-sd: Forward spacing to file:block 0:1. OK restoring from jobid 4: 19-Dec 18:37 ueun47-sd: Forward spacing to file:block 1:0. OK restoring the file from the new 2-dir job (jobid 8) 19-Dec 18:39 ueun47-sd: Forward spacing to file:block 2:0. OK restoring via "restore, 5" cd usr; mark src; 19,991 files marked. cd /; mark var; 56 files marked. relocate to /tmp/xx6 19-Dec 18:43 ueun47-sd: Forward spacing to file:block 2:0. Files Expected: 20,047 Files Restored: 20,047 OK the SAME again. restoring via "restore, 5" marking.. relocate to xx7 19-Dec 18:48 ueun47-sd: Forward spacing to file:block 2:0. Files Expected: 20,047 Files Restored: 20,047 OK the same again, but marking in reverse order. restore ,5 mark var; 56 files marked. cd /; cd usr; mark src; 19,991 files marked. relocate to /tmp/xx7 Files Expected: 20,047 Files Restored: 20,047 OK restoring /usr/src/linux from first full (jobid 1), just to be sure. restore, 3, jobid 1 cd usr; cd src; mark linux; 1 files marked. 19-Dec 19:00 ueun47-sd: Forward spacing to file:block 0:1. Files Expected: 1 Files Restored: 1 OK restoring /var/log (second fileset from last full): restore, 5 cd var; mark log; 56 files marked. relocate to /tmp/xx8 19-Dec 19:02 ueun47-sd: Forward spacing to file:block 2:0. Files Expected: 56 Files Restored: 56 OK Now adding "/" to fileset resource AFTER "/var/log": File = /usr/src File = /var/log File = / run full backup 19-Dec 19:04 ueun47-dir: Start Backup JobId 17, Job=ueun47.2004-12-19_19.04.29 19-Dec 19:04 ueun47-sd: 3301 Issuing autochanger "loaded drive 0" command. 19-Dec 19:04 ueun47-sd: 3302 Autochanger "loaded drive 0", result is Slot 1. 19-Dec 19:04 ueun47-sd: Volume "Volume01" previously written, moving to end of data. 19-Dec 19:04 ueun47-sd: Ready to append to end of Volume "Volume01" at file=3. ran incremental with 12 new files. damn. forgot to reload. ok, reload, same again. 19-Dec 19:06 ueun47-dir: Created new FileSet record "Full Set ueun47" 2004-12-19 19:06:05 19-Dec 19:06 ueun47-dir: No prior Full backup Job record found. 19-Dec 19:06 ueun47-dir: No prior or suitable Full backup found. Doing FULL backup. 19-Dec 19:06 ueun47-dir: Start Backup JobId 18, Job=ueun47.2004-12-19_19.06.03 FD Files Written: 93,502 SD Files Written: 93,502 OK Now restoring /var/log (in second fileset) from last full: restore, 5 cd var; mark log; 56 files marked. relocate to /tmp/xx9 19-Dec 19:32 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 19-Dec 19:32 ueun47-sd: Forward spacing to file:block 4:0. Files Expected: 56 Files Restored: 56 OK Now restoring /etc/ (in third fileset) from last full: restore, 5 mark etc; 4,117 files marked. relocate to /tmp/xx10 19-Dec 19:37 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 19-Dec 19:37 ueun47-sd: Forward spacing to file:block 4:0. Files Expected: 4,117 Files Restored: 4,117 OK Restoring /etc (3rd fileset) and /usr/src/linux (first fileset) from last full restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx11 19-Dec 19:40 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 19-Dec 19:40 ueun47-sd: Forward spacing to file:block 4:0. 19-Dec 19:41 ueun47-sd: Got EOF at file 5 on device /dev/nst0, Volume "Volume01" 19-Dec 19:41 ueun47-dir: Bacula 1.36.1 (24Nov04): 19-Dec-2004 19:41:07 Files Expected: 4,118 Files Restored: 0 Ok, there we have it. Restoring same files from last job in reverse order: cd usr; cd src; mark linux; 1 files marked. cd /; mark etc; 4,117 files marked. relocate to /tmp/xx12 19-Dec 19:46 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 19-Dec 19:46 ueun47-sd: Forward spacing to file:block 4:0. Files Expected: 4,118 Files Restored: 4,118 HUH? So if I mark the files as they are in order on the tape, it works - else, it does not. (IF there is a File in my fileset, that "includes" a directory from another File in that fileset?) I mean, if I save / I will get all mountpoints (like var or usr in my case) as empty directories in that fileset - but they are saved seperatly in different files). Could this be the problem? Just an assumption. Just to be sure. Reproducing: Restoring /etc (3rd fileset) and /usr/src/linux (first fileset) from last full restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx13 19-Dec 19:54 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 19-Dec 19:54 ueun47-sd: Forward spacing to file:block 4:0. Files Expected: 4,118 Files Restored: 4,118 WTF????? Why does it work now?? SAME again... restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx13 19-Dec 19:59 ueun47-sd: Ready to read from volume "Volume01" on device /dev/nst0. 19-Dec 19:59 ueun47-sd: Forward spacing to file:block 4:0. 19-Dec 19:59 ueun47-sd: Got EOF at file 5 on device /dev/nst0, Volume "Volume01" Files Expected: 4,118 Files Restored: 0 Oh my. Where's that EOF coming from? And again.. restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx14 Files Expected: 4,118 Files Restored: 4,118 And again.. restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx15 Files Expected: 4,118 Files Restored: 0 And again.. restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx15 Files Expected: 4,118 Files Restored: 4,118 I'm scared how regular this is. Again? restore 5 mark etc; 4,117 files marked. cd usr; cd src; mark linux; 1 files marked. relocate to /tmp/xx15 Files Expected: 4,118 Files Restored: 4,118 ... I think we need to debug the tape somewhat. Should I try to run several btape tests in a row?? Perhaps it happens there, too. Perhaps the drive is not OK? But its a new one. ---------------------------------------------------------------------- kern - 12-21-2004 01:26 PST ---------------------------------------------------------------------- It looks to me like there is either a bug in Bacula (I don't see it here), or your drive (more likely your OS driver) has some strange problem of keeping track of where it is so Bacula gets positioned into the wrong file. I recommend as a start, the following: - Try to get the simplest case where it fails. The one you already have is probably OK. - Run the SD with -d100 - When it works, capture the output (one time), and upload it here as an attachment with a name like working.txt (the .txt is most important). - When it fails, then do the same, upload as fail.txt or something like that. This debug output should give us a better idea of what kind of detailed tape movement operations are being used. If you can, pull down the current version of 1.37.1 from the CVS, build it. This will allow me to make changes to the code and transmit them to you easier. Also, there is a new Device directive that *may* help you. Try running the same test on the same tape, with the same Device resource, but add: UseMTIOCGET = no This is implemented only on 1.37.1 and is *totally* experimental, but should be interesting to try. ---------------------------------------------------------------------- chemical - 12-22-2004 07:29 PST ---------------------------------------------------------------------- After several more tests I believe this is a non-software issue. As I'm not at work until Jan, 3rd I will have to wait. Kern: Thanks for your help. I will report back after I got the tape drive working cleanly. (After setting the drive and bacula into fixed mode (64K), I receive several floods into my /var/log/warn and bacula hangs during restore.) Dec 22 16:14:24 ueun47 kernel: st0: Error with sense data: Info fld=0x1, ILI Current st0: sense = f0 2b Dec 22 16:14:24 ueun47 kernel: Additional sense: Data phase error Dec 22 16:14:24 ueun47 kernel: st0: Error with sense data: Info fld=0x1, ILI Current st0: sense = f0 2b Dec 22 16:14:24 ueun47 kernel: Additional sense: Data phase error Dec 22 16:14:24 ueun47 kernel: st0: Error with sense data: Info fld=0x1, ILI Current st0: sense = f0 2b Dec 22 16:14:24 ueun47 kernel: Additional sense: Data phase error Dec 22 16:14:24 ueun47 kernel: st0: Error with sense data: Info fld=0x1, ILI Current st0: sense = f0 2b Dec 22 16:14:24 ueun47 kernel: Additional sense: Data phase error I'm currently not aware how to interpret the error. Bad Cable? Too long cable? Bad Device settings? Faulty Tape Drive? At least I'm sure this is not the fault of bacula. Even a clean tape will fail with: tar cWf /dev/st0 /usr After several files it stops with "Read failed" (with blocksize 0). Though I find it rather inconvenient that btape 'test' works perfectly. I report back if you want (next year). Bug History Date Modified Username Field Change ====================================================================== 12-16-04 07:57 chemical New Bug 12-16-04 08:12 chemical Bug Monitored: chemical 12-16-04 14:01 kern Bugnote Added: 0000549 12-16-04 14:01 kern Status new => feedback 12-17-04 00:27 chemical Bugnote Added: 0000553 12-17-04 00:29 chemical Bugnote Added: 0000554 12-17-04 00:39 chemical Bugnote Added: 0000555 12-17-04 02:07 chemical Bugnote Added: 0000556 12-18-04 00:38 chemical Bugnote Added: 0000559 12-18-04 05:11 kern Bugnote Added: 0000566 12-19-04 11:50 chemical Bugnote Added: 0000567 12-21-04 01:26 kern Bugnote Added: 0000569 12-22-04 07:29 chemical Bugnote Added: 0000582 ====================================================================== |
From: <bac...@li...> - 2004-12-22 15:18:11
|
A BUGNOTE has been added to this bug. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000209 ====================================================================== Reported By: abuehler Assigned To: ====================================================================== Project: bacula Bug ID: 209 Category: File Daemon Reproducibility: always Severity: crash Priority: normal Status: new ====================================================================== Date Submitted: 12-21-2004 09:53 PST Last Modified: 12-22-2004 07:22 PST ====================================================================== Summary: FD crash after sucessfull backup Description: After sucessfull completion of the backup the FD crash. See attached traceback. In output of the "status client=albundy-fd" the job is not listed, but appears in "list jobs". ====================================================================== ---------------------------------------------------------------------- kern - 12-21-2004 10:10 PST ---------------------------------------------------------------------- The traceback doesn't seem to show the FD crashing. I recommend that you manually run it under the debugger. Then when it crashes, enter the following command: thread apply all bt Hopefully that will show where the problem lies. I suspect that the status client is showing nothing because either the job never ran or the FD crashed. If it crashes, any running jobs are lost and not reported if the FD is restarted (i.e. they are only written to the job history at the end of the job). ---------------------------------------------------------------------- abuehler - 12-22-2004 07:22 PST ---------------------------------------------------------------------- I've checked out the cvs 1.37.1 (21Dec04) and ran it with gdb. It seems the FD is getting SIGUSR2. After entering "continue" (>100 times) in gdb the FD terminates with SIGSEGV (gdbout.txt). I got a email notifcation with a failed backup. Next I've tried runing FD in foreground, set the debug level to 150 and redirect stdout and stderr to a file (debug-150.txt, omitted serveral lines). This time I got email notification with a "Backup OK" (debug-email.txt) and a backtrace mail (debug-trace.txt). Bug History Date Modified Username Field Change ====================================================================== 12-21-04 09:53 abuehler New Bug 12-21-04 09:53 abuehler File Added: traceback.txt 12-21-04 10:10 kern Bugnote Added: 0000579 12-22-04 07:22 abuehler Bugnote Added: 0000581 ====================================================================== |
From: <bac...@li...> - 2004-12-22 09:59:32
|
A BUGNOTE has been added to this bug. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000190 ====================================================================== Reported By: abuehler Assigned To: ====================================================================== Project: bacula Bug ID: 190 Category: configure/build process Reproducibility: always Severity: block Priority: normal Status: feedback ====================================================================== Date Submitted: 12-02-2004 08:14 PST Last Modified: 12-22-2004 02:03 PST ====================================================================== Summary: Comile src/lib/bnet.c failes, missing protodefs for inet_aton() Description: The g++ version is 2.95.2. ------------------------------------ g++ -c -I/usr/local/include -I. -I.. -I/usr/local/include bnet.c bnet.c: In function `class dlist * bnet_host2ipaddrs(const char *, int, const char **)': bnet.c:620: implicit declaration of function `int inet_aton(...)' gmake[1]: *** [bnet.o] Error 1 ------------------------------------ There are also problems with inet_ntop(), because it is used in conjunction with ipv6, which is not supported by Solaris 2.6. ====================================================================== ---------------------------------------------------------------------- abuehler - 12-03-2004 01:29 PST ---------------------------------------------------------------------- The bnet.diff adds the function inet_aton(). HAVE_OLD_SOCKOPT is only set on Solaris 2.6, as far as I know. ---------------------------------------------------------------------- abuehler - 12-03-2004 01:40 PST ---------------------------------------------------------------------- The no_ipv6.diff adds preprocessor definitions for HAVE_IPV6 in bnet_server.c and address_conf.c. These two diffs allow for a successful compilation on Solaris 2.6. I will try a functionality test today. Please set the severity level to minor. ---------------------------------------------------------------------- kern - 12-03-2004 12:28 PST ---------------------------------------------------------------------- I am willing to take the bnet.diff, because it is probably reasonable that if one has the old sockopt one is not likely to have inet_aton(), though it *really* should be keyed on HAVE_INET_ATON. I am not prepared to take the second patch because you remove calls to several subroutines and error messages and key it on IPv6. This will break the code on most machines. The correct ifdefing is already present as far as I can tell. If the ifdefs are not correctly detected on your system, i.e. you do not have inet_ntop or inet_ntoa, then you will need to supply corrections to autoconf/configure.in or one of the other modules. ---------------------------------------------------------------------- abuehler - 12-03-2004 14:42 PST ---------------------------------------------------------------------- Setting a HAVE_INET_ATON or maybe a NEED_INET_ATON would be good idea, but I don't known much about setting up configure.in. The other patch has nothing to do with a wrong dectection of the inet_ntop function (which is present and working under Solaris 2.6). Configure detects the inet_ntop function right. But the parameters of the inet_ntop use ipv6 related structs or definitions. These are not present on Solaris 2.6. That was the reason why I choose the combination of the ifdefs in the no_ipv6.diff. In the no_ipv6.patch.txt I separate these ifdefs and use the inet_ntop. ---------------------------------------------------------------------- kern - 12-18-2004 03:07 PST ---------------------------------------------------------------------- I've added your replacement for inet_aton(), but put it in address_conf.c since it seems more logical there. I also started modifying the inet_ntop() code for another bug report (bad argument), then starting adding your code. In the end, to do it correctly, the #ifdefing became *really* messy and impossible to read, so I moved all the code into address_conf.c This simplified things enormously. The results are now in the CVS dated (18Nov04). If you could pull down the code and test it, I would appreciate it since I don't have any way to test the "old" networking code here. If the new code breaks or there are #ifdef problems, please reopen the bug report. ---------------------------------------------------------------------- abuehler - 12-21-2004 08:15 PST ---------------------------------------------------------------------- I have checked out the cvs and tried to compile the source. Two errors appeared: 1) typo error, *** address_conf.c.orig Mon Dec 20 11:09:40 2004 --- address_conf.c Mon Dec 20 11:33:11 2004 *************** *** 572,578 **** (void*)&(((struct sockaddr_in*)sa)->sin_addr) : (void*)&(((struct sockaddr_in6*)sa)->sin6_addr), # else ! (void*)&(((struct sockaddr_in*)sa)->sin_addr) : # endif /* HAVE_IPV6 */ buf, len); #else --- 572,578 ---- (void*)&(((struct sockaddr_in*)sa)->sin_addr) : (void*)&(((struct sockaddr_in6*)sa)->sin6_addr), # else ! (void*)&(((struct sockaddr_in*)sa)->sin_addr), # endif /* HAVE_IPV6 */ buf, len); #else 2) e.g. on linking bacula-fd ld: fatal: symbol `inet_aton(char const *, in_addr *)' is multiply defined: (file ../lib/libbac.a(bnet.o) and file ../lib/libbac.a(address_conf.o)); It seems that the inet_aton code is still present in bnet.c After correcting the mentioned typo and removing the inet_aton function from bnet.c the code compiles fine. Backup would run but the file daemon crashes afterwards. Should I raise a new bug report with the traceback? ---------------------------------------------------------------------- kern - 12-21-2004 09:00 PST ---------------------------------------------------------------------- Thanks for the fixes. I've now corrected them and put them in the CVS. It will take a few hours for them to be updated in the public CVS. If the crash in the FD occurs because of my changes and did not occur before, then please attach the traceback to this bug report (with extension .txt). If the crash in the FD has always been there, then please open a new bug report as it is probably not related to these changes. ---------------------------------------------------------------------- abuehler - 12-22-2004 02:03 PST ---------------------------------------------------------------------- The cvs version 1.37.1 (21Dec04) compiles fine now. Only some compiler warnings: "aggregate has a partly bracketed initializer" which also appeared in previous versions. I don't think the crashes where related to these changes, so I raised a new bug report http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000209. Bug History Date Modified Username Field Change ====================================================================== 12-02-04 08:14 abuehler New Bug 12-03-04 01:27 abuehler File Added: bnet.diff 12-03-04 01:29 abuehler Bugnote Added: 0000500 12-03-04 01:29 abuehler File Added: no_ipv6.diff 12-03-04 01:40 abuehler Bugnote Added: 0000501 12-03-04 12:28 kern Bugnote Added: 0000508 12-03-04 12:28 kern Description Updated 12-03-04 12:28 kern Status new => feedback 12-03-04 13:44 abuehler File Added: no_ipv6.patch.txt 12-03-04 14:42 abuehler Bugnote Added: 0000513 12-18-04 03:07 kern Bugnote Added: 0000561 12-18-04 03:07 kern Resolution open => fixed 12-18-04 03:07 kern Status feedback => closed 12-18-04 03:07 kern version 1.36.0 => 1.36.1 12-21-04 08:15 abuehler Bugnote Added: 0000576 12-21-04 08:15 abuehler Resolution fixed => reopened 12-21-04 08:15 abuehler Status closed => feedback 12-21-04 09:00 kern Bugnote Added: 0000577 12-22-04 02:03 abuehler Bugnote Added: 0000580 ====================================================================== |
From: <bac...@li...> - 2004-12-21 18:05:46
|
A BUGNOTE has been added to this bug. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000209 ====================================================================== Reported By: abuehler Assigned To: ====================================================================== Project: bacula Bug ID: 209 Category: File Daemon Reproducibility: always Severity: crash Priority: normal Status: new ====================================================================== Date Submitted: 12-21-2004 09:53 PST Last Modified: 12-21-2004 10:10 PST ====================================================================== Summary: FD crash after sucessfull backup Description: After sucessfull completion of the backup the FD crash. See attached traceback. In output of the "status client=albundy-fd" the job is not listed, but appears in "list jobs". ====================================================================== ---------------------------------------------------------------------- kern - 12-21-2004 10:10 PST ---------------------------------------------------------------------- The traceback doesn't seem to show the FD crashing. I recommend that you manually run it under the debugger. Then when it crashes, enter the following command: thread apply all bt Hopefully that will show where the problem lies. I suspect that the status client is showing nothing because either the job never ran or the FD crashed. If it crashes, any running jobs are lost and not reported if the FD is restarted (i.e. they are only written to the job history at the end of the job). Bug History Date Modified Username Field Change ====================================================================== 12-21-04 09:53 abuehler New Bug 12-21-04 09:53 abuehler File Added: traceback.txt 12-21-04 10:10 kern Bugnote Added: 0000579 ====================================================================== |
From: <bac...@li...> - 2004-12-21 17:49:02
|
The following bug has been SUBMITTED. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000209 ====================================================================== Reported By: abuehler Assigned To: ====================================================================== Project: bacula Bug ID: 209 Category: File Daemon Reproducibility: always Severity: crash Priority: normal Status: new ====================================================================== Date Submitted: 12-21-2004 09:53 PST Last Modified: 12-21-2004 09:53 PST ====================================================================== Summary: FD crash after sucessfull backup Description: After sucessfull completion of the backup the FD crash. See attached traceback. In output of the "status client=albundy-fd" the job is not listed, but appears in "list jobs". ====================================================================== Bug History Date Modified Username Field Change ====================================================================== 12-21-04 09:53 abuehler New Bug 12-21-04 09:53 abuehler File Added: traceback.txt ====================================================================== |
From: <bac...@li...> - 2004-12-21 17:31:38
|
The following bug has been CLOSED ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000182 ====================================================================== Reported By: mikeacar Assigned To: ====================================================================== Project: bacula Bug ID: 182 Category: Director Reproducibility: always Severity: minor Priority: normal Status: closed ====================================================================== Date Submitted: 11-28-2004 16:13 PST Last Modified: 12-21-2004 09:35 PST ====================================================================== Summary: Bacula director exits when using "reload" and the config files have a syntax error Description: If there is a syntax error in your config file, and you issue a console "reload" command, then the director will exit. One of the nicest features of reload is that you don't lose running jobs when making a config change, and while syntax errors are hopefully rare, this has bitten me a couple of times. ====================================================================== ---------------------------------------------------------------------- kern - 12-21-2004 09:35 PST ---------------------------------------------------------------------- The attached patch can be applied to version 1.36.1 (and most likely 1.36.0). It is also in the current 1.37 CVS. Bug History Date Modified Username Field Change ====================================================================== 11-28-04 16:13 mikeacar New Bug 12-21-04 09:35 kern File Added: 1.36.1-reload.patch 12-21-04 09:35 kern Bugnote Added: 0000578 12-21-04 09:35 kern Resolution open => fixed 12-21-04 09:35 kern Status new => closed ====================================================================== |
From: <bac...@li...> - 2004-12-21 16:55:55
|
A BUGNOTE has been added to this bug. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000190 ====================================================================== Reported By: abuehler Assigned To: ====================================================================== Project: bacula Bug ID: 190 Category: configure/build process Reproducibility: always Severity: block Priority: normal Status: feedback ====================================================================== Date Submitted: 12-02-2004 08:14 PST Last Modified: 12-21-2004 09:00 PST ====================================================================== Summary: Comile src/lib/bnet.c failes, missing protodefs for inet_aton() Description: The g++ version is 2.95.2. ------------------------------------ g++ -c -I/usr/local/include -I. -I.. -I/usr/local/include bnet.c bnet.c: In function `class dlist * bnet_host2ipaddrs(const char *, int, const char **)': bnet.c:620: implicit declaration of function `int inet_aton(...)' gmake[1]: *** [bnet.o] Error 1 ------------------------------------ There are also problems with inet_ntop(), because it is used in conjunction with ipv6, which is not supported by Solaris 2.6. ====================================================================== ---------------------------------------------------------------------- abuehler - 12-03-2004 01:29 PST ---------------------------------------------------------------------- The bnet.diff adds the function inet_aton(). HAVE_OLD_SOCKOPT is only set on Solaris 2.6, as far as I know. ---------------------------------------------------------------------- abuehler - 12-03-2004 01:40 PST ---------------------------------------------------------------------- The no_ipv6.diff adds preprocessor definitions for HAVE_IPV6 in bnet_server.c and address_conf.c. These two diffs allow for a successful compilation on Solaris 2.6. I will try a functionality test today. Please set the severity level to minor. ---------------------------------------------------------------------- kern - 12-03-2004 12:28 PST ---------------------------------------------------------------------- I am willing to take the bnet.diff, because it is probably reasonable that if one has the old sockopt one is not likely to have inet_aton(), though it *really* should be keyed on HAVE_INET_ATON. I am not prepared to take the second patch because you remove calls to several subroutines and error messages and key it on IPv6. This will break the code on most machines. The correct ifdefing is already present as far as I can tell. If the ifdefs are not correctly detected on your system, i.e. you do not have inet_ntop or inet_ntoa, then you will need to supply corrections to autoconf/configure.in or one of the other modules. ---------------------------------------------------------------------- abuehler - 12-03-2004 14:42 PST ---------------------------------------------------------------------- Setting a HAVE_INET_ATON or maybe a NEED_INET_ATON would be good idea, but I don't known much about setting up configure.in. The other patch has nothing to do with a wrong dectection of the inet_ntop function (which is present and working under Solaris 2.6). Configure detects the inet_ntop function right. But the parameters of the inet_ntop use ipv6 related structs or definitions. These are not present on Solaris 2.6. That was the reason why I choose the combination of the ifdefs in the no_ipv6.diff. In the no_ipv6.patch.txt I separate these ifdefs and use the inet_ntop. ---------------------------------------------------------------------- kern - 12-18-2004 03:07 PST ---------------------------------------------------------------------- I've added your replacement for inet_aton(), but put it in address_conf.c since it seems more logical there. I also started modifying the inet_ntop() code for another bug report (bad argument), then starting adding your code. In the end, to do it correctly, the #ifdefing became *really* messy and impossible to read, so I moved all the code into address_conf.c This simplified things enormously. The results are now in the CVS dated (18Nov04). If you could pull down the code and test it, I would appreciate it since I don't have any way to test the "old" networking code here. If the new code breaks or there are #ifdef problems, please reopen the bug report. ---------------------------------------------------------------------- abuehler - 12-21-2004 08:15 PST ---------------------------------------------------------------------- I have checked out the cvs and tried to compile the source. Two errors appeared: 1) typo error, *** address_conf.c.orig Mon Dec 20 11:09:40 2004 --- address_conf.c Mon Dec 20 11:33:11 2004 *************** *** 572,578 **** (void*)&(((struct sockaddr_in*)sa)->sin_addr) : (void*)&(((struct sockaddr_in6*)sa)->sin6_addr), # else ! (void*)&(((struct sockaddr_in*)sa)->sin_addr) : # endif /* HAVE_IPV6 */ buf, len); #else --- 572,578 ---- (void*)&(((struct sockaddr_in*)sa)->sin_addr) : (void*)&(((struct sockaddr_in6*)sa)->sin6_addr), # else ! (void*)&(((struct sockaddr_in*)sa)->sin_addr), # endif /* HAVE_IPV6 */ buf, len); #else 2) e.g. on linking bacula-fd ld: fatal: symbol `inet_aton(char const *, in_addr *)' is multiply defined: (file ../lib/libbac.a(bnet.o) and file ../lib/libbac.a(address_conf.o)); It seems that the inet_aton code is still present in bnet.c After correcting the mentioned typo and removing the inet_aton function from bnet.c the code compiles fine. Backup would run but the file daemon crashes afterwards. Should I raise a new bug report with the traceback? ---------------------------------------------------------------------- kern - 12-21-2004 09:00 PST ---------------------------------------------------------------------- Thanks for the fixes. I've now corrected them and put them in the CVS. It will take a few hours for them to be updated in the public CVS. If the crash in the FD occurs because of my changes and did not occur before, then please attach the traceback to this bug report (with extension .txt). If the crash in the FD has always been there, then please open a new bug report as it is probably not related to these changes. Bug History Date Modified Username Field Change ====================================================================== 12-02-04 08:14 abuehler New Bug 12-03-04 01:27 abuehler File Added: bnet.diff 12-03-04 01:29 abuehler Bugnote Added: 0000500 12-03-04 01:29 abuehler File Added: no_ipv6.diff 12-03-04 01:40 abuehler Bugnote Added: 0000501 12-03-04 12:28 kern Bugnote Added: 0000508 12-03-04 12:28 kern Description Updated 12-03-04 12:28 kern Status new => feedback 12-03-04 13:44 abuehler File Added: no_ipv6.patch.txt 12-03-04 14:42 abuehler Bugnote Added: 0000513 12-18-04 03:07 kern Bugnote Added: 0000561 12-18-04 03:07 kern Resolution open => fixed 12-18-04 03:07 kern Status feedback => closed 12-18-04 03:07 kern version 1.36.0 => 1.36.1 12-21-04 08:15 abuehler Bugnote Added: 0000576 12-21-04 08:15 abuehler Resolution fixed => reopened 12-21-04 08:15 abuehler Status closed => feedback 12-21-04 09:00 kern Bugnote Added: 0000577 ====================================================================== |
From: <bac...@li...> - 2004-12-21 16:10:53
|
The following bug has been REOPENED. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000190 ====================================================================== Reported By: abuehler Assigned To: ====================================================================== Project: bacula Bug ID: 190 Category: configure/build process Reproducibility: always Severity: block Priority: normal Status: feedback ====================================================================== Date Submitted: 12-02-2004 08:14 PST Last Modified: 12-21-2004 08:15 PST ====================================================================== Summary: Comile src/lib/bnet.c failes, missing protodefs for inet_aton() Description: The g++ version is 2.95.2. ------------------------------------ g++ -c -I/usr/local/include -I. -I.. -I/usr/local/include bnet.c bnet.c: In function `class dlist * bnet_host2ipaddrs(const char *, int, const char **)': bnet.c:620: implicit declaration of function `int inet_aton(...)' gmake[1]: *** [bnet.o] Error 1 ------------------------------------ There are also problems with inet_ntop(), because it is used in conjunction with ipv6, which is not supported by Solaris 2.6. ====================================================================== ---------------------------------------------------------------------- abuehler - 12-03-2004 01:29 PST ---------------------------------------------------------------------- The bnet.diff adds the function inet_aton(). HAVE_OLD_SOCKOPT is only set on Solaris 2.6, as far as I know. ---------------------------------------------------------------------- abuehler - 12-03-2004 01:40 PST ---------------------------------------------------------------------- The no_ipv6.diff adds preprocessor definitions for HAVE_IPV6 in bnet_server.c and address_conf.c. These two diffs allow for a successful compilation on Solaris 2.6. I will try a functionality test today. Please set the severity level to minor. ---------------------------------------------------------------------- kern - 12-03-2004 12:28 PST ---------------------------------------------------------------------- I am willing to take the bnet.diff, because it is probably reasonable that if one has the old sockopt one is not likely to have inet_aton(), though it *really* should be keyed on HAVE_INET_ATON. I am not prepared to take the second patch because you remove calls to several subroutines and error messages and key it on IPv6. This will break the code on most machines. The correct ifdefing is already present as far as I can tell. If the ifdefs are not correctly detected on your system, i.e. you do not have inet_ntop or inet_ntoa, then you will need to supply corrections to autoconf/configure.in or one of the other modules. ---------------------------------------------------------------------- abuehler - 12-03-2004 14:42 PST ---------------------------------------------------------------------- Setting a HAVE_INET_ATON or maybe a NEED_INET_ATON would be good idea, but I don't known much about setting up configure.in. The other patch has nothing to do with a wrong dectection of the inet_ntop function (which is present and working under Solaris 2.6). Configure detects the inet_ntop function right. But the parameters of the inet_ntop use ipv6 related structs or definitions. These are not present on Solaris 2.6. That was the reason why I choose the combination of the ifdefs in the no_ipv6.diff. In the no_ipv6.patch.txt I separate these ifdefs and use the inet_ntop. ---------------------------------------------------------------------- kern - 12-18-2004 03:07 PST ---------------------------------------------------------------------- I've added your replacement for inet_aton(), but put it in address_conf.c since it seems more logical there. I also started modifying the inet_ntop() code for another bug report (bad argument), then starting adding your code. In the end, to do it correctly, the #ifdefing became *really* messy and impossible to read, so I moved all the code into address_conf.c This simplified things enormously. The results are now in the CVS dated (18Nov04). If you could pull down the code and test it, I would appreciate it since I don't have any way to test the "old" networking code here. If the new code breaks or there are #ifdef problems, please reopen the bug report. ---------------------------------------------------------------------- abuehler - 12-21-2004 08:15 PST ---------------------------------------------------------------------- I have checked out the cvs and tried to compile the source. Two errors appeared: 1) typo error, *** address_conf.c.orig Mon Dec 20 11:09:40 2004 --- address_conf.c Mon Dec 20 11:33:11 2004 *************** *** 572,578 **** (void*)&(((struct sockaddr_in*)sa)->sin_addr) : (void*)&(((struct sockaddr_in6*)sa)->sin6_addr), # else ! (void*)&(((struct sockaddr_in*)sa)->sin_addr) : # endif /* HAVE_IPV6 */ buf, len); #else --- 572,578 ---- (void*)&(((struct sockaddr_in*)sa)->sin_addr) : (void*)&(((struct sockaddr_in6*)sa)->sin6_addr), # else ! (void*)&(((struct sockaddr_in*)sa)->sin_addr), # endif /* HAVE_IPV6 */ buf, len); #else 2) e.g. on linking bacula-fd ld: fatal: symbol `inet_aton(char const *, in_addr *)' is multiply defined: (file ../lib/libbac.a(bnet.o) and file ../lib/libbac.a(address_conf.o)); It seems that the inet_aton code is still present in bnet.c After correcting the mentioned typo and removing the inet_aton function from bnet.c the code compiles fine. Backup would run but the file daemon crashes afterwards. Should I raise a new bug report with the traceback? Bug History Date Modified Username Field Change ====================================================================== 12-02-04 08:14 abuehler New Bug 12-03-04 01:27 abuehler File Added: bnet.diff 12-03-04 01:29 abuehler Bugnote Added: 0000500 12-03-04 01:29 abuehler File Added: no_ipv6.diff 12-03-04 01:40 abuehler Bugnote Added: 0000501 12-03-04 12:28 kern Bugnote Added: 0000508 12-03-04 12:28 kern Description Updated 12-03-04 12:28 kern Status new => feedback 12-03-04 13:44 abuehler File Added: no_ipv6.patch.txt 12-03-04 14:42 abuehler Bugnote Added: 0000513 12-18-04 03:07 kern Bugnote Added: 0000561 12-18-04 03:07 kern Resolution open => fixed 12-18-04 03:07 kern Status feedback => closed 12-18-04 03:07 kern version 1.36.0 => 1.36.1 12-21-04 08:15 abuehler Bugnote Added: 0000576 12-21-04 08:15 abuehler Resolution fixed => reopened 12-21-04 08:15 abuehler Status closed => feedback ====================================================================== |
From: <bac...@li...> - 2004-12-21 15:29:33
|
The following bug has been CLOSED ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000177 ====================================================================== Reported By: bootsy52 Assigned To: ====================================================================== Project: bacula Bug ID: 177 Category: Director Reproducibility: always Severity: minor Priority: normal Status: closed ====================================================================== Date Submitted: 11-24-2004 09:06 PST Last Modified: 12-21-2004 07:33 PST ====================================================================== Summary: Configuration Parse Error for verify=5 Description: I have the following defined for the FileSet Resource which is valid according to the documentation, however if I start bacula with the supplied script it gives me an error. Options { signature = MD5; compression = GZIP9; verify=5; aclsupport=yes; } the error I got is: bacula-dir: ERROR TERMINATION at lex.c:573 Config error: expected a name, got T_NUMBER: 5 : line 84, col 27 of file /etc/bacula/bacula-dir.conf verify=5; ====================================================================== ---------------------------------------------------------------------- bootsy52 - 11-24-2004 09:08 PST ---------------------------------------------------------------------- Ahh yes, a workaround is, to set verify=s5; ---------------------------------------------------------------------- kern - 12-21-2004 07:33 PST ---------------------------------------------------------------------- Fixed in the current 1.37.1 CVS. The fix will also appear in 1.36.2. Bug History Date Modified Username Field Change ====================================================================== 11-24-04 09:06 bootsy52 New Bug 11-24-04 09:08 bootsy52 Bugnote Added: 0000479 11-24-04 12:32 kern Status new => acknowledged 12-21-04 07:33 kern Bugnote Added: 0000575 12-21-04 07:33 kern Resolution open => fixed 12-21-04 07:33 kern Status acknowledged => closed ====================================================================== |