How to backup and restore APOD SOD (Console Only), APOD SOD WS (Console and Shares) and SHOD (Console and Shares) version 3.6

IN THIS ARTICLE:

 

Overview

This article is for customers who want to backup an APOD SOD (Console Only), APOD SOD WS (Console and Shares) or SHOD(Console and Shares) 3.6 and restore 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.

This process can be accomplished largely through the UI as described in this article, or largely on the command line as described in this Knowledge Base Article.

Procedure

A) Backup Console and Shares data and configuration on your SHOD 3.6 server

1) Backup the existing data and configuration

Via Console Web UI, go to Configuration > Save/Restore > Download Current Configuration and save the file to your local machine. 

Console_Backup.png

 

2) Connect to your SHOD from a Terminal/Command Prompt via SSH as root 

#  ssh -i customer's_perm -p 33001 ec2-user@ec2_host_IP
# sudo su -

3) Make a backup of Shares database into /tmp

# mkdir /tmp/shod-backup/
# /opt/aspera/shares/u/setup/bin/backup /tmp/shod-backup/

4) Backup other required files

I. Node user and transfer user mapping

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

II. SSL certificate files (if applicable)

If you have your own purchased SSL certificate, please back up the files by running the following commands:

# cp /opt/aspera/shares/etc/nginx/cert.key  /tmp/shod-backup/
# cp /opt/aspera/shares/etc/nginx/cert.pem  /tmp/shod-backup/

III. Obtain Customer ID and Entitlement ID

You need to know your customer ID and entitlement ID to entitle the new system. If you don't know these IDs, you can find out by running the following command:

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

IV. Back up /root/.ssh/

# cp -avr /root/.ssh /tmp/shod-backup/root/

5) Zip up the /tmp/shod-backup directory and move the file to a location where you can access from your new system

# cd /tmp/

# tar -cvzf shod-backup.tgz  shod-backup/

NOTE: now copy the file /tmp/shod-backup.tgz to your new AMI

B) Restore procedure on your new SHOD 3.6 server

1) Launch the same SHOD 3.6 AMI with the same SSH Key, Region and Security Group and entitle the new system

If you are not sure how to launch a new AMI, please see this article. Enter your customer ID and entitlement ID from the Web UI.

2) Backup initial configuration of Console and restore it with the backup files generated in Step A) - 1).

I. Backup initial Console data and configuration (to preserve some ami specific configurations)

Go to Configuration > Save/Restore > Download Current Configuration and save the file to your local machine.

II. Stop Console processes

Go to Configuration > Background and stop all processes.

Background_processes.png

 

III. Restore Configuration via Save/Restore

Go to Configuration > Save/Restore, click Browse and upload the configuration you saved from the old machine, click Restore.

Restore.png

IV. Restart MySQL and Console

 # asctl mysql:restart
# asctl console:restart

V. Copy the content in /root/.ssh on the old server and paste to /root/.ssh on the new server.

VI. Update the <server_name> section in /opt/aspera/etc/aspera.conf with the host name of the new server.

5.png 

3) Restore Shares

I. Run the following commands to stop Shares services:

 # service aspera-shares stop

II. Move the backup files from the old system to the new system and run the following commands:

# /opt/aspera/shares/u/setup/bin/restore /path/tothe/backupfiles
# /opt/aspera/bin/asnodeadmin --restore=/path/tothe/api-xfer-mapping
# service asperanoded restart

III. Restore SSL Certificate files

You can skip this step if you use a self-signed certificate.  This step is only necessary if you have a purchased SSL certificate.

Rename your existing SSL files:

# mv /opt/aspera/shares/conf/cert.key /opt/aspera/shares/conf/cert.key.org
# mv /opt/aspera/shares/conf/cert.pem /opt/aspera/shares/conf/cert.pem.org

Copy your back up SSL files to /opt/aspera/shares/conf:

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

 IV. Update the <server> section in aspera.conf to reflect the new hostname

You can skip this step if you DO NOT use a custom hostname for your server.

<server>
    <server_name>transfer.aspera.com</server_name>
</server>

 V. Add new Node users

You can skip this step if you use the default user setting.  This is only necessary if you added additional Node users on the original system.

#  /opt/aspera/bin/asnodeadmin -a username -p password -x system_user --acl-set "impersonation,internal"

 

4) Migrate the Elastic IP address from the original Shares to the new Shares

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.

I. Use the AWS interface to reassign the Elastic IP from the old instance to the new instance.

II. Navigate to AWS Elastic IP menu.

III. Select the IP address and disassociate the address from the old Shares instance

IV. Select the IP address and associate Address with the new Shares instance

 

C) Additional Steps

I. Restore home directories of transfer users /home/xfer, /home/xfer2, etc.

This step is needed only if the /home/xfer, /home/xfer2, .. directories are missing after running the previous steps.

II. (Optional step) Update the Node API users (xfer, xfer2, nodeadmin) with their password as the new instance ID .

After restore, your node users will have as their password the old instance ID. You may 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

III. Update MySQL password for console database users in database.yml using following commands:

Replace old_password with the password used on your old instance.

# /opt/aspera/common/mysql/bin/mysql -uroot –pnew_password

SET PASSWORD FOR 'root'@'localhost' = PASSWORD('old_password');
SET PASSWORD FOR 'root'@'127.0.0.1' = PASSWORD('old_password');
SET PASSWORD FOR 'aspera_reports'@'%' = PASSWORD('old_password');

IV. Edit /opt/aspera/shares/u/shares/config/database.yml

Find the production and production_reports section and replace old_password with the password that was set in the file on your old instance:

production:
database: "aspera_console"
username: "root"
password: "old_password"
<<: *server_defaults

production_reports:
database: "aspera_console_reports"
username: "aspera_reports"
password: "old_password"
<<: *server_defaults

 

Then restart Shares:

# service aspera-shares restart

V. Edit /opt/aspera/shares/.my.cnf

Replace old_password with the password that was set in the file on your old instance:

[client]
user = root
password = old_password
host = 127.0.0.1
port = 4406

VI. Check runlevels after restore

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

VII. Delete all internal Node API users except nodeadmin

For example, you can run the following commands to list the internal Node API users:

# cd /opt/aspera/bin/
# ./asnodeadmin -l --internal

You can then use the command below to delete internal users:

# ./asnodeadmin -d -u username --internal

VIII. Enable web entitlement for Shares (APOD SOD WS & SHOD)

1. Turn on Shares entitlement

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. (Optional step) Entitle Shares

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”’

IX. Enable web entitlement for Console

1. Turn on Console entitlement

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. (Optional step) Entitle Console

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"

X. Copy data (local node and local shares) from the old system to the new system.

XI. Restart your product

1. Restart Shares (APOD SOD WS & SHOD)

# service aspera-shares restart

2. Restart Console

# asctl all:restart

XII. Log into your new Shares

Use your original admin account and password to login to your new Shares. By default, the password is your instance ID. Click Test to check connection with the transfer node.  

8.png

XIII. Log into Aspera On Demand Console

Login with the credentials that you used on the old machine. Go to Nodes > edit,  update the node name and connect the node to Console.

Screenshot1cod.jpg

Screenshot2cod.jpg

 Screenshot3cod.jpg

 

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.
Powered by Zendesk