Should I Backup The Systems DBs and If so Which ones and why

  • I actually know the common reasons or recommendations for why one would typically backup the system databases on a SQL Server 2005 box and which system DB's but I wanted to word the Subject so as to make this easy to find and certain to get great feedback on the more specific question of When is it not necessary to do this.

    For example in our environment we have numerous SQL Server's most of which run SQL 2005 with a few older ones on 2000 (because of application requirements). I'm curious as to what you guys &gals think about the take of when it’s ok to NOT back up the system databases such as when you have a simple setup where there is only 1 non-system database and the there are no Jobs and no customizations in the model DB and as far as security goes there is only a handful of SQL Logins setup for use by the application that uses the only database on that server. In a scenario like that would it really be necessary to backup any of the system databases?

    SYSTEM DB's individually:

    TEMPDB: Its my understanding that you just don't back this up period as it is temporary. if thats wrong or not completely right please speak up and comment.

    MODEL: If you have no customizations or defaults you want each new DB you create to use then is there really a need to back up the MODEL DB since you are using as is or in other words Out-of-the-box?

    MSDB: The container DB for ALERTS, OPERATORS and SQL Jobs and their history. If you either do not use any Jobs, Operators or Alerts on the server or you do but they are but a few (i.e. 1-2) and you have T-SQL code to re-create them, then would you really need to back this up? What about if you don’t need to retain the jobs history info, would it then be unnecessary to back up MSDB?

    MASTER: This of course is the main system DB that if it doesn;t work then SQL Server doesn't and everything else becomes secondary. Even if the answer about backing up the other 3 is NO I can see where you'd still want to backup MASTER on a regular basis so you can restore SQL Server as a product should it fail. That being said, would it really be necessary to even backup the MASTER system DB if your recovery plan process involves using another SQL Server that is indetically configured and ready to go as a replacement on short notice?

    My main goal here is to get some input from you experienced DBA's on system DB backups to determine if it really is necessary to always backup one or more of the system DB's no matter what the scenario. In our particular case we have a SQL Server with so simple a setup (its only purpose is to service the DB for 1 application that has a very simple setup as far as SQL Security and the like) that I have to ask if backing up the system DB's is more of a hindrance then a help.

    We already are doing incremental backups of the actual database the application uses and if we were to go down because of the DB we would not need to do anything to the system DBs to recover. And if the problem were with SQL Server itself and would require restoring the MASTER DB we would switch over to a backup/stand by server anyway making the recovery of the original SQL Server something that is not time critical.

    In a scenario like that is backup the system DB's simply unnecessary in your opinion?

    Thanks in advance for your input

    .

    Kindest Regards,

    Just say No to Facebook!
  • Simple answer, yes. The only system database you can't backup is tempdb, which makes sense as it is recreated every time you restart SQL Server.

    As to frequency, that would depend on how frequently you update the databses. Model, if you aren't storing common DB elements, I'd backup monthly just to be sure I had a good backup. Back it up if you make any changes to it as well.

    Master and msdb, at least daily, more often if you have many updates to it. This may apply more to msdb, especially if you are storing SSIS packages in SQL Server.

  • Lynn Pettis (3/9/2010)


    Simple answer, yes. The only system database you can't backup is tempdb, which makes sense as it is recreated every time you restart SQL Server.

    As to frequency, that would depend on how frequently you update the databses. Model, if you aren't storing common DB elements, I'd backup monthly just to be sure I had a good backup. Back it up if you make any changes to it as well.

    Master and msdb, at least daily, more often if you have many updates to it. This may apply more to msdb, especially if you are storing SSIS packages in SQL Server.

    Thanks for the respone Lynn. Just to make sure we are on the same page you are saying that except for TEMPD I should, in my scenario where I have no SSSIS items, or any SSQL JOBS, or Logins that are't created already via script, and a SQL Server that if it went down would have its duties moved to another box anyway, in that scenario you'd still recomend backing up the system databases. yes?

    Thanks

    Kindest Regards,

    Just say No to Facebook!
  • Yes. Say there's a single drive failure, or database corruption, or someone stops SQL and deletes one of the files belonging to a system DB. Restoring from backup is far easier than rebuilding all of the system databases and then repopulating them.

    Bear in mind that MSDB also contains your job and backup history as well as the jobs and the SSIS/DTS packages.

    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
  • GilaMonster (3/9/2010)


    Yes. Say there's a single drive failure, or database corruption, or someone stops SQL and deletes one of the files belonging to a system DB. Restoring from backup is far easier than rebuilding all of the system databases and then repopulating them.

    Bear in mind that MSDB also contains your job and backup history as well as the jobs and the SSIS/DTS packages.

    I have to concur with Gail on this one. Yes, you really should backup the master and msdb databases.

  • Yes, Yes, Yes ....

    - master is a must !

    - resource db files .... maybe ... so YES too ! but only once after every install/hotfix/cu/sp

    - model ? I don't, but I don't modify anything in model, so I can take any model db file set from any of my sql instances (of the same sp/hf/cu level)

    - tempdb not needed.

    - msdb YES ! it plays a major role when using SQLAgent, SSIS, Service Broker and it holds your dbs backup set info !

    Johan

    Learn to play, play to learn !

    Dont drive faster than your guardian angel can fly ...
    but keeping both feet on the ground wont get you anywhere :w00t:

    - How to post Performance Problems
    - How to post data/code to get the best help[/url]

    - How to prevent a sore throat after hours of presenting ppt

    press F1 for solution, press shift+F1 for urgent solution 😀

    Need a bit of Powershell? How about this

    Who am I ? Sometimes this is me but most of the time this is me

  • And three for the record. I agree with Lynn and Gail. Backup your system dbs (master, model, msdb). This will save you time and effort should a problem arise.

    Also, what if you need to perform some investigative work and it is required to restore the msdb database (as a different database) to compare job history.

    There can be plenty of reasons to backup the system dbs.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • ALZDBA (3/9/2010)


    Yes, Yes, Yes ....

    - master is a must !

    - resource db files .... maybe ... so YES too ! but only once after every install/hotfix/cu/sp

    - model ? I don't, but I don't modify anything in model, so I can take any model db file set from any of my sql instances (of the same sp/hf/cu level)

    - tempdb not needed.

    - msdb YES ! it plays a major role when using SQLAgent, SSIS, Service Broker and it holds your dbs backup set info !

    Thanks for reminding us of the resource db.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • The system databases are so small, there's no good reason not to back them up.

    Trying to see how much you can get away without doing isn't really a good approach.

  • First off thanks to everyone who has taken the time to contribute, it is appreciated as always.

    What has been said so far in each reply is in agreement with the standard take on backing up your system DBs and that is you need to do this.

    What I haven't seen yet and maybe its my fault with how I worded my original post, is why one would back up their system DB's in a simple setup as I described.

    If you have a brand new out of the box install of SQL Server 2005 and the only thing you do to it is set it to use Mixed Mode authentication and then create 2 SQL Logins and assign them to the DB which the application you use restores to your server and nothing else is setup, no jobs, no operators no alerts or anything else like it, why in that scenario would you need to backup the system DB's if your recovery process (when the serve goes down) involves using a backup server that is already to go? I mean what is within the system DBs you are backing that you would need to restore from in that scenario?

    Keep in mind I am talking about this specific scenario and not all SQL Server setups in general. We backup stuff on our regular boxes. It is the 2 SQL Setups like this that I'm finding hard to justify the extra backup work for. We backup the user database of course but what would we gain from also backing up the system DBs?

    Thanks again for taking the time to chime in

    Kindest Regards,

    Just say No to Facebook!
  • Two reasons, first of the chances of that system remaining in that state for any significant time is small. Things change and you should plan for it now, not later. Second, practice good habits now instead of relying on making changes later when you may not have time.

  • YSLGuru (3/9/2010)


    If you have a brand new out of the box install of SQL Server 2005 and the only thing you do to it is set it to use Mixed Mode authentication and then create 2 SQL Logins and assign them to the DB which the application you use restores to your server and nothing else is setup, no jobs, no operators no alerts or anything else like it, why in that scenario would you need to backup the system DB's if your recovery process (when the serve goes down) involves using a backup server that is already to go? I mean what is within the system DBs you are backing that you would need to restore from in that scenario?

    The answer doesn't change for me. How much time does it take to reinstall SQL Server v. restore the system databases? It is faster and saves more time for me to simply restore the database. One of the first things done with a SQL server should be to setup the backup jobs, test the backup and test the restore. If you put off setting up the backup jobs for a later date - it may get forgotten. I have seen that happen numerous times and have been asked how to restore a database that hasn't been backed up.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • Well ... in your typical scenario .... there shouldn't be any user databases !

    From the moment you add a user database, you should have a DRP in place !

    That DRP off course not only includes the user database, but also the system databases.

    As Lynn stated, chances of your system remaining in your typical state are very small.

    BTW: here's a little overview of our Post SQLInstance Install Procedure.

    /* This is all implemented in a Post Install Script !! */

    1) SP_Configure 'show advanced options'

    2) revoke builtin\administrators / grant DBA windows group

    3) Set Auditlevel - Failure

    4) Expand SQLAgent log-settings

    5) set sa pwd to newid() -- never to be used !

    cluster ? if yes : search for "ExecCluster" in this script !!! ' to grant connect to the instance

    Specific windows domain ? if yes : find @PRDzone in this script and set serviceaccounts(default = SFA)

    SOX-related server ? : Search for @SoxServerNY (default=N) to enable audit traces

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA Optimize_tempdb_files.sql" -o "C:\_DBA_DBA_Optimize_tempdb_files_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA Install DBA_ServerPing.sql" -o "C:\_DBA_DBA_Install_DBA_ServerPing_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA install sp_DBA_RowCount.sql" -o "C:\_DBA_DBA_install_sp_DBA_RowCount_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA Install backup job Server certificates.sql" -o "C:\_DBA_DBA_Install_backup_job_Server_certificates_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA Install sp_DBA_SQL_SYSTEMINFO.sql" -o "C:\_DBA_DBA_Install_sp_DBA_SQL_SYSTEMINFO_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA install sp_DBA_SendAndKill.SQL" -o "C:\_DBA_DBA_install_sp_DBA_SendAndKill_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA install sp_DBA_WhoBlocks.sql" -o "C:\_DBA_DBA_install_sp_DBA_WhoBlocks_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA install Sp_DBA_TB_ix.sql" -o "C:\_DBA_DBA_install_Sp_DBA_TB_ix_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA install sp_DBA_LockInfo.sql" -o "C:\_DBA_DBA_install_sp_DBA_LockInfo_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA Install sp_DBA_Create_BuDevices.sql" -o "C:\_DBA_DBA_Install_sp_DBA_Create_BuDevices_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA Install DBA_ConnectionTracker via EventNotification.sql" -o "C:\_DBA_DBA_Install_DBA_ConnectionTracker_via_EventNotification_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA Install sp_dba_Rebuild_Reorganize.sql" -o "C:\_DBA_DBA_Install_sp_dba_Rebuild_Reorganize_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA install sp_DBA_UserMessages.sql" -o "C:\_DBA_DBA_install_sp_DBA_UserMessages_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA install sp_DBA_check_failed_jobs.sql" -o "C:\_DBA_DBA_install_sp_DBA_check_failed_jobs_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA Install Add SQLServer Startup parameters.sql" -o "C:\_DBA_DBA_Install_Add_SQLServer_Startup_parameters_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA Expand SQLAgent Jobhistory.sql" -o "C:\_DBA_DBA_Expand_SQLAgent_Jobhistory_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA Install job DBA_Switch_SQLServer_Errorlogfiles.sql" -o "C:\_DBA_DBA_Install_job_DBA_Switch_SQLServer_Errorlogfiles_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA Install RefreshErrorlogData.sql" -o "C:\_DBA_DBA_Install_RefreshErrorlogData_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA install Spc_DBA_Enable_Jobs.sql" -o "C:\_DBA_DBA_install_Spc_DBA_Enable_Jobs_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA install Spc_DBA_Disable_Jobs.sql" -o "C:\_DBA_DBA_install_Spc_DBA_Disable_Jobs_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA Install job DBA_StopStart_CommunicationMF_DB2_SQL.sql" -o "C:\_DBA_DBA_Install_job_DBA_StopStart_CommunicationMF_DB2_SQL_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA Install ADD reg-key TurnOffRpcSecurity for W2K3 and sqlserver MSDTC.sql" -o "C:\_DBA_DBA_Install_ADD_reg-key_TurnOffRpcSecurity_for_W2K3_and_sqlserver_MSDTC_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA Install ADD reg-key TurnOff_UseOnlineHelp.sql" -o "C:\_DBA_DBA_Install_ADD_reg-key_TurnOff_UseOnlineHelp_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\DBA Install backup sp_DBA_Create_BuDevices.sql" -o "C:\_DBA_DBA_Install_backup_sp_DBA_Create_BuDevices_NewSQLServer_Instance.txt"

    rem --------------------------------

    rem Site proprietary default scripts !

    rem --------------------------------

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\ALZ install fn_ALZ_Split UDF.sql" -o "C:\_DBA_ALZ_install_fn_ALZ_Split_UDF_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\ALZ Install fn_ALZ_List2DateTimeTb UDF.sql" -o "C:\_DBA_ALZ_Install_fn_ALZ_List2DateTimeTb_UDF_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\ALZ install fn_ALZ_List2MaxDateTime UDF.sql" -o "C:\_DBA_ALZ_install_fn_ALZ_List2MaxDateTime_UDF_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\ALZ Install fn_ALZ_convert_date2WeekALZ UDF.sql" -o "C:\_DBA_ALZ_Install_fn_ALZ_convert_date2WeekALZ_UDF_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\ALZ Install fn_ALZ_convert_date2WeekRangeALZ UDF.sql" -o "C:\_DBA_ALZ_Install_fn_ALZ_convert_date2WeekRangeALZ_UDF_NewSQLServer_Instance.txt"

    Sqlcmd -H %computername% -E -S NewSQLServer\Instance -d master -i "InstallationScripts\ALZ Install sp_ALZ_gen_PloegenShifts.sql" -o "C:\_DBA_ALZ_Install_sp_ALZ_gen_PloegenShifts_NewSQLServer_Instance.txt"

    Scripts to be loaded adjusted and executed :

    0) DBA Set Default Data- en LogFile locations.sql

    1) ADD ServerFunctionality-database(description db).sql

    2) DBA Alter Default Backup Directory.sql

    3) DBA Install backup job DB.sql -- FULL/LOG incr/Log init according to SLA

    4) Register in SQLServerInfo application.

    5) Double-check SOX needs !

    SCADAteam install proxy account (cmdshell / SSIS)

    ---------------------------------------------

    S1) DBA Install Application Server Proxy Account (cmdshell) JOBADMIN.sql

    S2) SCADA Grant Lijnserver_SRV_account.sql

    S3) SCADA import SCADASyncParams.sql

    As you can see the DBA Install backup job DB.sql must be executed.

    This installs at least a FULL backup job of all non-readonly databases.

    In most cases, also two log backup jobs are installed.

    All jobs handle all datases !

    Last two steps (before the copy to safe zone) in these jobs are:

    Backup master

    backup msdb

    Johan

    Learn to play, play to learn !

    Dont drive faster than your guardian angel can fly ...
    but keeping both feet on the ground wont get you anywhere :w00t:

    - How to post Performance Problems
    - How to post data/code to get the best help[/url]

    - How to prevent a sore throat after hours of presenting ppt

    press F1 for solution, press shift+F1 for urgent solution 😀

    Need a bit of Powershell? How about this

    Who am I ? Sometimes this is me but most of the time this is me

  • YSLGuru (3/9/2010)


    First off thanks to everyone who has taken the time to contribute, it is appreciated as always.

    What has been said so far in each reply is in agreement with the standard take on backing up your system DBs and that is you need to do this.

    What I haven't seen yet and maybe its my fault with how I worded my original post, is why one would back up their system DB's in a simple setup as I described.

    If you have a brand new out of the box install of SQL Server 2005 and the only thing you do to it is set it to use Mixed Mode authentication and then create 2 SQL Logins and assign them to the DB which the application you use restores to your server and nothing else is setup, no jobs, no operators no alerts or anything else like it, why in that scenario would you need to backup the system DB's if your recovery process (when the serve goes down) involves using a backup server that is already to go? I mean what is within the system DBs you are backing that you would need to restore from in that scenario?

    Keep in mind I am talking about this specific scenario and not all SQL Server setups in general. We backup stuff on our regular boxes. It is the 2 SQL Setups like this that I'm finding hard to justify the extra backup work for. We backup the user database of course but what would we gain from also backing up the system DBs?

    Thanks again for taking the time to chime in

    How lazy can you possibly be to not bother spending 60 seconds to create a backup job ? You could have created a lot of maintenance plans in the time it took to write your posts.

    If you are backing up user databases, then those backups jobs are in msdb, unless you back them up manually every day. And if they are in jobs, wouldn't you want an email alert to an operator if they fail ?

    I guess if everything on your server is "disposable" you can rebuild from scratch if you prefer.

  • Lynn Pettis (3/9/2010)


    Two reasons, first of the chances of that system remaining in that state for any significant time is small. Things change and you should plan for it now, not later. Second, practice good habits now instead of relying on making changes later when you may not have time.

    Lynn, As always thanks for the quick and detailed reply.

    Kindest Regards,

    Just say No to Facebook!

Viewing 15 posts - 1 through 15 (of 44 total)

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