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
- .jama backup, log in as the root user, and select option #3 in the backup tab
- .xml backup, log in as the root user and select option #2 in the backup tab
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
Comments
0 comments
Article is closed for comments.