Unit 5.7: Data Protection and Lifecycle

Introduction

There is no single "backup everything" product on IONOS Cloud, and treating one primitive as if it covered every workload is the most common data-protection design error on the platform. Each primitive protects a specific failure class, and three of them carry boundaries that, if missed, leave a tier silently unprotected. The Backup Service does not touch managed databases. A snapshot is a rollback point, not a consistent database backup. And the Backup Service offers no immutability. This unit treats those boundaries as the design inputs they are, then composes the primitives into one continuity plane for FinCorp.

1. The Four Primitives and the Boundaries That Separate Them

Each of the four data-protection mechanisms answers a different recovery question. The skill is matching the mechanism to the workload, not reaching for whichever one is most familiar.

1.1 The Backup Service: scope, and what it is not

The Backup Service is the agent-based protection product, backed by Acronis Cyber Protect. You install an agent on the workload, define a protection plan, and the agent ships encrypted data to a storage target. For in-cloud workloads the target workloads are IONOS Cloud Compute Engine VMs (Dedicated Core, vCPU, and Cubes), provisioned from public images (automatic agent install) or private images (manual install). The same product, in its external-agent variant, also protects on-premises servers, workstations, VMs in other public clouds, Hyper-V and VMware virtual machines, and macOS devices, which makes it the natural tool for protecting a hybrid estate from one console during a migration.

Encryption is solid: data in transit uses HTTPS and TLS, and data at rest uses AES-256 server-side encryption, with optional client-side AES-256 you enable per protection plan with a password. The default storage target is Backup Storage, but you can also direct backups to Object Storage (IONOS Cloud, S3-compatible, or other pre-configured providers) or Network File Storage.

Two boundaries must be stated plainly. First, the Backup Service does not support immutable backups. If your control objective is tamper-evident, write-once retention (the kind a ransomware-recovery or audit-evidence requirement demands), the Backup Service alone does not deliver it; you compose immutability separately, on Object Storage object lock (Unit 5.2). Second, on compliance scope: the Backup Service is covered by the BSI IT-Grundschutz ISO 27001 certificate (German data centers) but is not in the BSI C5 attestation scope. C5 Type 1 (2023-11-07) covers Compute Engine, Cloud Cubes, and Object Storage only. For FinCorp under BSI, that distinction is contractual, not cosmetic: a backup of a C5-scoped workload does not inherit C5 just because the source did.

1.2 Snapshots: VM-level rollback, not a database backup

A Block Storage snapshot captures the state of a single provisioned Block Storage device at a moment in time. Snapshots work on any Block Storage type (HDD, SSD Standard, SSD Premium, and DAS NVMe) and are created quickly. They are the right tool for a fast rollback point before a risky in-place change, such as an OS patch or an application upgrade, and they pair naturally with the migration-wave validation gates taught in Module 7.

Three properties define how you design with snapshots, and each is a constraint:

Non-incremental. Each snapshot is a separate, independent instance representing the full state of the source volume. There is no incremental chain; a snapshot of a 100 GiB volume holding 10 GiB of data still produces a 100 GiB snapshot, including blocks with no data written. A restored larger volume may need manual partition extension after booting the VM and mounting the volume.
Region-local. A snapshot lives in the region of its source volume. It does not protect against a region-level event and cannot, by itself, seed a cross-region recovery. For cross-region durability you copy the protected data to Object Storage.
Manual lifecycle. Snapshots are retained until you delete them. There is no automatic expiry, so an unmanaged snapshot population becomes a quiet cost line (snapshots consume HDD quota) and a governance gap.

The boundary that matters most here: a snapshot is a crash-consistent block-device image, not an application-consistent or database-consistent backup. Taking a snapshot of the volume under a running managed database is not a supported database backup mechanism, and it will not reliably restore to a transactionally consistent state. Database continuity has its own primitive, covered next.

1.3 The database boundary: PITR plus dump/restore

The single most important boundary in this unit: the Backup Service does not back up managed databases. Neither do snapshots serve as their backup. Database continuity on IONOS is delivered inside the database service itself, through two native mechanisms.

The first is point-in-time recovery (PITR). Managed PostgreSQL automates continuous backups to an encrypted IONOS Cloud Object Storage bucket in the same region (databases in regions without IONOS Object Storage are backed up to eu-central-2), and the backup storage location is immutable. The PITR window is 7 days for PostgreSQL by default, and on PostgreSQL the retention is configurable from 1 to 365 days via backup.retentionDays; do not teach 7 as a hard limit, it is the default. Managed MariaDB provides a 7-day PITR retention. Restore is governed by real constraints you must design around: only one backup can be restored at a time, the cluster must be AVAILABLE, you can restore from the same or an older major version, a restore can move a database to another region, and recoveryTargetTime is non-inclusive. The recovery target is not loss-free in the worst case: if all replicas lose data simultaneously, the potential data-loss window is up to the last 30 minutes or 16 MB.

The second is logical dump/restore, the same mechanism that serves as the only migration path into these services. For PostgreSQL the tools are pg_dump, pg_restore, and psql; for MariaDB it is mariadb-dump. A periodic logical dump landed in Object Storage gives you a portable, engine-version-tolerant copy that survives outside the cluster, which is exactly what PITR (tied to the cluster's own immutable backup store) does not provide.

So the database recovery design is layered: PITR for fine-grained rollback within the retention window, and scheduled logical dumps to Object Storage for long-horizon, portable, and (with object lock) tamper-evident retention.

2. Composing One Data-Continuity Plane

No single primitive is a continuity plane. The plane emerges when you assign each workload tier the mechanism that fits its failure class and recovery objective, then add Object Storage as the common archive and immutability layer underneath.

The following table maps the failure class each primitive actually covers.

Primitive	What it protects	Granularity	Region scope	Immutable?	What it does NOT cover
Backup Service (Acronis)	VMs and Block Storage; hybrid/on-prem via external agent	Per protected machine/volume	Target-dependent (use Object Storage for cross-region)	No	Managed databases; provides no immutable backups
Block Storage snapshot	Single Block Storage volume, full-state rollback	Per volume, point-in-time	Region-local	No	Cross-region events; not a DB-consistent backup; no auto-expiry
Database PITR	Managed PostgreSQL / MariaDB, in-cluster recovery	Continuous, to a timestamp in window	Same-region backup store (eu-central-2 fallback)	Backup store immutable; window-bound	Anything outside the retention window; not a portable copy
Object Storage archive	Long-term copies: dumps, exported backups, audit evidence	Per object	Bucket region; copy across regions for DR	Yes, via object lock (GOVERNANCE / COMPLIANCE)	Live recovery; it is the archive tier, not an operational backup

Two composition rules fall out of this table. First, immutability is an Object Storage property, not a Backup Service one: where a tier needs write-once retention, the recovery copy must land in an object-locked bucket, whether that copy is a Backup Service target, a snapshot's exported data, or a database dump. Object lock supports GOVERNANCE and COMPLIANCE modes, with retention up to 365 days in the DCD and up to 100 years via the API. Second, cross-region durability is achieved by getting a copy into Object Storage, because both snapshots and PITR backup stores are region-bound.

Enterprise Case Study (FinCorp)

FinCorp's regulated estate spans the migrated VMware workloads, a managed PostgreSQL cluster behind the application tier, and the audit archive established in Module 2. Under BSI and GDPR, the requirement is not "back everything up" but a defensible, per-tier recovery posture with tamper-evident evidence where it is mandated.

The compute tier (the migrated and IONOS-native VMs) is protected by the Backup Service. During migration this is doubly useful: the external-agent variant protects the on-premises VMs through cutover from the same console it will protect the IONOS VMs afterward. Because the Backup Service offers no immutability, FinCorp directs the ransomware-recovery copies to an Object Storage target with object lock in COMPLIANCE mode, so the evidence copy cannot be altered or deleted within its retention. The risky in-place steps during cutover get a snapshot rollback point immediately before, accepting that snapshots are region-local and short-lived working artifacts, not the archive.

The PostgreSQL cluster is deliberately excluded from the Backup Service, because that is the platform boundary. Its continuity is PITR for the 7-day operational window, plus a nightly pg_dump shipped to an object-locked bucket for the long-horizon, portable, audit-grade copy. The 30-minute / 16 MB worst-case loss window is documented as the cluster's accepted RPO and reconciled against the business RPO carried into Unit 7.1. The audit archive itself already sits in object-locked Object Storage from Unit 2.3. The result is one continuity plane: distinct mechanisms per tier, Object Storage as the shared immutable floor, and no tier silently relying on a primitive that does not cover it.

Decision Summary

Choose the protection mechanism by the workload tier and the recovery objective, not by familiarity.

Workload / objective	Use	Add for immutability / cross-region	Do NOT use
IONOS or hybrid/on-prem VMs and their Block Storage	Backup Service (Acronis)	Object Storage target + object lock	The Backup Service for any managed database
Fast rollback before a risky in-place change	Block Storage snapshot (then delete it)	Export/copy to Object Storage for retention	A snapshot as a DB backup or as a long-term archive
Managed PostgreSQL / MariaDB recovery within days	Database PITR (PG: 7d default, 1-365 configurable; MariaDB: 7d)	n/a (backup store is already immutable, region-bound)	Snapshots or Backup Service
Portable, long-horizon, audit-grade DB copy	Logical dump (`pg_dump` / `mariadb-dump`) to Object Storage	Object lock (COMPLIANCE for tamper-evident)	PITR (window-bound, non-portable)
Write-once tamper-evident retention, any tier	Object Storage object lock (GOVERNANCE / COMPLIANCE)	n/a (this is the immutability layer)	The Backup Service expecting native immutability

Hard constraints to carry forward: the Backup Service excludes managed databases and offers no immutable backups; snapshots are non-incremental, region-local, manually retained, and not database-consistent; PITR is window-bound and region-local; immutability and cross-region durability are achieved on Object Storage.

Summary

IONOS data protection is a set of single-purpose primitives, each with a hard boundary, that you compose into one continuity plane rather than a single backup product. The Backup Service protects VMs and Block Storage (and hybrid estates) but not managed databases and not with immutable backups; snapshots are fast region-local rollback points, not database backups; managed databases recover through their own PITR plus portable dump/restore; and Object Storage object lock supplies the immutability and cross-region archive layer that the others lack. Assign one mechanism per tier by failure class, and let Object Storage be the shared floor.

Key Points:

The Backup Service (Acronis) covers VMs and Block Storage, including on-prem and other-cloud VMs via the external agent, but explicitly does not back up managed databases and does not support immutable backups.
Block Storage snapshots are full-state, non-incremental, region-local, manually-retained VM-level rollback points, not database-consistent backups.
Managed database continuity is native: PITR (PostgreSQL 7-day default, configurable 1-365; MariaDB 7-day) for in-window recovery, plus logical dump/restore for portable long-horizon copies.
Immutability and cross-region durability are Object Storage properties (object lock GOVERNANCE / COMPLIANCE), composed under whichever recovery copy needs them.
Compliance is per service: the Backup Service sits under IT-Grundschutz ISO 27001, not under the BSI C5 attestation, so a backup does not inherit the source workload's scope.

Important Terminology:

Point-in-time recovery (PITR): Continuous database backup to an immutable, same-region Object Storage store, allowing restore to any timestamp within the retention window; window-bound and not a portable copy.
Object lock: Object Storage write-once-read-many retention in GOVERNANCE or COMPLIANCE mode (up to 365 days via DCD, 100 years via API); the platform's immutability layer.
Logical dump/restore: Engine-level export/import (pg_dump/pg_restore/psql, mariadb-dump) that produces a portable, version-tolerant database copy, doubling as the only managed-database migration path.

Learning Objectives