How to backup and restore SHOD v.3.2.2


This article is for customers who want to backup their v.3.2.2 SHOD (Shares On Demand) and restore it on a new v.3.2.2 SHOD AMI.  If you are still investigating Aspera on Demand options and want to learn more, please view the Aspera Cloud site for more info.


Migration Procedure

A) Backup Console and Shares data and configuration on your SHOD v.3.2.2 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. 


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 backup directory and stop Shares


# mkdir /tmp/shod-backup
# service aspera_shares_nginx stop
# service aspera_shares_delayed_job stop


4) Backup all the required items

I. Shares data and configuration

# /opt/aspera/shares/script/ backup DIR=/tmp/shod-backup

II. aspera.conf

# cp /opt/aspera/etc/aspera.conf /tmp/shod-backup

III. node user and transfer user mapping

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

IV. 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/conf/cert.key  /tmp/shod-backup/cert.key
# cp /opt/aspera/shares/conf/cert.pem  /tmp/shod-backup/cert.pem

V. Obtain Customer ID and Entitlement ID

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

# /opt/aspera/bin/alee-admin register  <enter> <enter> 

VI. Back up /root/.ssh/


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


B) Restore procedure on your new SHOD v.3.2.2 server

1) Launch a new v.3.2.2 SHOD instance 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 these processes:




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.



IV. Change directory to /opt/aspera/console/config and replace the following files with the same files you saved in Step 2) - I.





V. Restart mysql and console

 # asctl mysql:restart
# asctl console:restart


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


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


VIII. Run the following commands to create mysql user for DB Logger

  # cd /opt/aspera/console
 # export PATH=/opt/aspera/common/ruby/bin:$PATH
 # export RAILS_ENV=production
 # ruby ./script/console
 >> FaspNode.all.each {|n|n.grants_for_central}
 >> exit


 IX. Login to Aspera on Demand Console with the login credentials that you use on the old machine.  Go to Nodes -> edit,  update node name and connect node to Console





X. Restart asperacentral

    # service asperacentral restart



3) Restore Shares

I. Run the following commands to stop Shares services:

 # service aspera_shares_nginx stop 
# service aspera_shares_delayed_job stop


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


 # /opt/aspera/shares/script/ restore DIR=/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 exisiting SSL files

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

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.





 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


VI. Restart Nginx and the background service

 # service aspera_shares_nginx start
# service aspera_shares_delayed_job start


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.

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

      b) Navigate to AWS Elastic IP menu.

      c) Select the IP address and disassociate the address from the old Shares instance

      d) Select the IP address and associate Address with the new Shares instance


5) Log into your new Shares

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


Powered by Zendesk