Test that a backup works: restore in another region without touching production

You have snapshots of your machine. They are taken every night, they show up in the list with their date and size, and you have never had to use them. That has a good side and a bad side. The bad one is that you do not know whether they work. A snapshot can be corrupt, it can have been taken with the database half-written, it can be missing an additional disk that was added later, or the day you need it you may discover that nobody knows where to restore it from. All of this is found out on a quiet afternoon or in the small hours of the disaster. The afternoon is better.

The safest way to test is to restore in another region: a new machine, far from the production one, with its own address, which cannot tread on anything that is running. Along the way you check that your copy outside the region works too, which is the one that would save you in the worst case. When you are done you delete it and the test has cost you a few cents.

Step by step

1. Choose which snapshot to test and write down what you expect to see

   In the Lightsail console, Snapshots menu, find the machine and pick a snapshot that is recent but not from today: last night's or the one from two days ago. Testing the oldest is not much use; testing one from a few hours ago tells you nothing about the ones that have been stored for days either.

   Before starting, write in a note three or four specific things that should be in that copy: yesterday's last order, the blog post published on Tuesday, the user who signed up last week. They are your checklist. Without it, you will end up checking that "the website loads" and passing a copy that is missing two days of data.

2. Copy the snapshot to the test region

   In the snapshot's three-dot menu, choose Copy to another Region. Select the test region (if you already have a backup region, use that one; if not, a nearby one such as Ireland or Frankfurt), give it a name that says what it is (prueba-restauracion-2026-10-28) and confirm.

   The copy takes from a few minutes to over an hour depending on the disk size. To see it, switch region in the selector at the top of the console: copied snapshots only appear in the destination region. Wait until its status is Available.

   If you already have scheduled copies in that region, you can skip this step and test one of them directly: it is even better, because you check the copy you would actually use in a disaster.

3. Create the test machine from the snapshot

   In the test region, snapshot menu, Create new instance. Lightsail asks you for:

   • Availability Zone: any.
   • SSH key: choose that region's default key or upload your own. The machine also keeps the keys the original had, so you can normally log in with the usual one.
   • Plan: it has to be equal to or larger than the original machine's; Lightsail does not let you choose a smaller one. Since it is for an hour, choose the same.
   • Name: something that screams temporary, such as PRUEBA-borrar-web-tienda.

   Click Create instance. In two or three minutes it will be running with a new public IP. Write it down.

4. Open the firewall only as much as needed

   The new machine is born with the default firewall (SSH and HTTP). Open it, Networking tab, and add the ports you use for testing, usually 443 (HTTPS). Do not open more than you need: it is a copy of production with real data, living at an address nobody is watching.

   If you want to lock it down further, restrict each rule to your own IP address (the option to limit to specific addresses is in the rule itself). That way the test machine is invisible to the rest of the internet while the test lasts.

5. Check that it really works

   This is the part that separates a test from a formality. Go through the list in order:

   • It boots and you can log in: connect over SSH from the Lightsail browser button or with your client. If you cannot get in, you have already learned something important.
   • The website loads: open https://IP-de-la-prueba in the browser. The certificate will give an error because the domain does not point there; that is normal, accept the warning. Many websites (WordPress, for example) redirect to the real domain when loaded by IP: to avoid it, on your computer temporarily point the domain to the test IP in the hosts file, or test from SSH with curl -k -H "Host: tudominio.com" https://127.0.0.1/.
   • The database is there and is complete: log in to the website's admin or into the database directly and look for what you wrote down in step 1. If the database is in a separate service (Lightsail database or RDS), careful: the test machine will connect to the production database, because the configuration points there. To avoid writing anything to it by mistake, change the configuration to read-only or point it to a restored test database.
   • The scheduled tasks exist: over SSH, crontab -l and ls /etc/cron.d. They do not need to run (and better if they do not: they would send emails or make backups from the test machine); it is enough to see they are there.
   • The uploaded files are there: the last product photo, the last PDF. If they are missing, the snapshot does not cover that directory (maybe it is on another disk or in S3).

   Write down the result of each point, with the date. An "all good" from three months ago is a valuable piece of information on the day of the disaster.

6. Delete the test machine (and what you opened)

   A Lightsail machine is charged from the moment it exists until it is deleted, running or stopped. As soon as you finish: open the test machine, three-dot menu, Delete. Confirm. If you created a test database, delete it too. If you touched the hosts file on your computer, undo it.

   You can keep the copied snapshot as a backup copy (it is useful to have it in another region) or delete it if you already have scheduled copies there. Snapshots are charged per GB per month; it is little, but it adds up if you leave one behind for every test.

   Check the next day in Billing that no extra machine is left in the test region.

7. Repeat every quarter

   A test is valid as long as nothing changes: the machine, the plan, the website or the person who knows how to restore. In practice that is a quarter. Put "test restore" on a specific person's calendar for the first Monday of January, April, July and October, with a link to the note where you wrote down how it is done and what to check. Half an hour every three months. If the machine has changed a lot (new disk, database moved), run the test earlier.

What can go wrong