Paul,
Thanks for the detailed explanation.
Just out of curiosity, I was wondering about option 3 (using VSS on Win2003) and why it would work. Is this another instance of Microsoft using some undocumented API call?
Derek
-----Original Message----- From: Benn, Paul [mailto:paul.benn@netapp.com] Sent: Wednesday, November 10, 2004 8:12 PM To: Sto RageC ; Paul Galjan Cc: toasters@mathworks.com Subject: RE: Exchange growth after migration.
Hi Sto Rage (sorry, don't know your real name),
You are correct in that SME is "Exchange aware." This option is not available in Exchange 5.5, which might explain why you do not see it on your server. If this is what I think it is, it is likely to be what Paul Galjan writes of below. If so, this is a known issue and is documented in NetApp online bug 53144 and also on page 92 of the SnapManager for Exchange version 3.1 Installation and Administration Guide. Here is a direct link to the article for those of you who want to read about it and have access to NOW.
http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=53144
Basically, Exchange 2000 and Exchange Server 2003 have an option of "Do not permanently delete mailboxes and items until the store has been backed up." The option itself should be self explanatory. The issue is that in order for this feature to function, the entire database needs to be read during the backup process. This happens when you spool to tape or to a .BKF file, for example. SnapManager uses snapshot technology to perform the backup process so it does not read the entire database as part of the backup. This is simply a limitation of Exchange 2000 that is exposed when using snapshot technology to perform backups and is *not* limited to Network Appliance filers or to SnapManager for Exchange itself.
This Exchange option is *disabled* by default, which could also explain why you did not run into the unexplained growth.
There are three ways to get around this issue:
1) Disable the Exchange 2000 option of "Do not permanently delete mailboxes and items until the store has been backed up."
2) Run a copy-type backup in addition to the SnapManager backups using an Exchange aware backup application, such as NTBackup. This is what Paul Galjan suggested below. This can be done, say, once per week and could be spooled to a .BKF file versus a tape device. Some SnapManager customers create backup archives by creating a copy type backup anyway. Doing so would not only provide a backup archive but would also provide a work around to the above mentioned issue.
3) Move to Exchange Server 2003 on Windows Server 2003 to get the VSS technology. When running this combination of Exchange and Windows, VSS is used to create the snapshots. The issue does *not* apply to SME backups performed via VSS. I realize that this may not be an option for everyone but I am just calling it out as another way to solve the problem.
I hope this sheds some light on the issue. Please let us know if further clarification is needed.
Regards,
Paul Benn SnapManager Engineering Network Appliance
-----Original Message----- From: Sto Rage(c) [mailto:netbacker@gmail.com] Sent: Wednesday, November 10, 2004 5:06 PM To: Paul Galjan Cc: toasters@mathworks.com Subject: Re: Exchange growth after migration.
Are you sure of this? I thought when you schedule SnapManager for Exchange (SME) backups to create the snapshots, Exchange is aware of the full backup being done and it will truncate the transaction logs and also delete the items deleted as specified in the Limits tab. When you look at the database tab, it should show the time of the last full backup which would correspond to the last snapshot taken via SME. Am I wrong? We too recently migrated our exchange env to a netapp platform and haven't noticed any major database bloat (yet?). We do have the option "Donot delete .... until the store has been backed up" checked. Well, maybe our users don't delete any mails ;)
Darren, the question you should ask your Exch admin is ... are they using SME for scheduling the backups or someother means. Ask them to look at the database tab and see if it has a time recored for full backups. The time for incrementals would be none, since SME doesn't do an incremental backup. Hope this helps.
-G
On Wed, 10 Nov 2004 17:40:46 -0500, Paul Galjan galjan@gmail.com wrote:
Hi Darren,
Tech support is correct if you have some the checkbox
"Uncheck "Do not
permanently delete mailboxes and items until the store has
been backed
up"
The problems lies in the difference between the way
NTbackup and other
Exchange-aware backup programs and snapshot backup programs like SME work. When other backup programs do a backup, all blocks are read from the DB, and Exchange knows that items can be deleted "for real" after the blocks have been read. When SME (or any other snapshot-based program, for that matter), does a backup, the blocks are read by eseutil, but only after the backup is done, and
it's done
on the snapshot (not the active DB), so Exchange doesn't
know to clean
up deleted items.
This is an issue with any snapshot-based Exchange backup program. Right now, Microsoft doesn't have any special hooks into its backup API to allow this cleanup to be invoked after a snapshot. (I don't know if/when that's coming). The workaround right now is to either turn that option off in Exchange, or run occasional copy-only backup jobs with ntbackup or somesuch.
More information on how to turn this option off is here: http://www.msexchange.org/tutorials/MF022.html
--paul
On Wed, 10 Nov 2004 12:55:28 -0800 (PST), Darren Dunham
ddunham@taos.com wrote:
Danger, I'm not a windows person, so I'm a little over my
head on part
of this.
I've got a client that has just completed a migration of their Exchange 2000 servers onto a netapp iscsi lun with
snapmanager. So
far everything seems to be working great on the netapp side.
However, after running on the server for two weeks, their
private store
has jumped from about 120G to about 220G. Some of their
support is
suggesting that the standard Exchange backup process has
some cleanup
functions that run during the backup. Now that it doesn't run any longer with snapmanager in place, the cleanup is no
longer performed and
the DB grows out of control (unless you shut down and do
a defrag).
Does this sound familiar to anyone? I'm looking for confirmation, refutation, or hey, even solutions on this. I'm hoping there are similar environments out there. Specifically, a larger
database (such
that the nightly cleanup process can't tackle the entire store overnight).
Please don't ask me for anything that requires debugging.
I'm not the
windows guy. I'm just trying to find out if this growth
has occurred at
other sites. It's been escalated with both Netapp and
Microsoft, but no
word yet on if this is expected behavior.
Thanks!
Darren Dunham
ddunham@taos.com
Senior Technical Consultant TAOS
Got some Dr Pepper? San
Francisco, CA bay area
< This line left intentionally blank to confuse you. >