By default, a database is restored in the same location from where it was backed up and the existing database files are overwritten. This restore leaves the database in an online state. Follow the steps given below to restore a database:
By default, a database is left in the online state after a restore. However, you might need to change the state of the database depending on your needs (e.g., if you want to make the database inaccessible to the users). By recovering a database, you can select the state in which the database is to be left. Follow the steps given below to recover a database:
If you want the database to be offline after the restore, follow the steps given below:
If you want the database to be in a read-only state after the restore, follow the steps given below:
If you have a database in the offline or standby state and you want to bring the database back to the online state, follow the steps given below:
System databases are essential for the operation of the SQL server instance. If you need to restore the SQL Server in the event of a system failure, the system databases (master, msdb and model) must be backed up. The tempdb does not get backed up as it is re-created by the SQL Server every time the server is started.
By default, system databases are restored in the same location from where they were backed up and their data files are overwritten. Follow the steps given below to restore the system databases:
By default, files or filegroups are restored in the same location from where they were backed up. File/Filegroup restores give you the ability to bring back the files that have been damaged in the event of a failure. You can restore specific files and filegroups from both:
During a File/Filegroup restore job, the system restores the latest full and differential backups and then uses the transaction log backups up to the specified restore time. Hence, transaction logs are needed to successfully restore files or filegroups as it determines the end time of the restore. For more information, see Transaction Log Backups.
File/Filegroup restores are commonly used for situations in which individual data files on a database are damaged.
For a single data file, the file/file group restore chain consists of the most recent full backup, the most recent differential (if any), and all subsequent transaction log backups that occurred prior to the restore time. However, for multiple files or file groups, the same rules apply for each data file, and the log backups to be restored will be determined by the file requiring the oldest log.
Follow the steps below to restore one or more files or filegroups from a database:
|
![]() |
You can restore a database in its entirety by restoring all the filegroups within the database. Follow the steps below to restore the entire database at the File/filegroup level:
|
![]() |
If the size of a filegroup in a database is large, the restore operation may take considerable time. In such case, you can restore the database in stages.
Partial restores also known as Piecemeal Restore in SQL Server versions 2005 and later allows you to restore a database in stages.
Follow the steps given below to restore a database in stages at filegroup level:
After performing a partial (piecemeal) restore job, the next backup job for that database is automatically converted to a full backup. |
![]() |
When you want to restore an event in the database but do not know the exact
time of the event, you can first restore the database in the standby state and
apply transaction logs to the database. The Step Restore enables you to append
the logs to such a database. (Both Incremental or Transaction Log backups can be
applied.) Use the following procedure to apply the log backups one by one to
scan through the changes that have been committed between each log backup. This
way you can avoid performing multiple full restores when you are not sure of the
point of restore required.
Step Restores can be performed on individual databases.
Follow the steps given below to apply the logs to a database in the standby state:
If required, you can apply logs from other Log backups by selecting a different Log backup from the Restore Time list. |
![]() |
This option enables you to apply all the latest transaction logs to a hot standby sever. The hot standby server is the server where you can restore a latest backup data periodically. Follow the steps given below to restore only the logs that are backed on a specific time:
The Transaction Logs, backed up on the selected time will be restored and applied to the database. |
![]() |
If any undesired transaction occurs in the database, you can revert the database to a state just before the transaction. The point in time option enables you to restore the database to a specific point-in-time. This option is useful in the following scenarios:
Before performing the point-in-time restore of a database, ensure that transaction logs for the database are backed up. Follow the steps given below to restore a database(s) to a point in time:
The database(s) will be restored to the selected date and time. When you perform a point-in-time restore for a database, the next scheduled backup for that database will automatically convert to a Full backup. |
![]() |
If you are using any third-party software to backup and restore the databases, you can use SQL Server iDataAgent to restore only the logs. The database for which you are restoring logs must be in the standby state. Follow the steps given below to restore logs for a database:
The most recent log backup before the Restore Time will be restored and applied to the database. |
![]() |
You can restore directly to the marked transaction or a point before the transaction if the Transaction logs of the database has transaction marks.
This can be useful in situations where a transaction has caused undesirable results on a database and you need to go back to the point before that occurred.
Before performing the restore, ensure that transaction logs are backed up for the database that you want to restore to a transaction mark.
Follow the steps given below to restore a database(s) to a transaction mark:
After performing a transaction mark restore job, the next backup job for that database is automatically converted to a full backup. |
![]() |
This option is used to restore the database in a state where only the owner of the database can access the database.
Follow the steps given below to restore the database for the Database Owner (DBO_ONLY state):
After the database is restored, only the owner of the database can access the database. |
![]() |
You can preserve all the replication settings of a published database when you perform an out-of-place restore of a database. This options is used to restore backups of replicated databases. Only full backups are supported with this option, so make sure that you have performed at least one Full backup before restoring the database with replication settings. Follow the steps given below to preserve the replication settings:
After the restore has completed, all the replication settings of the database are available on the destination server. If the publication database is restored, ensure that the replication settings of the master and msdb databases on the Distributor and Subscriber servers are consistent with the publication database. For more information, see Backing Up and Restoring Replication Databases. |
![]() |
The SQL Server 2008 has an option to capture the changed data. If you have enabled this option, the changed data (insert, update, and delete) is captured and applied to SQL tables. The details of the changes are available in an easily applicable relational format. You can restore the captured changes and apply them to the restored database. You cannot restore the captured changes if you are using VSS enabled backup for restore.
Follow the steps given below to restore the captured data:
After the restore has completed, all the data changes are available and applied to the restored database. |
![]() |
The VDI (Virtual Device Interface) is an API used to communicate with the SQL Server during all backup and restore operation. When restoring a database, the VDI timeout represents the time the system must wait for the SQL server to become ready to accept data into the database. If any databases are dropped from the SQL Server after the backup, the database file(s) do not exist on the sever. Before starting the restore operation, these files will be created automatically on the SQL Server. The time required to create the file(s) will be the same as when you first created the database or altered the database and added the file(s).
By default, the system will wait 50 minutes (10 retries of five minutes each) for the SQL server to respond to a VDI command before giving up. If the SQL server takes longer then this timeout value, the system assumes that the command failed, and it aborts the restore operation.
Follow the steps given below to increase the VDI Timeout for a SQL Server instance.
|
![]() |
Use one of the methods below to restore a SQL database to a different location.
Follow the steps below to restore a database to a different location on the same destination server:
|
![]() |
By default, when restoring to a different SQL Server instance, a database is restored to the same location in the destination server. Follow the steps below to restore a database to a different destination server.
System databases cannot be restored to a different server as they would overwrite the existing system databases in the destination server.
|
![]() |
You can restore the database to a different location without changing its name. You cannot move a system database to a different location.
|
![]() |
If you perform a restore operation to move the database back to its original location, the database files will not be moved back as the database already exists on the server. The restore job will only check the database name and will restore the database on top of the same database regardless of its location. To move the database files back to the original location, use one of the following workarounds:
You can perform restores of one of more databases from the command line interface.
Command line restores enable you to perform restore operations on multiple clients at the same time. It also allows you to reuse the command line scripts for additional restores.
When performing command line restores, note that backups taken from the CommCell Console can be restored using Command Line and vice versa. However, backups taken from a previous version of the CommCell Console can be restored only from the Command Line.
In order to run the restores from command line, you need an input xml file which contains the parameters for configuring the restore options. This input xml file can be obtained using one of the following ways:
To run command line operations you must first login to the CommServe as follows:
qlogin -cs <commserve name> -u <user name>
qlogin -cs server1 -u user1
qoperation execute -af restore_template.xml -clientName xxxxx -instanceName xxxxx -toTimeValue yyyy-mm-dd hh:mm:ss -restoreSource xxxxx -database xxxxx
qlist job –j JOBID
qlogout [-cs commserver] [-all] [-tf tokenfile] [-tk token] [-h]
<device>|DB1|#12!DB1_rename|#12!DB1|#12!E:\RestoreLocation\DB1.mdf|#12!C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\DB1.mdf</device>
<device>|DB1|#12!DB1_rename|#12!DB1_log|#12!E:\RestoreLocation\DB1_log.ldf|#12!C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\DB1_log.ldf</device>
Where:qoperation execute –af out_of_Place_restore_template.xml -clientName xxxxx -instanceName xxxxx -restoreSource xxxxx -database xxxxx -toTimeValue yyyy-mm-dd hh:mm:ss
qlist job –j JOBID
qlogout [-cs commserver] [-all] [-tf tokenfile] [-tk token] [-h]
<device>|DB1|#12!DB1_rename|#12!DB1|#12!E:\RestoreLocation\DB1.mdf|#12!C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\DB1.mdf</device>
<device>|DB1|#12!DB1_rename|#12!DB1_log|#12!E:\RestoreLocation\DB1_log.ldf|#12!C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\DB1_log.ldf</device>
Where:qoperation execute -af out_of_Place_restore_template.xml -clientName client1 -instanceName client1\instance1 -restoreSource DB1 -database DB1 -toTimeValue yyyy-mm-dd hh:mm:ss -destClient/clientName client2 -destinationInstance/clientName client2 -destinationInstance/instanceName client2\instance2
qlist job –j JOBID
qlogout [-cs commserver] [-all] [-tf tokenfile] [-tk token] [-h]
Restoring from a Current Backup |
qoperation execute -af restore_template.xml -clientName client1 -instanceName client1\instance1 -restoreSource DB1 -database DB2 –toTimeValue 2011-11-28 15:40:00 |
Restoring Databases to a Point in Time (date and time) |
qoperation execute -af pit_restore_template.xml -clientName client1 -instanceName client1\instance1 -restoreSource DB1 -database DB2 –toTimeValue 2011-11-28 15:40:00 |
Restoring Database In Place in Standby Mode | qoperation execute -af standby_inplace_restore_template.xml -clientName client1 -instanceName client1\instance1 -restoreSource DB1 -database DB2 -toTimeValue 2011-11-28 15:40:00 -sqlRecoveryType STATE_STANDBY -renameFilesSuffix C:\UndoPath |
In addition to the parameters provided in the template xml file, if you want to include additional options for the restore, you can do so by selecting the required options from the CommCell Console and generate the command line xml script for the restore operation.
Follow the steps given below to generate a script which you can use to perform a restore from the command line interface:
|
![]() |
|
![]() |
Follow the steps given below to schedule a restore job:
1. |
|
![]() |
2. |
|
![]() |
3. |
Select the required restore options. Click OK.
|
![]() |
4. |
|
![]() |
5. |
Select the appropriate scheduling options. For example:
The restore job will execute as per the schedule. |
![]() |
See Scheduling for a comprehensive information on scheduling jobs.
|
![]() |
By default, a specified post process command is executed only on successful
completion of the restore operation.
Use the following steps to run a post process even if the restore operation did
not complete successfully. For example, this may be useful to bring a database
online or release a snapshot.
|
![]() |
Once you initiate the restore operation, a restore job is generated in the Job Controller. Jobs can be managed in a number of ways. See Job Management for a comprehensive information on managing jobs.
The following sections provide information on the different job management options available:
Jobs that fail to complete successfully are automatically restarted based on the job restartability configuration set in the Control Panel. Keep in mind that changes made to this configuration will affect all jobs in the entire CommCell.
To Configure the job restartability for a specific job, you can modify the retry settings for the job. This will override the setting in the Control Panel. It is also possible to override the default CommServe configuration for individual jobs by configuring retry settings when initiating the job. This configuration, however, will apply only to the specific job.
|
![]() |
The following controls are available for running jobs in the Job Controller window:
Suspend |
Temporarily stops a job. A suspended job is not terminated; it can be restarted at a later time. |
Resume |
Resumes a job and returns the status to Waiting, Pending, Queued, or Running. The status depends on the availability of resources, the state of the Operation Windows, or the Activity Control setting. |
Kill |
Terminates a job. |
Several additional options are available to further refine your restore operations. The following table describes these options, as well as the steps to implement them.
Be sure to read the overview material referenced for each feature prior to using them.
Option | Description | related topic |
Use hardware revert capability if available |
This option allow you to revert the data to the time when the snapshot was
created. Selecting this option brings back the entire LUN to the point when the
snapshot was created, overwriting all modifications to the data since the
snapshot creation. This option is only available if the storage array used for SnapProtect Backup supports the revert operation.
|
|
Startup Options |
The Startup Options are used by the Job Manager to set priority for resource allocation. This is useful to give higher priority to certain jobs. You can set the priority as follows:
|
Refer to Job Priority and Priority Precedence. |
Copy Precedence |
By default, the system retrieves data from the storage policy copy with
the lowest copy precedence. If the data was pruned from the primary
copy, the system automatically retrieves data from the other copies of
the storage policy in the lowest copy precedence to highest copy
precedence order. Once the data is found, it is retrieved, and no
further copies are checked. You can retrieve data from a specific storage policy copy (Synchronous Copy or Selective Copy). If data does not exist in the specified copy, the data retrieve operation fails even if the data exists in another copy of the same storage policy. Follow the steps given below to retrieve the data from a a specific storage policy copy:
|
Refer to Recovering Data From Copies. |
Data Path Options |
The data recovery operations use a default Library, MediaAgent, Drive Pool, and Drive as the Data Path. You can use this option to change the data path if the default data path is not available. Follow the steps given below to change the default data path:
|
Refer to Change Data Path. |
Encryption |
If the client's data is encrypted with a pass phrase, you must enter the pass-phrase to start the data recovery operation. Follow the steps given below to enter the pass-phrase:
|
Refer to Data Encryption. |
Alerts |
This option enables users or user groups to get automatic notification on the status of the data recovery job. Follow the steps given below to set up the criteria to raise notifications/alerts:
|
Refer to Alert. |
Command Line Restores |
Command Line Interface enables you to perform backups or restore from the command line. The
commands can be executed from the command line or can be integrated into scripts. You can also generate command line scripts for specific operations from the CommCell Browser using the Save As Script option. |
Refer to Command Line Interface. |
CommCell Readiness Report |
The CommCell Readiness Report provides you with vital information, such as
connectivity and readiness of the Client, MediaAgent and CommServe. It is useful
to run this report before performing the data protection or recovery job. Follow the steps
given below to generate the report:
|
Refer to CommCell Readiness Report. |
Restore Job Summary Report |
The Restore Job Summary Report provides you with information about all the data recovery jobs that are run in last 24 hours for a specific client and agent. You can get information such as failure reason, failed objects, job options etc. It is useful to run this report after performing the restore. Follow the steps given below to generate the report:
|
Refer to Restore Job Summary Report. |