I've already set both of these options... Last night i had a weird thing where instead of using the wednesday tape in the drive, it asked for the previous FRIDAY's tape which was still in append mode.
A simple unmount/remount fixed it and the backup started again.. after waiting for user intervention for 12 hours. I've been getting quite a few failed backups because it seems so unpredictable! On fridays, I actually delete volumes out of the catalog, then re-label them, as this is the only way i've found works every time! >>> Martin Simmons <[EMAIL PROTECTED]> 03/01/2006 18:29 >>> >>>>> On Tue, 03 Jan 2006 11:15:21 +0000, "Beren Gamble" <[EMAIL PROTECTED]> >>>>> said: Beren> I'm convinced that there's no solution in the current build. I think Beren> there needs to be a new setting implemented which forces Bacula to Beren> use the volume in the drive IF it is outside of the retention period. FWIW, it used to be options like Recycle Current Volume = yes Accept Any Volume = yes that made that work. __Martin >>>> Martin Simmons <[EMAIL PROTECTED]> 30/12/2005 23:11 >>> >>>>> On Fri, 30 Dec 2005 16:23:38 +0100 (CET), Gabriele Bulfon <[EMAIL >>>>> PROTECTED]> said: Gabriele> At last, I think I discovered the basic problem behind the Automatic Recycle/Purge/Prune so many people are facing (me included). Gabriele> I decided to start from a scratch situation, with the latest configuration I came up with, using all the suggestions I received in this list. Gabriele> As a first step, I just used bconsole to purge all my 7 weekly volumes, assuming that any previous job would have been deleted and removed from the database. Gabriele> With a lot of surprise, I discovered that some jobs were still in the bconsole list. Don't know why. Gabriele> So I decided to delete them by hand (delete job). Gabriele> Finally I had a scratch situation....I thought... Gabriele> But I wanted to be sure. Gabriele> So I stopped bacula daemons, ran psql on bacula database (I am using Postgres) and issued Gabriele> some sql statements to examine the database status: Gabriele> - a "select count(*) from job" was never returning....(or probably returning after a long time) Gabriele> - a "select count(*) from file" was never returining..... Gabriele> (or probably returning after an even longer time) Gabriele> So I supposed that both tables should have been very very large and still containing hidden data! Gabriele> Now, to get my hands on its data, I used pg_dump to dump all the bacula db on a flat file and see its content. Gabriele> ......many minutes of dump........300Mb of flat file was produced..... Gabriele> ...wow.....and there, I found a lot of data inside the job and file tables. Gabriele> So, I decided to drop the whole bacula db and recreate it. Gabriele> After doing this, my latest configuration files work perfectly! Gabriele> So, my last suggestion to anyone going crazy with their weekly backup, is to start from scratch Gabriele> any time you need to change the bacula-dir.conf file, then "add" the pre-labaled volumes by hand. Gabriele> Bacula won't prune or recycle some of your tapes, because old jobs are probably still in the db Gabriele> in some hidden status. Gabriele> I hope somone can clarify why this situation occurs. Beren> Junk in the File and Path tables is OK, because the entries are never removed Beren> and shouldn't affect recycling. Beren> Junk in the Jobs table is more worrying though. However, some types of job Beren> (e.g. Admin and Verify) are not directly associated with any media, so they Beren> don't get pruned and shouldn't effect recycling either. Beren> I think the JobMedia table is the one that affects Recycle/Purge/Prune most. Beren> __Martin Beren> ------------------------------------------------------- Beren> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files Beren> for problems? Stop! Download the new AJAX search engine that makes Beren> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! Beren> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click Beren> _______________________________________________ Beren> Bacula-users mailing list Beren> Bacula-users@lists.sourceforge.net Beren> https://lists.sourceforge.net/lists/listinfo/bacula-users Beren> *********************************************************************************** Beren> Mail FROM London Borough of Harrow: Beren> Unencrypted electronic mail is not secure and may not be authentic, in whole or in part. You are advised to check directly with the sender before acting upon any e-mail received. Beren> The information contained in this message and any attachments is confidential and is intended for receipt by the above named addressee(s) only. If you have otherwise encountered this message please notify its originator via +44(0)20 8863 5611 at LONDON BOROUGH OF HARROW. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. The views expressed within this message are those of the individual sender and not necessarily those of Harrow Council. Beren> Mail TO London Borough of Harrow: Beren> London Borough of Harrow monitors all electronic mail it receives for Policy compliance and to protect its systems including anti-spam and anti-virus measures. Beren> Electronic mail does not guarantee delivery, nor notification of non-delivery. It is suggested you contact your intended recipient(s) by other means should confirmation of receipt be important. Beren> *********************************************************************************** I've already set both of these options... Last night i had a weird thing where instead of using the wednesday tape in the drive, it asked for the previous FRIDAY's tape which was still in append mode. A simple unmount/remount fixed it and the backup started again.. after waiting for user intervention for 12 hours. I've been getting quite a few failed backups because it seems so unpredictable! On fridays, I actually delete volumes out of the catalog, then re-label them, as this is the only way i've found works every time! >>> Martin Simmons <[EMAIL PROTECTED]> 03/01/2006 18:29 >>> >>>>> On Tue, 03 Jan 2006 11:15:21 +0000, "Beren Gamble" <[EMAIL PROTECTED]> >>>>> said: Beren> I'm convinced that there's no solution in the current build. I think Beren> there needs to be a new setting implemented which forces Bacula to Beren> use the volume in the drive IF it is outside of the retention period. FWIW, it used to be options like Recycle Current Volume = yes Accept Any Volume = yes that made that work. __Martin >>>> Martin Simmons <[EMAIL PROTECTED]> 30/12/2005 23:11 >>> >>>>> On Fri, 30 Dec 2005 16:23:38 +0100 (CET), Gabriele Bulfon <[EMAIL >>>>> PROTECTED]> said: Gabriele> At last, I think I discovered the basic problem behind the Automatic Recycle/Purge/Prune so many people are facing (me included). Gabriele> I decided to start from a scratch situation, with the latest configuration I came up with, using all the suggestions I received in this list. Gabriele> As a first step, I just used bconsole to purge all my 7 weekly volumes, assuming that any previous job would have been deleted and removed from the database. Gabriele> With a lot of surprise, I discovered that some jobs were still in the bconsole list. Don't know why. Gabriele> So I decided to delete them by hand (delete job). Gabriele> Finally I had a scratch situation....I thought... Gabriele> But I wanted to be sure. Gabriele> So I stopped bacula daemons, ran psql on bacula database (I am using Postgres) and issued Gabriele> some sql statements to examine the database status: Gabriele> - a "select count(*) from job" was never returning....(or probably returning after a long time) Gabriele> - a "select count(*) from file" was never returining..... Gabriele> (or probably returning after an even longer time) Gabriele> So I supposed that both tables should have been very very large and still containing hidden data! Gabriele> Now, to get my hands on its data, I used pg_dump to dump all the bacula db on a flat file and see its content. Gabriele> ......many minutes of dump........300Mb of flat file was produced..... Gabriele> ...wow.....and there, I found a lot of data inside the job and file tables. Gabriele> So, I decided to drop the whole bacula db and recreate it. Gabriele> After doing this, my latest configuration files work perfectly! Gabriele> So, my last suggestion to anyone going crazy with their weekly backup, is to start from scratch Gabriele> any time you need to change the bacula-dir.conf file, then "add" the pre-labaled volumes by hand. Gabriele> Bacula won't prune or recycle some of your tapes, because old jobs are probably still in the db Gabriele> in some hidden status. Gabriele> I hope somone can clarify why this situation occurs. Beren> Junk in the File and Path tables is OK, because the entries are never removed Beren> and shouldn't affect recycling. Beren> Junk in the Jobs table is more worrying though. However, some types of job Beren> (e.g. Admin and Verify) are not directly associated with any media, so they Beren> don't get pruned and shouldn't effect recycling either. Beren> I think the JobMedia table is the one that affects Recycle/Purge/Prune most. Beren> __Martin Beren> ------------------------------------------------------- Beren> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files Beren> for problems? Stop! Download the new AJAX search engine that makes Beren> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! Beren> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click Beren> _______________________________________________ Beren> Bacula-users mailing list Beren> Bacula-users@lists.sourceforge.net Beren> https://lists.sourceforge.net/lists/listinfo/bacula-users Beren> *********************************************************************************** Beren> Mail FROM London Borough of Harrow: Beren> Unencrypted electronic mail is not secure and may not be authentic, in whole or in part. You are advised to check directly with the sender before acting upon any e-mail received. Beren> The information contained in this message and any attachments is confidential and is intended for receipt by the above named addressee(s) only. If you have otherwise encountered this message please notify its originator via +44(0)20 8863 5611 at LONDON BOROUGH OF HARROW. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. The views expressed within this message are those of the individual sender and not necessarily those of Harrow Council. Beren> Mail TO London Borough of Harrow: Beren> London Borough of Harrow monitors all electronic mail it receives for Policy compliance and to protect its systems including anti-spam and anti-virus measures. Beren> Electronic mail does not guarantee delivery, nor notification of non-delivery. It is suggested you contact your intended recipient(s) by other means should confirmation of receipt be important. Beren> *********************************************************************************** ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
