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!