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 <mar...@lispworks.com> 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 < > > 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 > > 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: <uwe.schuerk...@nionex.net> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ 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 Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
