(caution - this email is a long brain dump :)
> >
> > Any comments? It all sounds a bit hard at the moment...
>
> Yes it certainly need some thought. I am going to think about this a
bit
> more. In the mean time, can you give me a bit more information on the
> details you see for what Bacula would have to do if a user were simply
to
> select what database to restore (and how they want the log files
handled)?
>
Exchange has one or more Storage Groups (Enterprise can have multiple,
Standard only has a limit of one[1]). Each Storage Group has one or more
Stores (Databases) in them. Each Storage Group also has a set of
Logfiles, to which any change to the Stores are written and can be
replayed in a restore scenario.
When Exchange is backed up, I represent it in a pseudo filesystem like
this:
Storage Group 1
Store 1
EDB file (everything except the email attachments)
STM file (email attachments)
DatabaseInfo file (holds some stuff necessary to complete the restore)
Logfile 000
Logfile 001
etc
[1] To allow individual mailbox restore, Exchange allows the creation of
a special "Recovery Storage Group", even on Standard so you can
temporarily exceed the limit of one Storage Group. When you create that
"Recovery Storage Group", any attempt to restore the original Storage
Group is redirected (transparently to the plugin) to the Recovery
Storage Group. You can then copy the data from the mailbox back to where
it belongs.
Because of the way the plugin works, to do a restore every single item
above needs to be selected, including the Storage Group directory
itself, as restoring it triggers certain activity in the plugin. I'd
have to check but I think the parent directory of the Storage Group has
to be selected also for the same reason. So restoring a single Store
(there can be multiple in a storage group remember) means marking the
Storage Group (or the parent directory), and then unmarking each of the
Store's that you don't want to have restored. My test script for doing
restores does something like:
mark @EXCHANGE
cd @EXCHANGE
cd "Microsoft Information Store"
cd "First Storage Group"
unmark "Public Folder Store"
This selects everything in @EXCHANGE and then unselects the Public
Folder Store, which in my case leaves selected everything I need to
restore the "Mailbox Store".
The idea that's been floating around in my head for the last few days is
to invent some more virtual files that when marked for restore, also
mark whatever files are tagged as being related. To give an example, my
directory tree currently looks like (yes, the back slashes in the .edb,
.stm, and .log files form part of the filename):
@EXCHANGE/
Microsoft Information Store/
First Storage Group/
E:\Exchsrvr\MDBDATA\E000885B.log
E:\Exchsrvr\MDBDATA\E000885C.log
Mailbox Store (MYSERVER)/
D:\Exchsrvr\MDBDATA\priv1.edb
D:\Exchsrvr\MDBDATA\priv1.stm
DatabaseBackupInfo
Public Folder Store (MYSERVER)/
D:\Exchsrvr\MDBDATA\pub1.edb
D:\Exchsrvr\MDBDATA\pub1.stm
DatabaseBackupInfo
And so the virtual files (tags in square brackets, not visible to the
users, and not actually stored as part of the filename) would live under
@EXCHANGE and look like:
@EXCHANGE/
First Storage Group - Mailbox Store (MYSERVER) [select=1]
First Storage Group - Public Folder Store (MYSERVER) [select=2]
Microsoft Information Store/ [1,2]
First Storage Group/ [1,2]
E:\Exchsrvr\MDBDATA\E000885B.log [1,2]
E:\Exchsrvr\MDBDATA\E000885C.log [1,2]
Mailbox Store (MYSERVER)/ [1]
D:\Exchsrvr\MDBDATA\priv1.edb [1]
D:\Exchsrvr\MDBDATA\priv1.stm [1]
DatabaseBackupInfo [1]
Public Folder Store (MYSERVER)/ [2]
D:\Exchsrvr\MDBDATA\pub1.edb [2]
D:\Exchsrvr\MDBDATA\pub1.stm [2]
DatabaseBackupInfo [2]
So if the user were to mark '@EXCHANGE/First Storage Group - Mailbox
Store (MYSERVER)', everything which included '1' in its set of tags
would be selected. Alternatively, the new virtual files could define
multiple tags and all the other files just a single tag. The first way
is better though I think. The tags wouldn't have to be numeric.
I think the tags would live in the attributes field, so shouldn't
require any database changes, they are just decoded by the restore
selection code. A rule would exist that says only look deeper into the
tree for related files, so that you don't need to search the whole
restore set.
I have barely ever peeked at the restore selection code, so I don't know
at this stage if it's feasible at all... what does everyone else think?
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-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel
