Backup and Restore Using Volume Snapshots

This section outlines the modern, recommended approach for backing up and restoring your Link application data using Kubernetes Volume Snapshots.

This method is generally much faster, more reliable, and less disruptive than manually copying files from pods. It creates a point-in-time, block-level snapshot of your entire data volume at the storage layer.

Prerequisites

CSI Driver: Your Kubernetes cluster must have a Container Storage Interface (CSI) driver installed that supports the volume snapshot feature. This is standard for most managed Kubernetes services (EKS, GKE, AKS) and modern storage provider plugins (e.g., vSphere, Portworx, Ceph).
Snapshot CRDs: The VolumeSnapshot, VolumeSnapshotClass, and VolumeSnapshotContent Custom Resource Definitions (CRDs) must be installed in your cluster. You can check with:
```
kubectl get crd volumesnapshots.snapshot.storage.k8s.io
```
VolumeSnapshotClass: You must have at least one VolumeSnapshotClass available. This class tells the cluster how to create a snapshot (e.g., what driver to use, what deletion policy to apply). Find available classes by running:
```
kubectl get volumesnapshotclass
```
Note the name of a class provided by your storage system.

Backup Procedures

The goal is to create a VolumeSnapshot object for every PVC used by your Link application.

Step 1: Identify All Link PVCs

List all the PVCs in your Link namespace that are in a Bound state.

kubectl get pvc -n <namespace>

A snapshot must be created for each of the following components, if they exist:

Rest PVC
Server PVC
Executor PVC
Kafka PVC
Custom-connector PVC
Unica PVC
Redis PVC
MongoDB PVC

Step 2: Create a Volume Snapshot

A VolumeSnapshot resource needs to be created for each identified PVC.

Create a YAML file, such as mongo-snapshot.yaml:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: mongodb-snapshot-20251027 # Choose a clear, dated name
  namespace: <your-link-namespace> # The namespace where Link is running
spec:
  volumeSnapshotClassName: <your-snapshot-class-name> # From 'kubectl get volumesnapshotclass'
  source:
    persistentVolumeClaimName: <mongodb-pvc-name> # The name of the PVC to snapshot

Apply the manifest to the cluster:

kubectl apply -f mongo-snapshot.yaml

Repeat this process for all other Link PVCs (such as Kafka, Server, and REST), creating a separate VolumeSnapshot for each.

Step 3: Verify Snapshots are Ready

You can verify the status of your snapshots. They are ready for restoration when the READYTOUSE field is set to true.

kubectl get volumesnapshot -n <namespace>

# Example output
NAME                       READYTOUSE   SOURCEPVC            SOURCESNAPSHOTCONTENT   RESTORESIZE   SNAPSHOTCLASS         AGE
mongodb-snapshot-20251027  true         mongodb-pvc-name     snapcontent-xyz...      10Gi          my-snapshot-class     5m
kafka-snapshot-20251027    true         kafka-pvc-name       snapcontent-abc...      50Gi          my-snapshot-class     5m
...

The backup is now complete and securely stored by the storage provider.

Restore Procedures

Restoration involves creating new pre-populated PVCs from the snapshots and deploying a new Link instance that uses them.

Step 1: Create New PVCs from Snapshots

Before deploying Link, new PVCs must be created that source their data from the previously taken snapshots.

Create a YAML file for the new PVC, such as mongo-restore-pvc.yaml.

Important: The value of spec.resources.requests.storage must be equal to or greater than the size of the original PVC.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mongodb-pvc-restored # This is the NEW PVC name
  namespace: <your-link-namespace>
spec:
  storageClassName: <original-storage-class-name> # Must match the original PVC's storage class
  accessModes:
    - ReadWriteOnce # Must match the original PVC's access modes
  resources:
    requests:
      storage: 10Gi # Must be >= original PVC size
  dataSource:
    name: mongodb-snapshot-20251027 # The name of the snapshot you created
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io

Apply the manifest to create the PVC:

kubectl apply -f mongo-restore-pvc.yaml

Repeat this process for all other snapshots, creating a new, restored PVC for each component (Kafka, Server, etc.).

Step 2: Update Helm Chart (values.yaml)

The Link Helm deployment must be configured to use the newly created and pre-populated PVCs.

Edit your values.yaml file.

For each component, find the persistence settings and specify the existingClaim name you just created.

Example: values.yaml snippet

mongodb:
  persistence:
    enabled: true
    existingClaim: mongodb-pvc-restored # <-- Use the new PVC name
    # ... other settings

kafka:
  persistence:
    enabled: true
    existingClaim: kafka-pvc-restored # <-- Use the new PVC name
    # ... other settings

server:
  persistence:
    existingClaim: server-pvc-restored # <-- Use the new PVC name
    # ... etc.

Step 3: Deploy Link

Deploy Link using the modified values.yaml file. Helm will create the pods, which will mount the existing PVCs containing the restored data.

# Ensure any old Link release is removed or scaled down
helm upgrade --install <release-name> <chart-path> -f values.yaml -n <namespace>

Step 4: Verify Restoration

The Link pods should start up and attach to the restored volumes. Check the pod logs and application interface to confirm that your data has been successfully restored to its previous state.