Shares and Console backup and restore through the command line for APOD SOD WS (Shares and Console), SHOD (Shares and Console) and APOD SOD (Console Only)

IN THIS ARTICLE:

Description

This article details command-line instructions for backing up an APOD SOD (Console Only), APOD SOD WS (Console and Shares) or SHOD(Console and Shares) 3.6 and restoring it to a new 3.6 AMI. If you are still investigating Aspera on Demand options and want to learn more, please view the Aspera Cloud site for more info.

Before you start

A) Backup required files

This backup processes described in the next sections do not backup the following files, which you should do yourself prior to starting:

  • aspera.conf
  • system users / passwords / ssh keys
  • Node users
  • SSL certificates

I. Stop your product

For Console, go to the Console UI, navigate to Configuration > Background and stop all the background processes.

For Shares, run the following command:

# service aspera-shares stop

II. Back up the aspera.conf file

/opt/aspera/etc/aspera.conf

III. Back up SSH keys

Back up the following directory:

/root/.ssh

IV. Back up node users

# /opt/aspera/bin/asnodeadmin --backup=/backup/api-xfer-mapping

V. Back up Console files (if backing up/restoring Console)

  • /opt/aspera/console/config/database.yml
  • /opt/aspera/console/config/console.yml
  • /opt/aspera/console/config/secret.yml

VI. Back up SSL Certificates (APOD SOD WS or SHOD only)

Note: This step is only applicable if you have purchased SSL certificates and IBM Aspera Shares is installed on your machines.

# cp /opt/aspera/shares/conf/cert. key /backup/cert.key
# cp /opt/aspera/shares/conf/cert. pem /backup/cert.pem

VII. Migrate the Elastic IP address from the original Shares to the new Shares (APOD SOD WS or SHOD only)

You can skip this step if you DO NOT use Elastic IP address for your server. If you use a unique hostname with a dynamic IP address, you will need to update your DNS entry. The following steps are only necessary if you use an Elastic IP address from AWS.

1. Use the AWS interface to reassign the Elastic IP from the old instance to the new instance.
2. Navigate to AWS Elastic IP menu.
3. Select the IP address and disassociate the address from the old Shares instance
4. Select the IP address and associate Address with the new Shares instance

B) Check the entitlement on the current SHOD, APOD SOD WS, or APOD SOD instance

You can do this by running the following command:

# /opt/aspera/bin/alee-admin entitlement

Example of the output:

{
Customer ID: Test
License ID: 91530956-9809-4168-9e22- 312d210359e5
}

 

Backup and restore Shares

A) Backup Shares database

Tip: The Shares on Demand web UI and nginx service will still be available while performing a backup.

I. Run the following script as a root user

The script stops Shares on Demand services, backs up all necessary files, and restarts Shares on Demand. You cannot use this procedure with earlier versions of Shares on Demand.

# /opt/aspera/shares/u/setup/bin/backup /backup_dir

For example:

# /opt/aspera/shares/u/setup/bin/backup /tmp
Creating backup directory /tmp/20130627025459 ...
Checking status of aspera-shares ...
Status is running
mysqld is alive
Backing up the Shares database and config files ...
Backing up the SSL certificates ...
Done

II. Make a note of the ID of the created backup directory for future use. In the above example: 20130627025459

III. Backup database.yml from /opt/aspera/shares/u/shares/config on the new machine

D) Restore Shares from a Backup

I. Ensure that your IBM Aspera Shares on Demand backup is available

Verify that you have copied the Shares on Demand backup files to your new machine.

II. Stop Shares on Demand services

Run the script below as root. The script stops Shares on Demand services, restores Shares on Demand data, and restarts Shares on Demand. You cannot use this procedure with earlier versions of Shares on Demand.

# /opt/aspera/shares/u/setup/bin/restore /your_backup_dir/backup_id

Use the ID of the directory generated in the backup process.

For example, using the ID of the example directory generated in the previous section, we would run the following command:

# /opt/aspera/shares/u/setup/bin/restore /tmp/20130627025459

We would see the following output:

Checking status of aspera-shares ...
Status is running
mysqld is alive
Restoring the Shares database and config files ...
Migrating the Shares database ...
Initializing the Shares database ...
Configuring the stats collector to poll all nodes ...
Restoring the SSL certificates ...
Done

II. Make sure home directories of transfer users /home/xfer, /home/xfer2, etc. have been restored successfully on the new instance

IV. Replace database.yml under /opt/aspera/shares/u/shares/config on the new instance with the database.yml of the old instance of SHOD

Backup and restore Console

A) Backup Console

I. Stop Console background processes

Navigate to Configuration > Background from the Console menu and stop the background processes.

II. Backing up via asctl

To backup Console's database using the asctl command, execute the following command in a Terminal:

# asctl console:backup_database directory

This command uses mysqldump to create Console's MySQL database backup. The backup file, aspera_console.sql, is saved in the following directory:

  • /opt/aspera/console/backup/year-month-day_time

B) Restore Console

You can restore any back up of a Console database as long as you have access to the backup file.

I. Stop Console

# asctl console:stop

II. Restore the Console database

If you made a back up of the Console database with the asctl command, you can restore it with the following command, where dir is the date-stamped directory containing the desired backup file:

# asctl -v console:restore_database dir

For example:

# asctl -v console:restore_database /opt/aspera/console/backup/2013-1-16_164305

If you made a back up of the Console database with the web UI, you can restore it with the following command, where dir is the date-stamped directory containing the desired backup file:

# asctl -v console:restore_dir

For example:

$ asctl -v console:restore /tmp/console_full_backup_2013-1-16_00.57.28_UTC

III. Start Console

# asctl console:start

IV. Copy /opt/aspera/console/config/secret.yml from the old instance to /opt/aspera/console/config/secret.yml on the new SHOD instance

V. Copy /opt/aspera/console/config/database.yml from the old instance to /opt/aspera/console/config/database.yml on the new instance

VI. Make sure to restore system users / passwords / ssh keys from the old instance to the new instance

Steps to be performed on the new instance for both Shares and Console

A) Delete all existing Node API users with ‘internal’ ACLS flag set except “nodeadmin”

For example:

List of node user(s):

              user       system/transfer user       acls
====================    =======================    ====================   

s_el_1454734711       s_el_1454734711_sys     [internal]

B) Enable web entitlement

I. Enable web entitlement for Shares

1. Shares comes with a wrapper utility, so you can turn the feature on and off with one command line call. 

To turn off shares entitlement:

# /opt/aspera/shares/u/shares/bin/run rake aspera:ami:entitlement:license_mode_off

To turn on shares entitlement: 

# /opt/aspera/shares/u/shares/bin/run rake aspera:ami:entitlement:license_mode_on

2. To entitle the web application via the command line, run the following (where you must substitute a valid customer ID and entitlement key, in this case from the old instance):

# /opt/aspera/shares/u/shares/bin/run rake aspera:ami:entitlement:config_license_server EL_KEY="cd0904ae-f85a-4e3b- 8ae0-615d79e5dea1" EL_CUSTOMER_ID="Test"

II. Enable web entitlement for Console

1. Run the following commands:

# cd /opt/aspera/console/
# export RAILS_ENV=production
# export PATH=/opt/aspera/common/ruby/ bin:$PATH

To turn off entitlement, you would run the following:

# rake --trace aspera:ami:entitlement:license_mode_off

To turn on entitlement, you would run the following:

# rake --trace aspera:ami:entitlement:license_mode_on

2. To entitle the web application via the command line, run the following (where you must substitute a valid customer ID and entitlement key, in this case from the old instance):

# rake --trace aspera:ami:entitlement:config_license_server EL_KEY="cd0904ae-f85a-4e3b-8ae0-615d79e5dea1" EL_CUSTOMER_ID="Test"

C) Update the Node API users (xfer, xfer2, nodeadmin) passwords to the new instance ID

After restore, your node users will have as their password the old instance ID. You will need to update the passwords to the new instance ID.

To update the Node API user's password, which is used to connect the local node to Shares('xfer') and Console('nodeadmin'), use the following command:

# /opt/aspera/bin/asnodeadmin -m -u <nodeAPI_username> -p <new_instance_id> —internal

D) Restart your product

1. Restart Shares (APOD SOD WS & SHOD)

# service aspera-shares restart

2. Check runlevels after restore (APOD SOD WS & SHOD)

# /opt/aspera/shares/etc/runit/ runlevels
# ll setup
# ll up

3. Restart Console

# asctl all:restart

E) Login to the UI

I. Login to the Shares UI with username 'admin' and password as your old instance ID

On the left panel click the node to and select Edit. Set the Node API user 'xfer' password to the new instance ID and then click the Update Node button.

II. Login to Console UI  with username 'admin' and password 'old_instance_console password'

Edit the local node by going to the Nodes tab. Click the Managed Nodes Button and select Edit the Local Managed Node. Navigate to the Credentials tab. Set the Node API user password to the new instance ID.

Click the Test Credentials button and make sure the node was connected successfully to Console


For any questions or further assistance, please contact Aspera Support.

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.
Powered by Zendesk