---
title: "Fixing a Recovery Install that will not launch"
url: https://phatdev.net/en/docs/sl-migrations/how-to-handle-recovery-install-setup-launch-issues
lang: en
updated: 2026-10-20
alternate:
  vi: https://phatdev.net/docs/sl-migrations/how-to-handle-recovery-install-setup-launch-issues
markdown: https://phatdev.net/en/docs/sl-migrations/how-to-handle-recovery-install-setup-launch-issues.md
---

# Fixing a Recovery Install that will not launch

Part of the doc set: [SL Migrations](https://phatdev.net/en/docs/sl-migrations.md)

> The recovery URL will not open or the installer crashes.

## Recovery Install will not launch

## Symptoms

- Clicking the recovery URL → 404
- The installer opens but shows a PHP fatal error
- Step 1 reports "Cannot find archive"

## Causes + fixes

### 1. The recovery URL has expired

A Recovery Point is only valid while the matching backup still exists and its status is Complete. If the backup was deleted or overwritten, the old URL is no longer valid.

**Fix**: go to **SL Migrations → Packages**, set the Recovery Point on the newest backup, and get the new URL.

### 2. The `backups-slm/` folder is not readable

The web server cannot read the backup folder → 404 or 403.

**Fix**: set the right permissions on the backup folder (usually `755` for the folder, with the web server user as owner). Contact your hosting provider if you cannot change them.

### 3. The archive file was deleted

The recovery URL loads `recovery-installer.php`, which reads the archive in the same folder. If the archive was deleted (manually or by a rotation rule), recovery fails.

**Fix**: check the folder. If it is gone, you cannot recover from it. You need another backup.

### 4. PHP version too old

The installer requires PHP >= 7.4. If the destination server runs < 7.4 → fatal error.

**Fix**: upgrade PHP. On shared hosting you can switch the PHP version in cPanel/Plesk.

### 5. The database credentials are no longer correct

Recovery uses the credentials in the current `wp-config.php`. If the database password was changed recently but wp-config is old → step 2 fails.

**Fix**: edit `wp-config.php` on the server and update the correct password before running the recovery.

## When everything fails

Recovery Point is a convenience feature. Your main backup is still there, so you can:
1. Download the archive + installer.php from the backup folder to your computer
2. Run a regular [Classic Install](https://phatdev.net/en/docs/sl-migrations/classic-install)
3. It takes a few more steps but is more dependable

## See also

- [Recovery Point](https://phatdev.net/en/docs/sl-migrations/recover-a-backup)
- [Fixing permissions](https://phatdev.net/en/docs/sl-migrations/how-to-fix-file-permissions-issues)

## Security note (since 1.8.9)
We recommend configuring nginx to **block direct access** to the `wp-content/backups-slm/` folder (it returns 404) so that nobody can download a backup (including the database) through a web path, leaving only `*_log.txt` files open for the **Xem log** (View log) button. On a server that applies this rule, the **Tải backup** (Download backup) button in the admin still works because it goes through admin-ajax with a token that expires after 1 hour.

For that reason, a Recovery Point link of the form `https://<site>/wp-content/backups-slm/recover/...` **will not open**. When you really need to use a Recovery Point: ask the server administrator to temporarily open the `backups-slm/recover/` folder (the folder-blocking rule in the nginx configuration), then once the restore is done, delete the Recovery Point and block the folder again straight away. A safer way is to restore with **Import Install** or **Classic Install** from the backup stored on the remote destination (SFTP/FTP).