Data backups & Deployment Migrations

Dana Medhaug
Dana Medhaug
  • Updated

Author: Dana Medhaug

Updated: July 2024

Audience: Everyone

Environment: Self-hosted - Data Backups

Deployment Migration(s):

  • On-premises to Cloud Migrations
  • On-premises to Customer-Validated Cloud Migrations

Summary

Our top recommended backup file type for deployment migrations is the .jama backup file.

Customers must provide database backups and assets during deployment migrations, including attachments, avatars, reports, diagrams, equations, and metrics.

Assets must be backed up separately by tar-ing them for backups other than .jama files. For KOTS installations, customers must exec into the core-0 pod to perform this.

Backup procedures involve selecting options from the backup tab based on the backup type (e.g., option #3 for .jama backup, option #2 for XML backup).

The size of the data set is categorized into small, medium, and large based on the data size for each backup type (.jama, XML, MySQLDump).

Our top recommended backup file type for deployment migrations is the .jama backup file. This comprehensive option, accessible through the backup tab in Jama Connect®, encapsulates all necessary data, including the database and various assets such as attachments, reports, diagrams, equations, and metrics. It is particularly advantageous for small to medium-sized datasets and is fully compatible with MSSQL and MySQL environments. The ease of access and completeness of information make the .jama backup file the optimal choice for ensuring a smooth and efficient migration process.

.jama backup file

This option is accessed through the backup tab in Jama Connect®. It contains all the necessary information, including the database and various assets. It is suitable for small—to medium-sized datasets and compatible with MSSQL and MySQL.

To create a backup of your data on Jama Connect®, log in as root and download the .jama backup file from the backup tab. This file contains all the necessary information, including the database and various assets like attachments, reports, diagrams, equations, and metrics. It is an excellent option for small to medium-sized data sets and is compatible with MSSQL and MySQL. When you click to download the .jama backup, the file will be located in the /data/contour/backups directory for native replicated installations; for KOTS installs, the file will be located in the core-0 pod in the /home/contour/tenant/tenant_name/backup directory on the application server. Customers can exec into the core-0 pod to retrieve the backup file by using.

kubectl exec --stdin --tty core-0 /bin/bash

 .XML FORMAT

Similar to the .jama backup, accessed through the backup tab, it only includes the database, not assets. This is helpful in moving from MSSQL to MySQL with large datasets.

To create a backup file in .xml format, you can follow the same steps for creating a .jama backup file from the backup tab. However, you need to log in as the root user of the application. The XML backup option helps move from MSSQL to MySQL, which has a large dataset. In such scenarios, the .jama option is not suitable. The XML backup file contains only the database, not the assets. You must back up the assets separately. After clicking the button to download the XML backup, the file will be located in the /data/contour/backups directory for native replicated installations; for KOTS installs, the file will be located in the core-0 pod in the /home/contour/tenant/tenant_name/backup directory on the application server. Customers can exec into the core-0 pod to retrieve the backup file by using.

kubectl exec --stdin --tty core-0 /bin/bash

MSSQL proprietary backup

Recommended for extensive data on MSSQL, with separate asset backup following MSSQL documentation. Refer to MSSQL guide MSSQL documentation

MySQLDump

Recommended for customers already on MySQL with extensive data. The command provided for taking MySQLDump.

The MySQLDump file is for customers already on MySQL with extensive data. We provide the command below for them to take the MySQLDump.

mysqldump --max-allowed-packet=25M --single-transaction --skip-add-locks --routines --set-gtid-purged=OFF -u root -p databasename > databasename.sql

Backing up assets

When any option other than a .jama file is needed, the assets must be backed up and sent to us separately. We do this by having customers "tar up" the assets. They must navigate to /data/contour and run the command below.

tar -czvf assets.tar.gz avatars/ attachments/ diagrams/ reports/ equations/ metrics/

With KOTS installations, the customer must exec into the core-0 pod, navigate to the /home/contour/tenant/tenant_name/ directory, and use the tar command above to tar their assets.

Taking the backup

  1. .jama backup, log in as the root user, and select option #3 in the backup tab
    2023-12-12_09-23-56.png
  2. .xml backup, log in as the root user and select option #2 in the backup tab
    2023-12-12_09-23-56.png

Data Set Sizing

Small - XML = 1G or less, .jama = 2GB or less, MySQLDump = 1G or less

Medium - XML = 2G - 3G, .jama = 2GB - 3G, MySQLDump = 2G - 3G

Large - XML = 3G or more, .jama = 3GB or more, MySQLDump = 3G or more

 

Please feel free to leave feedback in the comments below.

 

Related to

Was this article helpful?

1 out of 1 found this helpful

Have more questions? Submit a request

Comments

0 comments

Article is closed for comments.