Re: [Bacula-users] Issue with recycling after moving from 2.0 to 2.4
Yann Cézard a écrit : [...] Actually, File Retention is configured 13 days for every clients. But you know what ? that's a very good point ! I explain myself : At the start of my migration, I had 2 director crashes, caused by old configuration files for Messages which were mentioning /var/bacula/log instead of /var/lib/bacula/log I noticed the volumes that were used at the time of the crash had a LastWritten field value of -00-00 00:00:00 which was causing trouble recycling, I already fixed that days ago, but I didn't thought to look at the File table ! I'll have a look at that, and keep you informed, thanks for pointing it up to me ! Yann Hi again list, So I had a look in the Files table, searching for something linked to duration, but I didn't find anything. I run dbcheck in fixing batch mode, in the hope it would fix the problem, but I still have problem with recycling. Here is the last exemple from this night. The Media table looks like this : MediaId;VolumeName;Slot;PoolId;MediaType;MediaTypeId;LabelType;FirstWritten;LastWritten;LabelDate;VolJobs;VolFiles;VolBlocks;VolMounts;VolBytes;VolParts;VolErrors;VolWrites;VolCapacityBytes;VolStatus;Enabled;Recycle;VolRetention;VolUseDuration;MaxVolJobs;MaxVolFiles;MaxVolBytes;InChanger;StorageId;DeviceId;MediaAddressing;VolReadTime;VolWriteTime;EndFile;EndBlock;LocationId;RecycleCount;InitialWrite;ScratchPoolId;RecyclePoolId;Comment 1;sciences-full-0001;0;76;File-sciences;0;0;2009-02-12 22:43:33;2009-02-12 23:49:38;2009-02-12 22:43:33;1;0;20920;2;1349578622;0;0;41737;0;Used;1;1;1123200;0;0;0;0;0;38;0;0;0;8351686;0;1349578621;0;1;-00-00 00:00:00;0;0;NULL 9;sciences-full-0009;0;76;File-sciences;0;0;2009-02-05 22:42:31;2009-02-05 22:48:28;2009-02-05 22:42:31;1;0;20885;1;1347322345;0;0;20886;0;Used;1;1;1123200;0;0;0;0;0;38;0;0;0;3412461;0;1347322344;0;0;-00-00 00:00:00;0;0;NULL So as you can see, the LastWritten time of the volume sciences-full-0009 is 2009-02-05 22:48:28, and the VolRetention is 1123200 seconds (13 days). Client is like this : ClientId;Name;Uname;AutoPrune;FileRetention;JobRetention 1;Sciences;2.4.4 (28Dec08) i486-pc-linux-gnu,debian,4.0;1;1123200;1123200 As you can see, Job retention is 1123200 seconds (13 days) to. And the Full Jobs still in catalogs are: JobId;Job;Name;Type;Level;ClientId;JobStatus;SchedTime;StartTime;EndTime;RealEndTime;JobTDate;VolSessionId;VolSessionTime;JobFiles;JobBytes;JobErrors;JobMissingFiles;PoolId;FileSetId;PriorJobId;PurgedFiles;HasBase 43;sciences.2009-02-19_22.30.00.53;sciences;B;F;1;A;2009-02-19 22:30:00;2009-02-19 22:45:47;2009-02-20 09:30:52;2009-02-20 09:30:52;1235118652;445;1234558143;0;0;0;0;76;1;0;0;0 29;sciences.2009-02-12_22.30.01.38;sciences;B;F;1;T;2009-02-12 22:30:01;2009-02-12 22:43:33;2009-02-12 23:49:39;2009-02-12 23:49:39;1234478979;22;1234454882;9805;1346784713;0;0;76;1;0;0;0 15;sciences.2009-02-05_22.30.00.41;sciences;B;F;1;T;2009-02-05 22:30:00;2009-02-05 22:42:31;2009-02-05 22:48:29;2009-02-05 22:48:29;1233870509;22;1233842441;9801;1344529845;0;0;76;1;0;0;0 Shouldn't the Job sciences.2009-02-05_22.30.00.41 already be gone ? And this is the messages I received this night : 19-fév 22:45 backuppa-sd JobId 43: Job sciences.2009-02-19_22.30.00.53 waiting. Cannot find any appendable volumes. Please use the label command to create a new Volume for: Storage: SAVE-SCIENCES (/save/sciences) Pool: PoolSciences-Full Media type: File-sciences 19-fév 23:45 backuppa-sd JobId 43: Job sciences.2009-02-19_22.30.00.53 waiting. Cannot find any appendable volumes. Please use the label command to create a new Volume for: Storage: SAVE-SCIENCES (/save/sciences) Pool: PoolSciences-Full Media type: File-sciences 20-fév 01:45 backuppa-sd JobId 43: Job sciences.2009-02-19_22.30.00.53 waiting. Cannot find any appendable volumes. Please use the label command to create a new Volume for: Storage: SAVE-SCIENCES (/save/sciences) Pool: PoolSciences-Full Media type: File-sciences 20-fév 05:45 backuppa-sd JobId 43: Job sciences.2009-02-19_22.30.00.53 waiting. Cannot find any appendable volumes. Please use the label command to create a new Volume for: Storage: SAVE-SCIENCES (/save/sciences) Pool: PoolSciences-Full Media type: File-sciences So, bacula still doesn't want to prune the disposable volume by itself. Or the job associated with it ? If i'm pruning it from bconsole, all is fine : +-++---+-+---+--+--+-+--+---+---+-+ | MediaId | VolumeName | VolStatus | Enabled | VolBytes | VolFiles | VolRetention | Recycle | Slot | InChanger | MediaType | LastWritten |
[Bacula-users] Issue with recycling after moving from 2.0 to 2.4
Hi list, I have recently moved to bacula 2.4.4 (2.4.3 at the start, I upgraded to 2.4.4 last week), from 2.0.3 (totally new installation : new server, new databases, the only thing that I kept from the old install is my client/jobs/pools/... configuration files) and I am facing a strange issue in volume recycling. Operating system is Debian Lenny (bacula packages are the official Debian ones). My backups are configured that way : - 1 Full job per week, Incremental the other days - jobs are kept 13 days (full or incr) - volume are 13 days retention period, recycling is on, autoprune is on, each job has one Full Pool (2 volumes) and one Incremental Pool (12 volumes) - all backups are done on disk (no tape) - multiple databases (not really one for each client, but not far - one database by client profile) Everything was working fine with 2.0.3, but I noticed that with 2.4.4 recycling is sometime happenning more lately, or not when wanted... Exple : Pools looks like this in database (sorry for the formatting) : ++--+-+-+-++-+--+++-+-+---+-+--+---+-+-+---+---+++---+---+ | PoolId | Name | NumVols | MaxVols | UseOnce | UseCatalog | AcceptAnyVolume | VolRetention | VolUseDuration | MaxVolJobs | MaxVolFiles | MaxVolBytes | AutoPrune | Recycle | PoolType | LabelType | LabelFormat | Enabled | ScratchPoolId | RecyclePoolId | NextPoolId | MigrationHighBytes | MigrationLowBytes | MigrationTime | ++--+-+-+-++-+--+++-+-+---+-+--+---+-+-+---+---+++---+---+ | 60 | PoolSso-Full | 2 | 2 | 1 | 1 | 0 | 1123200 | 0 | 0 | 0 | 0 | 1 | 1 | Backup | 0 | sso-full- | 1 |0 | 0 | 0 | 0 | 0 | 0 | | 61 | PoolSso-Incr | 12 | 12 | 1 | 1 | 0 | 1123200 | 0 | 0 | 0 | 0 | 1 | 1 | Backup | 0 | sso-incr- | 1 |0 | 0 | 0 | 0 | 0 | 0 | ++--+-+-+-++-+--+++-+-+---+-+--+---+-+-+---+---+++---+---+ Media : +-+---++---+-+---+-+-+-+-+--+---+---+---+ | MediaId | VolumeName| PoolId | MediaType | MediaTypeId | LabelType | FirstWritten| LastWritten | LabelDate | VolJobs | VolFiles | VolBlocks | VolMounts | VolStatus | +-+---++---+-+---+-+-+-+-+--+---+---+---+ | 2 | sso-full-0002 | 60 | File-sso | 0 | 0 | 2009-02-10 22:40:13 | 2009-02-10 22:46:00 | 2009-02-10 22:40:13 | 1 |0 | 21810 | 2 | Used | | 5 | sso-incr-0005 | 61 | File-sso | 0 | 0 | 2009-02-11 22:37:30 | 2009-02-11 22:39:19 | 2009-02-11 22:37:30 | 1 |0 | 1914 | 2 | Used | | 7 | sso-incr-0007 | 61 | File-sso | 0 | 0 | 2009-01-29 22:42:26 | 2009-01-29 22:43:13 | 2009-01-29 22:42:26 | 1 |0 | 1722 | 1 | Used | | 10 | sso-incr-0010 | 61 | File-sso | 0 | 0 | 2009-01-30 22:34:40 | 2009-01-30 22:35:13 | 2009-01-30 22:34:40 | 1 |0 | 1737 | 1 | Used | | 13 | sso-incr-0013 | 61 | File-sso | 0 | 0 | 2009-01-31 21:31:26 | 2009-01-31 21:32:00 | 2009-01-31 21:31:26 | 1 |0 | 1744 | 1 | Used | | 16 | sso-incr-0016 | 61 | File-sso | 0 | 0 | 2009-02-01 22:31:09 | 2009-02-01 22:31:43 | 2009-02-01 22:31:09 | 1 |0 | 1753 | 1 | Used | | 19 | sso-incr-0019 | 61 | File-sso | 0 | 0 |
Re: [Bacula-users] Issue with recycling after moving from 2.0 to 2.4
If my math is right, the 12th is the 13th day of the retention period. Since the previous job finished at 22:43, and your new job started at 22:38, the rentention period hadn't elapsed yet, by about five minutes. The reason it sometimes works and sometimes doesn't is simply the timing between the jobs. As you back up larger jobs, this problem is going to get worse. You really need more than 12 volumes for a 13 day retention period. Personally, I would suggest you consider letting Bacula automatically label volumes as needed. Also, with bi-weekly backups, you may want to consider 15 days instead of 13 days as your retention period. Otherwise, bacula has to delete an older backup just before doing the next one, and you'd be left with just one backup on your disk. If that is somehow corrupted, you'd have a problem. Yann Cézard wrote: Hi list, I have recently moved to bacula 2.4.4 (2.4.3 at the start, I upgraded to 2.4.4 last week), from 2.0.3 (totally new installation : new server, new databases, the only thing that I kept from the old install is my client/jobs/pools/... configuration files) and I am facing a strange issue in volume recycling. Operating system is Debian Lenny (bacula packages are the official Debian ones). My backups are configured that way : - 1 Full job per week, Incremental the other days - jobs are kept 13 days (full or incr) - volume are 13 days retention period, recycling is on, autoprune is on, each job has one Full Pool (2 volumes) and one Incremental Pool (12 volumes) - all backups are done on disk (no tape) - multiple databases (not really one for each client, but not far - one database by client profile) Everything was working fine with 2.0.3, but I noticed that with 2.4.4 recycling is sometime happenning more lately, or not when wanted... Exple : Pools looks like this in database (sorry for the formatting) : ++--+-+-+-++-+--+++-+-+---+-+--+---+-+-+---+---+++---+---+ | PoolId | Name | NumVols | MaxVols | UseOnce | UseCatalog | AcceptAnyVolume | VolRetention | VolUseDuration | MaxVolJobs | MaxVolFiles | MaxVolBytes | AutoPrune | Recycle | PoolType | LabelType | LabelFormat | Enabled | ScratchPoolId | RecyclePoolId | NextPoolId | MigrationHighBytes | MigrationLowBytes | MigrationTime | ++--+-+-+-++-+--+++-+-+---+-+--+---+-+-+---+---+++---+---+ | 60 | PoolSso-Full | 2 | 2 | 1 | 1 | 0 | 1123200 | 0 | 0 | 0 | 0 | 1 | 1 | Backup | 0 | sso-full- | 1 |0 | 0 | 0 | 0 | 0 | 0 | | 61 | PoolSso-Incr | 12 | 12 | 1 | 1 | 0 | 1123200 | 0 | 0 | 0 | 0 | 1 | 1 | Backup | 0 | sso-incr- | 1 |0 | 0 | 0 | 0 | 0 | 0 | ++--+-+-+-++-+--+++-+-+---+-+--+---+-+-+---+---+++---+---+ Media : +-+---++---+-+---+-+-+-+-+--+---+---+---+ | MediaId | VolumeName| PoolId | MediaType | MediaTypeId | LabelType | FirstWritten| LastWritten | LabelDate | VolJobs | VolFiles | VolBlocks | VolMounts | VolStatus | +-+---++---+-+---+-+-+-+-+--+---+---+---+ | 2 | sso-full-0002 | 60 | File-sso | 0 | 0 | 2009-02-10 22:40:13 | 2009-02-10 22:46:00 | 2009-02-10 22:40:13 | 1 |0 | 21810 | 2 | Used | | 5 | sso-incr-0005 | 61 | File-sso | 0 | 0 | 2009-02-11 22:37:30 | 2009-02-11 22:39:19 | 2009-02-11 22:37:30 | 1 |0 | 1914 | 2 | Used | | 7 |
Re: [Bacula-users] Issue with recycling after moving from 2.0 to 2.4
John Drescher a écrit : On Fri, Feb 13, 2009 at 5:19 AM, Yann Cézard yann.cez...@univ-pau.fr wrote: Hi list, I have recently moved to bacula 2.4.4 (2.4.3 at the start, I upgraded to 2.4.4 last week), from 2.0.3 (totally new installation : new server, new databases, the only thing that I kept from the old install is my client/jobs/pools/... configuration files) and I am facing a strange issue in volume recycling. Operating system is Debian Lenny (bacula packages are the official Debian ones). My backups are configured that way : - 1 Full job per week, Incremental the other days - jobs are kept 13 days (full or incr) - volume are 13 days retention period, recycling is on, autoprune is on, each job has one Full Pool (2 volumes) and one Incremental Pool (12 volumes) - all backups are done on disk (no tape) - multiple databases (not really one for each client, but not far - one database by client profile) Everything was working fine with 2.0.3, but I noticed that with 2.4.4 recycling is sometime happenning more lately, or not when wanted... Exple : Pools looks like this in database (sorry for the formatting) : ++--+-+-+-++-+--+++-+-+---+-+--+---+-+-+---+---+++---+---+ | PoolId | Name | NumVols | MaxVols | UseOnce | UseCatalog | AcceptAnyVolume | VolRetention | VolUseDuration | MaxVolJobs | MaxVolFiles | MaxVolBytes | AutoPrune | Recycle | PoolType | LabelType | LabelFormat | Enabled | ScratchPoolId | RecyclePoolId | NextPoolId | MigrationHighBytes | MigrationLowBytes | MigrationTime | ++--+-+-+-++-+--+++-+-+---+-+--+---+-+-+---+---+++---+---+ | 60 | PoolSso-Full | 2 | 2 | 1 | 1 | 0 | 1123200 | 0 | 0 | 0 | 0 | 1 | 1 | Backup | 0 | sso-full- | 1 |0 | 0 | 0 | 0 | 0 | 0 | | 61 | PoolSso-Incr | 12 | 12 | 1 | 1 | 0 | 1123200 | 0 | 0 | 0 | 0 | 1 | 1 | Backup | 0 | sso-incr- | 1 |0 | 0 | 0 | 0 | 0 | 0 | ++--+-+-+-++-+--+++-+-+---+-+--+---+-+-+---+---+++---+---+ Do not use volume PoolType Backup. Only Used, Full or Append. John Hi John, I don't understand what you mean, PoolType can only be one of this : (http://www.bacula.org/en/rel-manual/Configuring_Director.html#SECTION001415) Pool Type = type This directive defines the pool type, which corresponds to the type of Job being run. It is required and may be one of the following: Backup *Archive *Cloned *Migration *Copy *Save Note, only Backup is current implemented. So the note says that I don't really have the choice, the only type of pool that I can use is Backup ?! I you're talking about Volume status, you can look at the Media database that I've send, they're all marked as 'Used'. Or I misunderstand what you mean. Regards, -- Yann Cézard - Administrateur Systèmes Serveurs Centre de Ressources Informatiques-http://cri.univ-pau.fr Université de Pau et des Pays de l'Adour - http://www.univ-pau.fr -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Issue with recycling after moving from 2.0 to 2.4
Kevin Keane a écrit : If my math is right, the 12th is the 13th day of the retention period. Since the previous job finished at 22:43, and your new job started at 22:38, the rentention period hadn't elapsed yet, by about five minutes. The reason it sometimes works and sometimes doesn't is simply the timing between the jobs. Actually, I don't agree with your maths, sorry :) The 12th was the 14th day of the retention period. 29th 22:43:13 = start of retention, day/hour 0 30th 22:43:13 = 1st day 31th 22:43:13 = 2nd day 1st 22:43:13 = 3rd day 2nd 22:43:13 = 4th day ... 11th 22:43:13 = 13th day : job could be pruned, and then the volume 12th 22:38 = job is still there, volume is still not recycled ??? So basically it looks more like a Job pruning problem ? As you back up larger jobs, this problem is going to get worse. You really need more than 12 volumes for a 13 day retention period. I have 14 volumes : 2 full (1 day per week) + 12 incremental (6 days per week). So even if the job stopped one day after schedule (I limit the job to 20 hours by the way), when the two week after job should takes place (should it be Full or Incr), the volume should already have been recycled. That's why I choosed this 13 days Retention time, and not 14. Or perhaps I am wrong and don't understand some basic thing here ? Personally, I would suggest you consider letting Bacula automatically label volumes as needed. Also, with bi-weekly backups, you may want to consider 15 days instead of 13 days as your retention period. Otherwise, bacula has to delete an older backup just before doing the next one, and you'd be left with just one backup on your disk. If that is somehow corrupted, you'd have a problem. I know that, but that's a choice that I have made, I should restrict the size of backups that I have (more than 6To actually, keeping one more Full Jobs would mean about 9To...). Regards, -- Yann Cézard - Administrateur Systèmes Serveurs Centre de Ressources Informatiques-http://cri.univ-pau.fr Université de Pau et des Pays de l'Adour - http://www.univ-pau.fr -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Issue with recycling after moving from 2.0 to 2.4
Hi John, I don't understand what you mean, PoolType can only be one of this : (http://www.bacula.org/en/rel-manual/Configuring_Director.html#SECTION001415) Pool Type = type This directive defines the pool type, which corresponds to the type of Job being run. It is required and may be one of the following: Backup *Archive *Cloned *Migration *Copy *Save Note, only Backup is current implemented. So the note says that I don't really have the choice, the only type of pool that I can use is Backup ?! Forget that. Mental lapse. My mind does not work well this early in the morning. Sorry. John -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Issue with recycling after moving from 2.0 to 2.4
Yann Cézard wrote: Kevin Keane a écrit : If my math is right, the 12th is the 13th day of the retention period. Since the previous job finished at 22:43, and your new job started at 22:38, the rentention period hadn't elapsed yet, by about five minutes. The reason it sometimes works and sometimes doesn't is simply the timing between the jobs. Actually, I don't agree with your maths, sorry :) The 12th was the 14th day of the retention period. 29th 22:43:13 = start of retention, day/hour 0 30th 22:43:13 = 1st day 31th 22:43:13 = 2nd day 1st 22:43:13 = 3rd day 2nd 22:43:13 = 4th day ... 11th 22:43:13 = 13th day : job could be pruned, and then the volume 12th 22:38 = job is still there, volume is still not recycled ??? So basically it looks more like a Job pruning problem ? Oops. I think you are right. What are the volume, job and file retention times? I didn't see those two values in the tables you sent earlier; maybe I missed it. The only retention time I saw was the one for the pool - which really has no direct effect at all here. Maybe one of the files still had an unexpired retention time? In that case, the job won't get purged even if the job itself has passed its retention time. Similarly, if the job retention time is longer, the volume won't get purged even if its retention time has passed. As you back up larger jobs, this problem is going to get worse. You really need more than 12 volumes for a 13 day retention period. I have 14 volumes : 2 full (1 day per week) + 12 incremental (6 days per week). So even if the job stopped one day after schedule (I limit the job to 20 hours by the way), when the two week after job should takes place (should it be Full or Incr), the volume should already have been recycled. That's why I choosed this 13 days Retention time, and not 14. Or perhaps I am wrong and don't understand some basic thing here ? I think you have to look at the incremental and full pools separately. You have 13 days, and you have effectively 13 incremental volumes to work with (one of them is virtual because you are not using up an incremental volume on the day you did the full backup). That means that on some days, you will run into this timing problem. Personally, I would suggest you consider letting Bacula automatically label volumes as needed. Also, with bi-weekly backups, you may want to consider 15 days instead of 13 days as your retention period. Otherwise, bacula has to delete an older backup just before doing the next one, and you'd be left with just one backup on your disk. If that is somehow corrupted, you'd have a problem. I know that, but that's a choice that I have made, I should restrict the size of backups that I have (more than 6To actually, keeping one more Full Jobs would mean about 9To...). Wow. That's pretty big. I didn't check in your original post, but is it possible that some of the full backups take more than 24 hours? That might throw off the schedule, too. -- Kevin Keane Owner The NetTech Find the Uncommon: Expert Solutions for a Network You Never Have to Think About Office: 866-642-7116 http://www.4nettech.com This e-mail and attachments, if any, may contain confidential and/or proprietary information. Please be advised that the unauthorized use or disclosure of the information is strictly prohibited. The information herein is intended only for use by the intended recipient(s) named above. If you have received this transmission in error, please notify the sender immediately and permanently delete the e-mail and any copies, printouts or attachments thereof. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Issue with recycling after moving from 2.0 to 2.4
Kevin Keane a écrit : Yann Cézard wrote: Kevin Keane a écrit : If my math is right, the 12th is the 13th day of the retention period. Since the previous job finished at 22:43, and your new job started at 22:38, the rentention period hadn't elapsed yet, by about five minutes. The reason it sometimes works and sometimes doesn't is simply the timing between the jobs. Actually, I don't agree with your maths, sorry :) The 12th was the 14th day of the retention period. 29th 22:43:13 = start of retention, day/hour 0 30th 22:43:13 = 1st day 31th 22:43:13 = 2nd day 1st 22:43:13 = 3rd day 2nd 22:43:13 = 4th day ... 11th 22:43:13 = 13th day : job could be pruned, and then the volume 12th 22:38 = job is still there, volume is still not recycled ??? So basically it looks more like a Job pruning problem ? Oops. I think you are right. What are the volume, job and file retention times? I didn't see those two values in the tables you sent earlier; maybe I missed it. The only retention time I saw was the one for the pool - which really has no direct effect at all here. Maybe one of the files still had an unexpired retention time? In that case, the job won't get purged even if the job itself has passed its retention time. Actually, File Retention is configured 13 days for every clients. But you know what ? that's a very good point ! I explain myself : At the start of my migration, I had 2 director crashes, caused by old configuration files for Messages which were mentioning /var/bacula/log instead of /var/lib/bacula/log I noticed the volumes that were used at the time of the crash had a LastWritten field value of -00-00 00:00:00 which was causing trouble recycling, I already fixed that days ago, but I didn't thought to look at the File table ! I'll have a look at that, and keep you informed, thanks for pointing it up to me ! Wow. That's pretty big. I didn't check in your original post, but is it possible that some of the full backups take more than 24 hours? That might throw off the schedule, too Sure it is big ! In fact, all data is backupped from about 60 differents clients. The biggest job, which could not be done in 24 hours, is splitted in 7 jobs backing up a part of the total file system, each Full running on a different day. And with data volume keeps growing on it, I will probably have to move on a greater basis schedule, but that is another story :) Thanks again, Yann -- Yann Cézard - Administrateur Systèmes Serveurs Centre de Ressources Informatiques-http://cri.univ-pau.fr Université de Pau et des Pays de l'Adour - http://www.univ-pau.fr -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Issue with recycling after moving from 2.0 to 2.4
On Fri, 13 Feb 2009 15:28:09 +0100, Yann Cezard said: So basically it looks more like a Job pruning problem ? The pruning algorithm changed a little in the Bacula 2.2. Bacula 2.0 prunes all volumes in the current pool, but 2.2 stops pruning as soon as it finds one that can be purged. I'm not sure if that will break your setup. __Martin -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
