IMPORTANT: Backups and upgrade procedures

With the release of Orchestrator 2.3 we intended to simplify even more the installation and upgrade procedures to allow all our users to be fully autonomous on managing the platform.

For the time being we are focusing on the linux version of Orchestrator, soon we will expand to the Windows version.

While having a simplified installation and upgrade procedure makes a lot of sense, it is very important to take some preparation steps.

Make sure you have a full backup of the platform

 It might seem obvious, but this is the most important step of the entire process, both for a single installation or an high availability system.

A backup of Orchestrator consists on saving two main components:

- the database (usually called orchestrator within Aspera common shipped MySql)

- the var folders (usually under /opt/aspera/var there are 3 folders to backup ./config/orchestrator ./run/orchestrator ./archive/orchestrator, the last one being optional)

Backup for Orchestrator versions before 2.3.0

We strongly suggest to perform a backup with the orchestrator service stopped (not mandatory, but suggested).

Log into the server via SSH and make sure you are root or at least a superuser

  1. Create a snapshot of the database:
    /opt/aspera/common/mysql/bin/mysqldump -uuser -ppassword orchestrator > /tmp/orchestrator_db_backup.sql
    NOTE: user and password must be adapted to your configuration. If you don't know what the values are you can check the file /opt/aspera/var/config/orchestrator/database.yml (or if it does not exist /opt/aspera/orchestrator/config/database.yml)
  2. Create an archive of the run time folders:
    tar cvzf /target_folder/orchestrator-backup.tar.gz /tmp/orchestrator_db_backup.sql /opt/aspera/var/config/orchestrator /opt/aspera/var/run/orchestrator /opt/aspera/var/archive/orchestrator
    NOTE: replace target_folder with the destination folder for your backups, and use a name with a date suffix instead of orchestrator-backup.tar.gz

Backup for Orchestrator version after 2.3.0

We strongly suggest to perform a backup with the orchestrator service stopped (not mandatory, but suggested).

Log into the server via SSH and make sure you are root or at least a superuser

  1. Use asctl to create a DB backup
    asctl orchestrator:backup_database /tmp/orchestrator_db_backup.sql
  2. Create an archive of the run time folders:
    tar cvzf /target_folder/orchestrator-backup.tar.gz /tmp/orchestrator_db_backup.sql /opt/aspera/var/config/orchestrator /opt/aspera/var/run/orchestrator /opt/aspera/var/archive/orchestrator
    NOTE: replace target_folder with the destination folder for your backups, and use a name with a date suffix instead of orchestrator-backup.tar.gz

Backup for Orchestrator with ACM (only for HA installation)

We strongly suggest to perform a backup with the orchestrator service stopped (not mandatory, but suggested).

Log into the server via SSH and make sure you are root or at least a superuser

  1. Use acm to create a DB backup
    /opt/aspera/acm/bin/amcctl -b 
    NOTE: in the current version backups are generated under this folder: /opt/aspera/var/archive/orchestrator/backups. It is strongly recommended to symlink this folder to a secure storage location or to manually move the created back up file to a secure storage location, especially if /opt/aspera/var/archive it is not in a shared storage.

Restoring a backed up version

While the procedure of restoring a backup is as straight forward as the one for creating the backup, we strongly recommend to get in touch with Aspera support or with your Aspera ps main contact to get assistance in restoring the platform.

Important notes on using VMs

 In many scenarios Aspera Orchestrator is installed on virtual hardware (VMs) instead that physical hardware. This is perfectly fine but few precautions need to be taken when doing backups:

  1. Always make sure to move your back up files into an external storage. If the backup is stored locally, reverting to previous snapshots will delete the backup and there is nothing that can be done.
  2. In HA scenarios, there are multiple files that need to be shared between the different VMs. For this reason a shared storage is mandatory to implement HA. In this case it is important to understand that not everything is backed up when you create a snapshot, and reverting to a previous snapshot can lead to a completely corrupted platform since the data base is not reverted back.
  3. As a general rule, VM snapshot are NOT a a failure-proof procedure to backup Aspera products. Same goes for Aspera Orchestrator. You should consider performing both VM snapshots and complete Orchestrator backups

For a full description on backup and restore procedures, please refer to the administration guide that you can find in the forum.

0 Comments

Please sign in to leave a comment.
Powered by Zendesk