Backups and recovery¶

Backups in Canopy are separated into the following types:

Database
File data (uploads, templates, etc.)
Configuration data

The following sections describe each one of these, why they should be backed up and provides some guidance.

Note

Our Copy/Backup/Restore instance data and files guide is the quickest way to get started. It focuses on the practical steps invovled to backup or migrate a Canopy instance.

The information in this guide serves more as a high level overview than a practical guide.

Summary of backup steps for minor release upgrades¶

For backups that are performed routinely or for minor release upgrades, the high level steps are:

Backup Canopy database. See Database backup
Backup Canopy configuration files located in /etc/canopy. See File data backup
Backup Canopy data located in /var/opt/checksec/canopy/. See Configuration data backup

Database backup¶

The Canopy database stores practically everything relating to Canopy, with the exception of the uploaded files and templates. It is a critical component to running Canopy. By default, Canopy runs on PostgreSQL, and as such we can follow simple backup routines for PostgreSQL itself.

This section is PostgreSQL specific. The concepts should be transferable to Oracle databases also, although the specifics will be different. In Oracle environments, DBA support is usually available to assist with such activities, whom should also have environment-specific knowledge (which is usually important in such cases).

Backup PostgreSQL Database¶

To perform a simple database backup of the Canopy database, run the following command:

sudo -u postgres pg_dump -F c -d canopy > canopy_db.sqlc

For further information on backing up PostgreSQL and options for automation, see https://wiki.postgresql.org/wiki/Automated_Backup_on_Linux.

Other database operations: removing client data¶

Warning

This deletes ALL client/project/phase/report/finding/asset/example data!!!

As root:

sudo -u postgres psql canopy -c 'truncate canopy_company cascade'
sudo -u postgres psql canopy -c 'truncate canopy_activityentry cascade'

File data backup¶

Canopy stores all uploads (tool data, images, templates, and other shared files) on the file system, and references them in the database. Backing up the database alone is not sufficient for backing up all of the data stored in Canopy. In order to backup the file data, ensure that you take a copy of the following directories:

/var/opt/checksec/canopy/ for all canopy data

Example command, executed as the root user:

tar -zcf canopy_data.tgz /var/opt/checksec/canopy/

Configuration data backup¶

Canopy’s configuration data should also be backed up as needed. Canopy’s configuration data is stored under /etc/canopy/.

Example command, executed as the root user:

tar -zcf canopy_configs.tgz /etc/canopy/

Backup guidance¶

There are many options to consider when making a backup. For example, do you want to perform local backups only? Do you need off-site backups? Are there any data security concerns for transfer and storing Canopy’s data at rest? These questions are out of scope for this discussion. As an example scenario, you might want to backup the database, files and configuration data, place them into an archive, PGP encrypt it and copy it to an off-site host. This could then be automated to run daily/weekly via cron. You might also consider storing the data on a NAS or other redundant storage, and the database on a database cluster and the configuration data in a configuration management system (CMS); all of which may have their own backups in place already. Each organisation will have it’s own specific requirements.

What about recovery?¶

In order to recover Canopy from a backup:

Install a clean Canopy server (see Installation).
Load the database backup:
```
sudo -u postgres pg_restore -c -C -d postgres --if-exists < canopy_db.sqlc
```
Warning

This command will report the number of errors encountered during the import. It should generally be 2 and relate to the creation of the public schema. Any other errors encountered past the first few lines of output should not be ignored.

Warning

This will wipe the existing database before restoring the backup!!!
Copy the configuration data into /etc/canopy. Review the canopy.ini and other configuration files installed on the clean server under /etc/canopy and ensure that any new configuration settings are maintained during the copy.

Example command, executed as the root user:
```
tar -xvf canopy_configs.tgz -C /
```
Copy the Canopy data (files) into the correct location on the server (/var/opt/checksec/canopy/).

Example command, executed as the root user:
```
tar -xvf canopy_data.tgz -C /
```

Note

The Canopy service should be shutdown during recovery (as root user):

systemctl stop canopy canopy-celery

and started again afterwards (as root user):

systemctl start canopy canopy-celery

Note

If you have installed a newer version of Canopy on the new server then please execute the following before starting the services again:

canopy-manage postinstall

Virtual machines¶

Many users run Canopy on virtual machines and rely on snapshots for backup and restore purposes. This is a good approach, where it is supported, although it does result in maintaining a backup of the operating system and other data. However, it does allow for quick recovery of fully working systems. Overall, virtual machines are a solid approach to ensuring Canopy is both backed up and readily recoverable.