Recover deleted, dropped and truncated data
Reverse inadvertent or malicious database changes
Rollback or replay any DDL or DML change
Recover deleted data and files from SharePoint
Extract data directly from backup files
Extract BLOBs stored as files
Recover deleted BLOBs
Isolate specific SQL Server operations

Deleted data recovery
Recover data lost due to DELETE operations.

It is not that uncommon to find yourself in a situation when some inadvertent delete operations have deleted important data from a SQL Server database. The highest priority in these situations is to discover what exactly was deleted and how to get the deleted data back as quickly as possible. In this article, we are going to show you how to quickly recover data lost due to inadvertent delete operation using ApexSQL Log and ApexSQL Recover tools. Even though both tools generate the same output, a recovery script which rollbacks unintended deletes, the mechanisms used by them to acquire recovery information and create rollback script are quite different, so if the recovery with one tool doesn’t help, the other tool may.

Truncated data recovery
Recover data lost due to TRUNCATE operations.

In order to maximize chances for recovery, the time period between the incident and the recovery attempt needs to be minimized. A TRUNCATE TABLE operation deallocates (marks as available for use/overwrite) the data pages with the existing data, but leaves the actual row data intact. ApexSQL Recover scrapes these deallocated pages for lost data and recovers it from them. However, deallocated pages can be reused by SQL Server at any time, and as the time passes, the chances that SQL Server will overwrite these data pages with new data increase, decreasing the chances for successful recovery thereby. Performing a full database backup after the incident doesn’t ensure a successful data recovery.

Dropped data recovery
Recover data lost due to DROP operations.

In case of lost data due to a DROP TABLE operation scenario:

If possible, take the database offline, or set it to the read-only state, and copy the data and transaction log files to a safe location. Because post incident activities can overwrite information necessary for lost data recovery this is highly recommended. You can bring it back online after copying the data and or log files. If you cannot do this, the information necessary for recovery may be overwritten and recovery success rate reduced.
Attach the copies of the database and transaction log file as a new database.

Perform the recovery process against the newly attached database copy.

Table schema restore
Recover dropped table schemas.

An accidentally dropped table may be recovered in several ways. The choice of technique depends on the resources available for the recovery. The first choice is usually a database backup. But, even if the one doesn’t exist, the dropped table may still be recovered (in some cases even quicker than with a backup).

DML and DDL changes roll back
Reverse inadvertent or malicious database changes to repair affected schema and data. Recover from specific loss/damage without relying on full database restores. Create undo scripts for specific operations to rollback data and schema to its original state

DML and DDL changes roll forward
Replay DML and DDL changes made to the database. Create redo scripts and execute them against databases to repeat operations originally executed

Direct-to-database recovery
Recover data directly to a database. Recover lost tables directly to a database. Including tables containing calculated columns or tables with missing schema and user defined data type definition

Multiple data source types support
Recover from live databases and transaction logs, detached database and transaction log files as well as native or compressed transaction logs and database backups.

Only for V.i.P