[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] Backing up MS Exchange
First thanks for agreeing to work on the Bacula Exchange Plugin.
For the list, I gave James a brief spec of what is needed and he has responded
On Tuesday 09 September 2008 08:04:14 James Harper wrote:
> > Basically, think we need several options starting from simple and then
> > possibly over time getting more complex.
> > 1. Simply do a full backup of the whole Exchange database
> That is pretty straightforward in terms of API calls.
> > 2. As an option be able to do brick level backup or at least brick
> > restore.
> I am lead to believe that Backup Exec can do a brick level (or at least
> mailbox level) restore from a full backup, so maybe there are API's to
> do that, or maybe just under Exchange 2007.
> Either way, IMHO a brick level backup is a completely different project
> to an Exchange Database backup. There is almost nothing in common with
> the two other than that they ultimately get data from the same Exchange
> database, but at the Windows API level they couldn't be more different.
> Make of that what you will in terms of your spec, I'll be in a better
> position to comment when I see it.
Yes, you are right, it is an entirely different beast. Some vendors do it and
it is often requested. It appears that it requires the use the MAPI
interface as is used by Outlook, and from what I read from Microsoft, it is
first very slow, and second subject to a considerable number of problems.
I suspect that the way to get brick level restore (mailbox or message level)
is to restore the whole database to another server then use ExMerge to pull
out the parts you want -- at least that is what it seems is generally
recommened by Microsoft and other users.
As a consequence, I think this requirement should be dropped from the initial
plugin implementation, and then perhaps later we (or someone) can consider
doing a MAPI interface plugin.
> > 3. If possible be able to implement differential and incremental
> Based on the work I've already done:
> . a 'full' Exchange backup involves backing up one or more databases in
> the Information Store, backing up the logs, and then truncating the logs
> afterwards (I put the option in to not truncate too I think via a dummy
> 'include' directive in the file set).
> . a 'differential' Exchange backup involves backing up the logs only but
> not truncating them each time
> . an 'incremental' Exchange backup involves backing up the logs only and
> then truncating them each time.
Yes, these are the options we need. It is a lot easier to restore an
incremental backup rather than the whole database. I am sure we can handle a
differential backup, but I am not quite sure how Bacula will treat the
incrementals, since from what I understand, you must restore all the Exchange
incrementals to have a valid restore, but then I am kind of ignorant on this.
> I'm not sure how much wiggle room we have in terms of controlling the
> truncating of the log files. When the backup is done, using the Exchange
> API's, you either truncate the logs or you don't. So if you do a full
> backup, then an incremental backup, you can no longer do a differential
> backup based on the last full backup. You're probably the best person to
> comment on how that will interact with any assumptions the existing
> Bacula code makes about such things.
I think we should give the user the option of truncating the logs or not.
> There is a similar problem with MSSQL although it handles the log files
> a little differently so the problems are slightly different.
> > > Eg development platform?
> > It can really be developed any way you want. The end result should be
> > code or C++ that hopefully can be cross-compiled on a Linux system as
> > currently do with the FD. We also cross-compile the Win32 Volume
> > Copy SDK, but
> > we cannot distribute the source. Ideally the final product could be
> > without any Microsoft software or at the worst with something like the
> > SDK. What really counts is to get get final result, which is a Bacula
> > plugin dll so if the above won't work, let's discuss the
> I'll review the plugin API you have developed again and let you know. C
> or C++ should be fine. Do you have a preference?
I prefer C++, just because it makes cleaner code (checks the source better),
but as long as you compile it with C++, you can write it in C if you prefer.
The interface between Bacula and the DLL is forced to C to avoid name
> I'm comfortable in
> either although probably more so in C recently (I've been developing
> Windows drivers for Xen).
C is fine. In the end I would like to compile it with C++. I don't expect
this will be any problem.
The only other item I can think of, that I think is automatic in the API you
are planning to use is to ensure that Calendar and Contact items are also
backed up, and that the plugin works for both Exchange 2003 and Exchange
> > Please let me know what you think about the above, then we can get
> > specific about the project specification.
> I'll try and look through your plugin API asap and get back to you.
I will attempt to document the API a bit over the weekend. In any case, you
can look at src/plugins/fd and within that directory, there is a plugin
named bpipe.c that does a backup and a restore. It could possibly be the
prototype for what you will do.
One other issue: I *though* I had implemented a Win32 dll loader, but I
noticed that the core loading code src/lib/plugins.c is turned off for Win32,
so I need to check further to see why I turned it off -- probably because the
code is untested, because I have indeed implemented the code needed to load
dlls on Win32. More research needed here on my part ...
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Bacula-devel mailing list
This mailing list archive is a service of Copilot Consulting.