Backup Time vs Restore Time

  • As a rule of thumb, would you guys expect restores to take approx the same time as backups. Its a question I've not really considered before. I'm being asked to estimate restore time where backup time will be around 2hrs in total across a number of DBs.

    cheers

  • There are too many variables in a restore to say "that you should experience a 2 x backup time for you restore time". Your backup is backing up 8k pages that are in use, but your restore has to account for the full size of the database regardless of used 8k pages. So, some of the questions to answer are:

    1. Are you restoring to the same hardware (or very similar)?

    2. Are you on a SAN and are you restoring to the same level of spindles (or SSDs)?

    3. Does the restore DB already exist on the machine or will it create it new?

    4. Is instant file initialization turned on on the restore machine?

    5. How is the size of your DB distributed? MDF and NDF vs LDF (Log file can't use IFI).

    6. Will you be restoring from a network share, local storage, etc?

    The best way to tell how long it will take to restore is do actually restore the database. Good news there is a query that you can use to help let you know how long the restore will take once you have started it. I have provided a link to the blog post with the query:

    http://johnsterrett.com/2011/08/29/how-long-will-this-sql-server-restore-take/



    Microsoft Certified Master - SQL Server 2008
    Follow me on twitter: @keith_tate

    Forum Etiquette: How to post data/code on a forum to get the best help[/url]

  • _nzrdb6 (11/25/2013)


    I'm being asked to estimate restore time where backup time will be around 2hrs in total across a number of DBs.

    Restore the database, see how long it takes. Best way. You should be doing test restores regularly to ensure that the backups are restorable as it is.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • I'd expect the restore time to generally be longer; if restoring to a new database, potentially significantly longer.

    For a backup, SQL only needs to backup the active portion of the log. When restoring, SQL needs to restore the entire log, and also ultimately roll forward and/or roll back in-flight transactions to make the final db useable.

    SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".

  • I have a 141GB database that takes 00:31:05 to backup and and 01:31:27 to restore. I don't know if the 3:1 ratio exists elsewhere but, as you can see, it takes this particular database substantially longer to restore than it does to back-up.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • This is, obviously, an it depends moment. At a previous employer our 75 GB HR and Finance databases had backup and restore times under 10 minutes. These were native compressed backups using SQL Server 2008 Enterprise Edition.

    On older hardware with SQL Server 2005 and Hyperbac for compression these same databases took 30 minutes to backup and restore. Without compression, approximately 1 hour for both.

Viewing 6 posts - 1 through 5 (of 5 total)

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