---
title: "Recovery Point - Quick restore when the site breaks"
url: https://phatdev.net/en/docs/sl-migrations/recover-a-backup
lang: en
updated: 2026-10-20
alternate:
  vi: https://phatdev.net/docs/sl-migrations/recover-a-backup
markdown: https://phatdev.net/en/docs/sl-migrations/recover-a-backup.md
---

# Recovery Point - Quick restore when the site breaks

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

> Bookmark a backup as an emergency restore point and restore in one click.

## Recovery Point

SL Migrations has **Recovery Point** - you bookmark a backup as an emergency restore point. When the site is badly broken (white screen, plugin conflict, hack), you can restore in one click without uploading the installer again.

## Set a Recovery Point

1. **SL Migrations → Packages**
2. Find the most recent backup with status `Complete`
3. Click the **Set Recovery Point** button on that row
4. The plugin generates an emergency URL like this:
   ```
   https://example.com/wp-content/backups-slm/recovery-installer.php?key=xxxxx
   ```
5. **Save this URL** somewhere safe outside the site (a notes app, a password manager, an email to yourself)

## When you need an emergency restore

1. Open the saved recovery URL in your browser
2. The installer appears right away - nothing to upload
3. Enter the database details (if the database is not damaged you can keep it as is)
4. Run → the site is restored

## Comparison with the regular installer

| Recovery Point | Regular installer |
|---|---|
| Already on the server | Must be downloaded and uploaded again |
| Restores the main site in place | Restores onto another server |
| 1 click | 4 UI steps |
| Suited to disaster recovery | Suited to migration |

## Important notes

- Recovery Point only works with a backup whose status is `Complete`
- If the database details have changed since the backup, edit `wp-config.php` on the server before running the recovery
- After a successful recovery, remember to **set the Recovery Point again** on the newest backup
- The Recovery Point is stored on the server → protect the URL by NOT sharing it, and consider adding a web server rule that blocks access to the `backups-slm` folder

## Handling recovery errors

See [Fixing Recovery Install that will not launch](https://phatdev.net/en/docs/sl-migrations/how-to-handle-recovery-install-setup-launch-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).