Featured Article(s)
Maintenance Plans Gotchas SQL Server 2005
It almost looks as if SQL Server 2005 Maintenance Plans have been tossed into a blender with SQL Server 2000 DTS. In my opinion, for what its worth, I like the new look. But what should you watch out for…
Final Thoughts on "Trust, But Verify"
Jon writes "For SQL it should actually be simple. A SQLRAP with Microsoft would have caught this. We have one at my job after we change editions. Someone comes onsite for a day, and gathers a bunch of information using tools, and then comes back a few days later with a compiled report of what they found. A competent DBA should not feel threatened by something like this."
Timothy’s feedback: "It is next to impossible to "check up" on everything that a DBA or other trusted member of an IT group is suppose to perform as part of their duties. Even in large companies where you have multiple DBA’s in charge of multiple systems, you can not verify each and every little thing each and every day.
However, there are some things which a manager can insist on be completed and it can be verified. They may have to spend a little time, money and effort….but haven’t we learned that it is worth it.
1. Documentation – You have the IT profession document the "important" things. The system configuration, system builds (if they are to be duplicated), system policies (passwords policies, user policies, user groups), system/support contacts, inventory, software maintenance (contracts), configuration/change procedures, and backup/restore procedures (including off-site storage of backup). You make sure that they understand that it is in case something happens like a Milk truck hits them and they are in the hospital for a time (or worse). As the manager it is your right and responsibility to have this type of documentation created.
2. Test systems – Although not a perfect system and can be expensive, using development/test systems can be very beneficial in mitigating this type of sabotage. You can require backup/restore procedures to be practiced on a quarterly basis on the test/development systems. Have the IT team move the backups from the production to the test/development system can help ensure a backup copy (a little old) is available on site.
3. Depending on the value of the system, it might be beneficial to have Disaster Recovery Plan in place. If a fire burns my building down, how am I going to recovery/continue the business. It does not have to be extremely detailed, but at least some knowledge of where to go planned in the calm will help elevate the pressure if something bad does happen. It also forces your IT professional to think along those lines.
4. Audits (Internal or External) – If you must, have the IT professionals of your organization write up the type of actions they are suppose to be performing or responsible to check. Have either an external source, or do it internally, once a year do spot checks to verify that the actions are being handled. This can also be a part of their performance evaluation which is a good excuse to have the audit done but under a different name."
…a "Milk Truck?!" 🙂
Brent writes with this feedback:
"It really all boils down to: How valuable is your data?
Very? Make sure your "Disaster Recovery" processes are periodically (at set intervals) audited by an outside source. And, make sure "Recovery from Malicious attack" is part of that D.R.. And, make sure your IT manager isn’t also your DBA. Make it part of your IT managers performance review to pass all audits. (a 3rd party audit would’ve caught the potential for this way before it could’ve ever happened)."
…and finally, Christopher writes:
"All of your responses so far assume one of two things: there is more than one person involved in IT in the shop or the management knows something about what that person does.
I am the IT person in our shop (DBA, DB Developer, Web Developer, VB Programmer, Help Desk, and that’s on top of my duties related to our core business). While I would never do it because I enjoy where I work and, if that changes, would want to be able to find a job elsewhere, I am very much in a position to shut the company down for at least a few days with a few keystrokes. My company has the advantage that the primary purpose of our database is to drive our website, so all of our data is duplicated on the web server.
But I have designed all of our internal program and much of the website programming. Were I to delete any of that on the way out the door, it would take some time, and a lot of money, to reverse engineer things from the backups our web host makes and the pieces at our other branch.
The rest of my company [has] little or no background in computers beyond using what is put before them, so by and large their only information about security and backup is what I provide them. While some things may change as my children come into the workforce more experienced with computers, I suspect there are a lot of other business owners and managers out there relying on one in-house person, or one contractor, and without the knowledge to protect themselves should that person turn on them.
You can’t know what you don’t know."
Featured White Paper(s)
Continuous Data Protection : Increasing Backup Frequency without Pain
Daily data backups are an important, yet painful, operation slowing (even halting) production, requiring hands-on management… (read more)