Skip to main content

Introduction

There are two distinct domains to consider when defining backup strategies and solutions, the Control Tower and the edge sites with Edge Enforcers. Different data needs to be considered in those domains.

Control Tower data:

  1. Control Tower configuration and state
  2. Customer data such as application specifications, deployment specifications, secrets, site configuration etc.

Edge site data (hosts with Edge Enforcer installed):

  1. Edge Enforcer configuration and state
  2. Application specific data stored on volumes (ephemeral and persistent)
  3. Other files not within the Avassa context

Below follows a walk-through of solutions for these domains

Control Tower SaaS​

If you are using the hosted Control Tower provided as a service from Avassa, there is no need to consider backup strategies. That is part of the Avassa service. Avassa is periodically performing automatic backups of the Control Tower (A) as well as customer artifacts (B).

Avassa has established operational procedures to restore the corresponding complete environment.

Notes:

  • Three Control Tower instances/replicas are running which manages single point of failure scenarios making backup/restore superflous in most cases.
  • The backup/restore should be considered a disaster recovery in the case of a total outage for a cloud zone, not to restore a single "file".

Recommendations:

  • Manage the application specifications, deployment specifications etc in a CI/CD pipeline with code repositories. Push them to the Control Tower as part of a deployment step. In that way you have full versioning and internal control of backups of those artifacts.
  • Configure Avassa to use external authentication. Although Avassa has full support for built-in user management (including backup/restore) it is recommended to use your enterprise authentication method like Azure Entra ID to manage users.

On-premise Control Tower​

If you are using an on-premise Control Tower follow instructions outlined in the installation guide for on-premise installations.

Edge Site backup​

Avassa provides tools to backup and restore the Edge Enforcer state and configuration. Application data written on volumes is out of scope for Avassa. Any other files and data on the edge host is also out of scope for the Avassa procedures.

There are two kinds of Avassa tooling for backup and restore of a site:

  1. Restore from Control Tower configuration, the state for an edge site is a result of a desired configuration of the site and hosts in the Control Tower
  2. Local backup of Edge Enforcer per host.

Alternative 1: restore edge from Control Tower​

Depending on the restore scenario, you add a host to the site or create a new site with a new host. Since you have the previous site and host configuration available in Control Tower you can reuse that for the new host. This will bring the site and host up. After that make sure you have correct site labels and deployment label match expressions. Perform action redeploy on deployments to deploy the applications to the site.

If the target for the restore process is a host within a multi-host site you can add a new host to the site. Make sure it has the same config as the previous one. In this case you can perform a rebalance action on the site to spread the running applications across all the hosts including the new one.

Read more in site maintenance documentation.

Alternative 2: restore edge from Edge Enforcer backup​

The Edge Enforcer has a built-in backup/restore tool for systemd systems. This is not enabled by default when installing, but is possible to enable with the --enable-backups while using the supd install script.

  --enable-backups       Enable backup services which will, by default, perform a daily backup.
                         NOTE: only applicable for systemd systems.

In case the Edge Enforces was previously installed without backups, it can be enabled:

sudo systemctl enable backup-supd.service
sudo systemctl enable backup-supd.timer
sudo systemctl start backup-supd.service
sudo systemctl start backup-supd.timer

On the host where supd is installed the backup and restore scripts are available at /var/lib/supd/state/bin

 backup-supd
 restore-supd

The backups will generate a tar.gz file in /var/lib/supd/backups like

<host-name>-<NNN>.2025-04-11T1200Z.tar.gz

The five latest backups are saved.

Restoring this file will bring back the edge host to the state saved in the backup.

⚠️ Make sure that you automatically copy these files to a proper backup location since this is local file storage.

To simplify automatic upload of a newly created backup the backup-supd script checks for the environment variable UPLOAD_SUPD_BACKUP_SCRIPT and if it is set it executes the command:

 "${UPLOAD_SUPD_BACKUP_SCRIPT}" "${bup_file}"

This makes it possble to hook in a cusomized upload script.

⚠️ Make sure to set the environment variable UPLOAD_SUPD_BACKUP_SCRIPT in the correct context. By default the backup-supd script is invoked in the backup-supd.service script.

💡 One way to propagate an environment variable is to:

  1. create a backup-service override configuration file like /etc/systemd/system/backup-supd.service.d/override.conf with content:
[Service]
EnvironmentFile=/etc/default/backup-supd.service.env
  1. create a default environment file like: /etc/default/backup-supd.service.env with content:
UPLOAD_SUPD_BACKUP_SCRIPT=<PATH-TO-UPLOAD-SCRIPT>

To restore a supd backup file it is possible to either do this during installation by using the --restore option:

  --restore  BACKUP-FILE RESTORE-FILE Perform supd restore from backup file
                                      with migration instructions from restore file
                                      before supd is started. The RESTORE-FILE is a
                                      'sed' command file, typically with
                                      substitutions of IP addresses.

or using the restore-supd script directly:

Usage: bin/restore-supd [options] <supd-backup-file> <supd-restore-file>

Options:
  -v | --verbose      verbose output.
  --no-compression    omit compression when unpacking backup file.

<supd-restore-file> is a 'sed' command file containing needed
                    substitutions.

                    Example:
                       s/192,168,100,102/192,168,100,112/g
                       s/192,168,100,103/192,168,100,113/g
                       s/192,168,100,104/192,168,100,114/g