Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
When MySQL will not start after a restore, do not begin by deleting InnoDB files or repeatedly restarting the service. The first fatal message in the MySQL error log determines the correct recovery path. A restored directory can still be unused if the service points to another datadir, and a physically complete copy can fail when its permissions, tablespaces, undo files, or redo logs do not match the running configuration.
Work on a copy, preserve the failed restore, identify the first fatal error, and then follow the matching branch below. The goal is to make the restored instance start without destroying evidence that may be needed for recovery.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problems
What to do before trying another restart
- Stop the restart loop. Repeated attempts can overwrite useful log context and make it harder to distinguish the original failure from cascading messages.
- Preserve evidence. Copy the MySQL error log and record the MySQL version, operating system, backup method or product, restore timestamp, restored directory, service unit, configured socket, and configured TCP port. Keep the failed restored copy unchanged.
- Find the first fatal message. Read the error log and the service manager’s startup output in chronological order. Later messages often describe consequences, not causes. The earliest fatal line is the branch point for the investigation.
- Retry only after one change. Make a single controlled correction, start MySQL once, and capture the new first fatal line. This preserves a cause-and-effect trail.
Oracle’s MySQL troubleshooting guidance treats startup failures as configuration, access, process, or operating-system errors before they are treated as proof that the data itself is lost. That distinction matters: changing files first can turn a recoverable restore into a damaged one.
Read the error log and choose the right branch
Search the error log for the earliest occurrence of one of these patterns:
#1 Best Overall
Errcode 13,Permission denied, or an inability to open a directory or file.Can't open file, a missing tablespace, or a path that does not exist.unknown variableor another option-file parsing error.address already in useor a failure to bind the configured port.- Messages about missing or mismatched redo logs, undo tablespaces, or InnoDB initialization.
- Page-read, checksum, or other corruption errors.
Do not assume that a message mentioning InnoDB means the backup is corrupt. An incorrect path, an incomplete physical restore, or an account that cannot read one parent directory can produce an InnoDB startup failure that looks like a data problem.
Confirm that MySQL is using the restored instance
A correct file copy has no effect if the service starts a different instance. Verify the complete startup configuration rather than checking only the directory you copied.
Check the configured data and installation paths
Confirm the service’s effective --datadir and --basedir, including values inherited from included option files. Compare them character for character with the directory that contains the restored files. Relative paths, symbolic links, mount points, and a service-specific option file can redirect the service somewhere else.
Check the endpoint clients are using
Record the configured Unix socket and TCP port. A service can appear unavailable when it is actually running under another socket, or a client can connect to a different MySQL instance on the same host. The endpoint check also exposes accidental attempts to start a second instance against the same files.
Check the service unit
Identify the service unit that launches mysqld and inspect its command-line options, environment, and included configuration files. A restore procedure that copied files into a package-default directory will not work when the unit uses a custom data directory, and the reverse is also true.
Fix Errcode 13 and other permission failures
Oracle documents Errcode 13 as Permission denied: the privileges on the data directory or its contents do not permit the server to access them. The error may be reported for a file even though the real problem is a parent directory that blocks traversal.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Repair access for the account that runs mysqld
- Identify the operating-system account and group used by the service.
- Check the restored data directory, every required subdirectory, and each file named in the error log.
- Ensure that the service account can traverse all parent directories and read or write the files required during startup.
- Check host security-policy rules that can deny access even when ordinary Unix or Windows permissions look correct.
- Correct only the affected ownership, modes, ACLs, or policy labels. Do not make the entire filesystem world-writable as a shortcut.
- Start MySQL once and capture the new first fatal message.
A restore performed as an administrator or as a different user commonly leaves files inaccessible to the normal MySQL account. Permission repair must cover the complete path, not just the top-level directory. If the error changes from access denied to a missing file or InnoDB message, that new message is the next branch to investigate.
Rule out a competing process or port conflict
An existing mysqld process may already own the configured TCP port, or the service may be trying to launch a second instance against the same data files. The error log or service output may report address already in use.
- List running MySQL processes and determine which service unit started each one.
- Identify the process that owns the configured port.
- Confirm that the running process uses the intended
datadir, socket, and option files. - Stop the unintended instance through its own service manager before starting the restored instance.
- Do not start two servers against one physical data directory.
If a different instance is using the port, changing the restored server to an arbitrary port may hide the configuration error rather than fix it. First establish which instance should own the data and endpoint.
Validate a physical restore set before troubleshooting InnoDB
Physical backups are sets of interdependent files. InnoDB may refuse to initialize when one component is missing, copied from another point in time, or located somewhere different from the configured path.
Confirm that the required components arrived together
For a physical InnoDB restore, account for the system tablespaces, per-table .ibd files, undo tablespaces, and redo logs. A directory containing table files but missing system or redo information is not a complete restore. Likewise, restoring a tablespace while leaving its configured location unchanged can produce a missing-file error even when the file exists elsewhere.
Compare paths with the active configuration
Check every path referenced by the MySQL configuration and by the error log. Verify that the restored files are on the expected filesystem, that mounts are present before the service starts, and that case-sensitive path differences have not separated a file from the name MySQL expects.
Understand redo-log messages
A documented restore failure can occur when redo logs are missing. Do not create, rename, or delete redo files simply because their names look unfamiliar. Redo-log naming and locations differ by MySQL release; newer releases use files such as #ib_redo. The correct action depends on the exact MySQL version and the backup tool’s restore procedure.
Do not mix backup generations
System tablespaces, undo files, redo logs, and per-table files must represent a consistent backup point. Combining files from separate restores can create mismatched metadata that prevents startup. If the restore product has a manifest or validation report, compare it with the files actually placed in the data directory.
Account for MySQL version and layout differences
Use the MySQL version recorded before troubleshooting, not merely the version currently installed on the host. Physical restore procedures are sensitive to release-specific file layouts and redo-log behavior. A file name that was valid in one release may not be created, located, or handled the same way in another.
Rank #4
- Match the restore procedure to the MySQL release for which the backup was made.
- Use the backup tool’s documented compatibility rules instead of assuming that a file-level copy is portable between releases.
- Check whether the target installation uses a different default data directory or option-file structure.
- Do not infer that an absent file is safe to recreate, or that an extra file is safe to remove, from its name alone.
If the error log reports an unknown option, resolve the configuration-version mismatch before touching database files. An option accepted by one release can prevent another release from starting.
Separate logical and physical restore problems
The backup format determines what can be missing and what recovery path is practical.
| Restore type | What is restored | Typical startup dependency | Version and recovery considerations |
|---|---|---|---|
| Logical SQL dump | SQL statements that recreate schemas, tables, and data through a running server | The target server must start with a valid, compatible configuration before the dump can be imported | Import behavior depends on the dump’s SQL and the target MySQL release; the dump does not supply the physical InnoDB redo, undo, or tablespace files of the target instance |
| Physical file backup | Data-directory files, including InnoDB system and per-table files when included by the backup | Required system tablespaces, .ibd files, undo tablespaces, redo logs, paths, and permissions must agree |
Restore must follow the backup tool and MySQL release requirements; binary logs can extend a sound base backup for point-in-time recovery when they cover the interval |
If the backup is a logical dump, investigate why the target server itself cannot start; the dump is not yet involved. If it is a physical backup, inventory the complete file set and its paths before attempting database-level repairs.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Handle suspected InnoDB corruption without destroying the only copy
Oracle’s InnoDB recovery documentation warns that hardware failure or a severe system error can corrupt InnoDB data badly enough that MySQL refuses to start. A corruption message is therefore serious, but it is not a reason to experiment on the only restored copy.
Preserve and isolate
- Stop attempts against the failed directory.
- Make a byte-preserving copy or storage snapshot of the failed restore, if your environment supports one.
- Test a known-good backup on an isolated host or separate data directory so it cannot collide with production ports, sockets, or files.
- Compare the startup behavior of the known-good copy with the failed restore. This distinguishes a bad backup from a host, configuration, or version problem.
Use a sound base backup for point-in-time recovery
When the known-good base backup predates the desired recovery point, binary-log events can be applied with mysqlbinlog and the mysql client. This works only when the required binary logs cover the interval between the base backup and the target point. Preserve the original binary logs and verify their sequence and timestamps before applying anything.
Best Value
Escalate when recovery is uncertain
If the known-good copy also fails, or the error indicates page corruption, stop changing files and involve a MySQL recovery specialist or the organization responsible for the backup system. Provide the error log, version, backup method, restore manifest, configuration, and a copy of the failed files. A specialist can work from preserved evidence instead of trying to reconstruct what was deleted.
Why deleting InnoDB files is usually the wrong first move
Deleting ibdata*, .ibd, undo, or redo files can permanently remove metadata or data. It is not a general fix for a server that will not start, and it can make a later recovery impossible.
Deletion belongs only to a controlled reinitialization or rebuild procedure in which:
- A separate, preserved copy of the failed restore exists.
- The data loss and rebuild consequences are understood and approved.
- A known-good backup is available for restoration.
- The procedure matches the MySQL version and the backup method.
- Binary logs needed for point-in-time recovery have been retained.
Do not delete a file merely because a forum post used that step for a different release, layout, or failure. Missing redo logs, mismatched tablespaces, and permission errors require different remedies.
A practical decision checklist
- First fatal line: Is the earliest error access denied, a missing path, an option error, a port conflict, an InnoDB dependency failure, or corruption?
- Target instance: Does the service’s effective
datadirexactly match the restored directory, and dobasedir, option files, socket, and port match the intended instance? - Access: Can the account running
mysqldtraverse every parent directory and access every required file under the host’s security policy? - Process: Is another MySQL instance already using the port or the restored files?
- Restore completeness: For a physical backup, are system tablespaces, per-table files, undo tablespaces, and redo logs present and at the configured paths?
- Compatibility: Does the installed MySQL release match the backup procedure and file layout?
- Evidence: Have you preserved the failed copy and error log before making destructive changes?
- Recovery source: Is there a known-good base backup, and do retained binary logs cover the required point-in-time interval?
When to stop troubleshooting and rebuild
Rebuild the instance from a known-good backup when the restored copy is demonstrably corrupt, incomplete, or irreparably mismatched with the target release. Perform the rebuild on an isolated instance first, validate that MySQL starts and the expected schemas are present, and only then plan the production cutover. If binary logs cover the gap, apply them after the base restore to reach the required recovery point.
A successful startup is not by itself proof that the restore is correct. After the server starts, verify the expected databases, table counts or other application-level checks, users and grants, configured paths, and the timestamp represented by the restored data before declaring the incident resolved.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
