ADSM-L

Re: TDP for exchange vs. Veritas hot backups

2001-12-22 12:07:39
Subject: Re: TDP for exchange vs. Veritas hot backups
From: "Seay, Paul" <seay_pd AT NAPTHEON DOT COM>
Date: Sat, 22 Dec 2001 12:04:28 -0500
It is really not a versus.  These are two distinct Exchange backup and
recover functions.

I have not read the article yet but want to make sure that everyone knows
the deleted items folder does not related to the recover deleted items
folder.  There appears to be some confusion on what capabilities are in
Exchange.  Even if you empty your deleted items folder the items are still
in the "recover deleted items area" for whatever time period your Exchange
is setup for.  You can get to the recover deleted items area by viewing your
deleted items folder then the Tools pull down will have a "recover deleted
items" option.  In fact, when your mailbox is out of space and cannot figure
out why, it is probably that your recover deleted items folder area has a
lot of stuff in it.  You can delete items from it.

Now, as for using Veritas' or Commvault's capability to recover mail boxes
that is a business decision.  But, no matter what you still have to run
regular Exchange backups to be able to recover your Exchange stores as well
as the mailbox backup.  Yes, two backups.  When you have 5,000 mailboxes it
is simple, mailbox backup is so slow it is totally useless.  So, you start
to limit what mailboxes you need to backup to executives, less than 2
percent of the number or 100.

We went down the Veritas path of mailbox backup about 5 minutes and figured
out it is not feasible.  We have not investigated Commvault, but what ever
you do, mailbox backup/restore is not a replacement for TDP for Exchange or
other vendor's Exchange store backup/restore capabilities.  The main
reasons, it is not going to bring things back exactly the way they were
before.  Notably, a total new copy of the emails are created during the
restore.

The issue here is Microsoft will never provide an API for this that will
perform because it is simply a low yield no monetary value to them.  Let's
face it we have turned the mail system into a bunch of private data
repositories.  Everyone does it.  They have replaced their paper with
electronic for the most part.

Until Redmond thinks they can make some money at fixing the problem their
argument is mailbox restore is not needed.  Their software is never going to
have a problem where the customer needs to restore a mailbox and if they do,
they will use their "procedure" to recover it.  Remember, we finance all
their fixes.  They always make sure they create at least 10 nasty bugs that
will not be fixed until the next release which we will gladly pay for.

There was a question about Veritas install versus TSM install in this
document.  NetBackup is probably easier to get an initial install, but
tuning it is a daily nightmare.  TSM takes longer to install but once
installed it just works with about 5 rule of thumb settings in the
dsmserv.sys, dsm.sys, dsm.opt.

Having been deeply involved in both products, the answer to the questions is
simple.  Just look at the names of the products.  Netbackup (Veritas) and
Storage Manager (Tivoli).  I joke that it is NetBackup, no restore.
Actually, Netbackup just does not scale up for large environments without
spending lots of money on hardware based on what we have seen.  The main
reasons we are dissatisfied with Netbackup is support is lousy, it could not
scale in the NT world, and there is no deleted file policy to protect data
from being lost.  The bottom line, we had TSM about 7 years ago for NT and
UNIX on an OS/390 server, replaced with ArcServe, replaced with Netbackup,
and now back to TSM on an AIX server.  So far, I can clearly say the
architecture of TSM is vastly superior in the Storage Management arena and
backup and restore times are acceptably equivalent to Netbackup.  The real
kicker is the price tag of Netbackup is significantly more expensive when
configured correctly.

<Prev in Thread] Current Thread [Next in Thread>
  • Re: TDP for exchange vs. Veritas hot backups, Seay, Paul <=