David Breese
asked on
Exchange 2007 Server out of storage, need to migrate mailbox database
We have a bit of a situation with our Exchange storage, looking for recommendations. We are very close to running out of space on a disk partition on our Exchange 2007 server. This partition currently holds a critical mailbox database.
This server is our only Exchange server. (It also connects to Exchange Online Protection, for spam filtering only.)
In the medium term, regardless, our goal is to migrate all our Exchange data and services to a new Exchange server, and eventually to Exchange Online.
But our challenge right now is in the short term, we need to get this partition enough free space to allow our existing Exchange and backups to keep operating reliably. Probably, that means getting it up to something like 10% free space or more -- currently it's only got 6 GB free, which is around 2% of its capacity.
The partition is a 275 GB partition at the start of a logical drive (old HP ProLiant with P410i RAID). It has 3 other partitions after it, so there's no easy way to expand it.
There is no significant space available on any of the other disk partitions on the Exchange server at this point, either -- the server's internal storage is at capacity.
(By contrast, we have lots of available storage space on our vSphere cluster in the same (gigabit) LAN.)
The bulk of the data on the partition consists of one large mailbox database, which Windows says is about 225 GB -- plus its transaction logs which are a few GB.
Also living on this partition currently: 1 small public folder database and logs, and various Exchange internal program files -- all totaling around 6 GB. We recently migrated the Message Queue Database and its logs *off* of this partition, so those no longer live on this partition.
The Exchange server only allows 5 databases, and we've already got 5, so we can't create a new one as I understand.
Through our initial research, we've brainstormed various options, like running an "offline defrag" on the database, and/or trying to bring storage to the Exchange server across the network (e.g. via SMB). We're not very familiar with any of these processes using Exchange, though, so we're still trying to judge and assess them.
What kind of approaches might be recommendable in this situation? Any ideas?
This server is our only Exchange server. (It also connects to Exchange Online Protection, for spam filtering only.)
In the medium term, regardless, our goal is to migrate all our Exchange data and services to a new Exchange server, and eventually to Exchange Online.
But our challenge right now is in the short term, we need to get this partition enough free space to allow our existing Exchange and backups to keep operating reliably. Probably, that means getting it up to something like 10% free space or more -- currently it's only got 6 GB free, which is around 2% of its capacity.
The partition is a 275 GB partition at the start of a logical drive (old HP ProLiant with P410i RAID). It has 3 other partitions after it, so there's no easy way to expand it.
There is no significant space available on any of the other disk partitions on the Exchange server at this point, either -- the server's internal storage is at capacity.
(By contrast, we have lots of available storage space on our vSphere cluster in the same (gigabit) LAN.)
The bulk of the data on the partition consists of one large mailbox database, which Windows says is about 225 GB -- plus its transaction logs which are a few GB.
Also living on this partition currently: 1 small public folder database and logs, and various Exchange internal program files -- all totaling around 6 GB. We recently migrated the Message Queue Database and its logs *off* of this partition, so those no longer live on this partition.
The Exchange server only allows 5 databases, and we've already got 5, so we can't create a new one as I understand.
Through our initial research, we've brainstormed various options, like running an "offline defrag" on the database, and/or trying to bring storage to the Exchange server across the network (e.g. via SMB). We're not very familiar with any of these processes using Exchange, though, so we're still trying to judge and assess them.
What kind of approaches might be recommendable in this situation? Any ideas?
The main question here is where are you going to get the extra storage space from? Are you able to add an additional disk to the server at all? If not, then you can create a new volume from your SAN (please read the best practices for storage (https://www.itprotoday.com/storage/exchange-server-2007-storage-das-vs-san-vs-iscsi)
Once you add the storage then you can move the database and log paths to the new volume.
Another option would be to move the logs for that database to another volume OR move the Public folder database and its logs to another volume.
Once you add the storage then you can move the database and log paths to the new volume.
Another option would be to move the logs for that database to another volume OR move the Public folder database and its logs to another volume.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
So when you say "In the medium term, regardless, our goal is to migrate all our Exchange data and services to a new Exchange server and eventually to Exchange Online." Are you referring to have a hybrid environment?"
NOTE: If you want to clear out some space for your mailbox then, here is something you can do, delete the logs that are located on the exchange folder named mailbox. You might have tons of those logs files (in case you did not know) that need to be removed for space management and hygiene. You don't need them, there is a purpose for those logs but I don't want move ahead of myself on that.
How many mailboxes do you have? - If you have only one mailbox database then I can recommend you install another drive on your server at list 1TB or so, give a letter to it and move the database. Base upon your capacity your mailbox is not that big and the copy shouldn't take too long copying the data.