"Timo Neuvonen" <timo-news AT tee-en DOT net> kirjoitti viestissä 
news:hfjoo9$ksn$1 AT ger.gmane DOT org...
>
> "Simon J Mudd" <sjmudd AT pobox DOT com> kirjoitti viestissä
> news:m3fx7mkdv3.fsf AT mad06.wl0 DOT org...
>> timo-news AT tee-en DOT net ("Timo Neuvonen") writes:
>>
>>> "Simon J Mudd" <sjmudd AT pobox DOT com> kirjoitti viestissä
>>
>> ...
>>
>>> > Yes, but that's what I'm trying to avoid. I realise that I MUST have
>>> > sufficient
>>> > space really for at least 2 full backups plus some extra for
>>> > incrementals
>>> > but I don't want to worry about the details. Therefore I want to
>>> > configure
>>>
>>> You said you don't want to worry about the details. However, one such
>>> very
>>> strong detail is the schedule you already have specified, it says to run
>>> a
>>> full backup once a month. Required retention time is closely related to
>>> this, and needs to be specified too.
>>
>> Again, I think you're missing the point. You are right, in a business
>> environment you do want to decide to do X full backups every certain
>> period of time, X incrementals etc. and then you need to do some
>> calculations to work out how much disk space you need for this. This
>> value of course changes and you may later need to add more storage or
>> tapes or whatever to accommodate these changes.
>>
>> Think of the normal HOME user who may have an interest in Bacula to
>> backup data. He has a "unix" PC with disks occupying say 100GB of
>> space. So he buys himself a 1TB external USB disk and wants to use
>> that for backups. If it's dedicated he'll want to use ALL the space
>> for backups and keep as much as he can. So he's likely to want to do
>> perhaps a single weekly or monthly backup followed by incrementals in
>> between. Exactly how many backups he keeps is relatively unimportant.
>>
>> And for this type of scenario bacula is tricky (from what I can see)
>> to setup. I've had multiple problems (due to misconfiguration) of bacula
>> not labelling new disk devices in the pool and also when the disk starts
>> to fill up of not removing the oldest backups.
>>
>> I'm not a backup "administrator" and have plenty of other distractions
>> which prevent me properly working out how to get bacula running properly.
>> That's why I suggested a recipe for the type of configuration I suggest
>> might be extremely useful.
>>
>>> Since now you haven't specified the volume retention, Bacula uses its
>>> internal default which is one year, 365 days. You have to specify a
>>> shorter
>>> volume retention time if you want to be able to recycle the volumes
>>> sooner.
>>
>> But I dont' want retention to depend on time, but disk usage.
>>
>
>
>
> Bacula can use all disk space you allow it to use, that is controlled with
> volume size and maximum number of volumes, that you had set to reasonable
> values in the configuration. The volume retention time is just a minimum
> time limit; if your disk space will allow it, the old data in un-recycled
> volumes will still be available there after much longer time (in theory,
> forever). I think this is what you wanted, so I can't see any actual 
> problem
> there. But if you absolutely don't want to change the default volume
> retention time to something that would fit to your application, there 
> isn't

> much else to do, I think. Explicitly specifying the volume retention time 
> is
> the only way to make Bacula recycle the volumes in less than a year, since
> 365 days is Bacula's internal default.
>


An update / a correction to the statement above: setting
Purge Oldest Volume = yes
in the pool specification will override any retention period to recycle a 
volume when more space is needed. In general, it is a very dangerous option, 
but I think it is exacly what you are looking for.

Still, I would vote for relying on the decently set volume retention, and 
forgetting the above option.


>
>
>> ...
>>
>>> Btw, you can use "list media" command to see the status of the existing
>>> volumes.
>>
>> so while you can define how many volumes to have and their sizes you 
>> can't
>> get bacula to purge based on these values?
>>
>> ...
>>
>>> > the "pool" to auto purge if it fills up. New full or incremental
>>> > backups
>>> > will create new volumes as needed, and the older ones will get purged.
>>>
>>> Actually, Bacula will recycle the existing volumes, that is, discard the
>>> old
>>> data in the volume, and use the same "recycled" volume again. So the
>>> volume
>>> name won't change (unless this is possible due to some very new Bacula
>>> feature).
>>
>> That's fine. In the end I don't care howe the volumes are labelled, or if
>> new ones are created or existing ones are reused.
>>
>>> Within reasonable limits (reasonable amount of disk space available),
>>> this
>>> should be possible with Bacula.
>>
>> So it sounds part of my problem has been to misunderstand the precise
>> terms
>> used in Bacula. It sounds like I don't want to purge the disk volumes, 
>> but
>> to recycle them. So how do I configure this:
>>
>> - A fixed number of disk volumes of a predetermined size which will
>> be "recycled" when no more space is left? Ideally the recycling in this
>> simple
>> case would be based on a FIFO type principal.
>>
>
>
> If you don't want to have _any_ minimum time limit for volume retention,
> just set it to one second, which propably is the shortest value you can
> specify.
>
> In theory, this can result in a situation that if your one full backup 
> would
> consume more space than is designated for backup use, and recycling of the
> first volume used for that backup would then happen before that backup is
> finished. But if you prefer this, instead of seeing an error message in 
> this
> obvious case of malfunctioning, go for it.
>
> Seriously, a more reasonable value might be one hour, or one day. But if 
> you
> want, you can (at least you should, I guess no one has ever tried it) use
> value of as short as one second.
>
>
>
>> Simon
>>
>> ------------------------------------------------------------------------------
>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>> a free event focused on virtualization and cloud computing.
>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>> http://p.sf.net/sfu/redhat-sfdev2dev
>> _______________________________________________
>> Bacula-users mailing list
>> Bacula-users AT lists.sourceforge DOT net
>> https://lists.sourceforge.net/lists/listinfo/bacula-users
>>
>
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Bacula-users mailing list
> Bacula-users AT lists.sourceforge DOT net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
> 



------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users