Bug#475139: Inconsistencies should not cause a tape to be marked in error
Whenever Bacula marks a tape in error, it clearly prints that fact and why in the Job Report, so it is not quite accurate to say that it is impossible to distinguish between such a case and a case of a /real/ tape error.. Note, more recent versions of Bacula permit logging job reports to the database and easy access to that info using the GUI bat program. Just the same, having an additional state such as Inconsistent is a possibility. I will add it to our TODO list, but have not really decided whether or not to do it. In any case, it is a good deal of work to add a new state, including a major update of the database, so even if it is approved, don't count on it any time soon. If you want to ensure that this will become a project, please see: www.bacula.org - Feature Requests and follow the procedure outlined there. Kern Bacula Project Manager -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475139: Inconsistencies should not cause a tape to be marked in error
On Thu, Apr 10, 2008 at 09:03:03AM -0500, John Goerzen wrote: On Wed April 9 2008 5:08:47 am Wouter Verhelst wrote: (first, I'm not sure whether this is the right package to submit against; feel free to reassign if necessary). They are all (except -doc) built from the same source, and all wind up in my INBOX in any case :-) Right :) When a bacula tape becomes inconsistent with what bacula has recorded about that particular tape, for any reason (e.g., when there was an error writing to the database because the disk filled, or when the director crashed when a backup job was in progress), then bacula will mark the tape as being 'in error'. This makes it impossible to distinguish between such a case and a case of a /real/ tape error. It would probably be best to create a new state, 'Inconsistent' or some such, to be assigned to tapes of which the data as stored in the database does not correspond to the data as found on the tape itself. This would make it easier for a system administrator to figure out what the correct course of action is when a failure occurs (e.g., manually recycle the tape, or throw it away in case of a /real/ error). This is pretty obviously an upstream design decision. I would be willing to forward this upstream, but it's reported against a very old version. I am not set up to be able to test this particular behavior on the current Bacula 2.2.x, so I don't know for sure what the current behavior is. Would you be willing to either a) test 2.2.x and report back on its behavior, or b) take this discussion to a Bacula mailing list yourself, and we close the Debian bug with a pointer to the thread? Eh, hm, yeah, very sensible all. I actually am running a 2.something backport on one of my systems, which does backups to tape (since it needed to do backups of FreeBSD systems, too, which had bacula 2.something as well, and otherwise they wouldn't talk to eachother). I'll try to reproduce the behaviour there, and report to you when I find out more. Might not be for today, though. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475139: Inconsistencies should not cause a tape to be marked in error
On Wed April 9 2008 5:08:47 am Wouter Verhelst wrote: (first, I'm not sure whether this is the right package to submit against; feel free to reassign if necessary). They are all (except -doc) built from the same source, and all wind up in my INBOX in any case :-) When a bacula tape becomes inconsistent with what bacula has recorded about that particular tape, for any reason (e.g., when there was an error writing to the database because the disk filled, or when the director crashed when a backup job was in progress), then bacula will mark the tape as being 'in error'. This makes it impossible to distinguish between such a case and a case of a /real/ tape error. It would probably be best to create a new state, 'Inconsistent' or some such, to be assigned to tapes of which the data as stored in the database does not correspond to the data as found on the tape itself. This would make it easier for a system administrator to figure out what the correct course of action is when a failure occurs (e.g., manually recycle the tape, or throw it away in case of a /real/ error). This is pretty obviously an upstream design decision. I would be willing to forward this upstream, but it's reported against a very old version. I am not set up to be able to test this particular behavior on the current Bacula 2.2.x, so I don't know for sure what the current behavior is. Would you be willing to either a) test 2.2.x and report back on its behavior, or b) take this discussion to a Bacula mailing list yourself, and we close the Debian bug with a pointer to the thread? -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475139: Inconsistencies should not cause a tape to be marked in error
Package: bacula-sd Version: 1.38.11-8 Severity: normal Hi, (first, I'm not sure whether this is the right package to submit against; feel free to reassign if necessary). When a bacula tape becomes inconsistent with what bacula has recorded about that particular tape, for any reason (e.g., when there was an error writing to the database because the disk filled, or when the director crashed when a backup job was in progress), then bacula will mark the tape as being 'in error'. This makes it impossible to distinguish between such a case and a case of a /real/ tape error. It would probably be best to create a new state, 'Inconsistent' or some such, to be assigned to tapes of which the data as stored in the database does not correspond to the data as found on the tape itself. This would make it easier for a system administrator to figure out what the correct course of action is when a failure occurs (e.g., manually recycle the tape, or throw it away in case of a /real/ error). -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: arm (armv5tel) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-iop32x Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages bacula-sd depends on: ii bacula-common 1.38.11-8 Network backup, recovery and verif ii libacl12.2.41-1 Access control list shared library ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libgcc11:4.1.1-21GCC support library ii libssl0.9.80.9.8c-4etch1 SSL shared libraries ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii libwrap0 7.6.dbs-13Wietse Venema's TCP wrappers libra ii mtx1.2.17rel-2 controls tape autochangers ii python 2.4.4-2 An interactive high-level object-o ii python2.4 2.4.4-3 An interactive high-level object-o ii zlib1g 1:1.2.3-13compression library - runtime Versions of packages bacula-sd recommends: ii bacula-sd-pgsql [bacula-sd-to 1.38.11-8 Network backup, recovery and verif pn mt-st none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
