Re: [Bacula-users] Bacula BLOCKED waiting for mount
On 04.08.2015 18:41, Michael Schwager wrote: Actually, the restore jobs were in the 900-range. 687 was indeed the backup job, as I can see that the numbers before and closely following it were all backup jobs in the same data range (I didn't do my restore until months later). It was that restore process that taught me how to manage my Bacula Directory so as to avoid bscan's in the future. But it's good to know that I can restore without restoring the info in the catalog. (also I learned that Backups are useless. It's the restore I care about. At work we no longer talk about our "backup infrastructure", we talk about our "restore infrastructure"). Most people take a very long time to learn what you arew writing above. However, without a backup, you cannot do a restore. Consequently, I prefer to say that "Restore is the most important part of backup/restore" Best regards, Kern - Mike Schwager Linux Network Engineer, Mocho Trading LLC 312-646-4783 Phone 312-637-0011 Cell 312-957-9804 Fax On Tue, Aug 4, 2015 at 7:30 AM, Ana Emília M. Arruda emiliaarr...@gmail.com wrote: Hello Michael, When you use bscan to restore jobs and files information from a volume into catalog, a new jobid is created for the original jobid (the jobid that used the volume for its backup). This is why you have the JobId 687 and not the original one. This is the JobId that you will find in your Job table. And this is the jobId that Bacula will tie to your media in JobMedia table. If the bscan operation is usual for you, I would recommend you to have an Admin Job doing prune operations of your jobs scheduled in an adequate date/time for your environment. Also, I would remember you that you can use bls/bextrac/bscan to restore the directories/files without restoring the volume/job info into catalog. Best regards, Ana On Mon, Aug 3, 2015 at 7:15 PM, Michael Schwager mschwa...@mochotrading.com wrote: On Sun, Aug 2, 2015 at 5:43 PM, Michael Schwager mschwa...@mochotrading.com wrote: Starngely, we have another tape that SHOULD be available. Tapes in this pool are set to recycle after 90 days, and 90 days ago from today is May 4th. We have a tape that was last written to on March 28. So why would Bacula block on the unavailable tape? To answer my own question (with help from the other denizens of the Bacula-cave): A couple of months ago I needed to do a restore, but I had set some of the retention times too short. So
Re: [Bacula-users] Bacula BLOCKED waiting for mount
Hello Michael, When you use bscan to restore jobs and files information from a volume into catalog, a new jobid is created for the original jobid (the jobid that used the volume for its backup). This is why you have the JobId 687 and not the original one. This is the JobId that you will find in your Job table. And this is the jobId that Bacula will tie to your media in JobMedia table. If the bscan operation is usual for you, I would recommend you to have an Admin Job doing prune operations of your jobs scheduled in an adequate date/time for your environment. Also, I would remember you that you can use bls/bextrac/bscan to restore the directories/files without restoring the volume/job info into catalog. Best regards, Ana On Mon, Aug 3, 2015 at 7:15 PM, Michael Schwager mschwa...@mochotrading.com wrote: On Sun, Aug 2, 2015 at 5:43 PM, Michael Schwager mschwa...@mochotrading.com wrote: Starngely, we have another tape that SHOULD be available. Tapes in this pool are set to recycle after 90 days, and 90 days ago from today is May 4th. We have a tape that was last written to on March 28. So why would Bacula block on the unavailable tape? To answer my own question (with help from the other denizens of the Bacula-cave): A couple of months ago I needed to do a restore, but I had set some of the retention times too short. So the files for my Job were not in the database any longer. I scanned the tape and got the data back into the database. I'm not exactly sure what I'd done or why it broke, but I can tell you that the JobMedia database rows included references to JobId 687, and that was the ID of a job that contained my file. In any case, I'm sure these old references were what caused Bacula to not be able to mark the tape as recyclable, and it thought the tape was in use, so it requested the next tape in line (EPW681L3). I'm beginning to learn about the reasons why behind the warnings not to purge, and to let Bacula manage everything, and so on. At this point I think my Bacula is where I want it and I can move forward. Thank you all for your help, suggestions, and patience. *- Mike Schwager* * Linux Network Engineer, Mocho Trading LLC* * 312-646-4783 312-646-4783 Phone312-637-0011 312-637-0011 Cell312-957-9804 312-957-9804 Fax* This message is for the named person(s) use only. It may contain confidential proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Mocho Trading LLC reserves the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Bacula BLOCKED waiting for mount
Actually, the restore jobs were in the 900-range. 687 was indeed the backup job, as I can see that the numbers before and closely following it were all backup jobs in the same data range (I didn't do my restore until months later). It was that restore process that taught me how to manage my Bacula Directory so as to avoid bscan's in the future. But it's good to know that I can restore without restoring the info in the catalog. (also I learned that Backups are useless. It's the restore I care about http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html. At work we no longer talk about our backup infrastructure, we talk about our restore infrastructure). *- Mike Schwager* * Linux Network Engineer, Mocho Trading LLC* * 312-646-4783 Phone312-637-0011 Cell312-957-9804 Fax* On Tue, Aug 4, 2015 at 7:30 AM, Ana Emília M. Arruda emiliaarr...@gmail.com wrote: Hello Michael, When you use bscan to restore jobs and files information from a volume into catalog, a new jobid is created for the original jobid (the jobid that used the volume for its backup). This is why you have the JobId 687 and not the original one. This is the JobId that you will find in your Job table. And this is the jobId that Bacula will tie to your media in JobMedia table. If the bscan operation is usual for you, I would recommend you to have an Admin Job doing prune operations of your jobs scheduled in an adequate date/time for your environment. Also, I would remember you that you can use bls/bextrac/bscan to restore the directories/files without restoring the volume/job info into catalog. Best regards, Ana On Mon, Aug 3, 2015 at 7:15 PM, Michael Schwager mschwa...@mochotrading.com wrote: On Sun, Aug 2, 2015 at 5:43 PM, Michael Schwager mschwa...@mochotrading.com wrote: Starngely, we have another tape that SHOULD be available. Tapes in this pool are set to recycle after 90 days, and 90 days ago from today is May 4th. We have a tape that was last written to on March 28. So why would Bacula block on the unavailable tape? To answer my own question (with help from the other denizens of the Bacula-cave): A couple of months ago I needed to do a restore, but I had set some of the retention times too short. So the files for my Job were not in the database any longer. I scanned the tape and got the data back into the database. I'm not exactly sure what I'd done or why it broke, but I can tell you that the JobMedia database rows included references to JobId 687, and that was the ID of a job that contained my file. In any case, I'm sure these old references were what caused Bacula to not be able to mark the tape as recyclable, and it thought the tape was in use, so it requested the next tape in line (EPW681L3). I'm beginning to learn about the reasons why behind the warnings not to purge, and to let Bacula manage everything, and so on. At this point I think my Bacula is where I want it and I can move forward. Thank you all for your help, suggestions, and patience. *- Mike Schwager* * Linux Network Engineer, Mocho Trading LLC* * 312-646-4783 312-646-4783 Phone312-637-0011 312-637-0011 Cell312-957-9804 312-957-9804 Fax* This message is for the named person(s) use only. It may contain confidential proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Mocho Trading LLC reserves the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- This message is for the named person(s) use only. It may contain confidential proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Mocho Trading LLC reserves the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the
Re: [Bacula-users] Bacula BLOCKED waiting for mount
On 2015-08-03 08:45, Michael Schwager wrote: Under v. 5.x, I discovered that Bacula's tape usage algorithm went something like this: Use an eligible tape from the library. I discovered (I think) that I could use any tape that met Bacula's rewritable criteria. Now, I don't know what the algorithm is. I had 5.x go from 001_010 to 002_010, then 003_010, etc. even though there were 5 more blank tapes in magazine 001 and 15 blank tapes in each 002, 003, etc. So I'm pretty sure Bacula's tape selection algorithm is unpredictable -- at least to an end-user who isn't Kern. You just don't get hit by it very often. Dima -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Bacula BLOCKED waiting for mount
On Sun, Aug 2, 2015 at 5:43 PM, Michael Schwager mschwa...@mochotrading.com wrote: Starngely, we have another tape that SHOULD be available. Tapes in this pool are set to recycle after 90 days, and 90 days ago from today is May 4th. We have a tape that was last written to on March 28. So why would Bacula block on the unavailable tape? To answer my own question (with help from the other denizens of the Bacula-cave): A couple of months ago I needed to do a restore, but I had set some of the retention times too short. So the files for my Job were not in the database any longer. I scanned the tape and got the data back into the database. I'm not exactly sure what I'd done or why it broke, but I can tell you that the JobMedia database rows included references to JobId 687, and that was the ID of a job that contained my file. In any case, I'm sure these old references were what caused Bacula to not be able to mark the tape as recyclable, and it thought the tape was in use, so it requested the next tape in line (EPW681L3). I'm beginning to learn about the reasons why behind the warnings not to purge, and to let Bacula manage everything, and so on. At this point I think my Bacula is where I want it and I can move forward. Thank you all for your help, suggestions, and patience. *- Mike Schwager* * Linux Network Engineer, Mocho Trading LLC* * 312-646-4783 Phone312-637-0011 Cell312-957-9804 Fax* -- This message is for the named person(s) use only. It may contain confidential proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Mocho Trading LLC reserves the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Bacula BLOCKED waiting for mount
On 08/03/2015 03:35 PM, Michael Schwager wrote: In my case, there are Jobs associated with the MediaId in the JobMedia database table, but this JobId does not exist in the Job table. This means there should be a foreign key on jobmedia: jobid references job (jobid) on delete cascade. Looking at my 7.0.5/postgres 9.2, there should also be mediaid references media (mediaid) on delete cascade. It does explain it: in my case I'm pretty sure it happened after something went pear-shaped and a running backup crashed or otherwise ended abnormally. Presumably leaving some of the tables updated but not the others. -- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu signature.asc Description: OpenPGP digital signature -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Bacula BLOCKED waiting for mount
Thanks. I will look at the max time settings. Regarding setting the enabled field, I think rather than that, I will use list nextvol, and make sure the changer is populated with the proper tape. This should keep Bacula satisfied. I can even query the database and look for some of the other tapes that should be coming available, if I find that Bacula will likely write to more than one volume. *- Mike Schwager* * Linux Network Engineer, Mocho Trading LLC* * 312-646-4783 Phone312-637-0011 Cell312-957-9804 Fax* On Mon, Aug 3, 2015 at 2:15 PM, Bill Arlofski waa-bac...@revpol.com wrote: On 08/03/2015 09:45 AM, Michael Schwager wrote: Kern, Thanks for the reply from The Man himself :-) . I ran update slots, and it's true that EPW681L3 is not in the library. But that's as I planned it it: Why would it go to EPW681L3 when EPW680L3 is right there in the library? It is in the same pool, it is as full as EPW681L3 once was, it's older than the file/job retention period, but somehow Bacula chose 681 instead of 680 which is what I was expecting. As a matter of fact, I marked all the eligible tapes as full: First I marked 681 full then Bacula chose 682. So I marked that one as full. Now 683 and beyond are younger than the file/job retention periods, so Bacula thinks it has no tapes. Meanwhile I'm pulling my hair out because I'm saying, Bacula- 680 is *right there*! Use it! But no joy. Can I somehow mark a tape as usable? Under v. 5.x, I discovered that Bacula's tape usage algorithm went something like this: Use an eligible tape from the library. I discovered (I think) that I could use any tape that met Bacula's rewritable criteria. Now, I don't know what the algorithm is. This means it will be difficult for me to choose the proper tape to put in the library. I need to know before the weekend starts so it doesn't hang up my backups. Hi Michael, You might try setting the enabled field to '0' for all volumes which are - or should be - inaccessible (not in library), and therefore should not be considered by Bacula as viable. I had to implement this on my system a couple years back, and it has been working fine ever since: http://revpol.com/node/146 I wrote that script to work out this same problem I was having when vchanger drives were not in the drive caddy, and hence the file volumes on them were not available. You will surely have to adapt it, or probably just pick a few things from it for your specific system because it is highly vchanger v0.8.6 centric. :) Having said that, it is typically best to let Bacula manage what volumes it wants, when it wants them, but in my situation, each hard drive I use with vchanger has about 70 10GB volumes so I am not severely limiting Bacula, just guiding it a little and giving it a nudge. e.g.: I do not touch retention times, nor do I manually force purges etc. :) Also, regarding my other question: How do I make Bacula fail hard if it doesn't find the media it needs? I have used the various job max ... time settings for things like this in the past. Bill -- Bill Arlofski http://www.revpol.com/bacula -- Not responsible for anything below this line -- https://lists.sourceforge.net/lists/listinfo/bacula-users -- This message is for the named person(s) use only. It may contain confidential proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Mocho Trading LLC reserves the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Bacula BLOCKED waiting for mount
On 08/03/2015 09:45 AM, Michael Schwager wrote: Kern, Thanks for the reply from The Man himself :-) . I ran update slots, and it's true that EPW681L3 is not in the library. But that's as I planned it it: Why would it go to EPW681L3 when EPW680L3 is right there in the library? It is in the same pool, it is as full as EPW681L3 once was, it's older than the file/job retention period, but somehow Bacula chose 681 instead of 680 which is what I was expecting. As a matter of fact, I marked all the eligible tapes as full: First I marked 681 full then Bacula chose 682. So I marked that one as full. Now 683 and beyond are younger than the file/job retention periods, so Bacula thinks it has no tapes. Meanwhile I'm pulling my hair out because I'm saying, Bacula- 680 is *right there*! Use it! But no joy. Can I somehow mark a tape as usable? Under v. 5.x, I discovered that Bacula's tape usage algorithm went something like this: Use an eligible tape from the library. I discovered (I think) that I could use any tape that met Bacula's rewritable criteria. Now, I don't know what the algorithm is. This means it will be difficult for me to choose the proper tape to put in the library. I need to know before the weekend starts so it doesn't hang up my backups. Hi Michael, You might try setting the enabled field to '0' for all volumes which are - or should be - inaccessible (not in library), and therefore should not be considered by Bacula as viable. I had to implement this on my system a couple years back, and it has been working fine ever since: http://revpol.com/node/146 I wrote that script to work out this same problem I was having when vchanger drives were not in the drive caddy, and hence the file volumes on them were not available. You will surely have to adapt it, or probably just pick a few things from it for your specific system because it is highly vchanger v0.8.6 centric. :) Having said that, it is typically best to let Bacula manage what volumes it wants, when it wants them, but in my situation, each hard drive I use with vchanger has about 70 10GB volumes so I am not severely limiting Bacula, just guiding it a little and giving it a nudge. e.g.: I do not touch retention times, nor do I manually force purges etc. :) Also, regarding my other question: How do I make Bacula fail hard if it doesn't find the media it needs? I have used the various job max ... time settings for things like this in the past. Bill -- Bill Arlofski http://www.revpol.com/bacula -- Not responsible for anything below this line -- -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Bacula BLOCKED waiting for mount
Kern,
Thanks for the reply from The Man himself :-) .
I ran update slots, and it's true that EPW681L3 is not in the library. But
that's as I planned it it: Why would it go to EPW681L3 when EPW680L3 is
right there in the library? It is in the same pool, it is as full as
EPW681L3 once was, it's older than the file/job retention period, but
somehow Bacula chose 681 instead of 680 which is what I was expecting.
As a matter of fact, I marked all the eligible tapes as full: First I
marked 681 full then Bacula chose 682. So I marked that one as full. Now
683 and beyond are younger than the file/job retention periods, so Bacula
thinks it has no tapes. Meanwhile I'm pulling my hair out because I'm
saying, Bacula- 680 is *right there*! Use it! But no joy. Can I somehow
mark a tape as usable?
Under v. 5.x, I discovered that Bacula's tape usage algorithm went
something like this: Use an eligible tape from the library. I discovered
(I think) that I could use any tape that met Bacula's rewritable criteria.
Now, I don't know what the algorithm is. This means it will be difficult
for me to choose the proper tape to put in the library. I need to know
before the weekend starts so it doesn't hang up my backups.
Also, regarding my other question: How do I make Bacula fail hard if it
doesn't find the media it needs?
*- Mike Schwager*
* Linux Network Engineer, Mocho Trading LLC*
* 312-646-4783 Phone312-637-0011 Cell312-957-9804 Fax*
On Sun, Aug 2, 2015 at 11:40 PM, Kern Sibbald k...@sibbald.com wrote:
Hello,
Sorry you are having problems. You did a perfect job of supplying the
right information :-)
It looks like for some reason you did not have tape EPW681L3 in the
autochanger the last time you did an update slots barcodes so the slot
for that Volume is zero, which means that Bacula will not try to use it --
even though it is recycled.
Every time you remove or add a tape to the library you must subsequently
manually run update slots barcodes so that Bacula knows what Volumes are
in the library.
Best regards,
Kern
On 03.08.2015 00:43, Michael Schwager wrote:
Hello,
We are running Bacula 7.0.5 on CentOS 7.0. This weekend, one of our full
stores blocked waiting on a tape. However I was trying to enjoy the nice
Chicago weather and trying not to think about work, so needless to say our
backup failed.
Starngely, we have another tape that SHOULD be available. Tapes in this
pool are set to recycle after 90 days, and 90 days ago from today is May
4th.
We have a tape that was last written to on March 28. So why would Bacula
block on the unavailable tape? Can I set it to fail and move on if a tape
is not available? I will never be able to satisfy Bacula over the weekend-
I would rather it fail than hold everything up.
Thanks. Here's some Bacula queries; first my client entry from
bacula-dir.conf:
Client {
Name = fscluster2-backup
...
File Retention = 3 months
Job Retention = 3 months
AutoPrune = yes # Prune expired Jobs/Files
}
Here's what status jobs says:
Device HP_LTO-3 (/dev/nst0) is not open.
Device is BLOCKED waiting for mount of volume EPW681L3,
Pool:Tape
Media type: LTO-3
Drive 0 is not loaded.
==
...
Used Volume status:
Reserved volume: EPW681L3 on tape device HP_LTO-3 (/dev/nst0)
Reader=0 writers=1 reserves=0 volinuse=0
But list media shows a volume in the changer which was last written to
on March 28; much older than 90 days. Why didn't Bacula use it?
*list media
Automatically selected Catalog: MyCatalog
Using Catalog MyCatalog
Pool: Tape
+-++---+-+-+--+--+-+--+---+---+-+
| MediaId | VolumeName | VolStatus | Enabled | VolBytes| VolFiles
| VolRetention | Recycle | Slot | InChanger | MediaType |
LastWritten |
+-++---+-+-+--+--+-+--+---+---+-+
| 16 | EPW680L3 | Full | 1 | 557,867,971,584 | 145
|7,776,000 | 1 |1 | 1 | LTO-3 | 2015-03-28
07:11:04 |
| 17 | EPW681L3 | Recycle | 1 | 1 |0
|7,776,000 | 1 |0 | 0 | LTO-3 | 2015-04-25
08:08:59 |
...
| 46 | EPW692L3 | Full | 1 | 532,896,215,040 | 163
|7,776,000 | 1 |2 | 1 | LTO-3 | 2015-08-01
09:13:24 |
| 47 | EPW693L3 | Full | 1 | 420,250,650,624 | 105
|7,776,000 | 1 |8 | 1 | LTO-3 | 2015-08-01
11:55:27 |
...
| 68 | ERX840L3 | Full | 1 | 508,789,241,856 | 130
|7,776,000 | 1 |5 | 1 | LTO-3 | 2015-07-25
10:08:25 |
Re: [Bacula-users] Bacula BLOCKED waiting for mount
Hello Michael, I have been using Bacula tape volumes for 7 years. Since 3.X version up to now with 7.0.5 version. I had no problem with bacula recycling algorithm. About your problem, the EPW680L3 volume should be used instead EPW681L3 volume if these two volumes had the same settings (volume retention, recycle flag, enabled, etc.) and both volumes had status full or used. I mean the same settings because if you change pool settings in your configuration files and do not apply them for the existent volumes, even if they are in the same pool, they will have different settings. If EPW681L3 volume, for some reason, was marked purged (manually or automatic), then Bacula would use this volume instead EPW680L3 volume. Lots of others situations could occurs here that caused Bacula to use EPW681L3 volume instead the EPW680L3 volume. You can get the next volume that bacula would use for your backups with the list nextvol command from bconsole. This command returns only the first volume and if your backups spans over multiple tapes, this command will not be so helpful. I´m attaching a script that I have been using for a few months and I think that it could help you to know previously the tape(s) that Bacula should use for your backups in a specific date/time. IMHO, Bacula has a very stable recycling algorithm, and if things are well configured, it should work as expected. Best regards, Ana On Mon, Aug 3, 2015 at 4:15 PM, Bill Arlofski waa-bac...@revpol.com wrote: On 08/03/2015 09:45 AM, Michael Schwager wrote: Kern, Thanks for the reply from The Man himself :-) . I ran update slots, and it's true that EPW681L3 is not in the library. But that's as I planned it it: Why would it go to EPW681L3 when EPW680L3 is right there in the library? It is in the same pool, it is as full as EPW681L3 once was, it's older than the file/job retention period, but somehow Bacula chose 681 instead of 680 which is what I was expecting. As a matter of fact, I marked all the eligible tapes as full: First I marked 681 full then Bacula chose 682. So I marked that one as full. Now 683 and beyond are younger than the file/job retention periods, so Bacula thinks it has no tapes. Meanwhile I'm pulling my hair out because I'm saying, Bacula- 680 is *right there*! Use it! But no joy. Can I somehow mark a tape as usable? Under v. 5.x, I discovered that Bacula's tape usage algorithm went something like this: Use an eligible tape from the library. I discovered (I think) that I could use any tape that met Bacula's rewritable criteria. Now, I don't know what the algorithm is. This means it will be difficult for me to choose the proper tape to put in the library. I need to know before the weekend starts so it doesn't hang up my backups. Hi Michael, You might try setting the enabled field to '0' for all volumes which are - or should be - inaccessible (not in library), and therefore should not be considered by Bacula as viable. I had to implement this on my system a couple years back, and it has been working fine ever since: http://revpol.com/node/146 I wrote that script to work out this same problem I was having when vchanger drives were not in the drive caddy, and hence the file volumes on them were not available. You will surely have to adapt it, or probably just pick a few things from it for your specific system because it is highly vchanger v0.8.6 centric. :) Having said that, it is typically best to let Bacula manage what volumes it wants, when it wants them, but in my situation, each hard drive I use with vchanger has about 70 10GB volumes so I am not severely limiting Bacula, just guiding it a little and giving it a nudge. e.g.: I do not touch retention times, nor do I manually force purges etc. :) Also, regarding my other question: How do I make Bacula fail hard if it doesn't find the media it needs? I have used the various job max ... time settings for things like this in the past. Bill -- Bill Arlofski http://www.revpol.com/bacula -- Not responsible for anything below this line -- -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users list_available_volumes.sh Description: Bourne shell script -- ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Bacula BLOCKED waiting for mount
Well, to answer my own question, here's the algorithm (use The Source,
Luke!):
CLUE1: During the backup, after the previous tape filled, my log file says,
There are no more Jobs associated with Volume EPW681L3. Marking it
purged.
That text comes from ua_purge.c, which runs the following SQL command in
the is_volume_purged() function:
SELECT 1 FROM JobMedia WHERE MediaId=%s LIMIT 1
The MediaId comes from an argument to the command. So somehow Bacula is
looking over the volumes. How? And somehow it skipped over the volume I
thought it would choose, EPW680L3. Why?
According to autoprune.c, the aforementioned message string comes from
prune_volumes() in auto_prune.c. But before I dig into that, I need to back
up. prune_volumes() was called by find_next_volume_for_append(), which does
this:
* 1. Look for volume with Append status.
...The query is:
SELECT MediaId,VolumeName,VolJobs,VolFiles,VolBlocks,
VolBytes,VolMounts,VolErrors,VolWrites,MaxVolBytes,VolCapacityBytes,
MediaType,VolStatus,PoolId,VolRetention,VolUseDuration,MaxVolJobs,
MaxVolFiles,Recycle,Slot,FirstWritten,LastWritten,InChanger,
EndFile,EndBlock,VolParts,LabelType,LabelDate,StorageId,
Enabled,LocationId,RecycleCount,InitialWrite,
ScratchPoolId,RecyclePoolId,VolReadTime,VolWriteTime,ActionOnPurge
FROM Media WHERE PoolId=%s AND MediaType='%s' AND Enabled=1
AND VolStatus='%s' AND InChanger=1 AND StorageId=%s
with
if (strcmp(mr-VolStatus, Recycle) == 0 ||
strcmp(mr-VolStatus, Purged) == 0) {
order = AND Recycle=1 ORDER BY LastWritten ASC,MediaId; /* take
oldest that can be recycled */
} else {
order =
sql_media_order_most_recently_written[db_get_type_index(mdb)];/* take
most recently written */
}
Now here's what happens if it does not find a volume with Append status:
if (!ok) {
* No volume found, apply algorithm
Here is the argorithm:
* 2. Try finding a recycled volume
if (!ok) {
* 3. Try recycling any purged volume
if (!ok) {
* 4. Try pruning Volumes
if (!ok create) {
* 5. Try pulling a volume from the Scratch pool
* If we are using an Autochanger and have not found
* a volume, retry looking for any volume.
if (!ok InChanger) {
InChanger = false;
continue; /* retry again accepting any volume */
}
So- there is an algorithm! Quite elaborate, at that.
Now back to prune_volumes(). If it cannot find a volume, it will prune one.
prune_volumes() says,
* Prune at least one Volume in current Pool. This is called from
* catreq.c = next_vol.c when the Storage daemon is asking for another
* volume and no appendable volumes are available.
prune_volumes first looks in the Scratch pool somehow. Mine is empty so
I'll skip right over that part.
Next, it performs a query on the database:
/*
* Get the List of all media ids in the current Pool or whose
* RecyclePoolId is the current pool or the scratch pool
*/
const char *select = SELECT DISTINCT MediaId,LastWritten FROM Media
WHERE
(PoolId=%s OR RecyclePoolId IN (%s)) AND MediaType='%s' %s
ORDER BY LastWritten ASC,MediaId;
the PoolId comes from mr-PoolId, where mr is of type MEDIA_DBR which is
a class that is a reflection of a row in the Media table of the databes.
ua-jcr which I presume is a Job Control Record. The PoolId's can be
found in the Pool table. In my case, my Pool name is Tape so my PoolId is
5. I don't have a RecyclePoolId but that seems pretty straightforward. In
any event, in my case it's probably the same as my Pool id: 5. MediaType
comes from mr-MediaType which again comes straight from the
bacula-dir.conf file; my MediaType is 'LTO-3'. The last string (the fourth
%s) is I believe either empty or AND InChanger=1 AND StorageId IN (%s),
where StorageId comes from the Storage table. For me, I have a Storage
record that specifies a name of LTO-3 so StorageId found in the database is
simply 3.
So my backup is trying to write to a tape in my 'Tape' Pool, on my 'LTO-3'
Storage device. Thus the full query should be:
*select = SELECT DISTINCT MediaId,LastWritten FROM Media WHERE
(PoolId=5 OR RecyclePoolId IN (5)) AND MediaType='LTO-3'
ORDER BY LastWritten ASC,MediaId;
At this point, it goes through each volume and prunes them. When it finds a
volume that's then purged, it will use it. My volume EPW680L3 is not
purged, so it doesn't use it.
How is purged defined? This is found in is_volume_purged() in ua_purge.c:
- If FirstWritten or LastWritten are 0, the volume is not purged (I
believe 0 is the same as 1970-01-01 00:00:00)
- If the Volume Status is Purged then the volume is purged.
- If there are no Jobs associated with the MediaId in the JobMedia
database table, then the volume is purged.
In my case, there are Jobs associated with the MediaId in the JobMedia
database table, but this JobId
Re: [Bacula-users] Bacula BLOCKED waiting for mount
Hello,
Sorry you are having problems. You did a perfect job of supplying
the right information :-)
It looks like for some reason you did not have tape EPW681L3 in the
autochanger the last time you did an "update slots barcodes" so
the slot for that Volume is zero, which means that Bacula will
not try to use it -- even though it is recycled.
Every time you remove or add a tape to the library you must
subsequently manually run "update slots barcodes" so that Bacula
knows what Volumes are in the library.
Best regards,
Kern
On 03.08.2015 00:43, Michael Schwager wrote:
Hello,
We
are running Bacula 7.0.5 on CentOS 7.0. This weekend, one of
our full stores blocked waiting on a tape. However I was
trying to enjoy the nice Chicago weather and trying not to
think about work, so needless to say our backup failed.
Starngely, we have another tape
that SHOULD be available. Tapes in this pool are set to
recycle after 90 days, and 90 days ago from today is May 4th.
We have a tape that was last written to on March 28. So why
would Bacula block on the unavailable tape? Can I set it to
fail and move on if a tape is not available? I will never be
able to satisfy Bacula over the weekend- I would rather it
fail than hold everything up.
Thanks.
Here's some Bacula queries; first my client entry from
bacula-dir.conf:
Client {
Name = fscluster2-backup
...
File Retention = 3 months
Job Retention = 3 months
AutoPrune = yes # Prune expired
Jobs/Files
}
Here's what status jobs says:
Device "HP_LTO-3" (/dev/nst0) is not open.
Device is BLOCKED waiting for mount of volume
"EPW681L3",
Pool: Tape
Media type: LTO-3
Drive 0 is not loaded.
==
...
Used Volume status:
Reserved volume: EPW681L3 on tape device "HP_LTO-3"
(/dev/nst0)
Reader=0 writers=1 reserves=0 volinuse=0
But list media shows a volume in the changer which was
last written to on March 28; much older than 90 days. Why
didn't Bacula use it?
*list media
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
Pool: Tape
+-++---+-+-+--+--+-+--+---+---+-+
| MediaId | VolumeName | VolStatus | Enabled |
VolBytes | VolFiles | VolRetention | Recycle | Slot |
InChanger | MediaType | LastWritten |
+-++---+-+-+--+--+-+--+---+---+-+
| 16 | EPW680L3 | Full | 1 |
557,867,971,584 | 145 | 7,776,000 | 1 | 1
| 1 | LTO-3 | 2015-03-28 07:11:04 |
| 17 | EPW681L3 | Recycle | 1 |
1 | 0 | 7,776,000 | 1 | 0 | 0 |
LTO-3 | 2015-04-25 08:08:59 |
...
| 46 | EPW692L3 | Full | 1 |
532,896,215,040 | 163 | 7,776,000 | 1 | 2
| 1 | LTO-3 | 2015-08-01 09:13:24 |
| 47 | EPW693L3 | Full | 1 |
420,250,650,624 | 105 | 7,776,000 | 1 | 8
| 1 | LTO-3 | 2015-08-01 11:55:27 |
...
| 68 | ERX840L3 | Full | 1 |
508,789,241,856 | 130 | 7,776,000 | 1 | 5
| 1 | LTO-3 | 2015-07-25 10:08:25 |
+-++---+-+-+--+--+-+--+---+---+-+
*status slots
Automatically selected Storage: LTO-3
...
3306 Issuing autochanger "list" command.
Slot | Volume Name | Status | Media Type
| Pool |
[Bacula-users] Bacula BLOCKED waiting for mount
Hello,
We are running Bacula 7.0.5 on CentOS 7.0. This weekend, one of our full
stores blocked waiting on a tape. However I was trying to enjoy the nice
Chicago weather and trying not to think about work, so needless to say our
backup failed.
Starngely, we have another tape that SHOULD be available. Tapes in this
pool are set to recycle after 90 days, and 90 days ago from today is May
4th.
We have a tape that was last written to on March 28. So why would Bacula
block on the unavailable tape? Can I set it to fail and move on if a tape
is not available? I will never be able to satisfy Bacula over the weekend-
I would rather it fail than hold everything up.
Thanks. Here's some Bacula queries; first my client entry from
bacula-dir.conf:
Client {
Name = fscluster2-backup
...
File Retention = 3 months
Job Retention = 3 months
AutoPrune = yes # Prune expired Jobs/Files
}
Here's what status jobs says:
Device HP_LTO-3 (/dev/nst0) is not open.
Device is BLOCKED waiting for mount of volume EPW681L3,
Pool:Tape
Media type: LTO-3
Drive 0 is not loaded.
==
...
Used Volume status:
Reserved volume: EPW681L3 on tape device HP_LTO-3 (/dev/nst0)
Reader=0 writers=1 reserves=0 volinuse=0
But list media shows a volume in the changer which was last written to on
March 28; much older than 90 days. Why didn't Bacula use it?
*list media
Automatically selected Catalog: MyCatalog
Using Catalog MyCatalog
Pool: Tape
+-++---+-+-+--+--+-+--+---+---+-+
| MediaId | VolumeName | VolStatus | Enabled | VolBytes| VolFiles |
VolRetention | Recycle | Slot | InChanger | MediaType | LastWritten
|
+-++---+-+-+--+--+-+--+---+---+-+
| 16 | EPW680L3 | Full | 1 | 557,867,971,584 | 145
|7,776,000 | 1 |1 | 1 | LTO-3 | 2015-03-28
07:11:04 |
| 17 | EPW681L3 | Recycle | 1 | 1 |0
|7,776,000 | 1 |0 | 0 | LTO-3 | 2015-04-25
08:08:59 |
...
| 46 | EPW692L3 | Full | 1 | 532,896,215,040 | 163
|7,776,000 | 1 |2 | 1 | LTO-3 | 2015-08-01
09:13:24 |
| 47 | EPW693L3 | Full | 1 | 420,250,650,624 | 105
|7,776,000 | 1 |8 | 1 | LTO-3 | 2015-08-01
11:55:27 |
...
| 68 | ERX840L3 | Full | 1 | 508,789,241,856 | 130
|7,776,000 | 1 |5 | 1 | LTO-3 | 2015-07-25
10:08:25 |
+-++---+-+-+--+--+-+--+---+---+-+
*status slots
Automatically selected Storage: LTO-3
...
3306 Issuing autochanger list command.
Slot | Volume Name| Status | Media Type |
Pool |
--+--+---+--+|
1 | EPW680L3 | Full |LTO-3 |
Tape |
2 | EPW692L3 | Full |LTO-3 |
Tape |
3 | EPW732L3 |Append |LTO-3 |
WORM-CRM |
4 | EPW730L3 |Append |LTO-3 |
WORM-CRM |
5 | ERX840L3 | Full |LTO-3 |
Tape |
6 | EPW733L3 |Append |LTO-3 |
WORM-Onsite |
7 | EPW729L3 |Append |LTO-3 |
WORM-Onsite |
8 | EPW693L3 | Full |LTO-3 |
Tape |
*- Mike Schwager*
* Linux Network Engineer, Mocho Trading LLC*
* 312-646-4783 Phone312-637-0011 Cell312-957-9804 Fax*
--
This message is for the named person(s) use only. It may contain
confidential proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender. You must not, directly or indirectly use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. Mocho Trading LLC reserves the right to monitor all e-mail
communications through its networks. Any views expressed in this message
are those of the individual sender, except where the message states
otherwise and the sender is authorized to state them to be the views of any
such entity.
--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Bacula BLOCKED waiting for mount
...Curiously, I marked EPW681L3 as Full status from bconsole, and it
change the next tape to Recycle Status. Why is Bacula setting tapes to
Recycle status? It never used to do that. The again, I was never on level
7.0.5 before either...
| 17 | EPW681L3 | Full | 1 | 1 |0
|7,776,000 | 1 |0 | 0 | LTO-3 | 2015-04-25
08:08:59 |
| 26 | EPW683L3 | Recycle | 1 | 1 |0
|7,776,000 | 1 |0 | 0 | LTO-3 | 2015-05-02
09:04:19 |
*- Mike Schwager*
* Linux Network Engineer, Mocho Trading LLC*
* 312-646-4783 Phone312-637-0011 Cell312-957-9804 Fax*
On Sun, Aug 2, 2015 at 5:43 PM, Michael Schwager mschwa...@mochotrading.com
wrote:
Hello,
We are running Bacula 7.0.5 on CentOS 7.0. This weekend, one of our full
stores blocked waiting on a tape. However I was trying to enjoy the nice
Chicago weather and trying not to think about work, so needless to say our
backup failed.
Starngely, we have another tape that SHOULD be available. Tapes in this
pool are set to recycle after 90 days, and 90 days ago from today is May
4th.
We have a tape that was last written to on March 28. So why would Bacula
block on the unavailable tape? Can I set it to fail and move on if a tape
is not available? I will never be able to satisfy Bacula over the weekend-
I would rather it fail than hold everything up.
Thanks. Here's some Bacula queries; first my client entry from
bacula-dir.conf:
Client {
Name = fscluster2-backup
...
File Retention = 3 months
Job Retention = 3 months
AutoPrune = yes # Prune expired Jobs/Files
}
Here's what status jobs says:
Device HP_LTO-3 (/dev/nst0) is not open.
Device is BLOCKED waiting for mount of volume EPW681L3,
Pool:Tape
Media type: LTO-3
Drive 0 is not loaded.
==
...
Used Volume status:
Reserved volume: EPW681L3 on tape device HP_LTO-3 (/dev/nst0)
Reader=0 writers=1 reserves=0 volinuse=0
But list media shows a volume in the changer which was last written to on
March 28; much older than 90 days. Why didn't Bacula use it?
*list media
Automatically selected Catalog: MyCatalog
Using Catalog MyCatalog
Pool: Tape
+-++---+-+-+--+--+-+--+---+---+-+
| MediaId | VolumeName | VolStatus | Enabled | VolBytes| VolFiles
| VolRetention | Recycle | Slot | InChanger | MediaType |
LastWritten |
+-++---+-+-+--+--+-+--+---+---+-+
| 16 | EPW680L3 | Full | 1 | 557,867,971,584 | 145
|7,776,000 | 1 |1 | 1 | LTO-3 | 2015-03-28
07:11:04 |
| 17 | EPW681L3 | Recycle | 1 | 1 |0
|7,776,000 | 1 |0 | 0 | LTO-3 | 2015-04-25
08:08:59 |
...
| 46 | EPW692L3 | Full | 1 | 532,896,215,040 | 163
|7,776,000 | 1 |2 | 1 | LTO-3 | 2015-08-01
09:13:24 |
| 47 | EPW693L3 | Full | 1 | 420,250,650,624 | 105
|7,776,000 | 1 |8 | 1 | LTO-3 | 2015-08-01
11:55:27 |
...
| 68 | ERX840L3 | Full | 1 | 508,789,241,856 | 130
|7,776,000 | 1 |5 | 1 | LTO-3 | 2015-07-25
10:08:25 |
+-++---+-+-+--+--+-+--+---+---+-+
*status slots
Automatically selected Storage: LTO-3
...
3306 Issuing autochanger list command.
Slot | Volume Name| Status | Media Type |
Pool |
--+--+---+--+|
1 | EPW680L3 | Full |LTO-3
| Tape |
2 | EPW692L3 | Full |LTO-3
| Tape |
3 | EPW732L3 |Append |LTO-3 |
WORM-CRM |
4 | EPW730L3 |Append |LTO-3 |
WORM-CRM |
5 | ERX840L3 | Full |LTO-3
| Tape |
6 | EPW733L3 |Append |LTO-3 |
WORM-Onsite |
7 | EPW729L3 |Append |LTO-3 |
WORM-Onsite |
8 | EPW693L3 | Full |LTO-3
| Tape |
*- Mike Schwager*
* Linux Network Engineer, Mocho Trading LLC*
* 312-646-4783 Phone312-637-0011 Cell312-957-9804 Fax*
--
This message is for the named person(s) use only. It may contain
confidential proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you
