On 2007.10.05. 17:30, Foo Bar wrote:
...
>>> What I would like to do is to keep for example 2 full backups, and as
>>> soon as the third is made the oldest one should be deleted from disk
>>> (not just the job/volume entries in the catalog).
>> it seems that you might be interested in feature request #5 :
>> http://www.bacula.org/?page=projects
> 
> 'Remove Volume After' is of no use since I want to keep the volume, just
> control its contents.

actually, if you would limit each volume to a single job, it would 
nicely achieve the goal, i think

> Whether 'Volume Data Retention' is useful depends on how it is implemented.
> If it's tied to a time period then it's again not finegrained enough
> (depending on the timing of individual (manual) jobs it could delete the
> previous full backup before the next one is made, or keep superfluous files
> around too long). If it's tied to an action like an explicit command
> ("purge all files before previous full backup" or similar), great.

i think the only way to implement is the second way. everything else 
would be useless :)

> I guess I could work around this by using multiple volumes and 'Maximum
> Volume Files' or 'Maximum Volume Duration', but these have the same
> drawbacks as 'Volume Data Retention': if I make extra (incremental) backups
> in the meantime or am late with the full backup the next volume will have
> useless incremental stuff on it, thus wasting space, and involving extra
> work finding a complete restore.

well, ideally, for on-disk backups, there would be a storage that is 
finegrained enough (to allow easy syncing changes only to a remote 
system) and that can really use the benefits of the disk based solution.

base jobs would be one step further to such a situation.

in the end, a system/format that would back up only files that change 
and operate on a file level at the server end would be ideal - and do 
that with putting as little load on the server as possible (base + 
consolidation jobs would soon become quite resource intensive).

such a system should be able to easily and without much overhead update 
and remove files that are backed up, and provide a control over the 
backups at file level - i think, in tivoli there were options to keep x 
amount of last versions for a file that still exists and y copies of a 
file that has been deleted.
-- 
  Rich

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to