SolvedIssues
Fixes we actually ran — not copied.
← All fixes

Restore a raw /var/lib/mysql backup (not a .sql dump) onto a new server

MySQL Ubuntu 24.04 ✓ Verified 2026-06-04

The problem

Your backup is a tar of the raw /var/lib/mysql folder, not a mysqldump .sql file. You need to bring it back on a freshly installed server, and MySQL must be the same major.minor version (or newer) as the backup -- otherwise it refuses to open the data.

What you'll see

The way most sites tell you — and why it fails

✗ What the copied tutorials say

Guides assume every backup is a .sql dump and tell you to 'just import it', or they let the default MySQL (8.0) install first and then drop the data folder in.

gunzip -c backup.sql.gz | sudo mysql   # there is no .sql -- this does nothing useful
sudo apt install mysql-server          # installs 8.0
sudo tar xzf datadir.tar.gz -C /        # 8.4 data into an 8.0 engine -> crash

Why it fails: A raw datadir is binary InnoDB files, not SQL -- there is nothing to 'import'. And the version code is baked into the files (80408 = 8.4.8). An older engine (80046 = 8.0.46) treats opening it as a forbidden downgrade and aborts. Worse, letting 8.0 try to start even once writes junk (a fresh ibdata1 / #innodb_redo) into the folder, so you must re-extract the backup before retrying.

The correct way — we tested this

✓ Do this instead

Install the MATCHING (or newer) major.minor version FIRST, then stop it, wipe the data folder, extract the backup, fix ownership, and start. Never let the wrong version touch the folder.

# 1) install the matching engine first (here MySQL 8.4) and confirm:
mysql --version
# 2) only then restore:
sudo systemctl stop mysql
sudo rm -rf /var/lib/mysql
sudo tar xzf /path/to/datadir_backup.tar.gz -C / var/lib/mysql
sudo chown -R mysql:mysql /var/lib/mysql
sudo systemctl start mysql
sudo mysql -e "SHOW DATABASES;"

Why this works

MySQL allows opening data from the same major.minor release (and patch upgrades/downgrades within it), but never a jump down to an older minor. Matching the engine to the backup's version (8.4.8 -> any 8.4.x) lets InnoDB open the files and run its normal crash recovery. Extracting fresh from the tar guarantees the redo/system files are the originals, not the junk a failed wrong-version start left behind.