Operations
Backup And Restores
Custom Secret
tpl
This guide demonstrates how to perform Point-In-Time Recovery (PITR) for MongoDB clusters in KubeBlocks using:
PITR enables recovery to any moment within the timeRange
specified.
Before proceeding, ensure the following:
kubectl create ns demo
namespace/demo created
To perform a PITR restoration, both a full backup and continuous backup are required. Refer to the documentation to configure these backups if they are not already set up.
To identify the list of full and continuous backups, you may follow the steps:
Confirm you have a continuous WAL backup, either running or completed:
# expect EXACTLY ONE continuous backup per cluster
kubectl get backup -n demo -l dataprotection.kubeblocks.io/backup-type=Continuous,app.kubernetes.io/instance=mongo-cluster
Get the valid recovery window:
kubectl get backup <continuous-backup-name> -n demo -o yaml | yq '.status.timeRange'
Expected Output:
start: "2025-05-07T09:12:47Z"
end: "2025-05-07T09:22:50Z"
Find available full backups that meet:
# expect one or more Full backups
kubectl get backup -n demo -l dataprotection.kubeblocks.io/backup-type=Full,app.kubernetes.io/instance=mongo-cluster
KubeBlocks automatically selects the most recent qualifying full backup as the base.
Make sure there is a full backup meets the condition: its stopTime
/completionTimestamp
must AFTER Continuous backup's startTime
, otherwise PITR restoration will fail.
Configure PITR parameters in cluster annotation:
Key parameters:
name
: Continuous backup namerestoreTime
: Target recovery time (within backup timeRange
)Apply this YAML configuration:
apiVersion: apps.kubeblocks.io/v1
kind: Cluster
metadata:
name: mongo-cluster-restore-pitr
namespace: demo
annotations:
# NOTE: replace <CONTINUOUS_BACKUP_NAME> with the continuouse backup name
# NOTE: replace <RESTORE_POINT_TIME> with a valid time within the backup timeRange.
kubeblocks.io/restore-from-backup: '{"mongodb":{"name":"<CONTINUOUS_BACKUP_NAME>","namespace":"demo","restoreTime":"<RESTORE_POINT_TIME>","volumeRestorePolicy":"Parallel"}}'
spec:
terminationPolicy: Delete
clusterDef: mongodb
topology: replicaset
componentSpecs:
- name: mongodb
serviceVersion: "6.0.16"
replicas: 3
resources:
limits:
cpu: '0.5'
memory: 0.5Gi
requests:
cpu: '0.5'
memory: 0.5Gi
volumeClaimTemplates:
- name: data
spec:
storageClassName: ""
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
Track restore progress with:
# Watch restore status
kubectl get restore -n demo -w
# Watch cluster status
kubectl get cluster -n demo -w
For operational control and monitoring, use the OpsRequest API:
apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: mongo-cluster-restore
namespace: demo
spec:
clusterName: mongo-cluster-restore
force: false
restore:
backupName: <CONTINUOUS_BACKUP_NAME>
backupNamespace: demo
restorePointInTime: <RESTORE_POINT_TIME>
type: Restore
Track progress with:
# Watch restore operation
kubectl get restore -n demo -w
# Verify cluster status
kubectl get cluster -n demo -w
To remove all created resources, delete the MongoDB cluster along with its namespace:
kubectl delete cluster mongo-cluster -n demo
kubectl delete cluster mongo-cluster-restore -n demo
kubectl delete ns demo
This guide demonstrated how to restore a MongoDB cluster in KubeBlocks using a full backup and continuous backup for Point-In-Time Recovery (PITR). Key steps included:
With this approach, you can restore a MongoDB cluster to a specific point in time, ensuring minimal data loss and operational continuity.