SQL Server Backup and Restore - Simple Talk

Chapter 4: Restoring From Full Backup
Don't let these issues dissuade you from performing full restores as and when necessary.
Diligence is a great trait in a DBA, especially in regard to security. If you apply this
diligence, keeping a keen eye out when restoring databases between mismatched environments,
or when dealing with highly sensitive data of any kind, then you'll be fine.
Performing Full Restores
We are now ready to jump in and start restoring databases! This chapter will mimic the
structure of Chapter 3, in that we'll first perform a full restore the "GUI way," in SSMS,
and then by using native T-SQL RESTORE commands. In Chapter 8, we'll perform full
restores using the Red Gate SQL Backup tool.
Native SSMS GUI full backup restore
Using the SSMS GUI, we're going to restore the first of the two full backups (Database-
ForFullBackups_Full_Native_1.bak) that we took in Chapter 3, which was taken
when the database contained about 500 MB of data. First, however, we need to decide
whether we are going to restore this file over the current "live" version of the Database-
ForFullBackups database, or simply create a new database. In this case, we are going
to restore over the existing database, which is a common requirement when, for example,
providing a weekly refresh of a development database.
But wait, you might be thinking, the current version of DatabaseForFullBackups
contains about 1 GB of data. If we do this, aren't we going to lose half that data? Indeed
we are, but rest assured that all of those precious rows of data are safe in our second full
database backup file, and we'll be bringing that data backup to life later in this chapter.
So, go ahead and start SSMS, connect to your test instance, and then expand the
databases tree menu as shown in Figure 4-1.
122