Kubernetes Backup Storage

A Kubernetes backup that lives inside the same cluster or cloud account it protects isn't really a backup — it's a single blast radius away from being gone with everything else. The point of off-cluster backup storage is somewhere independent, durable, and reachable from a CronJob with the least possible moving parts. files.link fits that role: a plain REST endpoint, authenticated with a raw API key, that any backup script can hit with curl, plus encrypted-at-rest storage and a cold tier for long retention.

The honest scope first: files.link is not an S3-compatible endpoint, so tools that speak the S3 API natively — Velero's object-store plugin, etcd's S3 snapshot target — can't point straight at it. The clean integration is a post-backup upload step. Take an etcd snapshot the normal way (etcdctl snapshot save snap.db), or let Velero write its backup to its configured location, then have your CronJob upload the resulting file as a redundant off-account copy.

The upload is three calls: POST /v1/files/{folderId} returns a presigned URL and id, you PUT the snapshot bytes, then POST /v1/files/confirm-upload with {ids:[...]}. A minimal CronJob container does this with curl alone — no SDK image, no IRSA/workload-identity binding, no IAM policy to keep in sync with a rotating role. That last part is the real ergonomic win over Amazon S3 or Google Cloud Storage for this job: you skip the IAM-user-or-role, bucket-policy, and KMS-grant chain that a 'simple' cluster backup to native object storage usually drags in, and over a self-hosted MinIO you skip operating yet another storage system that needs its own backups.

Retention is where the cold tier earns its place: keep the last few days of snapshots on standard storage for a fast restore, and move weekly/monthly retention copies to the cold storage tier where long-term cost drops sharply (mind its minimum-retention period, so use it for genuine archive, not nightly churn). For restore, you pull the snapshot back over HTTPS and feed it to etcdctl snapshot restore or Velero's normal restore path against your primary store.

Because backups can contain secrets and config, keep these as private files and pull them with expiring signed URLs rather than public links. Billing is prepaid credits against real storage and transfer, which maps cleanly to a predictable nightly backup cadence.