SQL SERVER – How to Recover Truncated or Deleted Data When a Database Backup is or is not Available

Recovering lost data that was deleted or truncated can be fairly quick and easy, depending on the environment in which the database resides, recovery measures implemented before and after the data loss has occurred, and the tools used for the job. In this blog post we will learn about how to recover truncated or deleted data when a database is (or not) available.

In general, there are three specific scenarios for recovery when the data is lost:

Scenario #1

Full backup has been created before the unintended delete/truncate operations have occurred, and no additional database changes have been performed since. This is by far the easiest data loss to solve, since it can be recovered with the simple restoration of the full database backup, since it will bring the database to the pre-disaster state, and since no additional changes have occurred, the recovery process will be fully valid and completed with the simple restore.

Scenario #2

Same as in the first scenario, the full database backup has been created prior to the deletes/truncates, but these were followed by the additional changes which need to be preserved. If we would restore the full database backup as in the first case, we would lose all of these additional changes, so another solution should be implemented. The most obvious solution is to restore our full database backup as a different database, and then to extract the tables affected by truncate/delete operations, and to import them into the original database.

Even though this solution is easy for smaller databases, in some environments, it is not possible to fully restore full database backups, due to the resources consumed (backup and database size, restoration time, restoration performance impact…). Logical solution here would be to extract those tables for recovery from the full database backup, but this cannot be done via SQL Server mechanisms, nor via SQL Server Management Studio.

In order to extract specific tables from a database backup, we can use ApexSQL Recover, a powerful recovery tool for Microsoft SQL Server which can recover data and structure lost due to delete, drop and truncate operations, recover deleted BLOBs, or extract BLOBs or specific tables directly from database backups without the need to restore them first.

To extract the tables:

1. Install ApexSQL Recover on your workstation (the tool can be used to perform recovery both locally or remotely, so it can be installed directly on the production server to locally complete the recovery/extraction, or it can be installed on the workstation of the user’s preference to remotely connect to the SQL Server and perform recovery from there)
2. Start ApexSQL Recover and choose the option to extract data from a database backup in the main ribbon
   
3. Add database backup file by clicking on the ‘Add file’ button and selecting your full database backup. If you have consecutive transaction log backups which need to be used for table extraction, add them in this step, and check them together with the full database backup
   
4. In the next wizard step, ApexSQL Recover will show the list of tables in the database/backup, and it is recommended to exclude all tables which are of no interest for recovery and to check only tables which were affected by the truncate/delete operations
   
5. In the next step of the wizard, between the choice of saving the recovery script to the .sql file and recovering to a new database, let’s opt for the first option, which enables us to inspect the recovery script, or to execute the recovery script against the production database to complete the recovery. We can also specify the script location.
   
6. In the final step, we should select the output type. Since we want to recover only data lost due to truncate/delete operations, choose the ‘Extract data only’ option and click next
   
7. After ApexSQL Recover completes processing, the application will inform the user on the recovery outcome, and users can now inspect the script directly from the application internal editor, or open it manually in a SQL Server Management studio or similar tool, from where it should be executed against the production database to complete the recovery process
   

Scenario #3

A different scenario, and by far the worst one, is when a disastrous truncate/delete occurs, followed by additional important transactions which we also do not want to lose, but there is no full database backup to use as the recovery source. Since we do not have a database backup, restoring it, or extracting table data with ApexSQL Recover is not an option.

Luckily, we can use ApexSQL Recover to perform the recovery of truncated/deleted data, since it does not require full database backup in the recovery process, but instead utilizes information in the LDF and MDF files to rollback unintended changes. With this in mind, knowing the internal mechanisms of the SQL Server itself, prior to engaging the actual recovery, due to the fact that SQL Server overwrites MDF file information frequently, it is important to ensure that the information within is kept safe, and not overwritten by the upcoming traffic.

In general, here are the immediate steps to take once the disaster is detected:

1. Change database mode to ‘Read only’ to prevent overwriting of the information in the MDF file
2. Take the database offline and make copies of database LDF and MDF files, then take the database back online – these copies can then be used to create additional copies of the database which can be used to read recovery information from, and enable the production database to continue to receive changes while the recovery process is prepared and performed.

Even though both of these measures will mean that your database will have some downtime, it is important to take these precautionary steps whenever possible to secure the highest change of successful recovery.

As said above, we’ll use ApexSQL Recover to connect to the database affected by unintended truncate/delete operations and generate a recovery script. Here is how:

1. Start ApexSQL Recover and choose to recover ‘Deleted data’ or ‘Truncated data’, depending on the operation which you need to recover from – the remaining steps of the wizard will be the same regardless of this choice
   
2. In the next step, provide the connection details to your SQL Server instance, provide connection credentials and choose the database for recovery
   
3. In the next step, we can go with any of the three options, depending on our case:
   1. ‘Help me decide’ option will guide the user through a quick series of questions in order to provide the most appropriate resources
   2. ‘Add transaction logs’ option should be used if we are creating transaction log backups so we can use them in addition to the MDF and LDF files as the recovery source
   3. ‘No additional transaction logs are available’ option should be chosen if our transaction log is not being backup-ed
      
4. Regardless of the choice in the previous step, once we proceed, we will arrive to the step which is used to determine the recovery window – a time frame which will be considered for the recovery. If we do have a knowledge of the time frame where a disaster has occurred, we should specify the time frame, as close as possible, which will result in faster processing, and in a more accurate recovery (additional delete/truncate operations may have occurred close to the disastrous once, so we will want to exclude those from the recovery process by using proper date/time filters)
   
5. The next step allows us to further filter-out the recovery and narrow it down to specific tables, so it is recommended to include only tables affected by disastrous truncates/deletes
   
6. Same as when we were extracting table information in the scenario #2, we will choose to create a recovery script, and once the processing is finished, our recovery script can be inspected and finally executed against the production database to complete the recovery process
   

Reference: Pinal Dave (http://blog.sqlauthority.com)

First appeared on SQL SERVER – How to Recover Truncated or Deleted Data When a Database Backup is or is not Available