![\"SQL](\"https:\/\/academy.sqlbak.com\/wp-content\/uploads\/2016\/02\/SQL-Server-Database-Health-Check.jpg\")
Are you sure you can\u00a0restore your database with the help of backups with minimal loss? Do you restore your data regularly? Probably many\u00a0SQL Server users\u00a0don’t even think of\u00a0it until it strikes them. So ask yourself yet another question – What should I do about my backup to make sure I can restore it with minimal loss should a disaster occur? To put it shortly – You need to check the health of your SQL Server database regularly. Read on to find out how it’s done.<\/p>\n
It’s common knowledge that the best way of keeping your database safe and sound is to make scheduled backups regularly. Of course, it is necessary to work out the best backup plan that will cover all your needs. But before that you have to consider RPO (Recovery Point Objective) and\u00a0RTO (Recovery Time Objective).<\/p>\n
In other words – how much data can you afford to lose? For example, your database backup plan is Full backup every 24 hours, differential every four hours and transaction log every 15 minutes,\u00a0in such\u00a0case if failure occurs the time for which data will be lost will not exceed 15 minutes. To be confident in your backup plan your database should be in the full recovery mode and your transaction log backups should occur every “<=n” minutes. (“n” – is the\u00a0maximum amount of data loss that you can sustain).<\/p>\n
RTO – if database disaster occurs, how much time are you able to spend restoring a database to its working condition?\u00a0This will determine whether you just keep your backups on a drive ready for access or actively keep a warm standby using log shipping.<\/p>\n
Suppose you are familiar with\u00a0RPO and\u00a0RTO,\u00a0but beside this, you need to do regular SQL Server database backup health-check. Testing\u00a0your database backups is an extremely important point which should not be ignored.\u00a0This implies<\/span> that from time to time you need to restore your database with the help of backups to another server\u00a0or another database. Restoring\u00a0database periodically is useful not only for practice but also to check the validity of backups. <\/span><\/p>\n Please note, if you haven’t yet tried restoring your database backup it means that you don’t have a backup!<\/span><\/p>\n As an additional SQL Server database backup health-check, you can make all backups with\u00a0CHECKSUM option.\u00a0The checksum is a value calculated from the data page bytes. Equal data pages have equal\u00a0checksums. Use the following T-SQL Command to perform a backup with CHECKSUM:<\/p>\n You can verify a backup with the VERIFYONLY \u00a0option. It does not restore the backup, it only verifies it:<\/p>\n So, your backup plan and RESTORE VERIFYONLY &\u00a0CHECKSUM options are just additional tools that can help you to perform SQL Server database health-check, but the best way to make sure you will be able\u00a0to restore your database with minimal loss is to restore all necessary backups to another server or database.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":" Are you sure you can\u00a0restore your database with the help of backups with minimal loss? Do you restore your data regularly? Probably many\u00a0SQL Server users\u00a0don’t even think of\u00a0it until it strikes them. So ask yourself yet another question – What should I do about my backup to make sure I can restore it with minimal […]<\/p>\n","protected":false},"author":10,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"yoast_head":"\nRESTORE VERIFYONLY and CHECKSUM options<\/h3>\n
BACKUP DATABASE<\/span> Adventureworks <\/em><\/span>TO DISK<\/span> =<\/span> 'Adventureworks<\/em>.bak'<\/span> WITH CHECKSUM<\/span><\/span>;<\/pre>\nRESTORE VERIFYONLY FROM DISK<\/span> = <\/span>'Adventureworks<\/em>.bak'<\/span><\/pre>\nConclusion<\/h2>\n