Restoring Backups

All Webslice Containers are automatically backed up daily, and you can take manual backups whenever you need, so you’ll always have a recent copy of your website or application to roll back to. Containers covered by Managed Services have a one-click Backup Restore feature in the Webslice Console - incredibly handy when something has gone wrong and you need a quick recovery.

How to Restore a Backup From the Webslice Console

If your Webslice Containers are covered by Business or Premier Support and Management, then you can restore backups straight from the Webslice Console.

Look in the Container’s Backups tab for a list of backups to choose from.

Once you’ve chosen a backup to restore, the system will take a new backup. Then the restore process will begin.

How to Manually Restore a Backup

SSH users can access the /container/backups/ directory, which is the base path for backups. You’ll find subdirectories for each individual backup, named for the relevant day and time. A symbolic latest link points to the newest backup.

Within each backup’s subdirectory you’ll see a folder structure that closely mirrors the Container’s folder structure. From here, the steps to take depend on the image that the Container is running.

Restoring a MySQL database for a Web Container

The example code in these steps will restore the latest backup.

Connect to your Container via SSH.
Go to the directory that contains the backup file you want to restore and list the dump filename.
```
cd /container/backups/latest/databases/
ls
```
Uncompress the file and restore it into the database. The command below is a template: replace the UPPERCASE strings, including the database username and password, as required.
```
gunzip < FILENAME.sql.gz | mysql -h MYSQL_HOSTNAME -u USERNAME -p DATABASE
```
If you are prompted, enter the database username and password.
If the restore process is successful, no data will be returned. Check that the database has been properly restored.

For more help with command parameters, see Database documentation.

Restoring a Web Container’s Application Files

Like the example above, these steps will restore the latest backup.

Connect to your Container via SSH.
Go to the directory that contains the backup file you want to restore and check that the files look like you expect.
```
cd /container/backups/
ls
ls /container/backups/latest/application/
```
Copy the files to the running Container. Remember that this example code is for the latest backup - you might need to edit it.
```
rsync --archive --stats --delete /container/backups/latest/application/ /container/application/
```
Test your application to check that the backup has been restored properly.

Restoring a Web Container’s Configuration Files

There are two ways to go about this. One option is to compare backup files to your current configuration and only restore those files that need to change back. The other, easier, approach is to restore all config files together. That’s what these steps will achieve:

Connect to your Container via SSH.
Open the directory with the config files you want to restore, and check that they look like you expect. This code will work for the latest backup:
```
cd /container/backups/
ls
ls /container/backups/latest/config/
```
Copy the files to the running container (remember that this example code is for restoring the latest backup).
```
rsync --archive --stats --delete /container/backups/latest/config/ /container/config/
```
To apply the new config files, reboot the Container.
Test that the Container works as expected.

Restoring a PostgreSQL Container Database

PostgreSQL back-ups are a two-stage operation. First, a cron job dumps the database to the directory /container/application/backup/. Then these files are copied to an offsite location.

The restoration process is similar to restoring a MySQL database. The steps below describe how to restore the latest backup. If you need to know more about the parameters and default passwords used, see: [Connecting to a Container]( ## 008 ).

Connect to your Container via SSH.
Open the directory with the config files you want to restore, and check the database dump filename.
```
cd /container/backups/latest/application/backup/
ls
```
If you need to, drop that database you want to restore and then recreate it.
Using a command based on the template below, uncompress the file and restore it into the database. You will need to replace the UPPERCASE strings.
```
gunzip < FILENAME.dump.gz | psql -h PGSQL_HOSTNAME -U USERNAME DATABASE
```
If you are prompted, enter the database username and password.
Check that the database has been restored as you expected.

Restoring a MongoDB Container Database

MongoDB back-ups are a two-stage operation. First, a cron job dumps the database to the directory /container/application/backup/. Then these files are copied to an offsite location.

The restoration process is similar to restoring a PostgreSQL database. The steps below describe how to restore the latest backup. You will need to edit some of the code snippets.

Connect to your Container via SSH.
Open the directory with the config files you want to restore, and check the database dump filename.
```
cd /container/backups/latest/application/backup/
ls
```
If you need to, remove the database that you’re going to restore. Use this command as a template, replacing the UPPERCASE strings:
```
mongo --host MONGO_HOSTNAME
use DATABASE
db.dropDatabase()
exit
```
Use the code below as a template to restore the backup files into the database. Again, you will need to replace the UPPERCASE strings.
```
mongorestore --host  MONGO_HOSTNAME --nsInclude DATABASE.* /container/application/backup/
```
Check that the database has been restored as you expected.