I ran into a major issue on my dev box the other night. It was such a weird issue, I ran for the hills and waited for it to fix itself. That almost never works, so I dug in. What’s a bit of work without getting your hands dirty, eh?
The issue with my box was an update. I’m almost 99% sure it was an update, but I couldn’t pin it on one and since it’s a box running in Hyper-V, I decided to take the easy route. I constantly make backups of my content database. That is key, without these precious backups, I would have lost all of my work. Since I take snapshots of this server regularly, I figured the most effective time-saver was to use my latest snapshot. It was only a week old and I know I wasn’t suffering from my problem at that point.
The recovery went well and SharePoint snapped right open. So far, so good. I’ve never had to recover a full content database before, so this was new territory for me. Not to worry, I have good backups. A quick google search landed me on Stefan Keir Gordon’s blog. This specific post talks about moving the DB to a new server, it was exactly what I needed. I tweaked it just a bit by taking the Content DB offline first. After a reboot, I ran a Recover Database operation. You just simply point to the .bak from your backups and then pick the Content DB. This all took about 10 mins (My site is rather small).
What Have I Learned?
That’s what it’s all about right? Before this issue, I have been manually running them every week or so. Dropping off the bits to my file server here which is on a RAID 5. Plenty enough redundancy for my tiny operation… Now I’ve realized, the weeks’ worth of work that I lost was a big loss to me. Because of that, I now have my backups scheduled to run every day. It’s not talked about enough in my book: We all should review backup strategies every 3 mos. or so and re-evaluate what’s mission critical and what isn’t. It can literally save lots of time and money.
No comments:
Post a Comment