Skip to content

Restore MiaRec

MiaRec data can be restored in various disaster scenarios. Steps can vary based on the scope of the restoration.

  • Complete Reinstall of MiaRec cluster (all-in-one configuration)

  • Complete Reinstall MiaRec cluster (decoupled configuration).

  • Partial Reinstall of Database component only (decoupled configuration).

Retrieve database backup from S3

In any restore scenario, you will need to retrieve the database backup file from S3 and load it to the database instance.

This can be accomplished either using AWS CLI directly on the database instance or manually downloading the file via the Amazon AWS Web portal and uploading it to the server via SCP protocol.

Option 1. Copy database backup from S3 to the Database instance using AWS CLI

Info

This will require AWS CLI, if the database instance has been replaced, this will need to be reinstalled. Those steps are listed earlier in this document.

Set AWS credentials

Using environmental variables, these values will be set for this session, but not be retained after the session is ended.

export AWS_ACCESS_KEY_ID=<AWS_ACCESS_KEY_ID>

export AWS_SECRET_ACCESS_KEY=<AWS_AC_KEY_ID>

Execute a copy command

aws s3 cp s3://{s3-bucket-name}/{filename} /path/to/destination

Let's break down those options.

  • aws s3 cp calls the aws cli utility and instructs it to copy a file from s3 bucket to local file path

  • s3://{s3-bucket-name} sets a source of the database backup file on S3 bucket.

  • /path/to/source - a destination path and file name of the restored database dump

Example 

aws s3 cp
s3://miarec-db-backup/miarecdb-db.example.com-2022.08.17-21.05.24.backup/tmp/miarecdb.backup

Verification

The object will be moved to the defined path. 

[centos@ip-172-31-63-218 ~]$ ls -l /tmp
total 28
...
-rw-rw-r--. 1 centos   centos    2142 Aug 24 17:59 miarecdb.backup

Option 2. Download a backup file from the Amazon AWS portal

The backup can be downloaded from the AWS S3 console and then transferred to the database instance using a utility like scp.

From Amazon S3 console at https://console.aws.amazon.com/s3/.

  1. Click the name of the Amazon S3 bucket where DB backups are stored.

    Click Bucket Name

  2. In the Object section, locate the corresponding backup file by looking at the timestamp.

    Locate Backup File

  3. Select Download from the item menu.

    Select Download

  4. The file will be downloaded to your current machine. Use an utility like scp to transfer the file to the server:

scp ~/miarecdb-db.example.com-2022.08.17-21.05.24.backup centos@x.x.x.x:/tmp/miarecdb.backup

Complete Reinstall of MiaRec Cluster (All-In-One and Decoupled)

In the event that an entire cluster, all-in-one or decoupled, is lost and needs to be reinstalled, the following steps can be executed to restore data:

  • Install all the software on new servers

  • Restore database (configuration, call metadata)

  • Restore audio files

  • Regenerate license keys

Prepare Ansible Controller Host

This process prepares the ansible controller to provision the MiaRec Cluster. The ansible controller can be a local machine, the all-in-one MiaRec instance, or one of the instances in a decoupled MiaRec cluster (usually a database instance).

The process is described here

Prepare Target Hosts

This process prepares host(s) to be provisioned. Execute this process on all host(s) in the MiaRec Cluster.

The process is described here

Configure Deployment

This process prepares the ansible inventory which defines what and how the cluster is provisioned. Execute this process on the ansible controller.

Info

MiaRec application versions are defined in this step. For successful restoration of the database in later steps, these versions must be the same or newer as the backed-up cluster.

The process is described here

Execute prepare-hosts.yml playbook to provision the server(s)

This playbook installs all the required software dependencies for MiaRec applications, including the creation of the miarecdb database that can be a target for data restoration in the next step.

Execute Playbook

Execute these commands from the ansible controller.

cd /opt/ansible-miarec

ansible-playbook -i hosts prepare-hosts.yml

Verification

Confirm satisfactory completion with zero items unreachable or failed.

PLAY RECAP ********************************************************************
...
miarec                :  ok=79   changed=42   unreachable=0    failed=0

Result

All host(s) will be provisioned with supporting software such as Redis, Python, and PostgreSQL. The database miarecdb will be created, however, there will be no data present in the database.

Restore Database with pg_restore utility

The following commands must be executed from the Database instance. In an all-in-one configuration, this will be a single server instance, in a decoupled architecture, this will be the instance listed in the [db] group in the ansible inventory.

Execute pg_restore from db instance

sudo -iu postgres pg_restore -d miarecdb /path/to/backup_file

Let's break down those options

  • suo -iu postgres instructs the shell to execute the trailing command to run as user postgres, this is required for authentication.

  • pg_restore calls pg_restore utility.

  • -d miarecdb connects to database miarecdb and restores directly into the database, this should always be miarecdb.

  • /path/to/backup_file - the file to restore from, keep in mind this needs to be accessible by the postgres user account. Change the file permissions or owner of the backup file if necessary using chmod and chown utilities.

Verification

The database will be restored, you can verify it by querying the database. 

sudo -iu postgres psql -d miarecdb -c "SELECT COUNT(*) FROM calls;"
The count of all calls in the database should be returned.

[centos@miarecdb ~]$ sudo -iu postgres psql -d miarecdb -c "SELECT COUNT(*) FROM calls;"
 count 
-------
    34
(1 row)

Run setup-miarec.yml playbook to install the MiaRec software

This playbook installs the MiaRec applications. This should be executed after the database is successfully restored.

!!! MiaRec application versions specified in the ansible inventory must be the same or newer as the previously backed up cluster.

Execute Playbook

Execute these commands from the ansible controller. 

cd /opt/ansible-miarec

ansible-playbook -i hosts setup-miarec.yml
Verification

Confirm satisfactory completion with zero items unreachable or failed. 

PLAY RECAP ********************************************************************
...
miarec                :  ok=79   changed=42   unreachable=0    failed=0

Result

You should now be able to access the new instance of MiaRec using the previously configured admin account, all configuration and call recordings should be accessible. Audio files may still need to be restored separately depending on an initial storage configuration for audio files.

Info

WARNING! Depending on the type of recovery, License keys will need to be regenerated, contact Miarec support for that.

Restore License Keys

License keys are stored as database objects. However, with a complete reinstall, previous keys may become invalid on new hardware and new keys must be generated.

Contact MiaRec support for assistance.

Restore Audio Files

When Relocate Audio Files job is used to move files to external storage, there is no need to follow the restoration steps. Audio files should be accessible on the same external storage device.

If the files were stored locally on the recording server, then copy the audio files from your existing backup location to the same location as was used previously on the original server.

Partial Reinstall, Database Component Only (Decoupled only)

In the event that a database becomes unavailable or corrupt, the following steps can be executed to reinstall the database instance and accomplish the following:

  • Reinstall the Database component

  • Restore Database (configuration, call metadata)

Prepare Ansible Controller Host

This might not be needed if the ansible controller was not affected.

This process prepares the ansible controller to provision the MiaRec Cluster. The ansible-controller can be a local machine, the All-In-One MiaRec instance, or one of the instances in a Decoupled MiaRec Cluster.

The process is described here

Prepare Target Hosts

This process prepares the database host to be provisioned.

The process is described here 2. Prepare target hosts

Configure Deployment

This process prepares the ansible inventory which defines how the cluster is provisioned. In this scenario, likely the only update will be to the db instance IP address, where a database service should be redeployed.

MiaRec Application versions are defined in this step. For successful restoration of the database in later steps, these versions must be the same or newer as the previously backed-up cluster.

Execute this process on the ansible controller.

The process is described here 3. Configure Deployment

Execute prepare-hosts.yml playbook to provision the server

This playbook installs all the required software dependencies for MiaRec applications, including the creation of an empty miarecdb database.

Execute Playbook

Execute these commands from the ansible controller. 

cd /opt/ansible-miarec

ansible-playbook -i hosts prepare-hosts.yml
Verification

Confirm satisfactory completion with zero items unreachable or failed 

PLAY RECAP ********************************************************************
...
miarec                :  ok=79   changed=42   unreachable=0    failed=0

Result

The database instance will be provisioned with supporting software such as redis, pgbouncer and postgresql. The postgres user will be created and the database miarecdb will be created, however, there will be no data present.

Restore Database with pg_restore utility

The following commands need to be executed from the Database Instance. This will be the instance listed in the [db] group in the ansible inventory.

Execute pg_restore from db instance 

sudo -iu postgres pg_restore -d miarecdb /path/to/backup_file

Let's break down those options

  • sudo -iu postgres instructs the shell to execute the trailing command to run as user postgres, this is required for authentication.

  • pg_restore calls pg_restore utility.

  • -d miarecdb connects to database miarecdb and restores directly into the database, this should always be miarecdb.

  • /path/to/backup_file - the file to restore from, keep in mind this needs to be accessible by the postgres user account.

Verification

The database will be restored, you can verify by querying the database.

sudo -iu postgres psql -d miarecdb -c "SELECT COUNT(*) FROM calls;"

The count of all calls in the database should be returned.

[centos@miarecdb ~]$ sudo -u postgres psql -d miarecdb -c "SELECT COUNT(*) FROM calls;"
 count 
-------
    34
(1 row)

Run setup-miarec.yml playbook to modify the existing MiaRec Applications

This playbook installs and/or updates MiaRec applications. In this case, the only action that will be applied updates to the miarecweb and miarec configuration INI files, directing the applications to the new database IP address.

This should be executed only after the database is successfully restored.

Info

MiaRec Application versions specified in the ansible inventory must be the same or newer as the previously backed up cluster.

Execute Playbook

Execute this command from the ansible controller. 

cd /opt/ansible-miarec

ansible-playbook -i hosts setup-miarec.yml

*Verification

Confirm satisfactory completion with zero items unreachable or failed 

PLAY RECAP ********************************************************************
...
miarec                :  ok=79   changed=42   unreachable=0    failed=0

Result

You should now be able to access the MiaRec cluster using the previously configured admin account, all configuration and call recordings should be accessible.

Restore License Keys

No Action is required. License keys are stored as database objects, and since the recorder was not changed, license keys are still valid.

Restore Audio Files

No Action is required, since the recorder was not modified, audio files should be intact.