Re: [Bacula-users] Exchange plugin with VirtualFulls ('truncating' logs)
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Exchange plugin with VirtualFulls ('truncating' logs)
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). 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. 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? Thanks. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Exchange plugin with VirtualFulls ('truncating' logs)
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.
James
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
