<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://sqlblog.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Search results matching tags 'Tips', 'Disaster Recovery', and 'Administration'</title><link>http://sqlblog.com/search/SearchResults.aspx?o=DateDescending&amp;tag=Tips,Disaster+Recovery,Administration&amp;orTags=0</link><description>Search results matching tags 'Tips', 'Disaster Recovery', and 'Administration'</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP2 (Build: 61129.1)</generator><item><title>Backup those keys, citizen</title><link>http://sqlblog.com/blogs/buck_woody/archive/2010/04/20/backup-those-keys-citizen.aspx</link><pubDate>Tue, 20 Apr 2010 12:14:50 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:24408</guid><dc:creator>BuckWoody</dc:creator><description>&lt;p&gt;Periodically I back up the keys within my servers and databases, and when I do, I blog a reminder here. This should be part of your standard backup rotation – the keys should be backed up often enough to have at hand and again when they change.&lt;/p&gt;  &lt;p&gt;The first key you need to back up is the Service Master Key, which each Instance already has built-in. You do that with the &lt;a href="http://msdn.microsoft.com/en-us/library/ms190337.aspx" target="_blank"&gt;BACKUP SERVICE MASTER KEY command, which you can read more about here&lt;/a&gt;.&lt;/p&gt;  &lt;p&gt;The second set of keys are the Database Master Keys, stored per database, if you’ve created one. You can back those up with the &lt;a href="http://technet.microsoft.com/en-us/library/ms174387.aspx" target="_blank"&gt;BACKUP MASTER KEY command, which you can read more about here&lt;/a&gt;.&lt;/p&gt;  &lt;p&gt;Finally, you can use the keys to create certificates and other keys – those should also be backed up. &lt;a href="http://msdn.microsoft.com/en-us/library/ms189586.aspx" target="_blank"&gt;Read more about those here&lt;/a&gt;.&lt;/p&gt;  &lt;p&gt;Anyway, the important part here is the backup. Make sure you keep those keys safe!&lt;/p&gt;</description></item><item><title>Cluster Nodes as RAID Drives</title><link>http://sqlblog.com/blogs/buck_woody/archive/2010/03/25/cluster-nodes-as-raid-drives.aspx</link><pubDate>Thu, 25 Mar 2010 05:56:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:23734</guid><dc:creator>BuckWoody</dc:creator><description>&lt;P&gt;I'm unable to sleep tonight so I thought I would push this post out VERY early. When you don't sleep your mind takes interesting&amp;nbsp;turns, which can be a good thing. &lt;/P&gt;
&lt;P&gt;I was watching a briefing today by a couple of friends as they were talking about various ways to arrange a Windows Server Cluster for SQL Server. I often see an "active" node of a cluster with a "passive" node backing it up. That means one node is working and accepting transactions, and the other is not doing any work but simply "standing by" waiting for the first to fail over.&lt;/P&gt;
&lt;P&gt;The configuration in the demonstration I saw was a bit different. In this example, there were three nodes that were actively working, and a fourth standing by for all three. I've put configurations like this one into place before, but as I was looking at their architecture diagram, it looked familar - it looked like a RAID drive setup! And that's not a bad way to think about your cluster arrangements. The same concerns you might think about for a particular RAID&amp;nbsp;configuration provides a good way to think about protecting&amp;nbsp;your systems in general.&lt;/P&gt;
&lt;P&gt;So even if you're not staying awake all night thinking about SQL Server clusters, take this post as an opportunity for "lateral thinking" - a way of combining in your mind the concepts from one piece of knowledge to another. You might find a new way of making your technical environment a little better.&lt;/P&gt;</description></item><item><title>Have you backed up your keys lately?</title><link>http://sqlblog.com/blogs/buck_woody/archive/2010/03/01/have-you-backed-up-your-keys-lately.aspx</link><pubDate>Mon, 01 Mar 2010 14:06:04 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:22679</guid><dc:creator>BuckWoody</dc:creator><description>&lt;p&gt;Did you know that you already have a Server Master Key (SMK) generated for your system? That’s right – while a Database Master Key (DMK) is generated when you encrypt a certificate or Asymmetric Key with code, the Server Master Key is generated automatically when you start the Instance. &lt;/p&gt;  &lt;p&gt;So you should back all of those keys up periodically, and then store that backup AWAY from the server itself. &lt;/p&gt;  &lt;p&gt;There are two reasons for this – first, if the drives get stolen and you’re storing the key backup there, well, that should be obvious why that’s bad. Second, you want to protect the keys in case the system is destroyed or you can’t recover the drives. You will need those keys if you have encrypted anything in the database to get the data back.&lt;/p&gt;  &lt;p&gt;More here: &lt;a href="http://technet.microsoft.com/en-us/library/bb964742.aspx"&gt;http://technet.microsoft.com/en-us/library/bb964742.aspx&lt;/a&gt;&amp;#160;&lt;/p&gt;  &lt;p&gt;No, the standard Maintenance Wizards don’t get this data. And no, I haven’t seen it addressed in most of the maintenance scripts out there anyway – sometimes for good reason, but this means you need to take care of it manually, and then document where you put that backup.&lt;/p&gt;</description></item><item><title>Plan and Prepare or Just Do It? How about Both!</title><link>http://sqlblog.com/blogs/buck_woody/archive/2010/01/07/plan-and-prepare-or-just-do-it-how-about-both.aspx</link><pubDate>Thu, 07 Jan 2010 15:56:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:20683</guid><dc:creator>BuckWoody</dc:creator><description>&lt;P&gt;I'm kind of a type "A" person. OK, I'm a VERY type "A" person. I even cook by setting things up ahead of time. I'm definitely more in the "Plan and Prepare" camp than the "Just Do It" camp. &lt;/P&gt;
&lt;P&gt;But I do realize that there are times when you just can't stop and prepare. Sure, it would be great to know that server is going to melt down just now, but it happened and you have to deal with it. Now is not the time to open the plastic on that "Troubleshooting SQL Server" DVD course you bought! You just have to dive in and get the thing fixed.&lt;/P&gt;
&lt;P&gt;Hopefully you're not operating like that all the time. If you are, you probably need to get some help with your systems, at least temporarily, until you can get them stabilized. &lt;/P&gt;
&lt;P&gt;&amp;nbsp;So which is it? Should you be like me, a type "A" who has to have everything planned out, or a reactionary agent, fixing things as they happen? How about - Both!&lt;/P&gt;
&lt;P&gt;I think you should aim to plan and prepare as much as you can. Your life will be more stress-free, and you'll be happier in your job. But you can't lose your head when things go wrong and demand time to plan and prepare. You just have to jump in there and fix the problem.&lt;/P&gt;
&lt;P&gt;But I think there's a happy medium in there somewhere. I ten to plan and prepare for the times I have to "just do it". I have my scripts ready for things like backups, DBCC repairs, restores, web site links for "how to" articles and so on. I have those right by my desk so that I don't have to panic when panic hits. So in effect, I'm doing both - I'm planning to just do it.&lt;/P&gt;</description></item></channel></rss>