I have got a client who reported that NTBackup fails with HREseRead error message and -613 error message in the checksum of the priv1.stm (I suspect an initial corruption of the PRIV1 database). They run Exchange 2003 Enterprise Edition and their private DB size is 44 GB. Apart from this suspect corruption, the server is okay but it's choking: they are running out of space because the log files are not being flushed and now they have less than 1 GB free.According to KB article 318429, I could create a new storage group and move users' mailboxes there. My problem is that the server is running very low on disk space! If I move users into a new storage group, the first DB size won't immediately decrease and I have less than 1 GB free.So, what is the best thing to do?Thanks in advance.

That is a tough situation. The inevitable answer is going to be get more disk space. With only 1GB free on the disk they are going to need to spring for more disk at soon anyway. Since they are using Enterprise edition you might also want to split the stores into 25GB or less sizes so that you only need to keep that much extra space (plus a little more) on the disk in case this happens to a single store again.

They're going to buy a couple of extra SCSI disks soon, but now I need to build a brand-new database (storage group) and move all the mailboxes there in order to solve the corruption problem.I temporarily enabled circular logging and gained 5 GB, not bad... anyway, I'm going to add an extra IDE hard drive, create the second storage group there, move users' mailboxes, take a full backup of this new storage group, then wipe out the original database and move back the new storage group to the default location on the existing SCSI mirror.Does all this make sense?

That sounds like a valid plan. Make sure to use a known good or even brand new IDE/SATA drive. You don't want it to fail in the middle of your moves and lose everything. :| It also sounds like you have your logs and database on the same logical drive. This isn't recommended for various reasons, one of which is that if you lose or fill your database drive you also lose your logs, leaving you with a restore point of the last full backup.