On 22 November 2010 18:55, Blake Dunlap wrote:
> On Mon, Nov 22, 2010 at 11:02, Dermot Beirne wrote:
>>
>> That particular feature would be good news for me at least!
>> I definitely would really like to see the ability to automatically
>> purge volumes also, and leave it to the user to decide if
On Mon, Nov 22, 2010 at 11:02, Dermot Beirne wrote:
> That particular feature would be good news for me at least!
> I definitely would really like to see the ability to automatically
> purge volumes also, and leave it to the user to decide if they want to
> preserve the data as long as possible.
That particular feature would be good news for me at least!
I definitely would really like to see the ability to automatically
purge volumes also, and leave it to the user to decide if they want to
preserve the data as long as possible.
The patch you posted a link to is for version 3.0.1
Do you kno
If you say so, I guess it will be nice to have one less patch to manually
merge.
Personally, I'd rather see them add VirtualDiffs, VirtualFullCopys, fix the
Pool based expiration (really really really want that), have the option to
automatically purge expired volumes instead of only keeping data a
Hello Blake,
>> Basicly what I see here is that you really want a migration, not a copy
>> job. This coupled with the patch from
>> bacula-de...@lists.sourceforge.net/msg04724.html"
>> target="_new">http://www.mail-archive.com/bacula-de...@lists.sourceforge.net/msg04724.html>
>> should do what y
> On Thu, 18 Nov 2010 00:41:06 +, Dermot Beirne said:
>
> Hi Martin,
> I read that, and understand it doesn't run automatically, but must be
> called from a runscript, or whatever.
> However, my understanding is that the volumes need to be marked as
> purged before this feature will trunca
Hi,
You make a good point. I stuck with the 5Gb as keeping small volumes
aids restore times and reduces possibility of corruption affecting a
large part of the backups in the event of a disk fault, as indicated
in the documentation, which, as you say, may not be appropriate for my
setup any more,
On 11/18/10 05:56, Dermot Beirne wrote:
> Hi,
> There is a big difference in the size of individual jobs, they range
> from maybe 30Gb to 300Gb. No individual job would be multi terabyte.
> The number of clients combined would be over 1 TB for a given day,
> rather than an individual job. I used
Hello Blake,
Le jeudi 18 novembre 2010 00:30:16, Blake Dunlap a écrit :
> Basicly what I see here is that you really want a migration, not a copy
> job. This coupled with the patch from
> http://www.mail-archive.com/bacula-de...@lists.sourceforge.net/msg04724.html
> should do what you want if you
Hi,
There is a big difference in the size of individual jobs, they range
from maybe 30Gb to 300Gb. No individual job would be multi terabyte.
The number of clients combined would be over 1 TB for a given day,
rather than an individual job. I used 5Gb as it was a suggested size
in the bacula docum
On 11/17/10 19:16, Dermot Beirne wrote:
> Hi Phil,
> I have set a size limit of 5Gb on each volume. My daily incrementals
> are using over 300 such volumes at the moment, so 200 will be nowhere
> near enough to do a full backup of all the clients at year end, so
> I'll be increasing that before th
Hi Martin,
I read that, and understand it doesn't run automatically, but must be
called from a runscript, or whatever.
However, my understanding is that the volumes need to be marked as
purged before this feature will truncate them?
It does not purge them, but truncates any which have a status of
p
Thanks Blake,
I am thinking migration is the way to go also. I'll look into your
patch tomorrow.
Thank you.
Dermot.
On 17 November 2010 23:30, Blake Dunlap wrote:
> Basicly what I see here is that you really want a migration, not a copy job.
> This coupled with the patch from
> http://www.mai
Hi Phil,
I have set a size limit of 5Gb on each volume. My daily incrementals
are using over 300 such volumes at the moment, so 200 will be nowhere
near enough to do a full backup of all the clients at year end, so
I'll be increasing that before then. My problem is I don't have
enough disk space
Basicly what I see here is that you really want a migration, not a copy job.
This coupled with the patch from
http://www.mail-archive.com/bacula-de...@lists.sourceforge.net/msg04724.htmlshould
do what you want if you set the new option in the migration job (from
the patch, believe it is "Migrate Pu
On 11/17/10 05:48, Dermot Beirne wrote:
> Hi Phil,
>
> Here is the pool definitions I'm using.
>
> Is there some way I can get the entire "disk" pool volumes purged when
> they expire, so they are all truncated and all that space is released.
> I don't need them once they are copied to tape. Wo
Hi Blake,
That sounds great, exactly what I've been looking for by the sound of it.
If you can provide this and some details of how to get it working, I
for one would be very interested and grateful.
Incidently, how would using such a patch affect upgrading Bacula in
future, etc. I presume you ar
If you guys would like, I can attach the patch we apply to make migrations
purge the jobs themselves as well and thus cause volumes to properly
autoprune.
We also run a perl script to prune/purge any expired volumes every few
hours.
-Blake
On Wed, Nov 17, 2010 at 05:58, Graham Keeling wrote:
On Wed, Nov 17, 2010 at 11:32:44AM +, Dermot Beirne wrote:
> Hi Graham,
> I think this is a key feature, and am surprised it's not easily
> possible. The user should have the choice. I saw the blog entries
> you refer to, and that bug appears to have been fixed, but I don't see
> what use it
> On Wed, 17 Nov 2010 11:32:44 +, Dermot Beirne said:
>
> Hi Graham,
> I think this is a key feature, and am surprised it's not easily
> possible. The user should have the choice. I saw the blog entries
> you refer to, and that bug appears to have been fixed, but I don't see
> what use i
Hi Graham,
I think this is a key feature, and am surprised it's not easily
possible. The user should have the choice. I saw the blog entries
you refer to, and that bug appears to have been fixed, but I don't see
what use it is in the current system. If it's not possible to get
bacula to purge a
On Wed, Nov 17, 2010 at 10:48:36AM +, Dermot Beirne wrote:
> Hi Phil,
>
> Here is the pool definitions I'm using.
>
> Is there some way I can get the entire "disk" pool volumes purged when
> they expire, so they are all truncated and all that space is released.
I don't think that you're goin
Hi Phil,
Here is the pool definitions I'm using.
Is there some way I can get the entire "disk" pool volumes purged when
they expire, so they are all truncated and all that space is released.
I don't need them once they are copied to tape. Would a migrate job
instead of a copy job work better in
On 11/16/10 15:40, Dermot Beirne wrote:
> Hi
> I have just upgraded to 5.0.3 to take advantage of the actiononpurge
> truncate feature.
> I use disk to disk to tape backup, and need to recover the disk space
> asap after the copy job finishes.
> Problem is that bacula will not purge a volume until
Hi
I have just upgraded to 5.0.3 to take advantage of the actiononpurge
truncate feature.
I use disk to disk to tape backup, and need to recover the disk space
asap after the copy job finishes.
Problem is that bacula will not purge a volume until it needs it, even
if the files,jobs and volume reten
25 matches
Mail list logo
