Proper way to backup databases

  • hi, i have a quick question about the proper way to backup databases. i have a maintenance plan to backup 2 main databases daily at 2 am - i have trans logs to backup every 3 hours daily. also i have the optimization and integrity to run weekly on these 2 databases

    i have another maint plan for the master, model, and msdb to backup weekly only - nothing for the trans logs for these databases or optimization and integrity.

    is this a correct way to do the backups? i have sql 2000sp4

    thanks in advanced

  • There is no way to tell you what is the best because it varies by the situation. Certainly backing up daily and having transaction log backups are good. The decision comes down to, "How much data are you able to lose?". If 3 hours is good then you are all set, if not, then you need to increase transaction log frequency and might want to add differential backups during the day to reduce the # of steps required for a restore.

    One other thing you don't mention is where are your backups going to? Are they on a different drive than the log and database files?

  • thank you for the response.

    the backup is going to the local c drive and the trans log is going to the local d drive - the server gets backedup daily so i have the sql backups on tape from the nightly backups.

    3 hours is ok for the trans logs -we can lose 3 hours -

    i guess there are different ways to do backups - i am just wondering if using the maintenance option in sql is the most effective - i ask this becuase, from my experience, (which is very limited) i cant seem to get the backup and trans logs scheduled in the same maint job. i guess i could do one for each job - havent tried it yet -

    thanks

  • The only thing I might add is be sure the backups (data and log) are going to drives separate from where you data (mdf/ndf) files are. If something happens to that physical drive, you want backups separate.

  • Add integrity checks for the system databases. Finding that master is corrupt and there's no clean backup (because it's been corrupt so long that the last good backup was deleted weeks back) it not a good thing.

    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
  • Only think I would add, is that you if you are doing a full backup every day and tran log backups every 3 hours, you could be looking at more than 3 hours outage if you lose the drive the tran log backups are on.

    potentially you could lose all the tran log backups and have to restore from last nights backup. it might be overkill, but i would periodically copy some of your backups on to another drive and then at the end of the day if you want to, remove them from the other drive after the full backup has been done.

    --------------------------------------------------------------------------------------
    [highlight]Recommended Articles on How to help us help you and[/highlight]
    [highlight]solve commonly asked questions[/highlight]

    Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden[/url]
    Managing Transaction Logs by Gail Shaw[/url]
    How to post Performance problems by Gail Shaw[/url]
    Help, my database is corrupt. Now what? by Gail Shaw[/url]

  • thanks for all the good suggestions --

    one thing i found out was that the trans logs were failing - couldnt figure out why --finally i remeber to check the backup mode of the databases and of course they were in simple mode hence trans logs were not backingup. once i changed the mode to full the trans logs started to backup ok -

    so i guess it is a good idea to check the backup mode right from the begining -

  • You can run in simple mode, but you cannot recover to a point in time other than your full backups. If that's important, then you do need to be sure you are in full or bulk logged mode.

  • I would strongly recommend you read 'Pro SQL Server 2005 Disaster Recovery" by James Luetkehoelter. The book pretty much explains all aspects of the 'data preservation' - backup being just one small step of the entire process. Most of the concepts do apply to SQL2K.

    ---------------------------------------------
    [font="Verdana"]Nothing is impossible.
    It is just a matter of time and money.[/font]

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

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