Your team has maintained a Jenkins server installed in an AWS EC2 instance.
The Jenkins server is mainly used to build the artifacts for a Java application.
At the moment, there is no disaster recovery strategy for this Jenkins server.
Your team needs to design a new disaster recovery plan with both RTO and RPO set as 24 hours.
Which disaster recovery strategy should the team choose?
Click on the arrows to vote for the correct answer
A. B. C. D.Correct Answer - A.
In this case, the EC2 has a Jenkins server installed which is used as a CI/CD server.
It is not an application in production, so its impact is quite low.
Other than that, as both RPO and RTO are 24 hours, there is plenty of time to recover the server using a backup when there is an outage.
The Backup & Restore strategy is enough for this scenario.
There are several methods to back the server, such as the Jenkins configuration files, AMI for the EC2 instance, EBS daily snapshots, etc.
About different disaster recovery levels in AWS, refer to https://www.youtube.com/watch?v=lK_t_dhUh5I and https://aws.amazon.com/disaster-recovery/
Option A is CORRECT: Because the Backup & Restore strategy is the most suitable and cost-efficient one considering the given RPO and RTO.
Option B and D are incorrect: Refer to the above explanations.
The team needs to design a disaster recovery plan for the Jenkins server with RTO (Recovery Time Objective) and RPO (Recovery Point Objective) set as 24 hours. RTO is the maximum acceptable downtime for the system, and RPO is the maximum acceptable data loss in case of a failure. Here are the explanations of the four options and their suitability:
A. Backup & Restore strategy: This strategy involves taking regular backups of the Jenkins server configuration files and storing them in an S3 bucket. The team can use CloudFormation templates to provision the necessary AWS resources, such as an EC2 instance and a database server. In case of a failure, the team can restore the Jenkins server from the latest backup. This strategy is suitable for a scenario where the RTO and RPO are not very stringent, and the data can tolerate a maximum loss of 24 hours. However, the restore process can take longer, depending on the size of the backup and the complexity of the server configuration.
B. Pilot Light strategy: This strategy involves maintaining a small, scaled-down version of the Jenkins server in another AWS region, using an AMI (Amazon Machine Image). The team can stop this instance to save cost, and in case of a disaster, they can launch it and scale it up to handle the load. This strategy is suitable for a scenario where the RTO is crucial, and the team needs to recover the system quickly. However, the RPO can be longer than 24 hours, as the data needs to be replicated from the primary server to the Pilot Light server.
C. Warm Standby strategy: This strategy involves maintaining a smaller size EC2 instance in the same region but different VPC as a standby. The standby server can have a copy of the Jenkins configuration and data files. The standby server can be updated at regular intervals to ensure that it is up to date with the primary server. In case of a failure, the team can switch to the standby server and start the application. This strategy is suitable for a scenario where the RTO and RPO are crucial, and the team needs to recover the system quickly with minimal data loss.
D. Hot Standby (Multi Site) strategy: This strategy involves maintaining a fully operational Jenkins server instance in another AWS region. The team can keep the server in sync with the primary server using various replication techniques, such as database replication or file synchronization. In case of a failure, the team can redirect the traffic to the standby server and start the application. This strategy is suitable for a scenario where the RTO and RPO are very stringent, and the team needs to recover the system instantly with zero data loss.
In summary, the team needs to choose the disaster recovery strategy that aligns with their RTO and RPO requirements. If the team can tolerate longer recovery times and data loss, they can choose a Backup & Restore strategy. If the team needs to recover the system quickly, they can choose a Pilot Light or Warm Standby strategy. If the team needs instant recovery with zero data loss, they can choose a Hot Standby strategy.