---
tags:
  - wordpress
  - staging
  - testing
  - restore
  - rclone
  - disaster-recovery
  - mysql
---

# How to Test Your WordPress Restore Process (Staging Site)

Having automated backups is great, but how do you know they actually work? A failed restore during a real emergency is a nightmare scenario. The professional way to validate your backups is to periodically restore them to a separate, temporary "staging" server.

This guide shows you how to restore your site to a different server to confirm your backups are valid, without ever touching your live production site.

## 1. Prerequisites: The Staging Server

You need a second, clean Ubuntu server to act as your temporary staging environment. This can be another virtual machine, a different cloud instance, or even a local WSL environment.

1.  **Set up a LAMP Stack:** Your staging server needs a web server, database, and PHP.
    *   **Reference:** [[Ubuntu-LAMP-Setup|Setting Up a LAMP Stack on Ubuntu]]
2.  **Install and Configure `rclone`:** Install `rclone` and configure it with the *exact same remote* you use for your live site's backups (e.g., `gdrive`).
    *   **Reference:** [[Ubuntu-Rclone-Backups|Syncing Backups to the Cloud with `rclone`]]

## 2. Initial Restore

Follow the standard restore process to get the files and database onto your new staging server.

1.  **Download Backups:** Use `rclone sync` to pull the backup files from your cloud storage to the staging server's `/var/backups/wordpress` directory.
2.  **Create Database & User:** Create the `wordpress` database and `wp_user` in MySQL.
3.  **Import Database:** Restore the `.sql` backup file into the newly created database.
4.  **Extract Files:** Extract the `.tar.gz` file backup into the `/var/www/html` directory.

*   **Reference:** For detailed commands, follow steps 1-4 in the [[Ubuntu-Rclone-Restore|Disaster Recovery Restore Guide]].

**STOP! Do not proceed to the final step of that guide yet.**

## 3. The Critical Step: Update Site URLs

If you try to access your staging site now, WordPress will immediately redirect you to your *live* site's domain. This is because the live URL is stored in the database we just restored. We must change it to the staging server's IP address.

1.  **Log into MySQL:**
    ```bash
    sudo mysql
    ```
2.  **Select the WordPress database:**
    ```sql
    USE wordpress;
    ```
3.  **Find your staging server's IP address:**
    *   Run `ip a` in a separate terminal to get the IP (e.g., `192.168.1.100`).
4.  **Run the update commands:**
    *   Replace `YOUR_STAGING_IP` with the actual IP address.
    *   This tells WordPress that its new "home" is the staging server's IP.
    ```sql
    UPDATE wp_options SET option_value = 'http://YOUR_STAGING_IP' WHERE option_name = 'siteurl';
    UPDATE wp_options SET option_value = 'http://YOUR_STAGING_IP' WHERE option_name = 'home';
    ```
5.  **Apply changes and exit:**
    ```sql
    FLUSH PRIVILEGES;
    EXIT;
    ```

## 4. Finalization and Verification

Now you can safely finalize the setup.

1.  **Fix Permissions:** Set the correct file ownership and permissions on `/var/www/html`.
    *   **Reference:** [[Ubuntu-WordPress-Security|Securing a WordPress Installation]]
2.  **Test the Site:** Open a web browser and navigate to `http://YOUR_STAGING_IP`.

You should see a perfect copy of your live site, but running entirely on your temporary staging server. You can now log in, click around, and verify that all posts, pages, and images have been restored correctly.

## 5. Cleanup

Once you have confirmed your backups are working, you can safely delete the staging server to avoid confusion or extra costs.

> **Pro Tip:** For a more advanced staging environment where you need to fix many internal links (e.g., in image paths), you can install a plugin like **"Better Search Replace"** on the staging site. Use it to search for `https://www.yourlivesite.com` and replace it with `http://YOUR_STAGING_IP`.