> bacula with postgres 3.0.2
> Postgre 8.2.13
> Director & Storage Daemon on OpenSuse 10.3
> Exchange on SBS 2003 with bacula-win FD 3.0.2 & exchange plugin
>
> I am successfully backing up using the plugin but I may have
> misunderstood the backup methods and their actions on the transaction
> logs. If I am using an incremental backup of the Exchange Mail Store,
I
> expected the transaction logs to be truncated from what I read of a
> previous thread
>
http://www.mail-archive.com/bacula-devel AT lists.sourceforge DOT net/msg03029.
html
I had to change that behaviour - see below.
>
> However an incremental backup does not truncate the logs, according to
> the job log.
>
> 19-Oct 21:05 tal.airspeed.ie-dir JobId 406: Start Backup JobId 406,
> Job=EinBackup.2009-10-19_21.05.00_15
> 19-Oct 21:05 tal.airspeed.ie-dir JobId 406: Using Device "FileStorage"
> 19-Oct 21:05 tal.airspeed.ie-sd JobId 406: Volume "Incr-0005"
> .
> .
> 19-Oct 21:22 ein.airspeed.ie-fd JobId 406: Did NOT truncate
> database logs for Storage Group First Storage Group
> .
> .
> JobId: 406
> Job: EinBackup.2009-10-19_21.05.00_15
> Backup Level: Incremental, since=2009-10-16 21:05:03
>
>
>
> Perhaps this is not the final implemented behaviour of the plugin? I
> guess it does truncate on a Full backup, but still waiting for the
next
> monthly to occur. Does the Differential instead truncate or is there
an
> explicit parameter that one can pass into the plugin directive to
force
> a truncate?
>
Because of the nature of Exchange, if a Differential or Incremental
backup were to truncate the logs then you would be unable to perform
another Differential backup - the logs would be gone.
That said, it wouldn't be hard to add an option to say "truncate on
incremental backups". There is already a "no truncate on full" option.
The user would have to understand the implications of specifying that
option though, eg if you specify the hypothetical "trunconinc" option
then it is no longer possible to run a differential backup and get the
results you expect - the differential effectively becomes an incremental
and restoring would be really hard.
More importantly, best practice would suggest that you keep your logs
around. It isn't unheard of for the Exchange database to break - if you
have an entire set of logfiles on disk since the last full backup then
you simply restore the database and Exchange takes care of replaying the
logfiles for you. It may be that if you have (say) a Full backup of the
database, and incremental backups of logfiles 100-199, and logfiles
199-299 are still on disk (because they haven't been backed up yet) then
it might also "just work", but I've not tested that... I'll have a think
about it.
Based on what I said above, are you still interested in a 'truncate logs
on incremental backup' option? Are you in a position to be able to test
it? I could give you a 3.0.3 fd with the Exchange plugin for you to test
if you want (or as close to 3.0.3 as my tree is right now) - for the
testing I've been doing a 3.0.3 fd works file with a 3.0.1 dir and sd,
but I'd not recommend it for production use.
James
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
