How long would a backup take?

  • I am not a dba. But we work with a 30GB database on sql 2000. The DBAs claim the backup takes 15 hours to backup!! Is that a true? Would it take that long? is there anyway to speed it up?

  • Depends on the hardware you have and whether you backup to local disks, to disks in another server across the network and to the tape.

    I am luck to have very powerful machine, backup 500GB database takes about 6 hours to the SAN.

    I have another database in size 40GB and backup takes about 40 minutes to the local disk.

    We always backup the database to local drives and then backup them to somewhere else. Backup to local drives should be the fast way.

    Edited by - Allen_Cui on 06/19/2003 09:01:04 AM

  • 15 hours thats a huge time. i would suggest you to take a backup on a local drive and then copy it in the tape rather then taking the backup directly on the tape.

    SNIPED AGAIN!!!!!!!!!!!!!!!

    Edited by - nazim on 06/19/2003 09:03:38 AM

  • Two words: SQL Litespeed.

    http://www.sqlservercentral.com/columnists/sjones/sqllitespeedlightningfastbackups.asp

    http://www.sqllitespeed.com/slsdefault.asp

    Is the db 30GB or the backup file? no that it matters, neither should take 15 hours. If the DBAs need some help, sjones@sqlservercentral.com, US$100/hour, 4 hour min

    Steve Jones

    sjones@sqlservercentral.com

    http://www.sqlservercentral.com/columnists/sjones

    http://www.dkranch.net

  • We are running SQL 2K on a dual processor box, dumping up about 36 gig to a partition on the local server box. This partition is used for dumps only. It was taking about 1 hour and 20 minutes. We started to run out of space on this partition, so we compressed that partition only. Backup time immediately shot up to about 3 hours and 30 minutes. BOL warns of trying to locate the actual data files on a compressed drive, but I was a bit surprised by the increase in time copying to a local compressed drive. I had always heard that the extra processing time for compression would be offset by the reduced amount of I/O to the target partition. Anyway, this is something to consider before compressing your dump space.

  • We are running a 30+ Gig database, backups straight to a DAT tape drive takes 1 hr 30 minutes, to a local partition dedicated to backups, about 40 minutes. Both backups are run nightly.

  • Definitely your backups are too slow. Fifteen hours isn't practical.

    For one of my database servers I backup about 100 GB with Backup Exec to DLT in about 3 hours. That is made of 45 databases (don't ask why 45) and it includes moving the data over the network. For another server I backup 10GB using SQL Server BU to a network drive with a slow disk and that takes about 4 hours. (Then it gets backed up to tape from there.)

    I think you need to look into backing up either with one of the faster pieces of backup software or backup to a faster device, like a disk.

  • Hi there!

    Try to do backups to an hard drive and also, if possible, take a second look to your backpup strategy. If you aren't doing it already, try the file backup strategy with backup's to the transaction log.

    For more information on that strategy, look on books on line.

    Sorry for mi bad english.

  • Example: 1 h 40 min with 215 GB of used data in the databases to 2 SAN-disks with SQL LiteSpeed resulting in 53 GB on disk.

  • I think you need to be careful here. Although 15hours to back-up a 30Gb database does sound too long it sounds like the back-up of your SQL Server is part of some other back-up schedule.

    I used to work as a DBA but NOT the systems administrator. The backing up of SQL Server was handled by back-up software that had plug-ins to back-up various RDBMS's. The entire back-up process used to take around 12 hours and used to lock the databases in question.

    Although this was not ideal there wasn't enough physical space on the drives to do a local back-up and the DAT drives could only handle a 24Gb back-up so I had to live with the Sys Admins approach.

    I would get more details from your DBA before you fire him or her, there may be a VERY good reason why they are claiming a 15hour back-up time.

    I've seen situations where backups take a huge amount of time.

    • Huge amount of traffic on the server.
    • Back-up across the network rather than to a local device.
    • System disks nearly full on server.
    • Database locked by some process
    • Complicated backup routine for replicated databases

Viewing 10 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply