Fixing a Recovery Install that will not launch

The recovery URL will not open or the installer crashes.

SL MigrationsUpdated 21 Oct 2026
recoverytroubleshoot

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
  3. It takes a few more steps but is more dependable

See also

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).