On Tue, Sep 21, 2010 at 08:19:21AM +1000, James Harper wrote:
> > Hello,
> > 
> > I am testing backups of an Exchange 2003 server, with the plugin. I
> have a
> > schedule of incrementals with occasional virtualfulls.
> > 
> > The idea being that, after the first real full, doing a full backup is
> no
> > longer required (unless I restore the whole Exchange database, because
> > Exchange then demands a full backup).
> 
> Or if you apply a microsoft update / hotfix. That's caught me out a few
> times in Backup Exec which crashes the exchange services when this
> happens.
> 
> > But, I have realised that the Exchange logs are never 'truncated'
> because
> > there is never a real full backup.
> > Looking at the plugin code and the documentation, the logs get
> 'truncated' on
> > a
> > real full unless you give an option to the plugin for it not to
> happen.
> 
> And a differential I think.
> 
> > 
> > As I understand it, this means that the logs will just build up and up
> on the
> > Exchange server.
> > 
> > Is there a way of getting the Exchange logs to 'truncate' when doing a
> > virtualfull?
> > Or does somebody have another suggestion?
> > 
> 
> If you know a bit of C, you could do the following:
> 
> Add a "alwaystrunc_option" member just after notrunconfull_option to
> exchange_fd_context_t in exchange-fd.h
> 
> Init it to false in newPlugin
> 
> Add something like:
> if (context->alwaystrunc_option) {
>    context->truncate_logs = true;
> }
> To exchange-fd.c after switch(context->job_level) in exchange-fd.c after
> case bEventStartBackupJob: to override the context->truncate_logs flag
> despite whatever has been set prior.
> 
> Add something like:
> else if (stricmp(option, "alwaystrunc") == 0){
>    context->alwaystrunc_option = true;
> }
> In bEventBackupCommand for the option parsing.
> 
> Once you do that, you should be able to append :alwaystrunc to the
> backup command to tell it to always truncate the logs.
> 
> The reason for this complexity is that Exchange maintains its own
> 'backup state'. It knows when the last full backup was done and
> determines what needs to be backed up itself, while Bacula expects to
> set those parameters itself too (via the 'since' parameter). By keeping
> the logs around on incremental we can still do a differential too
> because the logs aren't thrown away.
> 
> The alwaystrunc options should probably be split out into 'always trunc
> on incremental' and 'always trunc on differential' flags for maximum
> flexibility but the above should be a good starting point.
> 
> If the above suggestions are not something you feel able to do I might
> be able to put a patch together, but not this week.

OK, that sounds easy enough.

Attached is my patch to bacula-5.0.3 (completely untested at the moment).

I've made two new options:
truncondiff
trunconincr
I will report on whether it works in a while.


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users