Bob Hetzel wrote:
> Arno Lehmann <al AT its-lehmann DOT de>  wrote:
>
>   
>> Carlo Maesen wrote:
>>     
>>>> I did read the bacula manual but, I have some questions about schedules.
>>>> I creat the following schedule:
>>>> Schedule {
>>>>   Name = aca-cycle
>>>>   Run = Level=Incremental Pool=aca mon-thu at 22:00
>>>>   Run = Level=Full Pool=aca 1st-4th sat at 22:00
>>>> }
>>>>
>>>> I backup one client according this schedule, but each different run has 
>>>> also a different file and job retention. (Incr = 4 weeks, Full = 1 year)
>>>> Do I have to create 2 different clients and jobs, one for the incemental 
>>>> backup and one for the full ?
>>>> Because the file and job retenion is defined in the client-directive.
>>>>         
>> If you actually need the job-specific retention times you are in 
>> trouble...
>>
>> An incremental can only be based on the latest full backup for the 
>> same job, and a job is defined by the unique combination of client and 
>> fileset.
>>
>> The better approach is to use distinct pools for full, differential, 
>> and incremental backups, where each pool has its own retention settings.
>>
>> When a job is purged from a pool volume, the accompanying file and job 
>> data is also removed.
>>
>> Typically, you'll keep the full backup longest, so in essence, the job 
>>   and file retentions apply to full backups only, if they are longer 
>> than the retention times of the partial backup pools retention times.
>>
>> This, typically, is exactly what is needed - complete control when 
>> restoring from recent backups, and less control but also less database 
>> use for the long-term storage.
>>
>> Arno
>>     
>
> If I could chime in here... different retention times for incrementals 
> and fulls sounds reasonable on it's face, but IMHO is likely to bite you 
> eventually... what you're doing with this technique is purging the data 
> that changes the most more often.  Sometimes that's helpful but it 
> sacrifices flexibility when a file changes a lot but you don't know when 
> somebody messed it up, or you don't discover that it was messed up until 
> after you've expired that differential/incremenatl.  Also, the space 
> required to keep all those incrementals is likely a lot less than the 
> space required to keep the fulls so you might as well keep both.
>   
What you describe can be a very valid point - but it's something you 
wouldn't want to address with a backup system in the first place. If you 
need access to every single change to a file, ever, you need a version 
control system, such as Subversion, CVS, or any number of commercial 
offerings. These products are designed to do exactly what you describe.

These systems are designed primarily for software projects, but there 
are similar products available for other kinds of documents, too.

So I think Arno is right - if you really do have to go back to a backup 
from 9 months ago, it really shouldn't matter whether it's from 9 months 
and two days or 8 months and 10 days ago. Worse comes to worse, you can 
always use two full backups to interpolate between the months.

That's why I don't keep incrementals longer than the most recent 
differential backup, and differentials no longer than the last full backup.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users