In a previous blog post, I talked about the possibility of having unexpected SQL Server database backups that can affect your disaster recovery strategy. You certainly don’t want to be caught off-guard when that happens. I’ve provided a very simple use case of how it can happen – and it did happen to me a lot in the past until I checked the backup history report. And with virtualization and consolidation happening in the modern data center, using third-party enterprise backups are not making it easier for SQL Server DBAs to meet recovery objectives and service level agreements. Do you remember that blog post about how a third-party virtualization-based backup could not restore the SQL Server databases?

This video shows how it can happen and how to find out if it did happen.

A Step Further

Be sure to regularly check your SQL Server databases for unexpected backups. If you see one, find out where it came from.  And when you do find out, talk to the stakeholders responsible for it. Understand why they need it. But don’t stop there. Educate them about how the current implementation is introducing risks in your database disaster recovery strategy. Show them this video. If they insist on keeping those backups, arrange a test environment to validate that the backups that they are taking can be successfully restored.

Once the backups have been successfully restored and validated, update your processes to reflect this change and redefine proper escalation procedures that includes the person-in-charge. Now, take it a step further – even further. Ask if this is a standard practice across all of the IT assets in your organization. It never hurts to ask. But it may tell you something that’s broken and needs to be fixed.

I know this may seem a lot of work for you. But our job as database administrators is to make sure that the data is well taken cared of – especially in times of unexpected disasters.