Many SQL Server DBAs are from time to time confronted with a disaster caused by unintentional or malicious changes on their database. Whatever the nature or intention of these changes are, they can cause great issues whether it was the data loss or a structure loss. With this in mind, it is important to start with the recovery process as soon as possible. Having a recovery scenario and solution for these situations prepared is also a great benefit, and is generally advised where possible. Whatever enhances our chance to recover in case of a disaster, and increases chances of successful and full recovery should be taken without any second thoughts. In this blog post we will learn about Database Disaster Recovery Process.
Before actually focusing on the actual recovery process, let alone the solution, it is important to always take post-disaster steps in order to ensure that the post-disaster database state is kept as it is, to avoid overwriting any information in the .mdf and .ldf files so that they can be used in a ‘pristine’ state when performing a recovery. So, when possible, immediately after the disaster is detected, take the database offline (again, where possible) and make copies of current .ldf and .mdf files, then bring the database back online to minimize downtime. In the situations where taking a database offline is not an option, you can opt to switch the database to the read-only mode to prevent any overwriting. To do this, simply access the database context menu in the SQL Server Management Studio and choose Properties and the Options and finally change the value of Database Read-Only to True – this will prevent anyone from writing into the database and ensure current information/data is preserved. Do not forget to take the database out of the read-only state for the recovery and afterwards.
Now that we have a solution for the post-recovery steps which are one of the most critical steps to take once the disaster strikes, we need a quick and easy solution to perform the actual recovery. ApexSQL Recover is a SQL Server recovery tool from ApexSQL which is used to recover database data and structure lost due to delete, drop or truncate operations, as well as to recover deleted BLOBs. In addition to the general recovery tasks, ApexSQL Recover also enables users to access database backup files directly and to extract blobs or table structure and data only for specific tables without the need to restore those backups on the SQL Server, which can save many hours in some cases. All SQL Server versions from SQL Server 2005 onwards are fully supported, as well as the all different variations (developer, enterprise, express…)
ApexSQL Recover can be installed directly on the machine which hosts the SQL Server where the database which needs recovery resides on. The other option is to install the tool on a workstation and to access SQL Server remotely. In case of remote access, server-side components need to be installed on the remote machine which hosts SQL Server instance user will access. These server-side components are just windows service which allows the tool to access the online transaction log file remotely – nothing is installed on the SQL Server itself.
Once ApexSQL Recover is installed, and the application started, user is faced with a simple interface which offers several recovery scenarios. Here, user should choose the most appropriate option, depending on the nature of their recovery request, and choose between recovering from delete, drop or truncate operation, to recover deleted blobs, or to perform extraction from the database backup.
When the recovery type is chosen (e.g. recover dropped table), the first task for the user is to specify the SQL Server instance, authentication method and credentials, and to finally choose the database on which the recovery will be performed.
The next step of the wizard offers a choice for the user to add sources which ApexSQL Recover will use for the recovery, specifically additional transaction log files and backups. The ‘No additional transaction logs are available’ option should be chosen if all the information is still included in the online transaction log file. The ‘Add transaction logs’ option should be chosen if the transaction log backup was created since the drop table operation has occurred. The ‘Help me decide’ option will lead the user through a quick series of yes/no questions to help them choose the best option and provide full recovery sources available.
Regardless of the previous step choice, the next step of the wizard is a filter step. Here, user can specify when the data was lost in order to focus recovery only on a specific time frame. The smaller the time frame, the faster recovery time will be. Also, by limiting the recovery process to the exact time frame will also exclude false-positive results (e.g. other dropped tables that user doesn’t want to recover, or similar).
Once the filters are set, the next step of the wizard offers users a choice for the recovery output. Recovered data can be directly exported into new database, so user can access that database via SQL Server Management Studio and check the database on site, or the recovery results can be written into the SQL Server script, which can be then inspected and finally executed against the database to recover dropped structure/data.
Finally, the user gets to specify what he actually wants to recover. The choice is between structure, data, or both together.
Once this choice is made, ApexSQL Recover will start the recovery process and create specified output. Once the process completes, application will show quick summary of the recovery process, and allow users to access recovery script directly from there.
As can be seen in the example above, ApexSQL Recover has recovered 2 dropped objects with 32 rows inside. A closer inspection of the script will show that one system and one user table were dropped, and that the script contains full information to completely recover dropped structure as well as the dropped data.
Extraction of data from database backups is even simpler task. Once the export wizard is started, the user is only required to add backup file from which to extract and to check it.
Then, select table(s) from which to extract, and similar to the previous recovery process, choose whether to create a script with the export results, or to write them into the new database. Finally, the same choice to export data, structure or both needs to be made, and once this is done, application will perform the exporting.
In summary:
- ApexSQL Recover is a recovery tool with capable of using information in the .mdf and .ldf files to recover the lost data.
- To ensure you maximize recovery chances, do every step possible to prevent overwriting of the database .mdf and .ldf files (offline mode, file copies)
- The tool can be used to create recovery scripts or to perform a recovery directly into a database when recovering from delete, truncate or drop operations, as well as the recovery of dropped blobs
- Application can extract blobs or table data and structure directly from database backups which nullifies the need for long and performance intensive database restore jobs
Reference: Pinal Dave (http://blog.sqlauthority.com)
First appeared on SQL SERVER – Database Disaster Recovery Process