Data Protection

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.

Recovery Point Objective (RPO)

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.

— - Glossary

Recovery Time Objective (RTO)

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.

— - Glossary


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.

Backup process monitoring

The backup process is monitored and acted upon, as defined in the SLA.

Backup data location

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.

Backup data encryption

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.

Content of the Backup data

Each snapshot is able to restore the full data of a service instance.

Backup retention policy

The backup retention policy depends on the service and how the backups are implemented. Please consult the service’s description for more information.

Deletion protection policy

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.

Backup process

A backup usually does not cause a general service connection interruption. However, there may be performance impacts with nondeterministic duration.

Restore trigger

Services that fully implement the maturity "Backup and Restore" can be restored via self-service.

Restore process

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.

For upstream products where no backup is provided, the backup process is operated and orchestrated by K8up with Restic as the low-level backup tool. Depending on the service, specific tools are used to ensure data integrity (e.g. database dumps instead of plain file backup).


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.


The backup process is not meant for disaster recovery, but to protect from accidental data loss like a bug, a cyberattack, user error or data corruption.