Container Service: Backups

Overview

The Container Service performs daily backups of customer OpenShift projects. Backups are performed to support two related but distinct recovery needs:

1. Disaster Recovery-level recovery, such as recovery from a cluster, cloud region, malicious actor or data center outage.

2. Application namespace-level recovery, such as restoring application configuration or persistent data after unintended deletion, corruption, or misconfiguration.

Backups run daily beginning at 1:00 a.m.

The selection of backups used to be optional when ordering a project through the Service Request System, or SRS. This changed in July 2026, such that all projects are now backed up. This change was made to better accommodate situations where prototype applications, which may not initially require backups, later graduate to production status.

This document explains:

• The differences between the two types of backups
• A description of what is backed up
• The cases in which persistent volume data is or is not backed up
• What is not backed up
• How to request restores

Backup Types

Disaster Recovery-Level Backups

Disaster Recovery, or DR-level, backups are intended to support recovery from major infrastructure events, such as:

• OpenShift cluster failure

• AWS Region or Account issues

• Scenarios involving malicious actors

These backups are managed by the Container Service for the AWS environment, and the Container Service and the MiServer and MiStorage teams for the on-campus environment. These backups are intended primarily for platform-level recovery.

Application Namespace Backups

Application namespace backups are intended to support recovery of customer workloads within OpenShift projects. These backups are used for scenarios such as:

• Accidental deletion of Kubernetes or OpenShift objects

• Application misconfiguration

• Unintended deletion of persistent data

• Recovery of a project namespace to a previous known-good state

These backups are managed by the Container Service for both environments. These backups are intended to allow for point-in-time restoration of customer applications.

What Is Backed Up?

OpenShift Application Artifacts

YAML versions of namespace-scoped OpenShift and Kubernetes objects within your projects are included in each daily backup. These are available for both Disaster-Recovery and namespace-level restores. Examples of application artifacts that may be included are:

• Deployments, DeploymentConfigs and StatefulSets

• Jobs and CronJobs

• HorizontalPodAutoscalers

• PodDisruptionBudgets

• BuildConfigs

• ImageStreams and ImageStreamTags

• Pods

• Services

• Routes and Ingresses

• ConfigMaps and Secrets

• ServiceAccounts

• Roles and RoleBindings

• PersistentVolumeClaims

• Operator-managed custom resources, when they are namespace-scoped

Important Notes About Application Artifacts

The backup captures the declarative YAML definitions of these resources. It does not necessarily capture all external systems or runtime state associated with them.

For example:

• A deployment definition is backed up, but the container image it references may be stored in an external image registry.

• A secret object may be backed up, but external credentials, certificates, database accounts, API tokens, or third-party service configuration may still need to be validated or rotated after a restore.

Application teams should maintain application deployment source, such as Helm charts, Kustomize overlays, GitOps repositories, CI/CD definitions, and external configuration, outside of the cluster as part of their own software delivery process.

Persistent Volumes

Applications that use persistent volumes are protected for disaster recovery regardless of the storage technology used. For namespace-level restores, however, some persistent volume data can only be captured when the volume is actively mounted by a running pod during the backup window. This is detailed in the section "Persistent Volume Backup Behavior" below.

Persistent Volume Backup Behavior

Backup behavior depends on the storage class used by the persistent volume and, in some cases, whether the volume is mounted by a running pod during the backup window.

What Is Not Backed Up?

The Container Service backup process should not be considered a complete backup of every system your application depends on. The following are generally not included in application namespace backups unless explicitly part of the OpenShift project or backed by an eligible persistent volume:

• External databases not managed by the Container Service

• External object storage, such as S3 buckets

• External file shares

• External APIs or SaaS platforms

• Source code repositories

• CI/CD pipeline systems

• Container images stored in external registries

• DNS records managed outside the cluster

• Third-party secrets managers

• External certificates or certificate authority configuration

• Application data written to ephemeral container filesystems

• Data stored in `emptyDir` volumes

Application owners are responsible for ensuring that any external dependencies have their own backup and recovery strategy.

Application Consistency Considerations

Backups are point-in-time captures. For many applications, this is sufficient. However, applications with active write operations may require additional steps to ensure application-consistent backups.

Examples include:

• Databases

• Message queues

• Search indexes

• Applications with local transaction logs

• Applications writing many files concurrently

• Applications with multi-volume consistency requirements

For these applications, teams should consider using application-native backup methods in addition to the Container Service backup.

Restore Requests

If you need data or application artifacts restored, contact the Container Service support team by emailing [email protected].

Include as much of the following information as possible:

• OpenShift cluster name

• Project or namespace name

• Resource or volume to restore

• Approximate date and time to restore from

• Reason for restore

• Whether the restore should include OpenShift objects, persistent volume data, or both

• Any application-specific consistency concerns

The ability to restore to any particular point may vary depending on the storage class, backup availability, requested recovery point, and whether the persistent volume met the backup requirements during the backup window.