1C Enterprise Database Recovery
AS provides 1C Enterprise database recovery for both file-based and client-server infobases — reading the underlying data directly rather than relying on 1C's own repair tools alone, which can discard data that a file-level recovery could have retrieved.
When you need this
- File-based infobase (.1CD) reports the format is not supported, or won't open
- 1C:Enterprise database corruption after an unclean shutdown or storage fault
- chdbfl.exe (Test and Repair) reports errors it can't fix, or removes data in the process
- SQL Server-backed 1C infobase in SUSPECT or RECOVERY_PENDING state
- DT (combined data and configuration dump) file corrupted or won't restore
- 1C:Enterprise database encrypted by ransomware
- Infobase blocked or locked after a failed platform update
- Configuration (.cf/.cfu) mismatch preventing the infobase from opening
- Documents or catalog entries deleted without a usable 1C backup
- Production 1C database down and emergency recovery needed
What we do
File-based infobase recovery
The .1CD file is parsed directly at the table level, independent of the 1C platform, to extract tables, documents and catalogs from an infobase that won't open or attach.
Beyond chdbfl.exe
1C's own Test and Repair tool fixes minor inconsistencies, but on serious corruption it can delete the affected data rather than recovering it. We assess the raw file first, since a file-level recovery can retrieve data that chdbfl.exe would simply discard.
SQL Server-backed infobase recovery
Client-server 1C infobases store their data in a SQL Server database — the same page-level, file-based recovery techniques used for SQL Server recovery apply, alongside 1C's own configuration and metadata tables.
DT dump recovery
Damaged .dt files are analysed for the recoverable portion, rather than assuming the whole export is unusable.
Configuration recovery
Where a .cf/.cfu mismatch or lost configuration is blocking access, the underlying data is recovered independently of the configuration, and reattached to a working configuration where possible.
Partial-encryption cases
Like other large database files, a 1CD file hit by ransomware often has significant unencrypted content still intact — we assess how much survives before assuming a total loss.
A file-based .1CD infobase (or the SQL Server database behind a client-server infobase) is made of fixed-size pages — a damaged or unreadable page doesn't make the rest of the file unreadable.
How it works
- Step 1
Consultation and scope
We establish what failed, what has been tried, and which data matters most. This shapes a targeted plan rather than a generic one.
- Step 2
Secure imaging and diagnosis
Where possible the source media is imaged before any work, so the original is never altered. Diagnosis then determines the safest recovery method.
- Step 3
Recovery
Data is extracted from the image or source using methods matched to the failure — logical, structural or hardware-level as required.
- Step 4
Verification
Recovered data is checked for integrity and completeness, and a file list is shared so you can confirm what matters is there.
- Step 5
Secure delivery
Verified data is returned through an agreed secure method, with guidance on validation before it goes back into production.
What affects the outcome
Outcomes are never guaranteed. Every case is assessed on its own condition, and we tell you what is realistic before you commit.
- Physical condition of the media and the extent of any damage
- Whether the media has been written to, reformatted or re-initialised since the failure
- Encryption, corruption or partial overwriting of the data
- Availability of source data such as images, backups, logs or transaction records
- Attempts made before assessment (rebuilds, repair tools, repeated reboots)
Frequently asked questions
chdbfl.exe found errors and "fixed" them, but now data is missing — can it be recovered?
Often, yes, provided the original file (or an image taken before running it) still exists. Test and Repair fixes structural inconsistencies by removing what it can't reconcile, which can discard recoverable data. Working from a copy of the file it modified, we can often recover what was removed.
Do you need the 1C platform installed to recover our data?
No. File-based infobases are read directly at the file level, and SQL Server-backed infobases are read the same way as any other SQL Server database, independent of a running 1C platform installation.
Our 1C database is on SQL Server — is this the same as SQL Server recovery?
Largely, yes, at the data-file level — the underlying storage engine is SQL Server. 1C adds its own configuration and metadata layer on top, which we also account for so the recovered data reattaches to a working infobase.
We only have a .dt export, not the live infobase — can that be recovered if it's damaged?
Often, yes. A DT file is analysed for the portion that's structurally intact rather than requiring the whole export to be valid.
Ransomware encrypted our 1C server — is the infobase a lost cause?
Not automatically. A 1CD file or SQL Server data file is exactly the kind of large file many ransomware variants only partially encrypt for speed — we assess how much is genuinely intact before assuming total loss.
Related services
Not sure what you're dealing with?
Describe the situation and we'll tell you what's realistic.