Backup coverage and data retention

Backup types and data retention

root360 will provide data backup as managed service for know data stores. Following describes the configuration as well as data handling for the services in scope.  

Backup configuration by server type

Application servers

All application servers are provisioned by a configuration management system. Each new server with the same role (function) is provided by this procedure with the same configuration. The following distinction exists for securing user data:

Autoscaled App-Servers and Non-autoscaled application servers with active deployment

These application servers are regarded as stateless since the sources originate from the deployment and are kept for 30 days independent of the application server. We additionally create snapshots of these servers as explained below in 2).

Backup time of source code 

At each deployment run 

Retention time of source code

30 days

Backup type 

full backup 

Recovery time 

Approx. 1 hour 

To restore previous source code version, please send a request to service@root360.de.

App-Server with persistent data (no "Autoscaling")

Application servers whose data is locally managed and modified by e.g. SFTP or SSH are backed up during the night from 00:00 (midnight) to 03:00. The individual backups are available for 7 days for productions servers and 1 day for test and stage server. After that period, they are deleted. They are stored as a full backup via EBS snapshots.

Backup time 

00:00 - 03:00 

Retention time 

7 days for PROD, 1 day for TEST / STAGE 

Backup type 

full backup 

Restore time 

Approx. 2 hours 

To restore the backups, please send a request to support@root360.de.

Database instances

The database instances of AWS' relational database service (RDS) are backed up every night between 22:00 and 06:00. The backup is based on a snapshot method that requires less resources than a classic MySQL dump.

The backup is always done as a full backup.

Backup time 

22:00 - 06:00 hours 

Retention time 

7 days for PROD, 1 day for TEST / STAGE 

Backup type 

full backup 

Restore time 

About 1 hour (depending on the size of the database instance, this may take longer) 

Cost

Backup storage is billed as GB per month. Details are available at https://aws.amazon.com/rds/mysql/pricing/ and https://aws.amazon.com/rds/aurora/pricing/.
A calculation example is provided below.

To restore the backups please follow How to restore a database backup or send a request to support@root360.de to support you within Profession Service.

Root360 provides a new RDS instance during recovery from which the backup data can be copied. 
We do NOT automatically replace / overwrite our customer's data.

Other services

If requested, root360 provides additional services such as NFS or MongoDB which are not offered directly via AWS. The information needed to (re-)create these servers is stored in our configuration management system.
Depending on the service, data is backuped by service-specific procedures or at least as a daily full backup.

backup time 

00:00 - 03:00 

Storage time 

7 days for PROD, 1 day for TEST / STAGE 

backup type 

full backup 

Recovery time 

Approx. 2 hours 

To restore the backup, please send a request to support@root360.de.

Type of backup 

For all components following type of backup is in place:

Full backup

  • also known as: snapshot, point-in-time backup / snapshot

  • backup of a data record at time X.

  • the entire existing data is always saved.

Recovery point objective (RPO) for AWS components/services

The Recovery Point Objective is the time period that may lie between two data backups, i.e. how much data/transactions may be lost at most between the last backup and the system failure. If no data loss is acceptable, the RPO is 0 seconds.

AWS Service

RPO

Configuration/ Mitigation for higher redundancy

EC2

see EBS

  • EC2 are provided using EBS volumes only

RDS

24 hours

  • At least daily backup using AWS backup

  • 7 day retention

EBS

24 hours

  • At least daily backup using AWS backup.

  • 7 day retention

EFS

24 hours

  • At least daily backup using AWS backup

  • 7 day retention

S3

24 hours

  • Lifecycle policy "Delete after 30 days versioning"

  • Versioning enabled

ElastiCache for Redis/Memcached

-

  • ElastiCache are handled as stateless so there is no backup in place

ElasticSearch Service

24 hours (depending on AWS support services)

  • For production environments at least 3 nodes are in place

  • At least daily backup using Elasticsearch snapshot

  • 14 day retention

SQS

-

  • SQS are handled as stateless so there is no backup in place

Recovery time objective (RTO) AWS components/services

The Recovery Time Objective is the time that elapses between the time of the failure and the complete recovery of the business processes (recovery of: infrastructure - data - reworking of data - resumption of activities) may pass. The time can range from 0 minutes (systems must be available immediately) to several days (in individual cases weeks).

AWS Service

RTO

Configuration/ Mitigation for higher redundancy

Application/Class Load Balancer

  • None defined by Service Level Agreement (SLA)

  • LB are always configured for at least two Availability Zones.

EC2

  • None defined by Service Level Agreement (SLA)

  • If supported by Application provisioning in at least two Availability Zones using EC2 Autoscaling.

EFS

  • None defined by Service Level Agreement (SLA)

  • EFS is always configured for at least two Availability Zones.

S3

  • None defined by Service Level Agreement (SLA)

  • S3 is redundant by design.

RDS

  • None defined by Service Level Agreement (SLA)

  • If required RDS is proviioned as Multi-AZ or as Aurora Multi-Node Cluster.

ElastiCache for Redis/Memcached

  • None defined by Service Level Agreement (SLA)

  • If required ElastiCache for Redis is provided as Multi-AZ Replication group.

  • If required ElastiCache for Memcached is provided as Multi-AZ sharded Multi-Node Cluster.

AWS Lambda

  • None defined by Service Level Agreement (SLA)



SQS

  • None defined by Service Level Agreement (SLA)



VPN (IPSec, OpenVPN)

  • None defined by Service Level Agreement (SLA)

  • IPSec based VPN connection can be provided redundant using 2 IPSec tunnels.

Elasticsearch Service

  • None defined by Service Level Agreement (SLA)

We have to contact the AWS Support team. It may take several hours to initiate index restore

  • For production environments at least 3 nodes are in place for redundancy.

  • If required, we offer configuration of index snapshots to S3 for shorter RTO.

Elastic Container Service (ECS)

  • None defined by Service Level Agreement (SLA)

  • ECS worker nodes are provisioned using EC2 Auto Scaling.

Sample calculation backup costs

The cost of full backups depends on the service type. The following lists are given as examples.

Databases

The general prices for fullbackups of AWS RDS databases can be found in detail under the item "Backup" at https://aws.amazon.com/rds/mysql/pricing/ .

A cost forecast for a specific database depends on the following factors:

  • The number of snapshots

  • The size of the hard disks of the databases

  • The total amount of storage space used for the snapshots

Sample calculation for the cost of our standard database backup

  • Given:

    • Size of database hard disks: 100 GB

    • Memory consumption: 20 GB

    • Night fullback

    • Storage: 7 days

    • Cost per GB / month for additional backup storage: $ 0.095 per GB / month

  • Calculation:

    • Total amount of disk space needed for Fullbackups: 20 GB * 7 Days = 140 GB

    • Free backups: 100 GB / 20 GB = 5

    • Remaining payable volume: 40 GB

    • Cost: 40 * 0.095 = 3.80 $ / month

Related tutorials

Related components