SimpleBackupsSimpleBackups

How to back up DigitalOcean Kubernetes (DOKS)

Posted on

There is no backup button in the DOKS dashboard. No automatic snapshot of your cluster config, no managed backup of your persistent volumes, no retention policy for your secrets. If you lose the cluster, you lose everything stateful unless you've set up Velero or an equivalent tool pointing somewhere outside your DigitalOcean account.

This article walks you through exactly that setup. You'll learn what DOKS does and doesn't protect, what you actually need to capture, and how to configure Velero to back up your cluster to either DigitalOcean Spaces or an external bucket like S3 or Backblaze B2. You'll also set up a schedule and verify it works before you need it.

What DOKS doesn't back up

DOKS is a managed Kubernetes service. DigitalOcean manages the control plane: API server, etcd, scheduler, controllers. You don't pay for control plane nodes, and you can't access them directly.

That also means you don't back them up. DigitalOcean handles control plane durability. If the control plane has an issue, DigitalOcean restores it. That's the part they own.

What they don't own is your workload. The worker nodes, the volumes attached to your pods, the Kubernetes manifests that define your deployments, the secrets your applications read at runtime: none of that is covered. See the DigitalOcean Kubernetes docs for what the managed service includes.

As covered in detail in what DigitalOcean native backup doesn't cover, every native DO backup mechanism lives inside the same DigitalOcean account as the resource it protects. DOKS is no different. Account compromise, a billing dispute, or a region-level event would take your cluster and any within-account copy of it at the same time.

What you actually need to protect

Before installing anything, it helps to be precise about what you're trying to capture. DOKS backup is not one problem; it's four.

Cluster config and manifests. Every Deployment, Service, ConfigMap, Ingress, StatefulSet, and CronJob definition. If you're already using GitOps (ArgoCD, Flux), you may have these in source control already. If you're not, Velero captures them from the live cluster.

Persistent volumes. Any PersistentVolumeClaim backed by a DigitalOcean Block Storage volume. This is where your database data, uploaded files, and stateful application state live. This is the part most people forget to verify their backup actually covers.

Secrets. Kubernetes Secret objects: database passwords, API keys, TLS certificates. Velero backs these up, but you should treat them as sensitive artifacts that warrant encryption at rest and tight access controls on the destination bucket.

Application state and databases. If your application writes to a persistent volume, the PV backup covers the data at the filesystem level. If it writes to a managed database outside the cluster, that's a separate backup problem covered in how to back up DigitalOcean managed databases. If it writes to a database running inside the cluster as a pod (common with StatefulSets), you need the PV backup and ideally a logical backup too. We cover the database-in-pod case in Kubernetes database backup patterns.

DOKS uses the DigitalOcean CSI driver for persistent volumes. Velero needs the CSI snapshot plugin to capture PV data. Without it, Velero backs up the PV metadata but not the data. You end up with a backup that restores your Deployment spec perfectly while leaving you with an empty volume.

Setting up Velero on DOKS

Velero is the standard open-source tool for Kubernetes backup and restore. It runs inside your cluster, captures cluster state and PV snapshots, and ships the backup to an object store you control. For a broader look at the tools available for backing up DigitalOcean infrastructure, including managed alternatives to Velero, see the guide to the best DigitalOcean backup tools.

Prerequisites:

  • A running DOKS cluster with kubectl access
  • The Velero CLI installed locally (install docs)
  • A destination bucket: either a DigitalOcean Spaces bucket or an external bucket (see the next two sections)
  • An access key and secret for that bucket

The install command configures Velero in one shot. The next section shows the full command for a Spaces destination; the section after that adapts it for external buckets.

Backing up to Spaces

DigitalOcean Spaces is S3-compatible, so Velero's aws provider plugin works with it. You'll need a Spaces bucket and a Spaces access key (created under API > Spaces Keys in the DigitalOcean control panel).

Create a file named credentials-velero with your Spaces credentials:

[default]
aws_access_key_id=YOUR_SPACES_KEY
aws_secret_access_key=YOUR_SPACES_SECRET

Then install Velero, pointing it at your Spaces bucket:

velero install
  --provider aws
  --plugins velero/velero-plugin-for-aws:v1.10.0,velero/velero-plugin-for-csi:v0.7.1
  --bucket YOUR_SPACES_BUCKET_NAME
  --secret-file ./credentials-velero
  --backup-location-config
    region=YOUR_SPACES_REGION,s3ForcePathStyle=true,s3Url=https://YOUR_SPACES_REGION.digitaloceanspaces.com
  --snapshot-location-config region=YOUR_SPACES_REGION
  --use-node-agent
  --default-volumes-to-fs-backup

Replace:

  • YOUR_SPACES_BUCKET_NAME with your Spaces bucket name
  • YOUR_SPACES_REGION with the region code, for example nyc3 or ams3

The --plugins flag installs both the AWS provider (for the S3-compatible Spaces API) and the CSI snapshot plugin. Both are required for persistent volume backup to work. Omitting the CSI plugin is the most common setup mistake.

The --use-node-agent and --default-volumes-to-fs-backup flags enable file-system-level backup of volumes via Velero's node agent (formerly Restic). This is the fallback path for volumes that don't support CSI snapshots.

Same-host risk

Backing up to Spaces keeps your backup inside your DigitalOcean account. DOKS has zero native backup. If you lose the cluster, you lose everything stateful unless you've set up Velero or equivalent pointing somewhere outside your DO account. Spaces is better than nothing and is a reasonable first step, but it doesn't address account-level risk. For full isolation, see the external bucket section below, and the discussion in our DigitalOcean off-site compliance guide.

Once installed, verify the backup storage location is available:

velero backup-location get

You should see your location listed with PHASE: Available. If it shows Unavailable, the credentials or endpoint configuration have a typo.

Backing up to an external bucket (S3, B2)

For off-site isolation, use a bucket outside DigitalOcean entirely. Backblaze B2 and AWS S3 are the two most common choices. The Velero install command is nearly identical; only the endpoint, region, and credentials change.

For Backblaze B2:

velero install
  --provider aws
  --plugins velero/velero-plugin-for-aws:v1.10.0,velero/velero-plugin-for-csi:v0.7.1
  --bucket YOUR_B2_BUCKET_NAME
  --secret-file ./credentials-velero
  --backup-location-config
    region=us-west-004,s3ForcePathStyle=true,s3Url=https://s3.us-west-004.backblazeb2.com
  --snapshot-location-config region=us-west-004
  --use-node-agent
  --default-volumes-to-fs-backup

For AWS S3:

velero install
  --provider aws
  --plugins velero/velero-plugin-for-aws:v1.10.0,velero/velero-plugin-for-csi:v0.7.1
  --bucket YOUR_S3_BUCKET_NAME
  --secret-file ./credentials-velero
  --backup-location-config region=eu-west-1
  --snapshot-location-config region=eu-west-1
  --use-node-agent
  --default-volumes-to-fs-backup

For S3, drop the s3ForcePathStyle and s3Url flags. AWS S3 uses virtual-hosted-style addressing by default.

The credentials-velero file uses the same format in all cases. Just swap the key and secret for the target provider.

If your workload writes to block storage volumes backed by the DigitalOcean CSI driver, CSI snapshots require the destination to support a compatible VolumeSnapshotLocation. When your backup destination is a non-DO external bucket, Velero falls back to file-system backup via the node agent. This is slightly slower but works reliably for most workloads. For databases inside the cluster, a logical backup alongside the filesystem backup gives you the cleanest restore path.

A note on volume backup with external destinations: backing up DigitalOcean volumes covers block storage snapshots in detail for standalone volumes. For volumes attached to DOKS pods, the Velero file-system path is the practical route when the destination is outside DigitalOcean.

Scheduling and verifying Velero backups

A Velero install with no schedule is a one-off tool. The backup only exists if someone remembered to run a command. Add a schedule.

Run a one-off backup first to confirm everything works end to end before automating:

velero backup create first-backup
  --include-namespaces production
  --wait

Replace production with your namespace. The --wait flag blocks until the backup completes so you see the result immediately. Check the status:

velero backup describe first-backup --details

Look for Phase: Completed. If it shows PartiallyFailed or Failed, the --details output shows which resources failed and why. Persistent volume issues caused by a missing CSI plugin show up here.

Once the one-off succeeds, add a daily schedule:

velero schedule create daily-cluster-backup
  --schedule="0 2 * * *"
  --include-namespaces production
  --ttl 720h

The --ttl 720h flag sets a 30-day retention on each backup object. Adjust to match your recovery requirements. The schedule uses standard cron syntax; 0 2 * * * runs at 02:00 UTC every day.

List active schedules and their last run:

velero schedule get

Testing restore. Running backups is half the job. The other half is proving you can restore from them. At least once a month, restore a recent backup to a test namespace:

velero restore create --from-backup first-backup
  --namespace-mappings production:restore-test
  --wait

This maps the production namespace to restore-test so the restore doesn't collide with your live workload. Check that your pods come up, your volumes mount, and your data looks correct. A backup you've never restored from is a backup you don't actually have.

Velero backs up whatever is in the cluster at the time the backup runs. If you're running a database as a StatefulSet, the data in the persistent volume is captured at the filesystem level. For a clean restore, quiesce writes before the backup window or use a pre-backup hook to run a database dump first. Velero supports pre and post hooks via backup annotations on the pod.

If scripting and scheduling all this yourself sounds like a second job, SimpleBackups handles DigitalOcean cluster config, persistent volume, and application state backups off-site, with alerts when a run fails. See how it works →

Keep learning

FAQ

Does DigitalOcean back up Kubernetes clusters?

No. DigitalOcean manages the DOKS control plane, but your workloads, persistent volumes, Kubernetes manifests, and secrets have no native backup. You are responsible for backing them up using a tool like Velero pointed at an object store you control.

Can Velero back up DOKS persistent volumes?

Yes, with the CSI snapshot plugin installed. Without it, Velero captures PV metadata but not the actual data on the volume. Always install the velero-plugin-for-csi alongside the AWS or other storage provider plugin. The --use-node-agent flag enables a filesystem-level fallback for volumes that don't support CSI snapshots.

Where should I store DOKS backups?

At minimum, store them in a DigitalOcean Spaces bucket. For better isolation, store them in a bucket outside DigitalOcean entirely, such as AWS S3 or Backblaze B2. Storing backups inside the same account as the cluster means a billing dispute or account compromise affects both the cluster and its backup simultaneously.

Can I restore a DOKS backup to a different cluster?

Yes. Velero restores are cluster-agnostic as long as the destination cluster has Velero installed with access to the same backup storage location. You can use this for disaster recovery to a new cluster in a different region, or for migrating workloads between clusters.

How often should I back up DOKS?

For production workloads, daily backups are a practical baseline. If your cluster state changes frequently or you're running stateful workloads that receive continuous writes, consider more frequent backups or combining Velero with database-level logical backups. The right frequency depends on your RPO: how much data you can afford to lose between a failure and your most recent backup.

This article is part of The complete guide to DigitalOcean backup, an honest, practical reference from the team that backs up DigitalOcean every day.


Table of contents