Backups

Kubernetes platform backups

Skyscrapers maintains backups of Kubernetes platform configuration - using Velero - according to your retention requirements - as specified in the onboarding SOW or any formal GitHub change requests. By default, Skyscrapers configures a 14 calendar day retentention period. This covers cluster state and EBS volume snapshots.

Additional technology component backup mechanisms

Skyscrapers provides backup mechanisms for the specified technology components in your environment. You define which components need to be backed up and communicate your requirements through GitHub issues (SoW) and Skyscrapers configures and maintains these mechanisms accordingly. All backup and restore services are subject to the limitations set out in your Agreement with Skyscrapers and the Terms and Conditions that are integral part of this Agreement.

How it works

When you decide that one of your technology components is in need of such backup mechanisms, you communicate these requirements to Skyscrapers through a GitHub issue. Such ticket shall include all specifications for the desired service, consisting of at least:

• Which components are in scope (e.g. production database yes, staging no; cache yes or no)
• How long backups need to be retained
• How frequently backups should run

Skyscrapers then configures the appropriate mechanism in accordance to these specs. If a component is not explicitly in scope, no backup mechanism will be configured for it. Backups that result from the service, are always encrypted and stored within the same account and region unless otherwise requested in a GitHub issue.

Available backup mechanisms

Depending on the technology component and your requirements, Skyscrapers will configure one of two backup mechanisms:

• Native cloud backups: snapshots and backups built into the managed cloud service (e.g. RDS automated backups, EBS snapshots). These are the standard option and are tightly integrated with the service.
• AWS Backup: an optional mechanism that provides more flexibility in backup frequency, retention periods, and replication. Skyscrapers will configure this when native backup capabilities are insufficient, for example when cross-region or cross-account replication is required, or when more granular scheduling is needed.

Backup restores

Backup restores are performed manually upon request by Skyscrapers during business hours, or via the 24/7 escalation path for critical incidents.

Responsibilities

Skyscrapers

• Configures and maintains backup mechanisms for the technology components you have identified as in-scope. It is the Customers responsibility to specify backup scope, retention time and frequency for each dataset.
• Monitoring and alerting on backup failures, and taking corrective actions to ensure backups mechanisms are functioning as expected
• Maintains backups of Kubernetes platform configuration according to your retention requirements
• Supports manual backup restores from the last available backup copy during. Backup restore are performed during business hours and are governed by our Support Process.

Customer

Following aspects of the backup service are strictly the customers’ responsibility:

• Define your scope: determine which technology components need backup mechanisms and communicate this to Skyscrapers.
• Communicate your requirements: specify retention period, frequency, and any other requirements when a component is set up.
• Validate your backups & organise restore rehearsals: verify that backups are created and functioning, that data is correct and complete, and that it can be successfully restored according to your requirements.
• Maintain independent copies: as set out in the Terms and Conditions, you should maintain independent backup copies to avoid Skyscrapers being a single point of failure.

Baseline vs Disaster Recovery add-on

The backup mechanisms described on this page are part of the baseline backup and restore service of the DevOps-as-a-Service offering. They protect against everyday mishaps such as accidental deletions and bad deploys, but they do not cover large-scale outages, cross-region failures, or complex multi-system recovery scenarios.

For customers who want formal recovery objectives, recurring testing, regulatory compliance (e.g. ISO 27001 / ISO 22301) or resilience against larger disasters, see the Disaster Recovery & Business Continuity add-on.