Failed to recover a faulty Microsoft SQL Server database online

Recovery Toolbox for SQL Server may be able to recover your corrupted Microsoft SQL Server database.

Reasons for unsuccessful recovery of Microsoft SQL Server databases

Possible reasons why the online SQL Server database recovery service was unable to recover a corrupted Microsoft SQL Server MDF file:

1. The service did not receive an MDF file, but rather an LDF, BAK, or other type of file that had only been renamed.
2. Part of the database data was stored in additional NDF files, but only the main MDF file was uploaded to the online service. To recover MDF+NDF file pairs, you need to use Recovery Toolbox for SQL Server.
3. The MDF file was truncated during copying or uploading. Some data is physically missing at the end of the file.
4. The MDF file is almost filled with zeros or garbage due to a disk failure, and there is nothing left to recover.
5. Critical database service pages (boot page, GAM, SGAM, etc.) have been destroyed and cannot be reconstructed.
6. The system catalogue tables (list of tables, columns, and relationships) are so damaged that the data structure cannot be understood.
7. Most data pages in the MDF file have broken checksums and cannot be read, even in blocks.
8. Parts of the MDF file have been physically overwritten with other data — the same pages appear in several incompatible versions.
9. The database was encrypted using SQL Server (TDE), and the service does not have the encryption keys — the file is visible as a set of encrypted blocks.
10. The MDF file was encrypted by ransomware using strong cryptography; the service does not perform decryption, only structure analysis.
11. Before uploading, the MDF file was additionally encrypted or packed with a third-party program, and the encrypted version was sent to the service.
12. The MDF file is damaged at the file system level: there are bad sectors that always return an error or zeros when read.
13. During network upload, the MDF file was corrupted (broken packets, connection failure), and a damaged copy reached the server.
14. The file was partially uploaded (did not wait for the end, closed the tab) — the service only works with files that are fully uploaded to the service.
15. The user accidentally downloaded another file: an old MDF file without the necessary data, a test copy, an empty database, etc.
16. Between the test run and the paid attempt, the MDF file was damaged or overwritten again, and now the level of damage is higher.
17. Before using the service, DBCC CHECKDB was run with the REPAIR_ALLOW_DATA_LOSS parameter — the problematic data was irretrievably deleted from the MDF file.
18. SHRINK or other operations that rewrote pages were previously performed on the database; the old data has been physically erased and cannot be recovered.
19. The necessary records were deleted long ago (TRUNCATE operation performed), and the pages have already been used for new tables. The MDF file does not contain old versions of the data.
20. The user expected to restore the intermediate state 'as of yesterday,' but the MDF only stores the current state without the necessary old data.
21. The streaming files associated with the database (FILESTREAM, FileTable, etc.) are missing, so it is impossible to recover data from them.
22. The table structure is damaged in such a way that the same pages refer to different objects, and it is impossible to assemble the tables unambiguously.
23. There is too much cross-damage to indexes and data — the risk of assembling an incorrect database is higher than is acceptable for an automated service.
24. The integrity of the reference structure (foreign keys, cascading relationships) in the tables is so compromised that it is impossible to recover a consistent set of data.
25. The file contains a serious logical inconsistency: the sizes of objects specified in the headers do not match the actual pages.
26. The MDF file contains fragments from several different databases (sequential reuse of the file), and the service cannot separate them correctly.
27. There was not enough space on the disk from which the MDF was copied; as a result, part of the file was not saved and was sent to the service in a truncated form.
28. The MDF file was restored from an image/backup with errors and was already damaged before being uploaded to the service.
29. Antivirus or Windows Defender on the client side damaged the file during copying (for example, cut out suspicious sections).
30. The database uses a non-standard page/block size or experimental settings that are not supported by the analysis mechanism.
31. The tables store a highly non-standard binary data format that cannot be interpreted correctly without user logic.
32. At the time of the failure, the SQL server was in the middle of a heavy operation (mass UPDATE/INDEX REBUILD), and it was not possible to logically complete it based on the traces in the MDF.
33. After recovery, the database structure was successfully reassembled, but the amount of data that could actually be recovered was practically zero — the service reports that recovery is not feasible.
34. The file shows signs of external interference (manual hex editing, 'repair' with unknown utilities) that violated the expected format.
35. The MDF file belongs to a database that was never fully initialised (creation was interrupted) — there is no complete structure inside for recovery.
36. The file belongs to a mirror/replica or snapshot that was created/deleted with an error, and some of the necessary pages are missing.
37. The database is severely damaged after a failed migration/upgrade of SQL Server, and the MDF file contains a mixture of old and new format structures.
38. The data in the service user tables (e.g., schema data) is critically damaged, without which the service cannot recover the remaining objects.
39. The service was able to extract only some of the tables, but the table with the data needed by the user is completely damaged; in the report, this appears as 'file cannot be repaired.'
40. The file was created by other software and only imitated the MDF format, so the online service correctly determined that it was an invalid SQL Server database.
41. There are security/storage policy restrictions on the server side (for example, a ban on processing files with certain types of encryption), which caused the analysis to be forcibly interrupted.