Restoring a Backup

There are different Cloud Container Images you can use so the backup restore procedure may be different depending on the image used, and if your Cloud Container server is managed, we even provide a one click backup restore feature for web, application, and service images.

The base path for container backups will depend on whether you are logged in as a single or multiple access SSH user:

For a user with access to a single container, /container/backups/containers/ contains subdirectories for each date/time a backup was taken, which we'll refer to as snapshots, as well as a symbolic link named latest that points to the latest snapshot.
For a user with access to multiple containers, /container/ contains subdirectories which correspond to each container linked to that user. Each of these subdirectories will then contain the snapshots for the corresponding container in backups/containers/ with the same structure as described above.

When browsing a snapshot directory you may notice the file structure is very similar to the Container's file structure.

This article assumes that you are logged in as a single access SSH user. If you're using a multiple access user, you should interpret any reference to /container/backups/containers/ as instead being /container/$NAME/backups/containers/, where $NAME is the name of your container.

In this article, we explain the procedures we would suggest you follow if you need to restore your Container files or Database from a backup. It's a good idea to back up your Container before applying significant changes. You can read more about Backing up a Container.

Restoring Backups from Control Panel

This feature is only available on managed Cloud Container servers.

Navigate to the Containers module from the menu on the left
Select the container you want to restore from the list
Select the Backups tab from the menu
Find the backup you want to restore in the list and click Restore

Once you have initiated the restore we will first take a new backup of the container as is so that you can safely roll back if something goes wrong.

This will only restore the files on your website. If you want to restore the database, please keep reading.

Restoring a MySQL database for a Web Container

Assuming you wish to restore from the latest copy taken, follow the steps below:

Connect to your Container via SSH.
Go to the directory that contains the backup file you wish to restore and list the dump filename.
```
cd /container/backups/containers/latest/databases/
ls
```
The command below is a template. This should help you uncompress the file and restore it into the database. Replace the uppercase strings as required.
```
gunzip < FILENAME.sql.gz | mysql -h MYSQL_HOSTNAME -u USERNAME -p DATABASE
```
Type in the database username password when prompted.
No data will be returned if all went well. Check the database has been restored as expected.

We would suggest reading the MySQL Databases section in case you are not sure what command parameters to use.

Restoring Web Container's application files

You can use rsync to restore a website snapshot, follow the steps below:

Connect to your Container via SSH.
Go to the directory that contains the backup files you wish to restore. Check the files are as expected.
```
cd /container/backups/containers/
ls
ls /container/backups/containers/latest/application/
```
Copy the files to the running Container as required. Just as an example, we are restoring from the latest backup taken.
```
rsync --archive --stats --delete /container/backups/containers/latest/application/ /container/application/
```
Check the files have been restored, test your application as required.

Restoring Web Container's configuration files

You can use the backup files as a reference and restore individual files as needed. It's easy to restore all configuration files though. This is what we are going to do next:

Connect to your Container via SSH.
Go to the directory that contains the backup files you wish to restore. Check the files are as expected.
```
cd /container/backups/containers/
ls
ls /container/backups/containers/latest/config/
```
Copy the files to the running Container. Just as an example, we are restoring from the latest backup taken.
```
rsync --archive --stats --delete /container/backups/containers/latest/config/ /container/config/
```
Using the SiteHost Control Panel, reboot the Container to apply the changes.
Test the Container is working as expected.

Restoring PostgreSQL Container database

PostgreSQL Containers backup happen in two different stages. The first stage is a cron job dumping the databases to a /container/application/backup directory. The second stage is when these files are copied over to the secure offsite location.

If you wish to restore the latest backup taken, follow the steps:

Connect to your Container via SSH.
Go to the directory that contains the backup files you wish to restore. Check the database dump filename.
```
cd /container/backups/containers/latest/application/backup/
ls
```
If required, drop the database you wish to restore, recreating it just after.
The command below is a template. This should help you uncompress the file and restore it into the database. Replace the uppercase strings as required.
```
gunzip < FILENAME.dump.gz | psql -h PGSQL_HOSTNAME -U USERNAME DATABASE
```
Type in the database username password when prompted.
Check the database has been restored as expected.

We would suggest reading the Connecting to a Container article if you want to learn more about the parameters used and default passwords.

Restoring MongoDB Container database

MongoDB Container backups happen in two different stages. The first stage is a cron job dumping the databases to a /container/application/backup/ directory. The second stage is when these files are copied over to the secure offsite location.