> 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-de...@lists.sourceforge.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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
