TYPO3 on Kubernetes under IT-Grundschutz, part 10: Database, backup and restore

01 — In the cluster or as a managed service

The first decision comes before the first line of YAML. A managed database from the cloud provider takes care of patches, replication and point-in-time recovery. In return, the data lives outside the cluster, and the provider becomes part of the model.

MariaDB as a StatefulSet in the cluster keeps everything in one hand. One instance per tenant separates the data cleanly and makes restores independent of each other. The price: updates, backups and high availability sit with the operator. In practice, one instance per tenant usually matters more than where it runs. A shared database for many tenants makes every kind of isolation harder.

Both paths fit IT-Grundschutz. The module APP.4.3 “Relationale Datenbanken” applies either way. The BSI practical guide for database systems adds concrete advice.

02 — Connections and privileges

Every connection to the database is encrypted. MariaDB enforces that with require_secure_transport=ON. A client connecting without TLS is rejected instead of quietly working in plain text. With a CA per tenant, as described in part 5, the database also checks the client certificate.

TYPO3 gets a user that can only see its own database. Schema changes run during deployment with a separate user whose credentials are not left in the running pod. No application has root access.

The data itself sits on an encrypted volume. For a high protection need, APP.4.4.A20 asks for encrypted data storage in pods. Encryption in the storage layer covers a disk that gets pulled. It does not help against an attacker with access to the running node. That belongs in the risk analysis.

03 — Backups nobody can alter

A CronJob takes a logical dump every night and uploads it to object storage. Two properties of the bucket turn that into a backup that survives an attack: versioning and object lock. In compliance mode, a locked object cannot be deleted or overwritten during its retention period, not even with administrator rights. Governance mode, by contrast, can be bypassed by anyone holding a special permission. For backups meant to survive an attack, compliance mode is therefore the right choice.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: db-backup
spec:
  schedule: "15 2 * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      backoffLimit: 2
      template:
        spec:
          serviceAccountName: db-backup   # write-only identity for the bucket
          restartPolicy: Never
          containers:
            - name: dump
              image: registry.example.org/mariadb-backup@sha256:...
              command: ["/bin/backup.sh"] # mariadb-dump --single-transaction | gzip | upload
              securityContext:
                runAsNonRoot: true
                readOnlyRootFilesystem: true
                allowPrivilegeEscalation: false

The job's identity may write to the bucket, but not read or delete. The node itself has no read access either. Whoever takes over the cluster cannot reach older backups and cannot destroy them. Volume snapshots run next to it as a second, independent layer.

Two numbers belong in the backup concept required by CON.3: the RPO, how much data may be lost, and the RTO, how long recovery may take. A nightly dump means an RPO of up to 24 hours. If that is too much for a high protection need, binary logs come in. With them the database can be restored to any point in time, provided they are copied continuously into the same locked bucket. Backups within the cluster itself are covered by APP.4.4.A5.

04 — A backup nobody has restored is a hope

The most important part of the concept is the restore. It gets practised regularly, following a fixed runbook, and the result is recorded. Only that proves that dump, keys and credentials fit together when it counts.

A proven sequence: start an empty database instance in its own namespace, load the latest dump, start TYPO3 against it and check a sample of pages. The measured duration is your real RTO, not the estimated one.

The typical pitfalls only show up while doing it. The credentials for the bucket live only in the cluster that just failed. The dump contains cache tables that TYPO3 rebuilds anyway and bloats the restore. Or nobody remembers which version of the application belongs to the dump. Each of these belongs in the runbook before it surfaces in an emergency.

Conclusion

The database remains the part of the cluster with the most state. Encrypted connections, narrow privileges and immutable backups cover confidentiality and integrity. Availability stands or falls with a practised restore.

How backups, access and anomalies can be evidenced is the topic of part 11: Evidence and operations. Back to part 9: autoscaling and probes.