Your message dated Thu, 22 Sep 2016 12:52:58 +0200
with message-id <87h998xl2t....@arioch.leonhardt.eu>
and subject line Re: bacula-director-mysql: Bacula chooses youngest, not
oldest, available tape
has caused the Debian Bug report #739996,
regarding bacula-director-mysql: Bacula chooses youngest, not oldest, available
tape
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
739996: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739996
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: bacula-director-mysql
Version: 5.2.6+dfsg-9.1
Severity: normal
Our bacula is asking for additional tape this morning to complete
a full dump. Full dumps are run weekly. We have a few more tapes
than are needed to do three weeks of full dumps. Our retention
period is set to 18 days.
The manual
(http://bacula.org/5.2.x-manuals/en/main/main/Configuring_Director.html#SECTION0014150000000000000000)
states "It is important to know that when the Volume Retention period
expires, Bacula does not automatically recycle a volume. _It attempts
to keep the Volume data intact as long as possible before over writing
the Volume._" (emphasis added)
Our Full pool definition is:
Pool {
Name = HMF
Pool Type = Backup
# Label Format = "HMF"
Cleaning Prefix = "CLN"
Recycle = yes
AutoPrune = yes
Volume Retention = 18 days
}
The list of tapes which are currently beyond their retention period are:
+---------+------------+-----------+---------+-------------------+----------+--------------+---------+------+-----------+-----------+---------------------+
| MediaId | VolumeName | VolStatus | Enabled | VolBytes | VolFiles |
VolRetention | Recycle | Slot | InChanger | MediaType | LastWritten |
+---------+------------+-----------+---------+-------------------+----------+--------------+---------+------+-----------+-----------+---------------------+
| 80 | HMF048L4 | Append | 1 | 807,716,519,936 | 162 |
1,555,200 | 1 | 0 | 0 | LTO-4 | 2014-02-03 11:57:12 |
| 79 | HMF050L4 | Full | 1 | 918,418,358,272 | 184 |
1,555,200 | 1 | 0 | 0 | LTO-4 | 2014-02-03 08:53:00 |
| 78 | HMF044L4 | Full | 1 | 846,183,006,208 | 170 |
1,555,200 | 1 | 0 | 0 | LTO-4 | 2014-02-03 05:12:48 |
| 95 | HMF056L4 | Full | 1 | 815,028,240,384 | 164 |
1,555,200 | 1 | 0 | 0 | LTO-4 | 2014-02-03 01:55:05 |
| 77 | HMF047L4 | Full | 1 | 1,067,510,136,832 | 214 |
1,555,200 | 1 | 0 | 0 | LTO-4 | 2014-02-02 22:07:28 |
| 122 | HMF070L4 | Full | 1 | 839,165,411,328 | 168 |
1,555,200 | 1 | 0 | 0 | LTO-4 | 2014-02-02 16:55:17 |
| 119 | HMF066L4 | Full | 1 | 852,338,147,328 | 171 |
1,555,200 | 1 | 0 | 0 | LTO-4 | 2014-02-02 13:37:28 |
| 89 | HMF049L4 | Full | 1 | 869,932,728,320 | 175 |
1,555,200 | 1 | 0 | 0 | LTO-4 | 2014-02-02 10:17:16 |
| 82 | HMF042L4 | Full | 1 | 818,461,802,496 | 164 |
1,555,200 | 1 | 0 | 0 | LTO-4 | 2014-02-02 06:34:04 |
| 81 | HMF045L4 | Full | 1 | 842,693,345,280 | 169 |
1,555,200 | 1 | 0 | 0 | LTO-4 | 2014-02-02 02:49:24 |
| 128 | HMF076L4 | Full | 1 | 768,285,868,032 | 154 |
1,555,200 | 1 | 0 | 0 | LTO-4 | 2014-02-01 23:16:17 |
| 129 | HMF077L4 | Full | 1 | 976,262,004,736 | 196 |
1,555,200 | 1 | 0 | 0 | LTO-4 | 2014-02-01 19:35:29 |
| 145 | HMF082L4 | Full | 1 | 978,494,947,328 | 199 |
1,555,200 | 1 | 0 | 0 | LTO-4 | 2014-02-01 05:51:25 |
| 83 | HMF046L4 | Append | 1 | 726,885,466,112 | 146 |
1,555,200 | 1 | 0 | 0 | LTO-4 | 2014-01-27 14:41:09 |
| 123 | HMF071L4 | Full | 1 | 975,751,348,224 | 196 |
1,555,200 | 1 | 0 | 0 | LTO-4 | 2014-01-27 11:38:45 |
| 120 | HMF068L4 | Full | 1 | 754,611,388,416 | 151 |
1,555,200 | 1 | 0 | 0 | LTO-4 | 2014-01-27 07:53:15 |
+---------+------------+-----------+---------+-------------------+----------+--------------+---------+------+-----------+-----------+---------------------+
This morning, Bacula wants HMF048L4, one of the two appendable tapes in
this list. It seems it should be asking for HMF046L4, if it wants to
use any appendable tapes first, or HMF068, if any expired tape will do.
Obviously, we could force the appendable/expired issue by setting
Volume Use Duration, but that's not really the part that concerns me.
In effect, Bacula is asking for the youngest expired tape, not
the oldest. This behavior reduces our available dump history from
"might often have three generations" to "will never have more than
two generations".
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.11-1-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to es_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Control: tag -1 - upstream
Hi,
sorry for the late answer to your bug report.
> The manual
> (http://bacula.org/5.2.x-manuals/en/main/main/Configuring_Director.html#SECTION0014150000000000000000)
> states "It is important to know that when the Volume Retention period
> expires, Bacula does not automatically recycle a volume. _It attempts
> to keep the Volume data intact as long as possible before over writing
> the Volume._" (emphasis added)
+---------+------------+-----------+---------+-------------------+----------+--------------+---------+------+-----------+-----------+---------------------+
| MediaId | VolumeName | VolStatus | Enabled | VolBytes | VolFiles |
VolRetention | Recycle | Slot | InChanger | MediaType | LastWritten |
+---------+------------+-----------+---------+-------------------+----------+--------------+---------+------+-----------+-----------+---------------------+
| 80 | HMF048L4 | Append | 1 | 807,716,519,936 | 162 |
1,555,200 | 1 | 0 | 0 | LTO-4 | 2014-02-03 11:57:12 |
| 83 | HMF046L4 | Append | 1 | 726,885,466,112 | 146 |
1,555,200 | 1 | 0 | 0 | LTO-4 | 2014-01-27 14:41:09 |
> This morning, Bacula wants HMF048L4, one of the two appendable tapes
> in this list. It seems it should be asking for HMF046L4, if it wants
> to use any appendable tapes first, or HMF068, if any expired tape will do.
> Obviously, we could force the appendable/expired issue by setting
> Volume Use Duration, but that's not really the part that concerns
> me. In effect, Bacula is asking for the youngest expired tape, not the
> oldest. This behavior reduces our available dump history from "might
> often have three generations" to "will never have more than two
> generations".
Bacula will wait as long as possible before _recycling an expired tape_
with old data on it. In your situation, there were still _appendable_
tapes available, so _no tape was to be recycled at all_, thus keeping
the promise from the manual.
More interesting would be to find out why several appendable tapes were
left around, especially if that was due to manual intervention, your
configuration, or a bug in bacula. If you are interested in following
this up, and it wasn't due to manual intervention, I'd like to ask you
to open a new bug report with more information, as that would be a
different issue (and I'm closing this one).
- Carsten
--- End Message ---
