One of my favorite aphorisms in data management is “There are those who backup, and those who will.”
Once you’ve had one catastrophe with a missing or corrupt backup, you’ll never forget about backing up again.
Or will you?
More and more, data systems are being hosted by third-party vendors. And part of that service is periodic backups of your data. But have you ever checked with your vendor(s) to ensure the data is actually being backed up? Ask your vendor(s) to prove they are backing up your data.
So maybe we need a new mantra: “There are those who check on their vendor backups, and those who will.”
When brand new on the job, I asked about the backup schedule on our critical applications. I was told that our managed service vendor was handling it. I investigated further and learned that the managed service vendor was taking server level snapshots per the contract, but no SQL backups were scheduled for any of the 3 applications on the server. I spent the rest of that day setting up backup routines for each SQL instance to run nightly backups and mid-day transaction logs.
I agree with Wes and would recommend you check the backups with your hosting vendor AND your application support vendor because you need both. The SQL backups are needed in the case that the software application fails and the server level snapshots would be best in a distaster recovery scenario.
And after you make sure backups are running on a regular schedule, I would ask your application support vendor about SQL maintenance routines to keep the database running at peak performance. My second week on the job, I learned that no standard SQL maintenance had been performed in over 5 years. Yikes.
Ultimately, it is the association’s responsibility, not the vendor’s, to ensure backups are occurring regularily. A vendor partner should welcome these questions and should be happy to show you the files, or better yet, offer to run a full restore to test the backups will work as intended, should you ever need it.
Excellent advice, Rene! Thanks for sharing.