要約

AWS Backup uses backup windows (minimum 1-hour window) to set when a backup takes place on an EBS/RDS instance. That means there is no way to predict the exact time when a Backup will run, and only know the period it will happen. This article covers some strategies that Bamboo administrators can adopt to overcome that limitation and ensure consistency in EBS/RDS data and allow safety when in case of a restore request.

環境

• Bamboo Server and Data Center (all versions)
• AWS Backup
• Any other file-level backup solution that uses a Backup window instead of a specific time of the day

原因

The Bamboo server runs on AWS, and AWS Backup file-level backup is used. AWS Backup does not allow the System Administrator to select a proper Backup time. Concern about the backup and restoration of data raises.

ソリューション

Backup strategies

It is advisable to simultaneously perform backups of Bamboo components, including application folders such as the contents of the <bamboo-home> and <bamboo-install> directories and the database. If any of these backup steps are executed asynchronously, for instance, when utilising a backup window on AWS Backup, the risk of data loss during restoration increases.

When considering restoration, the database contents dictate the requirements of the application structure and its associated files. Consequently, any data on the file system created after the database backup will not be considered by the application after its restoration. This implies that the database data takes precedence over any file system content.

The impact of a gap between the database and file system backup may vary depending on the data volume. A few hours' gaps might not cause significant issues, but crucial Job artifacts and build results may be lost on a very busy instance.

If you opt for this strategy, ensure that the database backup is:

1. Scheduled to finish as close as possible to the commencement of the file-level backup
2. Can optionally run concurrently with the file-level backup if the Application is down
3. Does not run after the completion of the file-level backup.

Setting up a less busy time of day for Bamboo backup operations is also advised. With AWS Backups, this time can be utilised to shut down Bamboo optionally, perform the backup during the "window", and restart it once the window is complete. Combining this with a parallel database backup would further enhance the process.

Regarding Expiry, please ensure that you run the Backup either before or after the expiry process, but never during the expiry process.

We want to point out that a successful restoration of a Bamboo backup can't be guaranteed if the backup was executed while the application was online. Therefore, it is recommended to completely stop the application or employ the built-in PAUSE mechanism to halt all write operations temporarily. These operations can be resumed later using an UNPAUSE REST call. The steps for this process are documented in the associated knowledge base article, which includes a sample backup script:

• Automating Bamboo backup operations

As a safeguard, you can consider implementing the PAUSE and UNPAUSE REST calls through a pre- and post-script execution with AWS Step Functions.

Restoration

During restoration from a backup, the file-level backup timestamp should always be more recent than the database timestamp and the closest as possible to the DB timestamp. This ensures that the necessary file system objects are available for the database references in Bamboo to utilise. While this approach usually works, it may result in orphan objects on the file system beyond Bamboo's control. These objects will consume space but will not cause any harm.