To protect your application data (including teams, projects, APIs, and more), it's essential to perform regular backups.Apidog relies on a single SQL database to store most of its runtime application data. By backing up this database, you safeguard the majority of your data. In the event of an issue, such as during an upgrade, you can use this backup to restore your Apidog installation.Backing Up the Application Database#
Amazon RDS for the Application Database#
Amazon Web Services (AWS) provides established best practices for backing up and restoring Amazon RDS databases. We strongly recommend adhering to these guidelines and enabling Automated RDS Backups for enhanced reliability and data protection.Self-Hosted MySQL or MariaDB Database#
If you are hosting your own MySQL or MariaDB database, you should follow the standard procedures for backing up your database. For instance, when using MySQL for your application database, refer to MySQL’s official documentation for backing up your database.As long as you have a backup (dump) of the Apidog database, your data should be secure and easily restorable.Scheduling Automated Backups#
The following script provides an example for automating the backup process of your MySQL Docker instance data.1.
Create the backup script by executing touch /root/backups/mysql-backup.sh. Ensure that you replace <password> in the DB_PASS variable with your actual MySQL root password.
2.
To grant execute permissions to the script, run the following command: 3.
Add the desired crontab configuration to schedule the script. To edit the crontab file, execute the following command crontab -e:10 23 * * * sh /root/backups/mysql-backup.sh
Troubleshooting#
If you encounter issues during the cleanup process, consider the following:1.
Permission Denied: Ensure that you are using the correct MySQL credentials with appropriate permissions.
2.
Container Not Found: Double-check the MySQL container name and confirm that the container is running.
3.
Database Locked: Verify that no other processes are currently accessing or locking the database.
Backing Up Other Data#
Certain data, such as automated testing reports, user-uploaded files, and project icons, are not stored within the database. If you have configured an object storage service, these files will be stored externally. For backup purposes, refer to the backup strategies provided by the respective object storage service.Amazon S3: Amazon provides comprehensive best practices for backing up and restoring S3 data. We recommend enabling automated backups for S3. For more details, refer to the official guide: Using AWS Backup for Amazon S3 MinIO: MinIO also offers its own guidelines for data backup and recovery. For detailed instructions, refer to the Minio Documentation. If you have not configured an object storage service, Apidog will store these files locally by default. In this case, we recommend regular file-based backups. To automate this process, you can modify the APIDOG_DATA_DIR value in the Scheduling Automated Backups script to match your actual data directory.Resetting the Database for Proof-of-Concept (POC) Deployments#
This section is intended exclusively for POC (Proof of Concept) environments. Never perform these operations in production, as they will permanently delete all Apidog data.
In POC deployments, you may need to completely reset the Apidog database to start fresh. This process involves dropping the existing database and creating a new one. Proceed with caution, and ensure that you have adequate backups before performing this operation.