MariaDB Recovery

This Q&A walks through a real MariaDB / InnoDB recovery case: a customer wanted to recover dropped databases on a server where multiple databases had been dropped. Below is the cleaned-up exchange with the operational notes that matter.

Q. If I have only the .ibd file, can DBRECOVER for MySQL retrieve the data? The free version showed some missing tables — does the paid version unlock more?

No. Buying a license does not change which tables are visible. The free version uses the same scan engine; the paid version only lifts the row-export limit. Always verify with the trial first that your tables are listed and that row previews look correct. If the table is not listed at all, paying does not bring it back.

Q. After a DROP DATABASE recovery, can I see every dropped database in the recovery folder?

Use the drop database scenario in DBRECOVER for MySQL. This mode scans ibdata1 for dictionary entries that survived the drop, plus the orphan pages on disk that still belong to the dropped tablespaces.

If a table is missing in this view, it means the drop-table metadata has already been purged from the dictionary in ibdata1. From that point on, you have to reconstruct the table by walking raw InnoDB pages.

Q. Can I roll back to a previous state to get the metadata back?

Only if you kept an older copy of ibdata1 (from a backup, an LVM snapshot, or a filesystem snapshot taken before the drop). Replace the current ibdata1 with the older one in the working copy and scan again. The older dictionary will identify the dropped tables.

If no older ibdata1 exists, you have to recognise every InnoDB page file by hand under the pages-<tablespace_id> directory that DBRECOVER produces.

Q. How do I recognise tables manually from the pages?

After a scan, DBRECOVER for MySQL splits the data into pages-XX directories grouped by index id. Open the directory in a hex/text viewer (Notepad++, Sublime Text, xxd, hexdump -C).
InnoDB pages contain printable substrings near the row payload: column values, VARCHAR contents, enum labels. Search for any unique string you remember from the table — a customer name, an error code, a known UUID, a unique product SKU.
Once a page file matches, treat it as a single-page tablespace and load it back into DBRECOVER for MySQL using the procedure in DBRECOVER for MySQL: read a single .ibd / page file. Important: load it as a page file, not as an .ibd file (the blog uses .ibd for the same screen, but for split pages you select page-file mode).

Q. With many dropped databases on the server, how do I quickly find the right one in the pages?

There is no automatic shortcut once the dictionary is gone. The fastest method is content search:

grep -l "ABC" pages-*/

where ABC is a string you know lives only in the target table (a customer ID, a unique tag, a primary-key value). Repeat per database to triage which page files belong to which table.

Recovery checklist for MariaDB / InnoDB cases

Stop the MariaDB service before starting; never scan a live datadir.
Copy the entire datadir, including ibdata1, ib_logfile*, every .ibd, and any older ibdata1 backups, to read-only media.
Record the MariaDB version, the value of innodb_page_size, and whether the tables used row format COMPRESSED or DYNAMIC — DBRECOVER needs to know.
Validate the trial first: if the table you need does not appear, do not buy a license expecting it to appear.

For a DBRECOVER for MySQL emergency engagement, contact [email protected] with a small sample .ibd or page file and the schema you need to recover.

DBRECOVER Recovery Options

For Oracle incidents, start with the DBRECOVER for Oracle trial to verify table visibility, row previews, and export readiness on copied datafiles. For MySQL and InnoDB incidents, DBRECOVER for MySQL is free software and can inspect.ibd files, ibdata1, and database directories locally.

When the case is urgent, preserve the original files first, work from copies, and contact paid emergency support with the database version, platform, error messages, file list, and recovery objective.