|
| Featured Contents |
| The Voice of the DBA |
Default Backups and Feature Awareness Have you ever been asked a question about your software and thought that the person was asking about an obvious feature? Perhaps someone has suggested a feature to you and you answered that this was already in the product. Did any of you think your users were stupid or not very observant, or something else? I've had that situation appear a few times, with my on different sides of the discussion. I watched someone ask a question that I knew the answer to, watched someone else respond, and thought, huh, how didn't they know that. I asked a question about something in the Microsoft Azure world and got a quick answer, wondering why I hadn't been able to find the solution myself. And stopping myself from cursing the Microsoft devs too much. I've had a few people do strange things at SQLServerCentral after the migration and wondered, why in the world.......? Then I remember that lots of people use the site differently than I do and I should expect that. I thought about this while reading Joey D'Antoni's piece on backups. It's not hard to make backups. It's not hard to set up a maintenance plan to run backups. It's not hard to set up a history task to trim old ones. Heck, it's not hard to implement Ola's scripts. The problem is all of these solutions require some knowledge. I think plenty of people assume either the system backs itself up or their nightly file sweep by a central backup system will grab the database. Hint: it won't. I think plenty of people think it's someone else's job. Or they are in a hurry with an installation and assume they or someone else will come back and set up backups later. Plenty of third party software may create a database, but never set up a backup process. That's not good. While I like Joey's suggestion, I'd go further. I'd have instance defaults set on install and an automatic, nightly full backup process set for all new databases with a week's retention. I'd embed this in the DDL so the default is backups will be set on CREATE DATABASE, and you can use a switch to turn this off if you want to use some other backup process. I bet backup software, like SQL Backup, would even do this for you, turning off native backups when you turn on their scheduler. I think backup is the most critical thing a DBA does, or an accidental DBA, or the accountant that installed Dynamics, or anyone working with a database. Next would be verifying things with a restore. Then comes security and the list goes on from that point. If you don't have the data, because of ransomware, virus, bad hardware, or anything else, you are in a bad situation. Please. Set up backups. If you find a server without them, inform someone in writing of the dangers and give them resources for creating backups. If you create databases as part of your software deployment process, set up backups somehow. Use a maintenance plan. Those aren't great, but they're better than nothing. There's a reason why SQL Monitor has an alert for databases with no backup. It's a critical one to have running. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
|
| Featured Contents |
