Skip to main content

Is your SQL Server Database backup good enough? Can it save you during a disaster?

Met a DBA from a company who are in business for ~2 years. During the conversation came to know they have never tested their backup file - not even once. Also, they have very rarely used DBCC CheckDB command. Should I call it as surprised or shocked?

It has become common to see Database Administrators to have fancy DB Backup plan, automate it and that's it. Their idea is whenever the need arises (read as disaster strikes) they can make use of it and restore the database. Although theoretically sounds like a good plan it actually isn't. Why?

All those efforts to take regular backups would become completely useless if those files can't be used to recover the database. One important question missed by many companies to whom I have consulted for - "Do we regularly make sure that we are able to restore a database from our backups?".

Despite backup process has succeeded how do we know it isn't corrupted (or) has some issues which don't allow it to be restored properly?

Our data is only as good as our last restorable backup

The bottom line is unless we do a database restore somewhere, we can't be completely sure that a given backup file is good.

At a high level, based on the business need we should first decide on:
- How much of "downtime" the system can have,
- How much of "data loss" is acceptable,
- After that put together a "Backup plan" to satisfy those requirements.
- Then the "Restore plan" should make sure all backup files are verified to be perfect and restorable in a test environment. Believe one would be already aware & using DBCC CheckDB often if not check the link provided at the end of this article.

DBA need to have a system that allows them to periodically review their plan and ensure they can get everything back up & running again.

Take away: I can't stress enough - Test your Backup file by periodically restoring in a test environment and make sure it's fine.

Recommended for further reading:

1. Paul Randal's The Accidental DBA (Day 8 of 30): Backups: Planning a Recovery Strategy
2. Award winning Maintenance script of Ola Hallengren
3. DBCC CheckDB FAQ by Kendra Little

Comments

Popular posts from this blog

AWS fatal error: An error occurred (400) when calling the HeadObject operation: Bad Request

While using AWS and trying to copy a file from a S3 bucket to my EC2 instance ended up with this error message. Command Used: aws s3 cp s3://mybucketname/myfilename.html /var/www/html/ Error: fatal error: An error occurred (400) when calling the HeadObject operation: Bad Request The error goes off if we add the region information to the command statement. I am using Asia Pacific (Mumbai) so used ap-south-1 as the region name. Modified Command: aws s3 cp s3://mybucketname/myfilename.html /var/www/html/ --region ap-south-1

Script table as - ALTER TO is greyed out - SQL SERVER

One of my office colleague recently asked me why we are not able to generate ALTER Table script from SSMS. If we right click on the table and choose "Script Table As"  ALTER To option would be disabled or Greyed out. Is it a bug? No it isn't a bug. ALTER To is there to be used for generating modified script of Stored Procedure, Functions, Views, Triggers etc., and NOT for Tables. For generating ALTER Table script there is an work around. Right click on the table, choose "Modify" and enter into the design mode. Make what ever changes you want to make and WITHOUT saving it right click anywhere on the top half of the window (above Column properties) and choose "Generate Change Script". Please be advised that SQL Server would drop actually create a new table with modifications, move the data from the old table into it and then drop the old table. Sounds simple but assume you have a very large table for which you want to do this! Then it woul

Timezone conversion UTC to CST with Daylight Savings

Converting UTC format date to Standard time of CST or EST is straight forward. DECLARE @UTC_Date DATETIME SET @UTC_Date = GETUTCDATE() SELECT @UTC_Date AS [UTC], DATEADD(hh, -6, @UTC_Date) AS [CST - Standard Time], DATEADD(hh, -5, @UTC_Date) AS [EST - Standard Time] But if the given date falls under daylight saving then the above calculation won't work. So how is Daylight saving calculated? 1. If the year <= 2006 then daylight saving is between: 2 am on First Sunday in April till 2 am on Last Sunday in October 2. If the year >= 2007 then daylight saving is between: 2 am on Second Sunday in March till 2 am on First Sunday in November 3. UTC to CST (Standard Time) = -6 4. UTC to CDT (Daylight Time) = -5 5. UTC to EST (Standard Time) = -5 6. UTC to EDT (DayLight Time) = -4 Solution - 1: DECLARE @UTC_Date DATETIME SET @UTC_Date = GETUTCDATE() SELECT @UTC_Date AS [UTC], DATEADD(hh, -6, @UTC_Date) AS [CST - Standard Time], DATEADD(hh, CA