Thanks, I've stopped with my habit setting the volstatus to recycle
manually. Now I just purge the volumes when I don't need it.

On Fri, Dec 9, 2016 at 11:29 PM, Alan Brown <a.br...@ucl.ac.uk> wrote:

> On 06/12/16 20:26, Gi Dot wrote:
>
> Well I've actually update the status of all the volumes to Recycle.
>
>
> Don't do this - for the same reason Uwe has already mentioned.
>
> Always purge an unwanted volume. Bacula will recycle it when it thinks
> it's needed.
>
> If you've been doing this for a while then you'll have a DB full of bogus
> records pointing to volumes that have been reused.
>
> My postgresql setup has a few hundred million records. Pruning takes
> minutes at most and PgSQL's indexing is pretty good. Uwe's analysis is
> proably correct.
>
>
>
> Before I did that the status of all volumes were Full.
>
> *list media
> Pool: Default
> +---------+--------------+-----------+---------+------------
> ----+----------+--------------+---------+------+-----------+
> -----------+---------------------+
> | mediaid | volumename   | volstatus | enabled | volbytes       | volfiles
> | volretention | recycle | slot | inchanger | mediatype |
> lastwritten         |
> +---------+--------------+-----------+---------+------------
> ----+----------+--------------+---------+------+-----------+
> -----------+---------------------+
> |       3 | vol-D1 | Recycle   |       1 | 69,292,597,248 |       80
> |      345,600 |       1 |    0 |         0 | DDS6      | 2016-12-04
> 22:03:11 |
> |       5 | vol-F2 | Recycle   |       1 | 69,283,049,472 |       71
> |      345,600 |       1 |    0 |         0 | DDS6      | 2016-11-22
> 11:43:19 |
> |       6 | vol-D3 | Recycle   |       1 |              1 |        0
> |      345,600 |       1 |    0 |         0 | DDS6      | 2016-11-30
> 13:40:43 |
> |       7 | vol-F1 | Recycle   |       1 | 69,295,693,824 |       70
> |      345,600 |       1 |    0 |         0 | DDS6      | 2016-11-21
> 18:00:49 |
> |       9 | vol-D2 | Recycle   |       1 | 69,308,918,784 |       77
> |      345,600 |       1 |    0 |         0 | DDS6      | 2016-11-27
> 23:18:31 |
> +---------+--------------+-----------+---------+------------
> ----+----------+--------------+---------+------+-----------+
> -----------+-----------------
>
> On Mon, Dec 5, 2016 at 6:04 PM, Wanderlei Huttel <
> wanderleihut...@gmail.com> wrote:
>
>> Hello Uwe
>>
>> First of all, you are using a very old version of Bacula. Is highly
>> recommended upgrade.
>> Are sure that your database is only 5MB?
>>
>> Could you post your Pool config and "list media pool=YourPool"
>>
>>
>> Best Regards
>>
>> *Wanderlei Hüttel*
>> http://www.huttel.com.br
>>
>> 2016-12-05 7:40 GMT-02:00 Gi Dot <gadi...@gmail.com>:
>>
>>> - Hardware specs of the director (assuming all components run on a
>>> single machine)
>>> >> Backup runs on a database server. There's also one remote client
>>> being backed up once a week.
>>>
>>> - Which database are you using for the catalog?
>>> >> PostgreSQL
>>>
>>> - Amount of RAM available to the DB / backend storage (disks, ssds?)
>>> >> 32G RAM on host, 8GB for effective cache size, 8MB for work mem, and
>>> 8GB for shared buffers / SAS disks
>>>
>>> - Catalog size (file table rows)
>>> >> The size of the catalog is close to 5MB. Nothing huge.
>>>
>>> - Bacula version
>>> >> 5.2.12-3.1
>>>
>>> What exactly do you mean by "too long"? Does bacula encounter a
>>> timeout during the pruning from a database error?
>>> >> Like it runs overnight and still not done with it. Sample log:
>>> https://dpaste.de/wetb/raw
>>>
>>> Thanks.
>>>
>>>
>>>
>>> On Mon, Dec 5, 2016 at 5:02 PM, Uwe Schuerkamp <
>>> uwe.schuerk...@nionex.net> wrote:
>>>
>>>> On Mon, Dec 05, 2016 at 03:18:45PM +0800, Gi Dot wrote:
>>>> > Hello,
>>>> >
>>>> > I have this problem with one of my client experiencing pruning of a
>>>> volume
>>>> > that is taking too long (and in the end I ended up recycling it
>>>> manually by
>>>> > updating the volume status). I have googled up on this and from what I
>>>> > understand it is mostly due to the database indexing (to be honest I
>>>> don't
>>>> > entirely understand this part).
>>>> >
>>>> > My question is, is there any downside or side effect if I were to
>>>> include a
>>>> > script that looks up for Used volume and update it to Recycle before
>>>> the
>>>> > backup runs for the day. I am using this script on another client and
>>>> > things are going fine over there, but I'm just worried if there is any
>>>> > impact in a long run.
>>>> >
>>>> > If anyone would be so kind to explain to me what exactly it means by
>>>> > pruning; as in what bacula does when it runs pruning on a volume, it
>>>> is
>>>> > much appreciated as well. I have read somewhere that bacula removes
>>>> the
>>>> > jobs associated  with the volume from the catalog.
>>>> >
>>>>
>>>> Hello Gidot,
>>>>
>>>> some more info could be useful to help you in analyzing your setup
>>>> further.
>>>>
>>>> - Hardware specs of the director (assuming all components run on a
>>>> single machine)
>>>>
>>>> - Which database are you using for the catalog?
>>>>
>>>> - Amount of RAM available to the DB / backend storage (disks, ssds?)
>>>>
>>>> - Catalog size (file table rows)
>>>>
>>>> - Bacula version
>>>>
>>>> What exactly do you mean by "too long"? Does bacula encounter a
>>>> timeout during the pruning from a database error?
>>>>
>>>> All the best,
>>>>
>>>> Uwe
>>>>
>>>>
>>>> --
>>>> Uwe Schürkamp | email: <uwe.schuerk...@nionex.net>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>>
>>> _______________________________________________
>>> Bacula-users mailing list
>>> Bacula-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bacula-users
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
>
>
>
> _______________________________________________
> Bacula-users mailing 
> listBacula-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bacula-users
>
>
>
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to