backing up information store

[John]

I am running 2000 server and exchange 2000, both updated. I am using veritas
9.0 for exchange. Within the selections area I am given the option of backing
up individual mailboxes, or the entire mailbox store (within the info store),
or both. Can I just backup individual mailboxes? I don't need to backup
everybody's email, and when I select the mailbox store to be backed up, it is
huge amount of data and doesn't fit on the tape. What is the purpose of
backing up both individual mailboxes and the mailbox store? thanks

[rpspiker]

Backing up the entire mailbox store allows you to restore it in the event of
a hard drive failure. Backing up the individual mailboxes allows you to
restore a single piece of email for an individual mailbox, without having to
restore the entire store. When you restore the entire mailbox store you lose
all items that came in after the mailbox store was backuped. By using the
individual mailbox you can restore single or multiple items without
overwriting the entire mailbox store.
--
rpspiker
There is no right way to do a wrong thing.<><

[Simon Walsh]

"When you restore the entire mailbox store you lose
all items that came in after the mailbox store was backuped"

Not if you have your transaction logs available.
Exchange will replay through all the t-logs up to point-of-failure

/Simon
"rpspiker" <rpsp...@discussions.microsoft.com> wrote in message
news:00A3527C-2D82-4172...@microsoft.com...

[J.H]

Unless that t-logs are not corrupted and continuous up to the previous
incremental backup log.

It is not recommended to Brick Level Backup (individual mailbox backup). 2
vendor of
popular Exchange agent backup are Veritas and CA BrightStor ArcServe, both
of their
application run brick level backup, but the rate of sucessful is low, I
tested myself, 4 failed
and 6 successful times. It is not reliable backup method at all.

It is however recommended for information store level backup (once per week
Friday eve)
and transaction log backup daily (M-T).

When needed to restore, restoring last full backup set first (do not commit
after restore),
then restoring incremental backup set of previous incremental transaction
log backup,
commit at the last incremental backup t-logs (apply existing logs if you
think that logs are not
corrupted and continuous to point of previous incremental backup of
transaction log).

Hope it helps,
JH

"Simon Walsh" <simon...@kerfi.com> wrote in message
news:%23pbsQul...@TK2MSFTNGP10.phx.gbl...