Hands-on Lab·MySQL
MySQL Dump Restore
The database is dropped for real, the client returns ERROR 1049, and the dump brings back all five customers and three orders. An untested backup is a guess - this is the test.
Backup and Restore Guide 22 of 45 Beginner
- OSUbuntu 26.04 LTS
- MySQL8.4.10-0ubuntu0.26.04.1
- BinlogROW format, enabled by default
- TimeAbout 14 min
Restoring a dump replays SQL statements, so it is bound by the same constraints as any other write. A dump restored in the wrong order can fail on foreign keys, which is why mysqldump emits its own ordering.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| db-a01 | 192.168.0.81 | Ubuntu 26.04 LTS | Primary / Source / Replica Set Member 1 | 2 Core | 4 GB | 50 GB |
This guide includes
Use this before you ever need it. This matters because the only proof a dump works is dropping the database for real and putting it back - and exit zero is not verification.
- recording what you expect to get back, by counting first
- destroying the database for real
- restoring by feeding the SQL back to the client
- verifying against the numbers you wrote down, since exit zero proves nothing
Before you start
- The dump file from the previous guide.
- A server you are willing to destroy - db-a01 in this lab.
-
Record what you expect to get back
-
Destroy it
-
Restore it
-
Verify against the numbers you wrote down