Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Resources to Backup 

Since an installation in AWS is done using Infrastructure as Code, it is not necessary to back up the application itself. The resources that need to be backed up are

title
Info

EFS

If you have used another NFS solution instead of EFS (FSx suite e.g.), that is fully comparable, however backup instructions would have to be looked up separately.

  • System database (hosted in RDS database, or in case of Derby EFS disk storage)

  • Disk-based Aggregation data (Stored on EFS storage)

  • Database based Aggregation data (Stored in Redis storage, like MemoryDB)

  • Duplicate UDR detection (Stored on EFS disk storage)

General Requirements

Regardless of the method chosen for the provisioning of backup and restore operations, there are requirements that must be met: 

  1. When an instance is restored from a backup image, the database backup must be older than the disk backup. The reason for this is to avoid database references to non-existing data.

  2. Temporary files must be excluded from the backups. This is to avoid inconsistent or partial data. 

Info
title

Temporary Data

Temporary files can be identified by various identifiers that form the file names:

  • Temporary files – Prefixed with "TEMP."

  • DupUDR function temporary files – They are in a separate folder called "tmp". 

  • InterWorkFlow temporary files – Stored in a separate folder called "DR_TMP_DIR". 

  • Archiving function files – Stored in a separate folder called "pending". 

Creating a Backup Plan

1. Setup Cold Backup Window

...

See https://docs.aws.amazon.com/aws-backup/latest/devguide/create-auto-backup.html for details.

Configure the following:

  • Schedule – When the backup occurs. Make sure to align this with you cold backup window defined in previous step!

  • Backup window – The window of time in which the backup needs to start. Make sure to align this with you cold backup window defined in previous step!

  • Lifecycle – When to move a recovery point to cold storage and when to delete it

  • Backup vault – Used to organize recovery points created by the Backup rule.

  • Backups should be taken as snapshot backups. I.e do not enable "continuous backups for point-in-time recovery (PITR)" as that can lead to unpredictable behaviour.

If AWS Backup is not available as a service in your region, the recommendation is to use EFS to EFS backup, see https://aws.amazon.com/solutions/implementations/efs-to-efs-backup-solution/.

...

To protect against multi availability-zone failures (unlikely) or human errors (more likely) snapshot backups to different region can be enabled. This is described in https://docs.aws.amazon.com/memorydb/latest/devguide/snapshots-automatic.html. Follow these instructions to configure:

  • Snapshot window - A period during each day when MemoryDB begins creating a snapshot. The minimum length for the snapshot window is 60 minutes. Although not required for consistency, it is recommended to align this with your cold backup window (if enabled) as configured in step 1.

  • Snapshot retention

    limit –

    limit – The number of days the snapshot is retained in Amazon S3. 

5. Kubernetes Managed Resources

Kubernetes managed resources are:

  • Image Removed platform

    Usage Engine platform application

  • ECDs - Solution deployment descriptors

  • Supporting applications like Prometheus, Grafana and ElasticSearch (note that the state and data held by these supporting applications are not covered by the scope of this document)

It is recommended to install all Kubernetes managed resources as Helm charts managed by automated CI/CD pipelines. The process to setup such a pipeline is described in Installation Procedure for CI Pipeline(4.3)

...