Use SnapScheduler with OCI Block Volume snapshots to bring policy-driven, Kubernetes-native recovery points to persistent workloads on Oracle Container Engine for Kubernetes.
Modern Kubernetes platforms are no longer limited to stateless microservices. Teams now run databases, message brokers, CI/CD systems, analytics services, AI/ML pipelines, and custom enterprise applications on Kubernetes. These workloads depend on persistent data, and persistent data changes the operating model.
When data lives behind a Kubernetes PersistentVolumeClaim (PVC), platform teams need more than pod availability. They need practical answers: how often should a workload have a recovery point, how long should recovery points be retained, which PVCs are protected, and how does restore fit into a broader continuity plan?
Oracle Container Engine for Kubernetes (OKE) and Oracle Cloud Infrastructure (OCI) Block Volume provide the storage foundation. With the OCI Container Storage Interface (CSI) volume plugin, OKE workloads can use PVCs backed by OCI Block Volume through the oci-bv storage class. Oracle also documents how CSI-based volume snapshots in OKE are backed by OCI Block Volume backups and can later be used to populate new persistent volumes.
The next step is automation. Instead of treating snapshots as one-off manual actions, platform teams can turn them into a Kubernetes-native policy. That is where SnapScheduler comes in. SnapScheduler is an open source Kubernetes operator from Backube that creates scheduled snapshots of Kubernetes persistent volumes and applies retention rules to those snapshots.
This does not turn every snapshot into a complete backup or disaster recovery strategy. Application-aware backup, replication, and business continuity design still matter. The goal is narrower and very practical: make storage-level recovery points routine, governed, and easy to consume from Kubernetes.
The idea: Scheduled Snapshots as a platform Capability
OCI Block Volume snapshots in OKE give teams the storage-level recovery primitive. SnapScheduler adds the policy layer: when snapshots should occur, which PVCs should be selected, and how many snapshots should be retained. The result is a clean operating model: automated, label-driven recovery points for stateful workloads on OKE.
- A workload uses a PVC backed by OCI Block Volume.
- SnapScheduler selects protected PVCs using labels and a schedule.
- A Kubernetes VolumeSnapshot is created on schedule.
- The OCI CSI driver creates the OCI Block Volume backup behind the scenes.
- A future PVC can be created from that snapshot for restore, validation, or reuse.
This pattern keeps responsibilities separated. Application teams declare that a workload needs durable storage. Platform teams define approved snapshot schedules and retention windows. OCI handles the storage operation through the CSI driver. Recovery remains Kubernetes-native.
How the architecture works
At a high level, the pattern has four layers.
- A stateful application runs on OKE and mounts a PVC backed by OCI Block Volume.
- SnapScheduler defines the snapshot policy as a Kubernetes resource in the same namespace.
- SnapScheduler creates VolumeSnapshot objects according to that policy.
- The OCI Block Volume CSI driver provisions the storage-level backup that backs the Kubernetes snapshot.
The Kubernetes snapshot API keeps the model portable and understandable. A VolumeSnapshot is the user-facing recovery-point request, a VolumeSnapshotClass defines the snapshot implementation and parameters, and the CSI driver connects that request to the underlying storage service. In this pattern, that underlying storage service is OCI Block Volume.
Figure 1: Automated snapshot flow on OKE
The flow starts with a stateful workload on OKE using a PVC backed by OCI Block Volume. SnapScheduler applies a policy to selected PVCs, creates Kubernetes VolumeSnapshot objects on schedule, and the OCI Block Volume CSI driver turns those requests into OCI Block Volume backups. Those recovery points can later be used to create a new PVC.
A declarative view of the workflow
The workflow can also be represented as a small set of Kubernetes resources. This is not a deployment walkthrough; it is a compact view of how the pieces line up: a namespace, a PVC using oci-bv, a SnapshotSchedule that selects the PVC by label, and a pod that mounts the claim.
---
apiVersion: v1
kind: Namespace
metadata:
name: webapp
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: webapp-pvc
namespace: webapp
labels:
snapshot-tier: hourly
spec:
accessModes:
- ReadWriteOnce
storageClassName: "oci-bv"
resources:
requests:
storage: 50Gi
---
apiVersion: snapscheduler.backube/v1
kind: SnapshotSchedule
metadata:
name: hourly
namespace: webapp
spec:
claimSelector:
matchLabels:
snapshot-tier: hourly
disabled: false
retention:
expires: "72h"
maxCount: 3
schedule: "0 * * * *"
snapshotTemplate:
labels:
created-by: snapscheduler
snapshot-tier: hourly
snapshotClassName: customer-volume-class
---
apiVersion: v1
kind: Pod
metadata:
name: sample-pod
namespace: webapp
spec:
containers:
- name: sample-nginx
image: nginx
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: sample-volume
volumes:
- name: sample-volume
persistentVolumeClaim:
claimName: webapp-pvc
In this example, the PVC is the contract between the application and storage. The workload simply mounts webapp-pvc; it does not need to know how OCI Block Volume is provisioned or how snapshots are created. The SnapshotSchedule adds policy by selecting PVCs with the snapshot-tier: hourly label, creating snapshots hourly, and retaining them for up to 72 hours or three snapshots. The snapshotClassName points to the VolumeSnapshotClass used by the CSI driver.
The label is the key design choice. It lets application teams express intent without owning the mechanics of snapshot creation. A team can classify a PVC for hourly protection, while the platform team controls what hourly means, how long recovery points remain available, and which snapshot class is used.
Why this matters
The value of this pattern is not simply that snapshots exist. The value is that recovery points become consistent, repeatable, and governed. Platform teams avoid custom scripts and manual storage actions. Application teams get a simple opt-in model through labels. Operations teams get clearer retention and fewer unmanaged snapshot artifacts.
This also improves change management. Before a risky release, migration, configuration change, or batch process, teams are more likely to have a recent recovery point already available. During an incident, they can restore to a new PVC for inspection instead of immediately changing the live volume.
A practical rollout model is to offer snapshot tiers. For example, Gold could protect business-critical workloads with more frequent recovery points and longer retention, Silver could provide daily protection, and Bronze could cover lower-risk workloads. SnapScheduler’s label-based selection supports this type of service-level model while keeping the platform in control of schedule and retention design.
The result feels like a service catalog for recovery points. Developers do not need to know every CSI or storage detail. They choose the right protection tier for the workload, and the platform turns that choice into scheduled, retained snapshots backed by OCI storage.
Recovery and regional continuity
The OCI CSI snapshot model does not restore an existing persistent volume in place. Instead, a volume snapshot is used to populate a new volume. That model is useful in production because teams can attach the restored volume to a separate pod, inspect the data, compare application state, extract files, or promote the restored PVC into a recovery workflow without immediately overwriting the original volume.
Scheduled snapshots protect workloads inside a cluster and region, but many enterprise applications also need a broader continuity strategy. Because OKE volume snapshots are backed by OCI Block Volume backups, those recovery points can align with OCI regional data protection capabilities. OCI Block Volume backups can be copied to another OCI region, and a copied backup can be restored by creating a new volume in the destination region. For workloads that need a more current regional copy, OCI Block Volume replication can complement backups with ongoing asynchronous replication. Backups provide point-in-time recovery; replicas provide a current copy of the data.
Figure 2: OCI Block Volume backups created from scheduled snapshots
The OCI Console view above helps connect the Kubernetes workflow to the OCI storage layer. SnapScheduler automates the snapshot lifecycle by creating recovery points on schedule and applying retention policies that keep only the snapshots needed for the defined recovery window. This automated lifecycle management reduces manual cleanup, prevents snapshot sprawl, and helps keep the storage costs associated with retaining snapshots under control.
This gives architects flexibility. A lower-risk workload might only need scheduled snapshots in the same region. A critical workload might combine scheduled snapshots, cross-region backup copy, replicated infrastructure, and application-level recovery procedures. The important point is that SnapScheduler creates the recovery point; OCI storage services can then extend that recovery point into a larger business continuity design.
Governance and operational guardrails
Automating snapshots is powerful, but it should be introduced with guardrails.
- Use labels intentionally so only the right PVCs are selected.
- Apply retention to every schedule to avoid unbounded snapshot growth.
- Stagger schedules rather than triggering every workload at the same minute.
- Document restore as a new-PVC workflow, not an in-place rollback.
- Consider namespace boundaries, volume size requirements, and application consistency needs.
Security and data governance should also remain part of the design. OCI documentation notes that dynamically provisioned OKE volume snapshots inherit tags from the source block volume, and the encryption key used for the source block volume is used for the resulting block volume backup. This helps keep automated snapshot creation aligned with the same governance model used for OCI storage.
These details are important because automation should not become an unmanaged side channel. Snapshot policies should be reviewed like other platform policies, tied to naming and tagging standards, and aligned with the organization’s retention, access, and compliance requirements.
Where this pattern helps
This pattern is useful for databases, developer platforms, artifact repositories, AI and data workspaces, and pre-production environments that need repeatable recovery points. For transactional systems, snapshots should be coordinated with application-aware backup, flush, or quiescing mechanisms. SnapScheduler does not replace database-native recovery or enterprise disaster recovery planning; it adds a governed storage-level recovery layer that fits naturally into Kubernetes operations.
It can also help with day-two operations. Teams can snapshot before upgrades, preserve a known-good dataset for testing, investigate data after an incident, or refresh a development environment from a recent recovery point. These are common operational needs, and they benefit from a predictable platform-level snapshot service instead of ad hoc manual actions.
Conclusion
Stateful applications on Kubernetes need more than persistent storage. They need a repeatable way to protect that storage. OKE and OCI Block Volume provide the foundation for persistent volumes and CSI-based snapshot recovery. SnapScheduler builds on that foundation with automated schedules, label-based PVC selection, and retention policies.
For teams standardizing Kubernetes operations on OCI, this is a practical platform pattern: use OCI-native storage, expose recovery points through Kubernetes-native snapshot objects, automate the lifecycle with SnapScheduler, and extend the design with cross-region backup copy or replication where business continuity requires it.
Snapshot smarter. Protect persistent data automatically. Keep recovery Kubernetes-native.