How to perform data recovery on an SQL server

It isn’t just enterprise that uses SQL servers. Small to medium-sized businesses use them too. As do web developers, web hosts, eCommerce stores and anyone who wants to store lots of data in an organized way. If your server goes down but you have a backup, how can you restore it?

I’ll use SQL Server 2012 as an example as I have one here at Dave’s Computers in New Jersey. It isn’t the latest version but it is still widely used out there in the world. That makes it a prime candidate for our data recovery exercise.

Restore SQL Server 2012

If you use a database server then backups should be a part of life. There’s no point using a database to store and organize your data if you’re going to leave it exposed. If you have an offsite or viable network backup, you can restore SQL Server 2012 in no time at all.

Here’s how:

  1. Start the SQL Server Management Studio and connect to the instance you need to restore.
  2. Find Object Explorer and right click database.
  3. Select Restore Database to… and verify the source and destination database.
  4. Select either the Last Backup or Specific Date and Time.
  5. Select OK.
  6. Select Options from the left and select Restore Options.
  7. Select to Restore with Recovery.
  8. Select OK to begin the restore process.

The restore shouldn’t take long. Much depends on the speed of the connection, the size of the database and the speed of the servers in question.

You don’t have to choose Restore with Recovery if you don’t want to as you have three options.

  • Restore with Recovery is the default setting and will restore the database and drop any uncommitted transactions.
  • Restore with NoRecovery will restore the database but not bring it into production. If you need to perform more maintenance before making it live, choose this option.
  • Restore with Standby restores the database but leaves it as read only. It also creates a log file of any uncommitted transactions in case you need to catch up between time of backup and time of failure.

As long as you’re not trying to recover from database corruption, virus or malware or where the database became inaccessible for some reason, you should be up and running in no time. If you did suffer downtime for any of those three reasons, you should restore a backup to an isolated machine and not live so you can perform maintenance or security checks beforehand.

If you need help with databases, restoration, data recovery or backups, Dave’s Computers can help. Contact us to find out more!