# MySQL or MariaDB won't start after a crash Source: https://vpsdime.com/knowledgebase/troubleshooting/mysql-wont-start Last reviewed: 2026-07-02 Summary: How to bring a database back safely, read the error log before touching anything, rule out the two usual killers (full disk, OOM), let InnoDB's normal crash recovery finish, and only then consider innodb_force_recovery, used read-only, to dump and rebuild, never as a setting you leave on. ## What this is The database died and won't come back up. This is the guide where **order of operations matters most**: the wrong first move can convert a recoverable situation into data loss, so the sequence below is arranged to be safe at every step. The single rule: **read before you write**, diagnose from logs before changing anything, and take a copy before any risky action. ## Step 0: read the error log Everything MySQL/MariaDB knows about why it won't start is in its error log: ``` journalctl -u mariadb -n 100 # or -u mysql tail -100 /var/log/mysql/error.log # location varies by distro ``` The last screen of output nearly always names the cause directly. Match it below. ## Step 1: rule out the two usual killers - **Full disk (or inodes).** InnoDB refuses to start, or crashed in the first place, when it can't write: `Disk full`, `errno 28`, or just cryptic write failures. `df -h && df -i`, and if either is at 100%, fix that first, [the disk-full guide](https://vpsdime.com/knowledgebase/troubleshooting/disk-full), then start the service. This resolves a large share of "corrupt database" panics with zero database surgery. - **The OOM killer.** If memory ran out, the kernel likely killed mysqld mid-write, and may kill it again on startup while it replays. On **Linux VPS**, OOM kills don't show in your own logs, run [My VPS is Down](https://vpsdime.com/knowledgebase/client-area/support/vps-troubleshooter), which reports them. If OOM is the story, shrink `innodb_buffer_pool_size` (the usual oversized culprit) or [add memory](https://vpsdime.com/knowledgebase/client-area/services/upgrade-downgrade) before restart attempts, or you'll crash in a loop. ## Step 2: let normal crash recovery run InnoDB is designed to survive crashes: on startup it replays its redo log and rolls back unfinished transactions on its own. On a large or busy database this can take **many minutes** while the service looks "stuck", watch the error log in a second terminal (`journalctl -u mariadb -f`); as long as recovery messages keep progressing, **wait**. Restarting it mid-recovery restarts the recovery. ## Step 3: take a copy before anything risky If recovery genuinely fails (the log shows a crash during recovery itself, or names corrupted pages), stop. Before any forced measure, copy the raw data directory somewhere safe: ``` systemctl stop mariadb cp -a /var/lib/mysql /root/mysql-datadir-copy ``` Every step after this point becomes reversible. (Check `df -h` first, you need the space.) ## Step 4: innodb_force_recovery, the escape hatch, not a fix `innodb_force_recovery` starts InnoDB while **skipping parts of its own safety machinery** so you can get your data out. Understand the contract: it's a **read-only rescue mode for dumping**, not a setting that repairs anything, and higher levels can themselves corrupt data. 1. Add to the `[mysqld]` section of your config: `innodb_force_recovery = 1`, and try to start. If it won't, step up one level at a time, **2, 3, 4**, using the **lowest level that starts**. 2. Once it starts, **do not resume normal operation.** Dump everything immediately: `mysqldump --all-databases > /root/all.sql`. 3. Treat levels **4 and above** as data-affecting (they skip undo/redo application), only with your Step 3 copy in place, and if 1 to 3 didn't start it, this is the moment to consider [asking for direction](https://vpsdime.com/open-ticket/) before going further. 4. Rebuild clean: stop the server, move the broken data directory aside, reinitialize (or reinstall the DB packages), start **without** `force_recovery`, and load `/root/all.sql`. Remove the setting from the config, leaving it on silently breaks the database later. ## If you have backups, weigh them first A [nightly dump](https://vpsdime.com/knowledgebase/getting-started/backing-up-your-vps) or a [Nightly Backups image](https://vpsdime.com/knowledgebase/troubleshooting/recover-deleted-files) from before the crash may cost you a day of data but zero surgery, often the better trade than hours of forced recovery for a database that was corrupted anyway. This is also the standing argument for the dump-nightly cron: dumps restore cleanly, always. ## Prevent the rerun The crash had a cause: usually [OOM](https://vpsdime.com/knowledgebase/troubleshooting/slow-vps) (right-size the buffer pool against your plan's RAM), a [full disk](https://vpsdime.com/knowledgebase/troubleshooting/disk-full), or hard power-offs during writes. And make sure the service is [enabled to start on boot](https://vpsdime.com/knowledgebase/troubleshooting/services-not-starting-after-reboot) while you're here. ## Related questions - "MariaDB won't start after my VPS crashed, what's the safe order of steps?" - "What is innodb_force_recovery and is it safe?" - "How long does InnoDB crash recovery take?" - "MySQL says disk full or errno 28 and won't start." - "Should I restore a backup or repair the database?"