Kubernetes backup retention decides how large the backup target has to be, more than the size of the cluster does. A container platform may hold only a few terabytes of persistent data today, but daily backups kept for weeks, monthly points kept for a year and separate policies per application add up quickly. Most Kubernetes backup tools write to S3-compatible object storage, so the sizing question becomes how much capacity that S3 target needs and how it will grow.
This post describes what a Kubernetes backup contains, how retention policies turn into stored capacity and what else to consider when sizing the target.
A backup of a Kubernetes application has two parts. The first is the resource definitions: deployments, services, configuration maps, secrets and custom resources that describe how the application runs. These are small, usually measured in megabytes. The second is the data in persistent volumes, such as database files, message queues and uploaded content. This is where nearly all the capacity goes.
Backup tools capture volume data either by taking a storage snapshot and exporting it to the object store or by reading the file system directly. In both cases the first backup is roughly the size of the used data, and later backups store what changed.
| Input | Typical source | Effect on the S3 target |
|---|---|---|
| Used persistent volume data | Storage class and volume metrics | Size of the first full export |
| Daily change rate | Measured from the first weeks of backups | Size of each incremental |
| Backup frequency | Policy per application | Number of restore points created |
| Retention schedule | Hourly, daily, weekly, monthly and yearly counts | Number of restore points kept at once |
| Data reduction | Compression and deduplication in the backup tool | Reduces stored size, varies by data type |
| Immutability period | Object Lock setting on the bucket or policy | Holds data beyond logical retention |
| Number of clusters and namespaces | Platform inventory | Multiplies all of the above |
A simple example shows the effect. An application has 500 GB of volume data and changes 3 percent a day. Its first backup stores about 500 GB before reduction. A policy that keeps 30 daily restore points adds roughly 15 GB a day, or 450 GB, on top. Adding 12 monthly points, each of which differs substantially from the last, can add several hundred gigabytes more. The stored total settles at two to three times the live data, and a platform with fifty such applications needs tens of terabytes.
Databases behave differently from file content. A busy database may rewrite a large share of its files each day, so its incrementals approach the size of a full. Measuring the change rate per application during the first few weeks is more reliable than applying one percentage to the whole platform. Matching retention to recovery needs helps decide how many points are actually required.
When Object Lock is enabled, each backup object is held for the lock period regardless of what the retention policy says. A namespace that is deleted, or an application whose policy is removed, leaves its backups in the bucket until the locks expire. In development-heavy platforms where namespaces come and go, this locked remainder can be a noticeable share of the total. Immutable retention after jobs are deleted covers the same effect for virtual machine backups.
Kubernetes backups tend to produce many objects. Each restore point for each application writes resource manifests, metadata and data chunks as separate objects, and a platform with hundreds of namespaces backed up daily creates millions of them over a retention period. The target has to handle that object count and the listing operations that retention processing performs. Capacity in terabytes is one sizing dimension, and request handling is the other. S3 backup compatibility testing describes how to check a target against a specific backup tool's behaviour.
The S3 target is also what makes an application portable. A backup stored outside the cluster can be restored to a rebuilt cluster, a different cluster or a different site, which is how most platform teams handle cluster upgrades gone wrong and disaster recovery. For that to work, the object store has to be reachable from the destination cluster and must not itself run on the cluster being protected.
Container platforms grow by adoption. The number of stateful applications in the second year is often several times that of the first, as teams move databases and queues onto the platform. Sizing the S3 target for current data plus a modest margin leads to an early expansion. It is more useful to estimate capacity per application and multiply by the expected number of applications over three years, then confirm the target can grow in place to that figure.
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. Kubernetes backup tools that write to S3-compatible storage can use it as their backup location, outside the clusters they protect. Immutability is provided by S3 Object Lock on each object where the backup tool supports it, and in compliance mode no account, including ARTESCA administrators, can remove a lock before it expires.
ARTESCA grows within the same deployment from roughly 50 TB to 8.5 PB, which suits a platform whose backup footprint rises with adoption. It is used as a target for Veeam and other backup software.
A workable first estimate takes an afternoon. List the stateful applications and their used volume data. Apply a measured or assumed daily change rate to each. Multiply through the retention schedule, adding the immutability period where it exceeds retention. Then apply the expected growth in application count. The result is a range to refine once real backups have run for a month.