[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] Backing up MS Exchange

> > > 2. As an option be able to do brick level backup or at least brick
> > > level restore.
> >
> > I am lead to believe that Backup Exec can do a brick level (or at
> > mailbox level) restore from a full backup, so maybe there are API's
> > do that, or maybe just under Exchange 2007.
> >
> > Either way, IMHO a brick level backup is a completely different
> > to an Exchange Database backup. There is almost nothing in common
> > the two other than that they ultimately get data from the same
> > database, but at the Windows API level they couldn't be more
> > Make of that what you will in terms of your spec, I'll be in a
> > 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,
> is
> first very slow, and second subject to a considerable number of
> 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.

Under Exchange 2003 and above (*) you can create a special 'Recovery
Storage Group' which you can restore your database to, and then just
copy mailboxes from that to your normal database. Obviously you need
enough disk space free to hold a complete second copy of your mail store
in the Recovery Storage Group, but that is one way to do a mailbox or
item restore. I have tested this using my existing agent and it works

(*) Another question... I have only ever worked with Exchange 2003.
Exchange 2007 is out now and I believe the API is compatible. Is there
any requirement to support Exchange 2000, or 5.5?

> >
> > > 3. If possible be able to implement differential and incremental
> >
> > backups.
> >
> > Based on the work I've already done:
> >
> > . a 'full' Exchange backup involves backing up one or more databases
> > the Information Store, backing up the logs, and then truncating the
> > afterwards (I put the option in to not truncate too I think via a
> > 'include' directive in the file set).
> > . a 'differential' Exchange backup involves backing up the logs only
> > not truncating them each time
> > . an 'incremental' Exchange backup involves backing up the logs only
> > 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
> this.

Yes. The restore operation involves restoring the database and then
replaying the log files. The log files can be ones you have just
restored or ones already on disk. If you had a situation where you did a
backup 24 hours ago and then your database went corrupt (eg your raid
array blew up), you can restore the database and Exchange will
automatically replay the logs already on the system (assuming they
weren't on the array that blew up) and your restore will be effectively
as at the moment your system died. You need every single log file
between the last backup and now for this to work though. In many ways
it's a very nice system.

> > I'm not sure how much wiggle room we have in terms of controlling
> > truncating of the log files. When the backup is done, using the
> > API's, you either truncate the logs or you don't. So if you do a
> > backup, then an incremental backup, you can no longer do a
> > 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


> > 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)

C++ it will be then!

> The only other item I can think of, that I think is automatic in the
> you are planning to use is to ensure that Calendar and Contact items
> also backed up, and that the plugin works for both Exchange 2003 and
> Exchange 2007.

Correct. The API backs up complete Information Stores, which contain all
the mail items, calendar items, contact items, task items, journal
items, etc

One other thing, I noticed that the default VSS backup also backs up the
exchange databases, although not in a way that makes them nice to
restore and replay the logs. I think it would have to be manual but it
would be nice for the agent to be able to tell the file daemon not to do
the vss backup of the exchange databases...


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.