views:

394

answers:

2

It currently is 700MB but it's conceivable that it'll grow beyond the 1GB. Normally I just copy this file to another location (for the curious, it's the database of a Zope instance, a ZODB file).

This file changes little from day to day, but I understand Bacula can't do inside-the-file subdivision for incremental backups. Anyway, it doesn't matter. What I want to do is a full backup daily and keep two of them and a full backup weekly and also keep two of them. So at any given time I can get yesterday, the day before yesterday, a week ago and two weeks ago. Would you think that's a good idea?

I suppose I should make two schedules, daily and weekly. But which numbers should I have on the volumes and the pools to achieve this? Two volumes of 1.5GB? Any hints or guidance is welcome, I'm not a sysadmin and my experience with Bacula is very limited.

+1  A: 

In my experience with bacula and backup to disk, it is best to keep one volume per backup job. That way there is no dead space in the files as jobs expire. Bacula can reuse the whole volume and it cuts down on disk utilization. Use the "Set Maximum Volume Jobs = 1" directive in the pool resource.

I would set up two pools, a daily and weekly. Set the volume retention to two days in the daily and two weeks in the weekly. Schedule the daily on say, mon-sat, and the weekly on sunday.

Georg Zimmer
If you only have one volume, when it gets full and its time to re-use it, wouldn't it purge it and for some time you wouldn't have any backups at all?
J. Pablo Fernández
no, sorry onve volume per job. so it never gets full. Every job gets a new volume. That way, when the volume is older than the retention period, it can just reuse it. If you allow multiple jobs per volume, then you end up with expired backups and wasted space within your volumes.
Georg Zimmer
+1  A: 

Online backup of a large database file is risky business, as the file might change while you are reading it, rendering the backup inconsistent and possibly useless. I believe you should not be making backups of the ZODB file itself, but rather of diffs created daily by the repozo tool. This way, you also outsource the job of handling the inside-the-file subdivisions that you say Bacula is incapable of dealing with.