Hello James,
Thanks for the write up. Can you confirm? if I understand this correctly,
the complication comes about because the log files must be restored
at the same time as any of the Stores that are under the selected
Storage Group, and normally only one Store should be selected.
Getting this resolved and working is for me a very important project, so Eric
and I have been discussing various ways to group files. Grouping them is
really not much of a problem, but it looks like in addition to grouping
certain files, you need to include another group (log files) that may be
required to restore a number of different groups (Stores within a Storage
Group).
What seems to me almost impossible to do automatically at least with the
current code, is to recognize that there are two separate Stores under the
Storage Group, and only one or the other must be selected. We might be able
to do this, by defining a particular folder to always be included when its
parent is included, and other folders to be sort of like radio buttons --
only one of the series can be selected at a time.
Something like the following:
@EXCHANGE/
+Microsoft Information Store/
-First Storage Group/
+Log 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
-Second Storage Group/
...
Where the leading - means only one directory at that given level is chosen,
and the + indicates that the directory is always chosen.
What do you think?
Kern
On Thursday 22 October 2009 11:38:58 James Harper wrote:
> (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
