Skip to main content
Deutsch Español Français Nederlands

Restore a backup on another website

Updated

This is how you bring the backup of one website to another: when moving to a new server or for a copy for testing. The pre-check shows you every difference between the two websites before anything is written.

What you need

  • on the new website, a running WordPress with cloneworx Backup,
  • at least one configured target there,
  • the backup of the old website: as a downloaded file or at a target that the new website can reach,
  • the credentials of an administrator of the old website.

Step 1: Get the backup onto the new website

A backup can only be restored once it is in the list of the new website. Two ways lead there.

Way How it works When it fits
Import from a file Download the backup on the old website and import the file on the new one: Download a backup, Import a backup from a file. For a move and for a copy. A backup can only be downloaded if it is stored at a local target.
Connect the target On the new website, set up the target where the backups of the old one are stored, and take over the folder of the old website there: Find backups again after a total loss. Only for a move in which the new website replaces the old one, and only as long as the list of the new website is empty.

For a copy: import, do not take over

With the takeover, the folder at the target belongs to the new website, and the plugin treats the website as moved. If the old website keeps running, use the import from a file.

Step 2: Read the pre-check

On the new website, open the Restore page. In the row of the backup, open More …, then Restore. The pre-check runs on its own. That the backup comes from a different website is a warning and does not block the start: you judge the risk.

Pre-check with warnings for a backup of a different website

  1. A point with a warning is yellow. The point Same website reports a different website here.
  2. The differences between the backup and this website, one difference per line with both values.
  3. Replaced on import (unknown to this database server): names character sets and collations that the database server here does not know, and the replacement for them.
  4. Not restored: names what the restore leaves out, and in brackets the reason.
  5. The notice that the backup comes from a different website and that the site address stays the one of this website.
  6. Start restore remains usable: warnings do not block the start.

The pre-check names these differences:

Difference What it means
PHP, WordPress The versions differ. Whether a plugin from the backup runs under a different PHP version is something cloneworx Backup cannot know.
Database, Database version, Database character set Type, version or character set of the database server differ. If the server here does not know a character set or a collation from the backup, the import takes a replacement. A replacement can change sorting and searching.
Table prefix The tables are named differently here. The restore creates the tables under the prefix of this website and adapts the entries that carry the prefix in their name.
Multisite Multisite is not supported: the backup contains only the tables of the main website.
Plugin version The backup comes from an older version of cloneworx Backup. Columns that this website has may be missing in it. The restore names them; they get their default value.

If the backup has no fingerprint, the point Same website reports an unknown origin. The same defaults apply as with a different website.

Step 3: Decide what is restored in addition

For a backup of a different website, the restore leaves out three things by default:

  • the WordPress core,
  • the drop-ins object-cache.php, advanced-cache.php and db.php,
  • the files .htaccess, web.config and .user.ini.

The core and the three files in the root folder then stay those of the new website. The new website’s own drop-ins move to the previous state during the restore, like other entries in wp-content that do not come from the backup.

If you want to restore any of this from the backup, switch to the Extended view. There, the three switches Do not restore WordPress core, Do not restore drop-ins (object-cache.php, advanced-cache.php, db.php) and Do not restore .htaccess, web.config, .user.ini are ticked.

Scope and switches for the backup of a different website

  1. Do not restore WordPress core is ticked: the core stays the one of this website.
  2. Do not restore drop-ins (object-cache.php, advanced-cache.php, db.php) is ticked: the three files from the backup are left out.
  3. Do not restore .htaccess, web.config, .user.ini is ticked: the three files stay those of this website.

Remove the tick, and the pre-check runs again. More about the switches: Restore only parts.

Step 4: Start the restore

Click Start restore. The confirmation dialog names the number of warnings.

Confirmation dialog before the start after a pre-check with warnings

  1. … point(s) of the pre-check warn; you have judged the risk.
  2. Start restore

The restore runs as on the same website: Restore the website from a backup. After the switch-over, the new website must confirm itself. If the state from the backup does not load on this server, the plugin brings the previous state back.

Step 5: Log in again and check

With the database come the user accounts of the old website. Log in with the credentials of the old website. Check the home page, the login and the links and images in the content. Then decide: Keep or undo a restore.

The site address

  • The site address stays the one of the new website. The same applies to the location of the uploads if it is set in the WordPress settings.
  • The plugin replaces no addresses in the content. Links and images in posts that name the old address keep pointing there.
  • The plugin rewrites the permalinks after the restore of the database.

Good to know

  • cloneworx Backup itself stays as it is set up on the new website: targets, backup plans and settings do not come from the backup.
  • The restore never restores the wp-config.php. The credentials for the database stay those of the new website.
  • On a different website, the restore sets the permissions of the folders the way WordPress creates them there. It never sets owner and group.
  • The plugin never deletes an imported backup automatically. It stays until you delete it.

See also

On the command line

WP-CLI not set up yet? How to install WP-CLI.

On the new website, the whole way also works with WP-CLI. The parameters --include-core, --include-dropins and --include-htaccess add what a different website leaves out by default.

# Import the backup file to the target local-1
wp cloneworx-backup import /tmp/backup.tar --target=local-1

# The pre-check: differences and what is left out
wp cloneworx-backup restore precheck <Job>

# Restore the backup, including the WordPress core
wp cloneworx-backup restore run <Job> --include-core