Case studies

A law firm's 12-disk RAID array went offline after its RAID controller failed, taking the whole array down and putting the firm's case files and records out of reach.

Rather than attempting a rebuild through the same controller that had already failed, AS imaged the member disks individually and reconstructed the array virtually, working from the disks directly rather than depending on the failed hardware.

Most of the firm's data was recovered and returned, allowing the firm to get back to its case files.

An IT services company's SQL Server environment was hit by the TheGentleMan ransomware, which encrypted seven production databases — each backing a 1.4 TB MDF file, around 9.8 TB of data in total.

AS worked directly from the encrypted MDF files, recovering and repairing each database back to a consistent, working state — one at a time, at that scale.

All seven databases were fully recovered and repaired.

A healthcare technology company's SAP-on-Oracle environment was hit by the Akira ransomware, which encrypted the production database — its Oracle export (DMP) and datafiles, around 2.5 TB in total.

AS worked directly from the encrypted Oracle files, recovering and repairing the database back to a consistent, working state.

The database was fully recovered and repaired.

More on Akira ransomware recovery →

A medical education and research institute's SQL Server database was hit by ransomware, leaving the database inaccessible.

AS worked directly from the affected database files to recover and repair it back to a consistent, working state.

The database was fully recovered and repaired.

A customer's Veeam full backup of a server (.vbk, 43 GB, renamed .vbk.akira) would not open in Veeam. Measured directly, the first part of the file was encrypted: at least the first 64 MB, with the file header, both snapshot slots and the first metadata banks. The backup was compressed, so every data block carries its own checksum.

Newer Veeam backups keep further generations of their metadata tables deeper in the file, and in this backup they had survived about 42 GB in. AS VBK Recovery Studio found and read them, rebuilt the map of the virtual disk, and placed the tables whose index pages were lost by their content, guided by the NTFS file table inside the disk. The result was the server's 466 GB virtual disk with both volumes: C: (199 GB) and D: (266 GB, the data volume with accounting and database files). Of 142,624 data blocks, 140,143 were verified intact; 2,481 blocks (about 2.6 GB) were lost to the encryption.

The rebuilt disk was exported as a VHDX file. Windows mounted the D: volume read-only and reported it healthy; C:, whose system files lay partly in the encrypted region, is browsed and saved in the program itself. In a check with independent reader software, 354 of 412 sampled files opened correctly. Files that had blocks in the encrypted regions are damaged or missing: this is recovery of what Akira left, not decryption.

Akira ransomware recovery: what's recoverable →

A 27.3 GB SQL Server 2008 R2 database was encrypted by ransomware and renamed with the .M142HIMARS extension. SQL Server could not attach it. The "good" copy the customer still had turned out not to be clean: compared byte by byte, only its first page had been restored.

Measured page by page, the ransomware had encrypted every other 8 KB page in the first and the last 2.5 MB of the file and appended a 1,544-byte block — few pages, but exactly the ones holding the boot page, the allocation maps and the start of the system catalog. The data pages in between were intact.

Recovered directly from the file: 96.0 million rows from 222 tables in 23 minutes, with no row failing its checks. 179 tables came back complete — their row counts exactly equal to the counts in the database's own catalog. Tables whose definitions had been hit were rebuilt from the surviving metadata, and a 2018 copy of the same database identified 10 more (structure only, none of its data). Partial tables miss only the rows stored on encrypted pages (2 to 284 rows each). About 20 small tables could not be linked automatically and were left for manual mapping.

Can a ransomware-encrypted SQL Server database be recovered? →

In a LockBit 3.0 incident (identified from its ransom note and decryption ID), the customer had a few unencrypted copies of affected files. Comparing a 1.1 GB archive with its encrypted version byte by byte showed exactly what LockBit did to it.

It encrypted the first 15 MB, then 2.5 MB at a fixed interval of every 102.5 MB, and appended 266 bytes — the size of an RSA-2048 key block. In total only 3.76% of the file was encrypted; the other 96% was still exactly as written.

That does not make the file usable by itself — the encrypted start holds the parts a program reads first — but it shows how much real content is still there, and that the same measurement can be made from encrypted files alone. That measurement is the first step of every recovery we assess.

LockBit ransomware recovery →

A company's SQL Server 2019 ERP database backups (.bak, 10.5 GB) were encrypted by LockBit and renamed with a random extension. The backup header was destroyed, so SQL Server could not restore them, and the backup from the next day did not help: LockBit had encrypted the same places in both files.

AS SQL Recovery & Repair Studio opened the encrypted backup directly, found every surviving 8 KB page image by its checksum, and rebuilt the tables. The system catalog was partly lost, so a sister company's database with the same structure was used as the reference for table and column definitions (never for data). Result: 354 tables and 4,703,039 of 4,759,135 rows (98.8%), with no table mislabelled. The client also still had a healthy copy of the database, so every recovered row could be checked against it.

Ransomware-encrypted SQL Server database recovery →

An ERP system's Oracle Data Pump export (.dmp, 354 GB) had been renamed by ransomware with a .ftagic007 extension, and impdp refused it. Measured directly, only the first 128 MB of the file and a 96-byte block at its end were damaged; the rest was plain.

In a Data Pump export every table is stored as its own stream with a self-describing header, and the export's own catalogue sits at the end. AS Oracle Recovery Studio searched the file for those headers and found 8,132 table streams, exactly the 8,132 tables listed in the catalogue. Only one table had lost its header in the destroyed region; its rows are offered with column types worked out from the data. Every other table came back with its name, columns and rows.

Ransomware-encrypted Oracle database recovery →