Recovery Objectives (4.3)

Owned by Jenni Wallin
Last updated: Sept 20, 2024 by Jacob Almqvist
1 min read

Recovery Point Objective (RPO)

Usage Engine stores data in RDS database that can refer to data in a runtime storage that is either:

  • EFS disk storage

  • Redis MemoryDB storage

It is crucial that the data referred from the database actually exist in the runtime data storage. A failure to meet this criteria can result in unpredictable behaviour and a failure to execute business logic, i.e aborted workflows. The other dependency does not apply, i.e if data exist in the runtime storage but the referring data in the RDS database is missing, this will not lead to aborted workflows but just dataloss. As some dataloss is expected during a disaster recovery scenario but a failure to execute business logic can be fatal it is important that in recovery scenarios the resulting data on the file system is always newer than the data in the database. 

To achieve the above, RDS should be recovered using Point In Time Recovery (PITR) to be able to recover it to a point in time as close as possible before the EFS and MemoryDB backups were taken. For RPO this means that the total RPO is given by the RPO of the EFS backups, which is defined in the AWS Backup plan for EFS snapshot backups (https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html#automatic-backups), plus the backup interval of RDS automated backups, which is 5 minutes.

Recovery Time Objective (RTO)

RTO is given by the time it takes to restore a system after disaster according to Disaster Recovery (4.3). Estimated total time for recovery is 5 hours.

Â