
Database Repair Service
Database won't open? Corrupt MDF? Crashed tables? Don't run repair commands blindly — we specialise in database rescue. No recovery, no fee.
A database is a company's brain — customer records, orders, inventory, all inside. When it fails, it's not an IT problem, it's business stoppage. CentralComputer.hk specialises in database corruption of all kinds — from an SME's MySQL webshop to a corporation's SQL Server ERP.
Supported Databases
Database Types We Support
Our Services
What Our Database Rescue Covers
Corrupt Database Repair
MDF won't attach, MySQL tables crashed, PostgreSQL reporting corruption — we analyse file structures directly and rescue table by table, record by record. We don't just tell you to restore from backup.
MDF / LDF File Repair
Corrupt SQL Server MDF, missing LDF, database stuck in SUSPECT mode? We have specialised tools and manual workflows — we've even rescued orphaned MDF files with no log file at all.
Backup Restoration & Verification
Have a backup that won't restore? Extremely common — backups go bad silently. We verify backup integrity, restore to a test environment first, and only go to production once confirmed working.
Emergency On-Site Support
A database is a company's lifeblood — every minute down costs money. We offer emergency on-site support; we once rescued a retail chain's POS database within two hours of their till system dying.
Process
Our 4-Step Database Rescue Process
Stop Writes, Preserve State
When a database fails: stop the application, halt all writes. Copy the MDF, LDF and backup files somewhere safe first — all subsequent work happens on the copies.
Free Damage Assessment
We analyse the location and extent of damage: page-level corruption, broken indexes, or structural failure? We assess which tables are salvageable and give you an honest success rate.
Table-by-Table Rescue
Specialised tools extract data table by table, skipping corrupt pages, salvaging everything possible. The whole process is logged so you can see exactly what was done.
Rebuild, Verify & Prevent
Recovered data is imported into a fresh database for your table-by-table verification. Then we set up automated backups and integrity checks so it never happens again.
Case Study
Real Customer Case
A trading firm in Central had their SQL Server go SUSPECT after a typhoon-night power cut — inside were all the company's orders and receivables. Their IT vendor said restore last week's backup, meaning a whole week of transactions lost. The boss wouldn't accept that and called us.
We went on-site, copied the files out, and found only the first few MDF pages damaged — over 90% of data pages were fine. Two days of table-by-table extraction recovered 98% of order data, including that morning's entries. The boss bought us dinner and moved his entire company's IT support to us.
— Owner of a Central trading firm (anonymised on request)
FAQ
Frequently Asked Questions
No — SUSPECT is common, usually a damaged MDF header or missing LDF. Our standard flow: copy everything first, assess with DBCC CHECKDB, and we've recovered 90%+ many times. One client's ERP database went SUSPECT; vendor support said restore a 3-day-old backup, but we recovered that day's data so they didn't have to re-enter three days of transactions. And never run REPAIR_ALLOW_DATA_LOSS yourself — it deletes data.
MyISAM crashes are classic and usually fixable with REPAIR TABLE, but InnoDB corruption is trickier. We read ibdata files directly to extract data, and can even rebuild table definitions from data-dictionary fragments. We once rescued an online shop's entire MySQL — all order records — the owner said he'd nearly had to ask every customer for their orders again.
Often yes. ATTACH_REBUILD_LOG can rebuild the log, though some transactions may be lost. If the MDF structure itself is intact, tables recover fine. We once rescued an entire database for a client from just an MDF copied off an old server — they'd assumed a full backup set was required.
It depends on database size and damage. A few GB typically takes 1–3 days; a multi-hundred-GB database can take a week since scanning alone is slow. Urgent cases get priority — we once rescued a restaurant group's membership system before dinner service so they could take payments.
Technically, rescuing data unavoidably exposes content. But we're strict: all engineers sign NDAs, work machines are air-gapped, and temporary files are securely destroyed afterwards. We've handled banks, clinics and law firms without incident. You can also require all work to be done on-site at your office — disks never leave.
Database Down? Don't Guess Commands
Wrong repair commands permanently delete data. Stop writes first, then contact us for a free assessment.