Every service which is part of the application catalog has data protection features. This means that the system takes care of creating regular backups and provides means to restore from a backup.
Scheduled is at least one backup every 24h. Handling of failed scheduled backups are subject to the SLA. The time of backup can be at a random time of day and is not customizable.
Recovery point objective (RPO) is defined as the maximum amount of data – as measured by time – that can be lost after a recovery from a disaster, failure, or comparable event before data loss will exceed what is acceptable to an organization. An RPO determines the maximum age of the data or files in backup storage needed to be able to meet the objective specified by the RPO, should a network or computer system failure occur.
We currently do not provide any guarantees, as it highly depends on the service and the amount of data to be restored.
The recovery time objective (RTO) is the maximum acceptable time that an application, computer, network, or system can be down after an unexpected disaster, failure, or comparable event takes place. RTO captures the maximum allowable time between restoration of normal service levels and resumption of typical operations and the unexpected failure or disaster. RTO defines a turning point, after which time the consequences of interruption from a disaster or failure become unacceptable.
No additional costs occur for this service, it’s integral part of the service offering. Allthough the service consumer can be charged additionally for every compute and storage resource (including temporary) that the backup itself consumes on a pay-per-use basis. This cost may differ from service to service and depends on the infrastructure the service is running on.
The backup snapshots are stored on the same cloud provider and region where the service instance is provisioned on. The cloud providers storage prices apply to the backup.
Transfer of data happens over a TLS encrypted and authenticated connection.
Encryption at rest depends on the service capabilities. Please see service details for more information.
The backup retention policy depends on the service and how the backups are implemented. Please consult the service’s description for more information.
The deletion protection policy depends on the service and the configured instance. By default the backup retention policy is enabled and the backups are stored for 7 days after instance deletion. Please consult the service’s description for more information.
A backup usually does not cause a general service connection interruption. However, there may be performance impacts with nondeterministic duration.
Services that fully implement the maturity "Backup and Restore" can be restored via self-service.
In order to trigger a restore of a service, a new instance has to be provisioned. The provisioning of each service exposes parameters for restoring from existing instance-backups of the same service. After the restore has completed, the restored service can be consumed like any other AppCat service.
The tooling is depending on the service. For example, if a Cloud Service Provider already provides a backup solution, we leverage it.
For VSHN Managed Services the backup tooling also depends on the actual used upstream product. If the Kubernetes Operators or Helm Charts used already provide backups facilities, they will be re-used.
Currently no customization of the backup process is possible. The backup process is enabled by default, but can be disabled per service instance. Once disabled, we don’t guarantee any data safety.