Quantcast

Pruning is taking too long; downside of force update status to recycle.

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Pruning is taking too long; downside of force update status to recycle.

Gi Dot
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.

Thanks.

--
gidot

------------------------------------------------------------------------------

_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Uwe Schuerkamp
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: <[hidden email]>








------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Gi Dot
- 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 <[hidden email]> 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: <[hidden email]>









------------------------------------------------------------------------------

_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Uwe Schuerkamp
Are you seeing any high loads on the server while pruning job is
running? It looks like the pruning job is stuck in some sort of
loop. Given your machine specs, db backend and catalog size the job
should be through in an instant.

If you're feeling adventurous you could also try mannually purging the
volume.


All the best, Uwe











------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Martin Simmons
In reply to this post by Gi Dot
>>>>> On Mon, 5 Dec 2016 17:40:08 +0800, Gi Dot said:
>
> > 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

This doesn't look like a database indexing problem to me.

It looks like it needs an extra volume and fails to find one older than the
retention periods.

Did you expect vol-D1 to fill up?  If so, which volume should it use next?
You need to look at the retention period of that volume to see why it was not
recycled.

BTW, forcing a volume from Used to Recycle using the update command is a bad
idea because the database will bloat with unwanted file records.  You could
use the purge command but beware that you might lose backups that you wanted
to keep.

__Martin


>
> Thanks.
>
>
>
> On Mon, Dec 5, 2016 at 5:02 PM, Uwe Schuerkamp <[hidden email]>
> 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 manuall=
> y
> > 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 th=
> e
> > > 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=C3=BCrkamp | email: <[hidden email]>
> >
> >
> >
> >
> >
> >
> >
> >
>
> --001a113fc4b4cef4d20542e612a1
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> <div dir=3D"ltr"><div>- Hardware specs of the director (assuming all compon=
> ents run on a<br>
> single machine)<br>
> </div>&gt;&gt; Backup runs on a database server. There&#39;s also one remot=
> e client being backed up once a week.<br><div><br>
> - Which database are you using for the catalog?<br></div><div>&gt;&gt; Post=
> greSQL<br></div><div>
> <br>
> - Amount of RAM available to the DB / backend storage (disks, ssds?)<br></d=
> iv><div>&gt;&gt; 32G RAM on host, 8GB for effective cache size, 8MB for wor=
> k mem, and 8GB for shared buffers / SAS disks<br></div><div>
> <br>
> - Catalog size (file table rows)<br></div><div>&gt;&gt; The size of the cat=
> alog is close to 5MB. Nothing huge.<br></div><div>
> <br>
> - Bacula version<br></div><div>&gt;&gt; 5.2.12-3.1<br></div><div>
> <br>
> What exactly do you mean by &quot;too long&quot;? Does bacula encounter a<b=
> r>
> timeout during the pruning from a database error?<br></div><div>&gt;&gt; Li=
> ke it runs overnight and still not done with it. Sample log:<br><a href=3D"=
> https://dpaste.de/wetb/raw">https://dpaste.de/wetb/raw</a><br><br></div><di=
> v>Thanks.<br><br><br></div><div><div class=3D"gmail_extra"><br><div class=
> =3D"gmail_quote">On Mon, Dec 5, 2016 at 5:02 PM, Uwe Schuerkamp <span dir=
> =3D"ltr">&lt;<a href=3D"mailto:[hidden email]" target=3D"_blank"=
> >[hidden email]</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
> ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
> 204,204);padding-left:1ex"><span class=3D"gmail-">On Mon, Dec 05, 2016 at 0=
> 3:18:45PM +0800, Gi Dot wrote:<br>
> &gt; Hello,<br>
> &gt;<br>
> &gt; I have this problem with one of my client experiencing pruning of a vo=
> lume<br>
> &gt; that is taking too long (and in the end I ended up recycling it manual=
> ly by<br>
> &gt; updating the volume status). I have googled up on this and from what I=
> <br>
> &gt; understand it is mostly due to the database indexing (to be honest I d=
> on&#39;t<br>
> &gt; entirely understand this part).<br>
> &gt;<br>
> &gt; My question is, is there any downside or side effect if I were to incl=
> ude a<br>
> &gt; script that looks up for Used volume and update it to Recycle before t=
> he<br>
> &gt; backup runs for the day. I am using this script on another client and<=
> br>
> &gt; things are going fine over there, but I&#39;m just worried if there is=
>  any<br>
> &gt; impact in a long run.<br>
> &gt;<br>
> &gt; If anyone would be so kind to explain to me what exactly it means by<b=
> r>
> &gt; pruning; as in what bacula does when it runs pruning on a volume, it i=
> s<br>
> &gt; much appreciated as well. I have read somewhere that bacula removes th=
> e<br>
> &gt; jobs associated=C2=A0 with the volume from the catalog.<br>
> &gt;<br>
> <br>
> </span>Hello Gidot,<br>
> <br>
> some more info could be useful to help you in analyzing your setup<br>
> further.<br>
> <br>
> - Hardware specs of the director (assuming all components run on a<br>
> single machine)<br>
> <br>
> - Which database are you using for the catalog?<br>
> <br>
> - Amount of RAM available to the DB / backend storage (disks, ssds?)<br>
> <br>
> - Catalog size (file table rows)<br>
> <br>
> - Bacula version<br>
> <br>
> What exactly do you mean by &quot;too long&quot;? Does bacula encounter a<b=
> r>
> timeout during the pruning from a database error?<br>
> <br>
> All the best,<br>
> <br>
> Uwe<br>
> <br>
> <br>
> --<br>
> Uwe Sch=C3=BCrkamp | email: &lt;<a href=3D"mailto:[hidden email]=
> ">[hidden email]</a>&gt;<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> </blockquote></div><br></div></div></div>
>
> --001a113fc4b4cef4d20542e612a1--
>
>
> --===============8049073509691406397==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> ------------------------------------------------------------------------------
>
> --===============8049073509691406397==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> Bacula-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
> --===============8049073509691406397==--
>

------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Gi Dot
In reply to this post by Gi Dot
Well I've actually update the status of all the volumes to Recycle. 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 <[hidden email]> 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

2016-12-05 7:40 GMT-02:00 Gi Dot <[hidden email]>:
- 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 <[hidden email]> 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: <[hidden email]>









------------------------------------------------------------------------------

_______________________________________________
Bacula-users mailing list
[hidden email]
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 list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Gi Dot
In reply to this post by Uwe Schuerkamp
Not that I noticed. Purging will remove the jobs associated with the volume off the catalog right?

On Mon, Dec 5, 2016 at 6:34 PM, Uwe Schuerkamp <[hidden email]> wrote:
Are you seeing any high loads on the server while pruning job is
running? It looks like the pruning job is stuck in some sort of
loop. Given your machine specs, db backend and catalog size the job
should be through in an instant.

If you're feeling adventurous you could also try mannually purging the
volume.


All the best, Uwe












------------------------------------------------------------------------------
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 list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Gi Dot
In reply to this post by Martin Simmons
All of the volumes were full at the time, and have past the retention period. Bacula prunes the oldest volume, and stuck at it.

Sorry if this question is trivial, but I don't really understand purging. If I were to purge a volume manually, I will definitely lose all of the backups in the volume. And all the jobs associated with the volume will be removed from the catalog. So how does it make me lose other backups that I wanted to keep? Isn't it pretty much the same if I were to recycle the volume?

On Tue, Dec 6, 2016 at 3:18 AM, Martin Simmons <[hidden email]> wrote:
>>>>> On Mon, 5 Dec 2016 17:40:08 +0800, Gi Dot said:
>
> > 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

This doesn't look like a database indexing problem to me.

It looks like it needs an extra volume and fails to find one older than the
retention periods.

Did you expect vol-D1 to fill up?  If so, which volume should it use next?
You need to look at the retention period of that volume to see why it was not
recycled.

BTW, forcing a volume from Used to Recycle using the update command is a bad
idea because the database will bloat with unwanted file records.  You could
use the purge command but beware that you might lose backups that you wanted
to keep.

__Martin


>
> Thanks.
>
>
>
> On Mon, Dec 5, 2016 at 5:02 PM, Uwe Schuerkamp <[hidden email]>
> 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 manuall=
> y
> > 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 th=
> e
> > > 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=C3=BCrkamp | email: <[hidden email]>
> >
> >
> >
> >
> >
> >
> >
> >
>
> --001a113fc4b4cef4d20542e612a1
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> <div dir=3D"ltr"><div>- Hardware specs of the director (assuming all compon=
> ents run on a<br>
> single machine)<br>
> </div>&gt;&gt; Backup runs on a database server. There&#39;s also one remot=
> e client being backed up once a week.<br><div><br>
> - Which database are you using for the catalog?<br></div><div>&gt;&gt; Post=
> greSQL<br></div><div>
> <br>
> - Amount of RAM available to the DB / backend storage (disks, ssds?)<br></d=
> iv><div>&gt;&gt; 32G RAM on host, 8GB for effective cache size, 8MB for wor=
> k mem, and 8GB for shared buffers / SAS disks<br></div><div>
> <br>
> - Catalog size (file table rows)<br></div><div>&gt;&gt; The size of the cat=
> alog is close to 5MB. Nothing huge.<br></div><div>
> <br>
> - Bacula version<br></div><div>&gt;&gt; 5.2.12-3.1<br></div><div>
> <br>
> What exactly do you mean by &quot;too long&quot;? Does bacula encounter a<b=
> r>
> timeout during the pruning from a database error?<br></div><div>&gt;&gt; Li=
> ke it runs overnight and still not done with it. Sample log:<br><a href=3D"=
> https://dpaste.de/wetb/raw">https://dpaste.de/wetb/raw</a><br><br></div><di=
> v>Thanks.<br><br><br></div><div><div class=3D"gmail_extra"><br><div class=
> =3D"gmail_quote">On Mon, Dec 5, 2016 at 5:02 PM, Uwe Schuerkamp <span dir=
> =3D"ltr">&lt;<a href=3D"mailto:[hidden email]" target=3D"_blank"=
> >[hidden email]</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
> ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
> 204,204);padding-left:1ex"><span class=3D"gmail-">On Mon, Dec 05, 2016 at 0=
> 3:18:45PM +0800, Gi Dot wrote:<br>
> &gt; Hello,<br>
> &gt;<br>
> &gt; I have this problem with one of my client experiencing pruning of a vo=
> lume<br>
> &gt; that is taking too long (and in the end I ended up recycling it manual=
> ly by<br>
> &gt; updating the volume status). I have googled up on this and from what I=
> <br>
> &gt; understand it is mostly due to the database indexing (to be honest I d=
> on&#39;t<br>
> &gt; entirely understand this part).<br>
> &gt;<br>
> &gt; My question is, is there any downside or side effect if I were to incl=
> ude a<br>
> &gt; script that looks up for Used volume and update it to Recycle before t=
> he<br>
> &gt; backup runs for the day. I am using this script on another client and<=
> br>
> &gt; things are going fine over there, but I&#39;m just worried if there is=
>  any<br>
> &gt; impact in a long run.<br>
> &gt;<br>
> &gt; If anyone would be so kind to explain to me what exactly it means by<b=
> r>
> &gt; pruning; as in what bacula does when it runs pruning on a volume, it i=
> s<br>
> &gt; much appreciated as well. I have read somewhere that bacula removes th=
> e<br>
> &gt; jobs associated=C2=A0 with the volume from the catalog.<br>
> &gt;<br>
> <br>
> </span>Hello Gidot,<br>
> <br>
> some more info could be useful to help you in analyzing your setup<br>
> further.<br>
> <br>
> - Hardware specs of the director (assuming all components run on a<br>
> single machine)<br>
> <br>
> - Which database are you using for the catalog?<br>
> <br>
> - Amount of RAM available to the DB / backend storage (disks, ssds?)<br>
> <br>
> - Catalog size (file table rows)<br>
> <br>
> - Bacula version<br>
> <br>
> What exactly do you mean by &quot;too long&quot;? Does bacula encounter a<b=
> r>
> timeout during the pruning from a database error?<br>
> <br>
> All the best,<br>
> <br>
> Uwe<br>
> <br>
> <br>
> --<br>
> Uwe Sch=C3=BCrkamp | email: &lt;<a href=3D"mailto:[hidden email]=
> ">[hidden email]</a>&gt;<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> </blockquote></div><br></div></div></div>
>
> --001a113fc4b4cef4d20542e612a1--
>
>
> --===============8049073509691406397==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> ------------------------------------------------------------------------------
>
> --===============8049073509691406397==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> Bacula-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
> --===============8049073509691406397==--
>

------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
[hidden email]
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 list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Gi Dot
Weird thing is, after the long pruning, I decided to change the volume status to recycle. Done that, the backup worked fine. After that I changed the status of all volumes to recycle. But last night, the scheduled backup didn't run because of pruning vol-F1. I thought when the volume is recycled it will skip all the pruning part.




On Wed, Dec 7, 2016 at 4:41 AM, Gi Dot <[hidden email]> wrote:
All of the volumes were full at the time, and have past the retention period. Bacula prunes the oldest volume, and stuck at it.

Sorry if this question is trivial, but I don't really understand purging. If I were to purge a volume manually, I will definitely lose all of the backups in the volume. And all the jobs associated with the volume will be removed from the catalog. So how does it make me lose other backups that I wanted to keep? Isn't it pretty much the same if I were to recycle the volume?

On Tue, Dec 6, 2016 at 3:18 AM, Martin Simmons <[hidden email]> wrote:
>>>>> On Mon, 5 Dec 2016 17:40:08 +0800, Gi Dot said:
>
> > 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

This doesn't look like a database indexing problem to me.

It looks like it needs an extra volume and fails to find one older than the
retention periods.

Did you expect vol-D1 to fill up?  If so, which volume should it use next?
You need to look at the retention period of that volume to see why it was not
recycled.

BTW, forcing a volume from Used to Recycle using the update command is a bad
idea because the database will bloat with unwanted file records.  You could
use the purge command but beware that you might lose backups that you wanted
to keep.

__Martin


>
> Thanks.
>
>
>
> On Mon, Dec 5, 2016 at 5:02 PM, Uwe Schuerkamp <[hidden email]>
> 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 manuall=
> y
> > 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 th=
> e
> > > 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=C3=BCrkamp | email: <[hidden email]>
> >
> >
> >
> >
> >
> >
> >
> >
>
> --001a113fc4b4cef4d20542e612a1
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> <div dir=3D"ltr"><div>- Hardware specs of the director (assuming all compon=
> ents run on a<br>
> single machine)<br>
> </div>&gt;&gt; Backup runs on a database server. There&#39;s also one remot=
> e client being backed up once a week.<br><div><br>
> - Which database are you using for the catalog?<br></div><div>&gt;&gt; Post=
> greSQL<br></div><div>
> <br>
> - Amount of RAM available to the DB / backend storage (disks, ssds?)<br></d=
> iv><div>&gt;&gt; 32G RAM on host, 8GB for effective cache size, 8MB for wor=
> k mem, and 8GB for shared buffers / SAS disks<br></div><div>
> <br>
> - Catalog size (file table rows)<br></div><div>&gt;&gt; The size of the cat=
> alog is close to 5MB. Nothing huge.<br></div><div>
> <br>
> - Bacula version<br></div><div>&gt;&gt; 5.2.12-3.1<br></div><div>
> <br>
> What exactly do you mean by &quot;too long&quot;? Does bacula encounter a<b=
> r>
> timeout during the pruning from a database error?<br></div><div>&gt;&gt; Li=
> ke it runs overnight and still not done with it. Sample log:<br><a href=3D"=
> https://dpaste.de/wetb/raw">https://dpaste.de/wetb/raw</a><br><br></div><di=
> v>Thanks.<br><br><br></div><div><div class=3D"gmail_extra"><br><div class=
> =3D"gmail_quote">On Mon, Dec 5, 2016 at 5:02 PM, Uwe Schuerkamp <span dir=
> =3D"ltr">&lt;<a href=3D"mailto:[hidden email]" target=3D"_blank"=
> >[hidden email]</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
> ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
> 204,204);padding-left:1ex"><span class=3D"gmail-">On Mon, Dec 05, 2016 at 0=
> 3:18:45PM +0800, Gi Dot wrote:<br>
> &gt; Hello,<br>
> &gt;<br>
> &gt; I have this problem with one of my client experiencing pruning of a vo=
> lume<br>
> &gt; that is taking too long (and in the end I ended up recycling it manual=
> ly by<br>
> &gt; updating the volume status). I have googled up on this and from what I=
> <br>
> &gt; understand it is mostly due to the database indexing (to be honest I d=
> on&#39;t<br>
> &gt; entirely understand this part).<br>
> &gt;<br>
> &gt; My question is, is there any downside or side effect if I were to incl=
> ude a<br>
> &gt; script that looks up for Used volume and update it to Recycle before t=
> he<br>
> &gt; backup runs for the day. I am using this script on another client and<=
> br>
> &gt; things are going fine over there, but I&#39;m just worried if there is=
>  any<br>
> &gt; impact in a long run.<br>
> &gt;<br>
> &gt; If anyone would be so kind to explain to me what exactly it means by<b=
> r>
> &gt; pruning; as in what bacula does when it runs pruning on a volume, it i=
> s<br>
> &gt; much appreciated as well. I have read somewhere that bacula removes th=
> e<br>
> &gt; jobs associated=C2=A0 with the volume from the catalog.<br>
> &gt;<br>
> <br>
> </span>Hello Gidot,<br>
> <br>
> some more info could be useful to help you in analyzing your setup<br>
> further.<br>
> <br>
> - Hardware specs of the director (assuming all components run on a<br>
> single machine)<br>
> <br>
> - Which database are you using for the catalog?<br>
> <br>
> - Amount of RAM available to the DB / backend storage (disks, ssds?)<br>
> <br>
> - Catalog size (file table rows)<br>
> <br>
> - Bacula version<br>
> <br>
> What exactly do you mean by &quot;too long&quot;? Does bacula encounter a<b=
> r>
> timeout during the pruning from a database error?<br>
> <br>
> All the best,<br>
> <br>
> Uwe<br>
> <br>
> <br>
> --<br>
> Uwe Sch=C3=BCrkamp | email: &lt;<a href=3D"mailto:[hidden email]=
> ">[hidden email]</a>&gt;<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> </blockquote></div><br></div></div></div>
>
> --001a113fc4b4cef4d20542e612a1--
>
>
> --===============8049073509691406397==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> ------------------------------------------------------------------------------
>
> --===============8049073509691406397==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> Bacula-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
> --===============8049073509691406397==--
>

------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
[hidden email]
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 list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Kern Sibbald
Hello,

Here are a few tips for you.

- You absolutely need to understand what Pruning is.  The best way to understand it is to read the manual.

- If you are running MySQL as that catalog and you are having catalog performance issues, you should consider switching to Postgresql. 

- Usually performance issues with the catalog are related to several points
   1. You may have added additional indexes.  Doing so sometimes speeds up a particular operation,
       but much more often totally destroys the performance elsewhere.  If you have added any, start by
       removing them.
   2. Every database and particularly Postgresql needs some tuning for your system and your workload.
       Generally the database vendor has programs that will help you find problems.

- If you are running more than 1000 jobs per day, then you clearly need Postgresql and you need it to be properly tuned.  You may also need to turn off automatic pruning and specifically schedule a prune.

- Pruning of a single job should never take an excessive amount of time, but if as noted above you have 1000 jobs, it is not always ideal to do it while backups are running.

- You should *never* be manually (with SQL commands) be changing the Bacula catalog. 

- You should almost never need to use a built in command to modify the catalog Media records.  This does not include running prune or purge commands.

- If you are running more than 500 jobs a day, you need to take the Bacula Admin I course.

- If you are running more than 500 jobs and not a Bacula expert, you most likely need a professional service contract.

Best regards,
Kern

On 12/06/2016 09:55 PM, Gi Dot wrote:
Weird thing is, after the long pruning, I decided to change the volume status to recycle. Done that, the backup worked fine. After that I changed the status of all volumes to recycle. But last night, the scheduled backup didn't run because of pruning vol-F1. I thought when the volume is recycled it will skip all the pruning part.




On Wed, Dec 7, 2016 at 4:41 AM, Gi Dot <[hidden email]> wrote:
All of the volumes were full at the time, and have past the retention period. Bacula prunes the oldest volume, and stuck at it.

Sorry if this question is trivial, but I don't really understand purging. If I were to purge a volume manually, I will definitely lose all of the backups in the volume. And all the jobs associated with the volume will be removed from the catalog. So how does it make me lose other backups that I wanted to keep? Isn't it pretty much the same if I were to recycle the volume?

On Tue, Dec 6, 2016 at 3:18 AM, Martin Simmons <[hidden email]> wrote:
>>>>> On Mon, 5 Dec 2016 17:40:08 +0800, Gi Dot said:
>
> > 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

This doesn't look like a database indexing problem to me.

It looks like it needs an extra volume and fails to find one older than the
retention periods.

Did you expect vol-D1 to fill up?  If so, which volume should it use next?
You need to look at the retention period of that volume to see why it was not
recycled.

BTW, forcing a volume from Used to Recycle using the update command is a bad
idea because the database will bloat with unwanted file records.  You could
use the purge command but beware that you might lose backups that you wanted
to keep.

__Martin


>
> Thanks.
>
>
>
> On Mon, Dec 5, 2016 at 5:02 PM, Uwe Schuerkamp <[hidden email]>
> 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 manuall=
> y
> > 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 th=
> e
> > > 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=C3=BCrkamp | email: <[hidden email]>
> >
> >
> >
> >
> >
> >
> >
> >
>
> --001a113fc4b4cef4d20542e612a1
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> <div dir=3D"ltr"><div>- Hardware specs of the director (assuming all compon=
> ents run on a<br>
> single machine)<br>
> </div>&gt;&gt; Backup runs on a database server. There&#39;s also one remot=
> e client being backed up once a week.<br><div><br>
> - Which database are you using for the catalog?<br></div><div>&gt;&gt; Post=
> greSQL<br></div><div>
> <br>
> - Amount of RAM available to the DB / backend storage (disks, ssds?)<br></d=
> iv><div>&gt;&gt; 32G RAM on host, 8GB for effective cache size, 8MB for wor=
> k mem, and 8GB for shared buffers / SAS disks<br></div><div>
> <br>
> - Catalog size (file table rows)<br></div><div>&gt;&gt; The size of the cat=
> alog is close to 5MB. Nothing huge.<br></div><div>
> <br>
> - Bacula version<br></div><div>&gt;&gt; 5.2.12-3.1<br></div><div>
> <br>
> What exactly do you mean by &quot;too long&quot;? Does bacula encounter a<b=
> r>
> timeout during the pruning from a database error?<br></div><div>&gt;&gt; Li=
> ke it runs overnight and still not done with it. Sample log:<br><a href=3D"=
> https://dpaste.de/wetb/raw">https://dpaste.de/wetb/raw</a><br><br></div><di=
> v>Thanks.<br><br><br></div><div><div class=3D"gmail_extra"><br><div class=
> =3D"gmail_quote">On Mon, Dec 5, 2016 at 5:02 PM, Uwe Schuerkamp <span dir=
> =3D"ltr">&lt;<a href=3D"mailto:[hidden email]" target=3D"_blank"=
> >[hidden email]</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
> ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
> 204,204);padding-left:1ex"><span class=3D"gmail-">On Mon, Dec 05, 2016 at 0=
> 3:18:45PM +0800, Gi Dot wrote:<br>
> &gt; Hello,<br>
> &gt;<br>
> &gt; I have this problem with one of my client experiencing pruning of a vo=
> lume<br>
> &gt; that is taking too long (and in the end I ended up recycling it manual=
> ly by<br>
> &gt; updating the volume status). I have googled up on this and from what I=
> <br>
> &gt; understand it is mostly due to the database indexing (to be honest I d=
> on&#39;t<br>
> &gt; entirely understand this part).<br>
> &gt;<br>
> &gt; My question is, is there any downside or side effect if I were to incl=
> ude a<br>
> &gt; script that looks up for Used volume and update it to Recycle before t=
> he<br>
> &gt; backup runs for the day. I am using this script on another client and<=
> br>
> &gt; things are going fine over there, but I&#39;m just worried if there is=
>  any<br>
> &gt; impact in a long run.<br>
> &gt;<br>
> &gt; If anyone would be so kind to explain to me what exactly it means by<b=
> r>
> &gt; pruning; as in what bacula does when it runs pruning on a volume, it i=
> s<br>
> &gt; much appreciated as well. I have read somewhere that bacula removes th=
> e<br>
> &gt; jobs associated=C2=A0 with the volume from the catalog.<br>
> &gt;<br>
> <br>
> </span>Hello Gidot,<br>
> <br>
> some more info could be useful to help you in analyzing your setup<br>
> further.<br>
> <br>
> - Hardware specs of the director (assuming all components run on a<br>
> single machine)<br>
> <br>
> - Which database are you using for the catalog?<br>
> <br>
> - Amount of RAM available to the DB / backend storage (disks, ssds?)<br>
> <br>
> - Catalog size (file table rows)<br>
> <br>
> - Bacula version<br>
> <br>
> What exactly do you mean by &quot;too long&quot;? Does bacula encounter a<b=
> r>
> timeout during the pruning from a database error?<br>
> <br>
> All the best,<br>
> <br>
> Uwe<br>
> <br>
> <br>
> --<br>
> Uwe Sch=C3=BCrkamp | email: &lt;<a href=3D"mailto:[hidden email]=
> ">[hidden email]</a>&gt;<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> </blockquote></div><br></div></div></div>
>
> --001a113fc4b4cef4d20542e612a1--
>
>
> --===============8049073509691406397==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> ------------------------------------------------------------------------------
>
> --===============8049073509691406397==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> Bacula-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
> --===============8049073509691406397==--
>

------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
[hidden email]
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 list
[hidden email]
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 list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Josip Deanovic
On Wednesday 2016-12-07 10:20:56 Kern Sibbald wrote:
> Hello,
>
> Here are a few tips for you.
>
> - You absolutely need to understand what Pruning is.  The best way to
> understand it is to read the manual.
>
> - If you are running MySQL as that catalog and you are having catalog
> performance issues, you should consider switching to Postgresql.

I'll add some thoughts and experiences on this matter...

I usually use mysql as a catalog database and the only case where I have
experienced performance issues (e.g. even with a very small data sets it
takes half an hour or more just to get the prompt to browse files in
bconsole during the restore procedure) was actually a combination of
hardware issues (slow IO on the host machine that serves the virtual
machine) in combination with insufficient resources assigned to the
virtual machine (RAM or CPU).

In my case as described above, the problem was always solved by adding
more resources to the virtual machine.
I have never experienced performance issues on the real hardware machine
when using mysql as a catalog database (database sizes from 1.5G to 50+G).
However I do pay some care to the configuration of my databases.

It's a good idea to make a backup server a dedicated machine (performance
as well as security-wise) and for most small/medium bacula setups the
catalog database could exist on the same server with other bacula daemons
in which case it could be better optimized for the specific bacula's
needs.

--
Josip Deanovic

------------------------------------------------------------------------------
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 list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Martin Simmons
In reply to this post by Gi Dot
The output shows that Bacula repeatedly tried to prune the same volume and
apparently failed to recycle it, which suggests that there were still jobs
associated with it somehow (or the catalog was already in a broken state).

Purging won't make you lose other backups.  My point was just that purging
overrides the retention period, so you can lose backups that were supposed to
be kept according to the retention period.

__Martin


>>>>> On Wed, 7 Dec 2016 04:41:47 +0800, Gi Dot said:
>
> All of the volumes were full at the time, and have past the retention
> period. Bacula prunes the oldest volume, and stuck at it.
>
> Sorry if this question is trivial, but I don't really understand purging.
> If I were to purge a volume manually, I will definitely lose all of the
> backups in the volume. And all the jobs associated with the volume will be
> removed from the catalog. So how does it make me lose other backups that I
> wanted to keep? Isn't it pretty much the same if I were to recycle the
> volume?
>
> On Tue, Dec 6, 2016 at 3:18 AM, Martin Simmons <[hidden email]> wrote:
>
> > >>>>> On Mon, 5 Dec 2016 17:40:08 +0800, Gi Dot said:
> > >
> > > > 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
> >
> > This doesn't look like a database indexing problem to me.
> >
> > It looks like it needs an extra volume and fails to find one older than the
> > retention periods.
> >
> > Did you expect vol-D1 to fill up?  If so, which volume should it use next?
> > You need to look at the retention period of that volume to see why it was
> > not
> > recycled.
> >
> > BTW, forcing a volume from Used to Recycle using the update command is a
> > bad
> > idea because the database will bloat with unwanted file records.  You could
> > use the purge command but beware that you might lose backups that you
> > wanted
> > to keep.
> >
> > __Martin
> >
> >
> > >
> > > Thanks.
> > >
> > >
> > >
> > > On Mon, Dec 5, 2016 at 5:02 PM, Uwe Schuerkamp <
> > [hidden email]>
> > > 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
> > manuall=
> > > y
> > > > 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
> > th=
> > > e
> > > > > 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=C3=BCrkamp | email: <[hidden email]>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >

------------------------------------------------------------------------------
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 list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Martin Simmons
In reply to this post by Gi Dot
Setting the state to Recycle can also prevent recycling unfortunately.  Use
the purge command if you want to override the retention periods.

__Martin


>>>>> On Wed, 7 Dec 2016 04:55:09 +0800, Gi Dot said:
>
> Weird thing is, after the long pruning, I decided to change the volume
> status to recycle. Done that, the backup worked fine. After that I changed
> the status of all volumes to recycle. But last night, the scheduled backup
> didn't run because of pruning vol-F1. I thought when the volume is recycled
> it will skip all the pruning part.
>
>
>
>
> On Wed, Dec 7, 2016 at 4:41 AM, Gi Dot <[hidden email]> wrote:
>
> > All of the volumes were full at the time, and have past the retention
> > period. Bacula prunes the oldest volume, and stuck at it.
> >
> > Sorry if this question is trivial, but I don't really understand purging.
> > If I were to purge a volume manually, I will definitely lose all of the
> > backups in the volume. And all the jobs associated with the volume will be
> > removed from the catalog. So how does it make me lose other backups that I
> > wanted to keep? Isn't it pretty much the same if I were to recycle the
> > volume?
> >
> > On Tue, Dec 6, 2016 at 3:18 AM, Martin Simmons <[hidden email]>
> > wrote:
> >
> >> >>>>> On Mon, 5 Dec 2016 17:40:08 +0800, Gi Dot said:
> >> >
> >> > > 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
> >>
> >> This doesn't look like a database indexing problem to me.
> >>
> >> It looks like it needs an extra volume and fails to find one older than
> >> the
> >> retention periods.
> >>
> >> Did you expect vol-D1 to fill up?  If so, which volume should it use next?
> >> You need to look at the retention period of that volume to see why it was
> >> not
> >> recycled.
> >>
> >> BTW, forcing a volume from Used to Recycle using the update command is a
> >> bad
> >> idea because the database will bloat with unwanted file records.  You
> >> could
> >> use the purge command but beware that you might lose backups that you
> >> wanted
> >> to keep.
> >>
> >> __Martin
> >>
> >>
> >> >
> >> > Thanks.
> >> >
> >> >
> >> >
> >> > On Mon, Dec 5, 2016 at 5:02 PM, Uwe Schuerkamp <
> >> [hidden email]>
> >> > 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
> >> manuall>> > y
> >> > > 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 th>> > e
> >> > > > 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: <[hidden email]>
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> >

------------------------------------------------------------------------------
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 list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Josh Fisher
In reply to this post by Josip Deanovic

On 12/7/2016 5:45 AM, Josip Deanovic wrote:

> On Wednesday 2016-12-07 10:20:56 Kern Sibbald wrote:
>> Hello,
>>
>> Here are a few tips for you.
>>
>> - You absolutely need to understand what Pruning is.  The best way to
>> understand it is to read the manual.
>>
>> - If you are running MySQL as that catalog and you are having catalog
>> performance issues, you should consider switching to Postgresql.
> I'll add some thoughts and experiences on this matter...
>
> I usually use mysql as a catalog database and the only case where I have
> experienced performance issues (e.g. even with a very small data sets it
> takes half an hour or more just to get the prompt to browse files in
> bconsole during the restore procedure) was actually a combination of
> hardware issues (slow IO on the host machine that serves the virtual
> machine) in combination with insufficient resources assigned to the
> virtual machine (RAM or CPU).
>
> In my case as described above, the problem was always solved by adding
> more resources to the virtual machine.
> I have never experienced performance issues on the real hardware machine
> when using mysql as a catalog database (database sizes from 1.5G to 50+G).
> However I do pay some care to the configuration of my databases.

Also, pay some care to the physical disk drives that the db is using.
Having the catalog db on the same physical disks that are also being
used for Bacula's spool area can be very detrimental to performance.

>
> It's a good idea to make a backup server a dedicated machine (performance
> as well as security-wise) and for most small/medium bacula setups the
> catalog database could exist on the same server with other bacula daemons
> in which case it could be better optimized for the specific bacula's
> needs.
>


------------------------------------------------------------------------------
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 list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Alan Brown
In reply to this post by Martin Simmons
On 07/12/16 12:44, Martin Simmons wrote:
> The output shows that Bacula repeatedly tried to prune the same volume and
> apparently failed to recycle it, which suggests that there were still jobs
> associated with it somehow (or the catalog was already in a broken state).

Assuming the catalog isn't broken, the most likely explanation is that
the volume in question contains the only remaining backup of a given job.

Bacula won't allow deletion of that last backup without a fight (ie, the
volume should be purged, or the jobid deleted)

If you want to see what bacula thinks is still in the volume, add this
query to /opt/bacula/scripts/query.sql


:List Jobs stored for a given Volume name
*Enter Volume name:
SELECT DISTINCT Pool.Name as Pool,Job.JobId as JobId,Job.Name as
Name,Job.StartTime as StartTime,
   Job.Type as Type,Job.Level as Level,Job.JobFiles as Files,
   Job.JobBytes as Bytes,Job.JobStatus as Status
  FROM Media,JobMedia,Job,Pool
  WHERE Media.VolumeName='%1'
  AND Media.MediaId=JobMedia.MediaId
  AND JobMedia.JobId=Job.JobId
  AND Media.PoolID=Pool.PoolId
  ORDER by Job.StartTime;
#


Purging only deletes the database jobids associated with a volume.

The volume itself is not reformatted until recycled and reinitialised,
so an accidentally purged one can be recovered before reuse by using the
bscan utility.


>
> Purging won't make you lose other backups.  My point was just that purging
> overrides the retention period, so you can lose backups that were supposed to
> be kept according to the retention period.
>
> __Martin
>
>
>>>>>> On Wed, 7 Dec 2016 04:41:47 +0800, Gi Dot said:
>> All of the volumes were full at the time, and have past the retention
>> period. Bacula prunes the oldest volume, and stuck at it.
>>
>> Sorry if this question is trivial, but I don't really understand purging.
>> If I were to purge a volume manually, I will definitely lose all of the
>> backups in the volume. And all the jobs associated with the volume will be
>> removed from the catalog. So how does it make me lose other backups that I
>> wanted to keep? Isn't it pretty much the same if I were to recycle the
>> volume?
>>
>> On Tue, Dec 6, 2016 at 3:18 AM, Martin Simmons <[hidden email]> wrote:
>>
>>>>>>>> On Mon, 5 Dec 2016 17:40:08 +0800, Gi Dot said:
>>>>> 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
>>> This doesn't look like a database indexing problem to me.
>>>
>>> It looks like it needs an extra volume and fails to find one older than the
>>> retention periods.
>>>
>>> Did you expect vol-D1 to fill up?  If so, which volume should it use next?
>>> You need to look at the retention period of that volume to see why it was
>>> not
>>> recycled.
>>>
>>> BTW, forcing a volume from Used to Recycle using the update command is a
>>> bad
>>> idea because the database will bloat with unwanted file records.  You could
>>> use the purge command but beware that you might lose backups that you
>>> wanted
>>> to keep.
>>>
>>> __Martin
>>>
>>>
>>>> Thanks.
>>>>
>>>>
>>>>
>>>> On Mon, Dec 5, 2016 at 5:02 PM, Uwe Schuerkamp <
>>> [hidden email]>
>>>> 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
>>> manuall=
>>>> y
>>>>> 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
>>> th=
>>>> e
>>>>>> 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=C3=BCrkamp | email: <[hidden email]>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
> ------------------------------------------------------------------------------
> 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 list
> [hidden email]
> 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 list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Josip Deanovic
In reply to this post by Josh Fisher
On Friday 2016-12-09 07:47:03 Josh Fisher wrote:
> Also, pay some care to the physical disk drives that the db is using.
> Having the catalog db on the same physical disks that are also being
> used for Bacula's spool area can be very detrimental to performance.

Of course.
However in case of file storage the spooling option should be switched
off (IMHO) as it will yield significant decrease in performance.

I doubt that there are many cases where data is coming at a rate that
would justify spooling in case of file storage (I don't think I have
ever stumbled upon such case). I would of course like to hear different
experiences on the matter if there are any.

--
Josip Deanovic

------------------------------------------------------------------------------
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 list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Kern Sibbald
On 12/09/2016 09:15 PM, Josip Deanovic wrote:

> On Friday 2016-12-09 07:47:03 Josh Fisher wrote:
>> Also, pay some care to the physical disk drives that the db is using.
>> Having the catalog db on the same physical disks that are also being
>> used for Bacula's spool area can be very detrimental to performance.
> Of course.
> However in case of file storage the spooling option should be switched
> off (IMHO) as it will yield significant decrease in performance.
>
> I doubt that there are many cases where data is coming at a rate that
> would justify spooling in case of file storage (I don't think I have
> ever stumbled upon such case). I would of course like to hear different
> experiences on the matter if there are any.
>
Yes, that is very true.

Ah, and something I completely forgot:  always have Attribute Spooling
turned on.  If Attribute Spooling is not turned on putting the metadata
in the catalog will be *very* slow.

Best regards,

Kern


------------------------------------------------------------------------------
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 list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Josip Deanovic
On Friday 2016-12-09 21:22:14 Kern Sibbald wrote:
> Ah, and something I completely forgot:  always have Attribute Spooling
> turned on.  If Attribute Spooling is not turned on putting the metadata
> in the catalog will be *very* slow.

I have just checked few of my setups and I am indeed using Attribute
Spooling option.

It's either documented or I have learned about the impact of this option
from this mailing list a long time ago.

Regards

--
Josip Deanovic

------------------------------------------------------------------------------
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 list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Dimitri Maziuk
In reply to this post by Josip Deanovic
On 12/09/2016 02:15 PM, Josip Deanovic wrote:
>
> I doubt that there are many cases where data is coming at a rate that
> would justify spooling in case of file storage (I don't think I have
> ever stumbled upon such case). I would of course like to hear different
> experiences on the matter if there are any.

Consider interleaving and running jobs in parallel. And current prices
on SSDs.

I've two setups using SSD spools and 50GB file volumes on "commodity"
SATA drives; on one storage is a vchanger, on the other: a big zfs pool.
In both cases backup runs as fast as clients can push bits over the wire
(all running in parallel) and I don't need to care how slow despooling
to spinning rust might be.

With ZFS you'd want the SSD anyway for write caching (ZIL) so it's only
really a matter of buying slightly larger ones to hold the spool as well.
--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu


------------------------------------------------------------------------------
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 list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users

signature.asc (197 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pruning is taking too long; downside of force update status to recycle.

Josip Deanovic
On Friday 2016-12-09 14:55:49 Dimitri Maziuk wrote:

> On 12/09/2016 02:15 PM, Josip Deanovic wrote:
> > I doubt that there are many cases where data is coming at a rate that
> > would justify spooling in case of file storage (I don't think I have
> > ever stumbled upon such case). I would of course like to hear
> > different
> > experiences on the matter if there are any.
>
> Consider interleaving and running jobs in parallel. And current prices
> on SSDs.
>
> I've two setups using SSD spools and 50GB file volumes on "commodity"
> SATA drives; on one storage is a vchanger, on the other: a big zfs pool.
> In both cases backup runs as fast as clients can push bits over the
> wire (all running in parallel) and I don't need to care how slow
> despooling to spinning rust might be.
>
> With ZFS you'd want the SSD anyway for write caching (ZIL) so it's only
> really a matter of buying slightly larger ones to hold the spool as
> well.

Good point.
When did you start to use SSD drives for spooling in your setups?

I believe the SSD still suffer from faster wear effect when compared to
the classic rotational disks although they have improved on that regard
in last few years.

--
Josip Deanovic

------------------------------------------------------------------------------
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 list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
12
Loading...