Does TYPO3 automatically recover custom extension table schemas after a failed core upgrade?

Direct Answer

No. TYPO3 has no built-in mechanism that automatically detects, reverts, or repairs custom extension tables after a failed core upgrade. The database analyzer in the Install Tool only proposes SQL to bring the live schema forward to match currently installed extension definitions — it cannot infer a pre-upgrade state or undo partial migrations.

What Actually Happens

TYPO3 schema management is definition-driven. Core and each extension declare their tables in ext_tables.sql and TCA. During an upgrade, the Install Tool compares the live database against those declarations and emits CREATE, ALTER, DROP, or RENAME statements to align them. If the upgrade aborts mid-way, the analyzer still only knows the target definitions; it has no record of what the custom tables looked like before the migration started.

Third-party extensions may also create tables outside normal declarations, run custom update scripts, or carry data that the analyzer cannot validate. Structural drift detection is limited to missing tables, columns, indexes, or type mismatches — it does not catch semantic corruption, half-migrated rows, or extension-specific invariants. Note also that the premise of an automatic rollback-to-backup mechanism should be verified for your specific deployment; do not assume one exists unless you configured it.

Available Options and Their Reliability

• Install Tool Database Analyzer — detects structural differences against current ext_tables.sql/TCA. Proposals can be additive, corrective, or destructive. Reliability: low for recovery; review every statement before execution, especially drops and type changes.
• Extension Upgrade Wizards — some extensions ship wizards that migrate their own data. They run forward only and assume a clean starting schema. Reliability: medium if the wizard exists and the table structure matches its expectations; unsafe if a prior attempt partially migrated data.
• Manual Comparison — export SHOW CREATE TABLE for each custom table, diff against the extension's ext_tables.sql and TCA, then hand-craft corrective SQL. Reliability: high for schema alignment but labor-intensive and cannot restore lost data.

Practical Recovery Path

1. Confirm a pre-upgrade database dump exists and restores cleanly in an isolated instance.
2. On that restored copy, run the full upgrade sequence again (core migrations first, then extension upgrade wizards).
3. After a successful upgrade, run the database analyzer to catch any remaining drift.
4. If no backup exists, work on a copy of the failed site: run the analyzer, compare output with each extension's declared schema, and decide table-by-table whether to accept analyzer proposals, run extension wizards, or manually correct.

One Diagnostic Detail That Changes the Recommendation

Does a verified, restorable pre-upgrade database dump exist? If yes, restore and re-run — that is the only reliable path. If no, you are in manual repair territory: record the exact core version, database platform, extension versions, and the first failing wizard step, then engage the extension maintainers for guidance on their specific tables.