Apparently the IT guy who liked to tell people how smart he was decided to rely on RAID as a backup for the database, but had automated backups of the web servers. He was apparently caught steeling from the company and wiped out the SQL database on his way out the door.
Apparently my suspicions were correct and it wasn’t a system problem, but a person who deleted the data.
Andrew Hart posted a note on how some of the users are able to get there data back using the Google cache. I tried using the Internet Wayback Machine but apparently JournalSpace.com was set to not allow it to be archived.
I would recommend to the owner of the site that the contact the local police department and file a report. While company employees can’t be held liable for stupidity, intentionally destroying the company we can be held liable for.
Denis Gobo posted an update as well, as I’m sure others did as well.
UPDATE: I forgot to include that I’m following the JournalSpace.com user on twitter so that I can keep abreast of new updates.
SECOND UPDATE: My horrible spelling was pointed out to me, so I’ve corrected this. Apparently Firefox didn’t pickup the spelling problems the first time around.
In case you live under a rock and haven’t heard about Journalspace.com‘s little mistake, they have gone out of business due to a database problem. Here’s a screenshot in case the site is down when you look at it.
In a nutshell it appears that they were relying on a RAID1 array as the database backup. While we see this all the time in small database shops as noted on /. this site has been up since 2002 and had an Alexa page rank of 106,881 with 14k monthly visitors (according to Quantcast). For a site so large to be making such a simple mistake is just unacceptable. Continued »
It’s been a while since I’ve posted about new articles that I’ve published. Over the next few weeks I’m going to see if I can’t remedy that, and get all caught up.
Over on SearchSQLServer.com I posted an article entitled “SQL Server virtualization pros and cons: Weigh the performance impact“.
If you have used SQL Server 2005 Express Edition (or SQL Server 2008 Express Edition) then you know that the SQL Agent has been removed from the product. I have from time to time found this to be annoying as I want to do things like backup my database on a regular basis, or do other basic things. The normal solution is to either use another SQL Server to do the scheduling, or use the Windows Task Scheduler to do the scheduling. Continued »
Have a happy New Year. Go spend the night with family.
That’s what I’m doing tonight.
I’ve been tagged by Denis Gobo for a New Years Resolution post. I’ve only got a couple of things to put, since I’m not a big fan of New Years resolutions.
Upgrade our production systems to SQL Server 2008
I’ve been speaking about SQL Server 2008 since before it was released. It would probably be nice if I actually upgraded our production systems at the office. It’s just a matter of time to actually get it done.
Get started writing a SQL book of my own
In 2008 I wrote a few chapters for a couple of books for other people. In 2009 I’ll attempt to write my own.
Back in November I wrote an article for Enterprise IT Planet entitled “Managing Multiple Databases on a Single Server” in which I go over the potential problems you can face when consolidating instances of SQL Server.
I’m often asked (both online and offline) once you have all your database backups, in what order to they need to be restored in?
I’ve actually asked this very question to senior level DBAs as an interview question before, and gotten some very interesting answers.
When restoring your database you start with your full backup, then restore your diffential backup (if you have taken one) then restore all the transaction log backups begining with the backup taken after the full (or differential) and going until the last transaction log backup available (or until you reach the point in time you want to stop the restore at).
My answer to that one is pretty easy. Let him / her. I’m a firm believer that every machine on the network should have anti-virus software installed. Most anti-virus software is pretty lightweight (especially compared to the amount of hardware that your SQL Server has), and if a virus did get onto the SQL Server the results could be awful.
So tonight I finely got around to patching the fourth VMware ESX 3.0.2 server to 3.5 Update 3.
The other 3 servers went just fine, quick reboot when done and back up and running in no time.
So experience said that the fourth one would be no problem…