none
Exchange 2003 backup taking too long RRS feed

  • Question

  • After moving a mailbox from the private database to public folders, the the ntbackup job that backs up Exchange takes 20 hours instead of 8 hours.  The amount of data that was moved is about 8 gigabytes.  It increased the size of the public database from 3 gigabytes to 11 gigabytes.  The private database is about 350 gigabytes in size, but that has not changed much.  Any idea why it might be taking almost three times as long?

    • Edited by ChrisFidz Tuesday, February 19, 2013 9:07 PM
    Tuesday, February 19, 2013 8:19 PM

Answers

  • We performed an offline defrag of the database.  That reduced the size of the database but, unfortunately, did not reduce the backup time.  Next, we added the /fu switch to the ntbackup command line.  This reduced the backup time from more than 20 hours to about 5 hours.  We do not know why this works, however, or what caused the backup time to jump to 20 hours in the first place.
    • Marked as answer by ChrisFidz Friday, March 22, 2013 6:33 PM
    Friday, March 22, 2013 12:30 PM

All replies

  • When you move the actual mailbox, the physical size of the mbx DB does not reduce, & this is what is backed up. You will have to perform a offline defrag (outage for all users on that DB) or create a new mbx DB and move users to this new DB and then backup this DB.

    By moving mbx from the existing DB, you will only gain white space over time, the backups will remain the same.


    Sukh

    Wednesday, February 20, 2013 12:29 AM
  • I realize that the size of the database file does not reduce right away.  It should shrink after 7 days when the deleted data gets purged.  This does not really explain, however, why a change that's a small percentage in size compared to the overall amount of data caused the backup time to almost triple overnight.

    • Edited by ChrisFidz Wednesday, February 20, 2013 9:04 PM
    Wednesday, February 20, 2013 2:07 PM
  • Can you double check the backup report & make sure it's just the edb which is getting backed up.

    Post the backup report


    Sukh

    Wednesday, February 20, 2013 2:36 PM
  • Only Exchange and the system state are selected.  The system and Exchange database are on different volumes.  The backups have not been altered.  We have already checked and exclude anything that could be an obvious cause.
    Wednesday, February 20, 2013 3:14 PM
  • Can you compare the size of the data on each drive which is backed up to what was backed up?

    I.e, the files you see = the size of backup?

    I know you have mentioned this, but just want confirmation.

    ANd was the 20 hours just to backup or was them some "verify" too?

    What you have said doesn't make sense to me either, all you have done is move 8GB worth of data.


    Sukh


    • Edited by Sukh828 Wednesday, February 20, 2013 3:32 PM
    Wednesday, February 20, 2013 3:30 PM
  • The 20 hours is without a verify.
    Wednesday, February 20, 2013 8:59 PM
  • Does the backup job do both the mbx DB and PF DB or are they seperate jobs?

    If seperate jobs, which one has increased in time?


    Sukh

    Wednesday, February 20, 2013 9:30 PM
  • It's just one backup as shown in the backup log:

    Backup Status
    Operation: Backup
    Active backup destination: File
    Media name: "Fri Backup.bkf created 2/22/2013 at 10:00 PM"

    Volume shadow copy creation: Attempt 1.
    Backup of "EXCHANGE\Microsoft Information Store\First Storage Group"
    Backup set #1 on media #1
    Backup description: "Set created 1/15/2009 at 3:25 PM"
    Media name: "Fri Backup.bkf created 2/22/2013 at 10:00 PM"

    Backup Type: Normal

    Backup started on 2/22/2013 at 10:00 PM.
    Backup completed on 2/23/2013 at 7:15 PM.
    Directories: 4
    Files: 54
    Bytes: 356,554,289,216
    Time:  21 hours,  15 minutes, and  1 second

    Monday, February 25, 2013 3:49 PM
  • We performed an offline defrag of the database.  That reduced the size of the database but, unfortunately, did not reduce the backup time.  Next, we added the /fu switch to the ntbackup command line.  This reduced the backup time from more than 20 hours to about 5 hours.  We do not know why this works, however, or what caused the backup time to jump to 20 hours in the first place.
    • Marked as answer by ChrisFidz Friday, March 22, 2013 6:33 PM
    Friday, March 22, 2013 12:30 PM
  • I realize that the size of the database file does not reduce right away.  It should shrink after 7 days when the deleted data gets purged.  This does not really explain, however, why a change that's a small percentage in size compared to the overall amount of data caused the backup time to almost triple overnight.


    It will not.  As Sukh says, the size of the file on disk will remain the same. 

    Cheers,

    Rhoderick

    Microsoft Senior Exchange PFE

    Blog: http://blogs.technet.com/rmilne  Twitter:   LinkedIn:   Facebook:   XING:

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, March 22, 2013 5:54 PM
  • Possibly because you were close to the performance threshold in the first place.

    http://support.microsoft.com/kb/839272

    "The private database is about 350 gigabytes in size"

    That is too big for a 2003 database, you would be better served splitting that up into multiple smaller databases.  That gives you better checkpoint depth and also shortens time to restore/maintain particular databases.


    Cheers,

    Rhoderick

    Microsoft Senior Exchange PFE

    Blog: http://blogs.technet.com/rmilne  Twitter:   LinkedIn:   Facebook:   XING:

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, March 22, 2013 5:59 PM
  • Yes, we did an offline defrag once the deleted data had been purged after 7 days to shrink the size of the file on disk.
    Friday, March 22, 2013 6:28 PM
  • This is a good explanation for why the /fu parameter is helping.  Thank you.
    Friday, March 22, 2013 6:30 PM
  • Hello

    Below are the details of why it happens

    Switch: /FU
    Description: Enables a "file unbuffered" setting to bypass the cache manager. This change provides a number of benefits during the disk-to-disk backup process:
    • Sustainable throughput over time
    • Reduction in processor utilization: on average, peak utilization is reduced to 30 percent
    • Elimination of impacts to the system process during the backup job
    Note The /FU switch is available only in the revised version of Ntbackup.exe that is included with Windows Server Service Pack 1. You can also obtain this revised version by downloading it as a hotfix. To do this, click the following article number to view the article in the Microsoft Knowledge Base:
    System performance is negatively affected when Ntbackup.exe writes to a destination .bkf file

    Thanks Prem P Rana MCSA Messaging 2003 MCSE 2003 Server MCTS MCITP Exchange 2007, 2010 Gurgaon, India http://blogs.msexchange-experts.com

    Monday, March 25, 2013 1:13 PM