Support

Documentation

Overview of the backup restoration procedure

The backup restoration procedure generally consists of two discrete steps:

  1. Extraction of the backup archive. The backups taken with the application are compressed to save space and, in the case of JPS archives, encrypted to protect their contents from prying eyes. The first thing you need is to extract the archive, getting access to the files contained in it.

    You can find information about the different ways to extract backup archives in Extracting your backup archives.

  2. Database restoration and site (re-)configuration a.k.a. "running the installer". All backups taken with the application contain a web-based restoration script called the installer. Its job is to restore the database backup, move the backed up off-site folders to their proper locations and, if your site script is supported, rewrite your site's basic configuration to match the new server.

    You can find information about the different restoration scripts in ANGIE: Akeeba Solo's restoration scripts.

Prerequisites

Before you begin the restoration procedure you will also need to have a database to hold your data and the connection information to it at hand. For this you need to create a database for your site's data, or note down the connection information to an existing database if you are installing on top of an existing site. You will need the following information:

  • Database host name. This is usually localhost, but you may need to check with your host

  • Database name. The name of the database you are restoring to. If you are on a host powered by cPanel or Plesk do note that the name of the database includes an account-specific prefix. If your account name is foo and the name of your database you asked to create is bar, the full database name is foo_bar.

  • Database user name. The user name you use to connect to your database. The same thing about the naming prefix on cPanel and Plesk hosts is true for the username as well.

  • Database user password.

  • Your preferred table name prefix. This is not something your host will tell you, it's just a matter of your personal preference. With most scripts (e.g. WordPress, Joomla!) you may use anything you want. It's best to pick a name consisting of three to four letters and a single trailing underscore, i.e. tst_ or test_. Do not use bak_ as it is a reserved prefix for keeping copies of replaced tables when you select the Backup old tables option in the installer later in the process.

If your host gives you such an option —or if you are using a local server— it’s a good idea to set the default collation of the database to utf8_general_ci. If you are not given such an option, don't worry. The installer can work around this limitation with its Force UTF8 collation on tables option on MySQL databases. For other database types you have to specify the correct collation on the database when creating it.

Some PHP software, such as WordPress, is using the utf8mb4_general_ci collation instead. This collation supports multi-byte Unicode characters such as Emoji, certain Tradition Chinese characters and so on. If you need to restore such a site please remember to turn on the Allow UTF8MB4 auto-detection option. This is done automatically for WordPress restoration.

The server where you are restoring your backup must be using PHP 7.2.0 or later by default. Please note that many hosts claim to support a high version of PHP (e.g. PHP 7.3) but it's not the version they use by default. For instance, we've seen hosts which claim to support PHP 7.3, but the default version they are using is PHP 5.3. If the restoration fails with a notice that the PHP version is too old please do contact your host and ask them to make PHP version 7.2.0 or later as the default PHP version of your site. It's really easy for them: they have to change just one line in your site's configuration.