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!
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 http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. >
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 http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. >
Hi Darren,
I have had customers running snapmanager and I have never seen anything like this. As far as I know Snapmananger uses the the Exchange backup API so nothing should be different, except where the backup is stored and how it is stored.
How many stores and how many storage groups does your customer have ? Have they been changing their exchange storage layout lately?
Victor
-----Opprinnelig melding----- Fra: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] På vegne av Darren Dunham Sendt: 10. november 2004 21:55 Til: toasters@mathworks.com Emne: Exchange growth after migration.
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!
I have had customers running snapmanager and I have never seen anything like this. As far as I know Snapmananger uses the the Exchange backup API so nothing should be different, except where the backup is stored and how it is stored.
It looks like this might be the issue. The snapshot API and the NTBackup do different things.
http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=53144 I missed seeing this originally.
I think these folks were just surprised that none of the folks that helped them set everything up suggested that this might be a problem.
Since the bug mentions 2000 explicitly, I'm hoping that this does not affect 2003. If so, they might be willing to do the upgrade sooner rather than later to avoid having to do periodic cleanup at this stage.
Thanks for all the suggestions!
-
Darren Dunham -
Paul Galjan -
Sto Rage© -
Victor Olsen