Backing up Apidog

Avoid losing your application data (all of your teams, projects, APIs, etc.) by regularly backing up your data.

Apidog primarily uses a single SQL database to store most of its runtime application data. Therefore, backing up this database will safeguard most of your data. You can use this backup to restore your Apidog installation if anything goes wrong (e.g., during an upgrade).

Backing up the application database

Amazon RDS for the application database

Amazon has its own best practices on how to backup and restore RDS databases, so we'll defer to them. We recommend that you enable automated RDS Backups.

Instructions can be found in the Amazon RDS User Guide.

Self-hosted MySQL or MariaDB database

If you're hosting your own MySQL/MariaDB database, simply follow the same instructions you would use for making any normal database backup. For example, if you're using MySQL for your application database, you should follow MySQL's instructions for backing up your database.

As long as you have a dump of the Apidog database, you should be good to go.

Scheduling Automated Backups

The following script provides an example for regularly backing up your MySQL Docker instance data.

By default, it aligns with our Docker Compose Setup Guide.

Create the script by executing touch /root/backups/mysql-backup.sh. Remember to replace <password> in the DB_PASS variable with your actual MySQL root password.

Grant execute permissions for the script: chmod 700 mysql-backup.sh

Add the following crontab configuration by executing crontab -e:

10 23 * * * sh /root/backups/mysql-backup.sh

Troubleshooting

If you encounter issues during the cleanup process:

Permission Denied: Ensure you're using the correct MySQL credentials

Container Not Found: Verify the MySQL container name and that it's running

Database Locked: Make sure no other processes are accessing the database

Backing up other data

However, some data, such as automated testing team reports, user-uploaded files, and project icons, are not stored in the database.

If you have configured an object storage service, these data will be stored on the object storage service. You can refer to the backup method of this service to back up these data. For example:

Amazon has its own best practices on how to backup and restore S3 data, so we'll defer to them. We recommend that you enable automated S3 Backups. Instructions for S3 can be found in the Using AWS Backup for Amazon S3.

Minio also provides its own best practices for data backup and restore. You can find more information in the Minio Documentation.

If you have not configured an object storage service, Apidog will store these resources in a file-based manner by default. You can back up these files regular (you can utilize the Scheduling Automated Backups script by changing the APIDOG_DATA_DIR value to your actual DATA directory).

Resetting Database for Proof-of-Concept (POC) Deployments

⚠️ Warning: This section is intended for POC (Proof of Concept) environments only. Never perform these operations on production systems as they will permanently delete all your Apidog data.

During POC deployments, you may need to completely reset the Apidog database to start with a clean slate. This process involves dropping the existing database and creating a new one.

Backing up the application database#

Amazon RDS for the application database#

Self-hosted MySQL or MariaDB database#

Scheduling Automated Backups#

Troubleshooting#

Backing up other data#