> ADSML (aka Kelly),
>
> >Nothing like seeing a IBMer blame Microsoft....
>
> I don't believe there was any intent to "blame" anyone...it was a simple
> statement of fact.
> The backup/recovery APIs for Exchange do not support that level of
granularity.
> Vendors who
> provide mailbox or folder level granularity must be using the Messaging
API
> (MAPI) which is not
> intended for backup  and recovery purposes.
>
> >Nope, the "dopeheads" that implemented it says one must
> >restore the whole thing.
>
> If you consider us dopeheads for choosing to stay within the Exchange
> backup/recovery architecture,
> I guess you are entitled to your opinion.  However, I believe we have made
the
> right choice given the
> various issues related to the use of MAPI for backup and recovery at a
more
> granular level. In addition
> to the performance and scalability issue, it is really important to
understand
> the impact of breaking the
> single instance store architecture in Exchange.   To better understand
this,
> consider the following example:
>
> When a mail message is sent to a distribution list of 20 people, that mail
item
> is stored in exchange only
> once and each of the 20 mailboxes has a pointer to the single instance of
the
> item.  When MAPI interfaces
> are used to extract the mail items for mailbox level backup, then the full
mail
> item is extracted repeatedly
> for each mailbox.  This means that the size of the backup data when stored
per
> mailbox could be much
> larger than the actual size of the IS.   Further, when restoring by
individual
> mailbox, the mail object will be
> stored multiple times so that the resulting IS will be larger than the
> original...and may even cause issues
> with being able to fit on available storage.
>
> This is probably the main reason why Microsoft recommends against use of
the
> MAPI for backup and
> recovery and also why they are providing alternate mechanisms to address
the
> issue of individual item
> recovery that do not compromise this architecture.
>
> Chris Zaremba
> TDP CLient (formerly ADSM Agent) Development
> internet  zaremba AT us.ibm DOT com