Importing backups

You can restore a live site into any local site. WP Instances replaces the local site's database and files with the backup and points every URL at the local address.

Restore into a site you created for it. Create a blank site first if you don't have one, then import into it.

Open the Import Backup screen

Select the site and click Import backup… on the Overview tab, or press I. The dialog is called Import Backup into “site name” and has two modes at the top:

Importing needs an active trial or license.

Restore Now

Backups already in the site

Under Backups in this site, WP Instances lists backup files it finds in the site:

• wp-content/ai1wm-backups (All-in-One WP Migration)
• wp-content/updraft (UpdraftPlus)
• the site's root folder

It looks for .wpress, .sql, .sql.gz, -db.gz and .zip files. The files of one UpdraftPlus run are grouped into one row, with its date and size. Click Restore on a row and confirm.

If nothing is found, it says None found — choose files from this PC below.

Backup files on this PC

1. Under Or restore files from this PC, click Choose… and select the backup files. You can select several. You can also paste full paths into the box, one per line.
2. For UpdraftPlus, choose every file of the backup: the -db.gz and all the .zip files.
3. Leave Live site URL empty. WP Instances reads it from the backup. Only fill it in, for example https://example.com, if the job log says it couldn't find it.
4. Click Restore from Files and confirm.

The files are copied into a hidden folder inside the site through Docker, restored, and then the copies are deleted. Your original files are not touched.

What a restore replaces

The confirmation says it: the restore replaces the site's database and overwrites its files with the backup. In detail:

• The site's database is emptied first, so the backup replaces the blank install instead of sitting beside it.
• Plugins, themes, uploads and other wp-content folders from the backup are written over the site's own.
• The site's own wp-config.php is always kept, because it points at the local database.

Supported formats

A generic .zip is placed by looking at what's inside:

Files only, or a database only, also work. The job log says files only when there's no database in the set.

What a restore does, step by step

The progress window shows these steps:

1. Copy backup into the site
2. Unpack plugins, themes & uploads
3. Import database
4. Match the live WordPress version
5. Rewrite URLs to the local address
6. Fix file permissions

Table prefix

Dumps often don't use the standard wp_ prefix. After the import, WP Instances finds the prefix the restored tables use and sets $table_prefix in wp-config.php to match.

WordPress version

UpdraftPlus and All-in-One WP Migration backups don't include WordPress itself, but they record which version the live site ran. When the backup records it and it differs from the site's, WP Instances installs that WordPress version (downloaded once and cached). Only WordPress core is replaced; wp-content and wp-config.php are left alone. If the download fails, the site keeps its current version and the log says so. Then any pending database update runs.

If the backup says the live site ran a different PHP version, the job log notes it. Switch the site's PHP to match if anything breaks; see PHP versions.

URL rewriting

WP Instances replaces the live address with the local one in every table of the site, using WP-CLI's search-replace, which handles serialized data safely. It covers:

• https:// and http://, with and without www.
• protocol-relative links (//example.com)
• JSON-escaped URLs (\/\/example.com), as page builders, block attributes and SEO plugins store them
• sites that lived in a subfolder, such as example.com/blog, which are mapped onto the local site's root

GUIDs are left unchanged, as WordPress advises. Plugins and themes are not loaded while URLs are rewritten, so a plugin that can't run on the site's PHP version can't stop it. Afterwards home and siteurl are set to the local address and caches are flushed.

If no live address is found, or it already is a local one, URLs are left unchanged and the log warns you. Run the import again with Live site URL filled in.

After a restore

• The site's users are now the live site's users, with their passwords. The admin / admin login shown under Admin login no longer applies. Use Open admin to sign in as any user without a password; see Working with sites.
• The mail catcher is installed again, so the restored site can't email your live site's customers. See Mail.
• A new preview is taken.

Only Copy for the Plugin

Use this when you'd rather restore from inside the backup plugin.

1. Choose Only Copy for the Plugin.
2. Under Backup plugin, choose All-in-One WP Migration or UpdraftPlus.
3. Under Backup files, click Choose… or paste the paths, one per line.
4. Click Copy Files.

The files go to wp-content/ai1wm-backups or wp-content/updraft, owned by the web server so the plugin can read them. Nothing else changes: the site still shows its old content. A notification says Backup copied into site name — not restored yet, with a Restore now button.

To restore, either:

• in wp-admin, go to All-in-One WP Migration → Backups or UpdraftPlus → Existing backups and restore there (the plugin must be installed and active on the site), or
• open Import backup… again and click Restore on the backup under Backups in this site.

Limits and refusals

WP Instances stops with a clear message, and changes nothing, when:

Other things to know:

• When you restore a set from Backups in this site, only files of the same UpdraftPlus run are used, even if the folder holds several backups.
• A dump that switches databases (CREATE DATABASE or USE lines) is cleaned first, so it always lands in this site's database.
• There's no fixed size limit. Large backups need enough free space on Docker Desktop's disk for the backup and the unpacked site.
• If a restore fails partway, run it again. The site's database and files may be partly replaced until a restore completes.