A useful backup plan must survive the failures you are planning for, and it must produce data you can restore. The 3-2-1 rule is a practical way to think about copies, storage and location; a dashboard label alone does not establish that all three are independent.
Last reviewed: 2 November 2026. This article follows the current DanubeData Backups & Disaster Recovery product description. Platform object-storage copies are on separate servers within the same Falkenstein campus. They are not a geographically separate backup or a second-region recovery guarantee.
What the 3-2-1 rule means
- Three copies: the working data and additional recoverable copies.
- Two storage types: avoid relying on a single storage mechanism for every recovery path.
- One offsite copy: place a copy outside the location or failure boundary your plan must survive.
The rule is a planning aid, not a promise that no data loss is possible. Copies can share credentials, software bugs, deletion policies or a physical site. Identify those dependencies and test the restoration you intend to rely on.
How DanubeData's copies fit
| Layer | Purpose | Important boundary |
|---|---|---|
| Live workload data | Serve the application | It is the working state, not a backup |
| Local snapshot, where supported | Restore a captured storage state | Depends on the underlying storage being available |
| Completed object-storage copy | Provide a separate backup artifact | Separate storage servers, same Falkenstein campus |
| Customer-arranged external copy | Support recovery outside that location | Must be configured, protected and tested independently |
A completed object copy can give another recovery path when local storage is unavailable. A campus-wide incident can affect both the workload and platform copies. If your requirement includes recovery outside Falkenstein, arrange and verify an independent external backup.
Recovery follows the resource
Managed databases
PostgreSQL uses base backups and continuous WAL archiving for recovery within its available window. MySQL and MariaDB restore from completed backups. Check the resource's enabled policy and latest usable point; a snapshot is not automatically a timestamp-selectable recovery history.
Managed caches
Redis, Valkey and Dragonfly recovery uses persistent-storage snapshots, with options depending on the deployment and available copies. Decide whether the cache contains rebuildable data or application state that needs an explicit recovery requirement.
VPS instances
KubeVirt snapshots capture VM disks. A local snapshot and completed export have different dependencies. Check which action is available for the recovery point and validate the guest application after restoration; captured disks alone do not demonstrate application consistency.
Consistency and interruption
Do not assume one persistence command works for every deployment. Databases, caches and VM guests have different consistency mechanisms, and behaviour depends on the resource and backup engine. Confirm what is captured and whether the operation pauses writes or affects availability.
The older version of this article called every snapshot instant and interruption-free. That is too broad. Plan maintenance and recovery around the actual action, and test application behaviour rather than infer it from a storage snapshot's name.
Schedules and retention
Enable protection for each resource you want to cover and inspect its settings. Automated snapshots run daily when enabled or follow the resource's policy; scheduled database backups have their own controls. A configured schedule is not proof of a successful copy.
- Confirm the newest completed point and how old it is.
- Check the retention period and whether the copy you need will still exist.
- Investigate failed or incomplete operations before counting them as protection.
- Review retained backup storage and the cost of a restore target.
- Revisit the policy when the workload or recovery requirement changes.
Choose a recovery point and validate the result
- Define the incident: accidental deletion, application corruption, local storage failure and site unavailability need different recovery paths.
- Choose the point: review its date, copy status and retained history. For supported PostgreSQL, select a timestamp inside the available window.
- Review the destination: inspect the action before replacing a resource. A new restore target can create a separate billed instance.
- Follow the operation: wait for completion and record errors; request support for an unclear or failed state.
- Validate application data: check representative records or files, permissions, versions and application operations.
- Reconnect clients: move traffic after validation and keep the previous state while the rollback decision remains open.
There is no universal “minutes to hours” recovery promise here. Data size, retained artifacts, destination readiness and application validation affect the result. Record your own rehearsal's duration and recovered point.
Add an independent customer copy when needed
For a requirement that includes loss of the Falkenstein campus, the external copy must be outside that failure boundary. Simply putting another bucket on the same campus does not provide that geographic separation.
- Choose a suitable separate location and confirm its actual storage scope.
- Use credentials and recovery keys that remain accessible if the production account or host is unavailable.
- Capture application-consistent database exports and required files, not only whichever directory is easiest to copy.
- Protect the copy from unintended deletion with suitable permissions and retention.
- Keep configuration, restore instructions and necessary secrets securely available for recovery.
- Test restoration without depending on the original live host.
This external copy is a customer-arranged part of the recovery plan. It is not automatically created by a platform snapshot toggle. Use the Linux backup guide for a backup workflow and the European object-storage comparison when selecting another target.
What to verify regularly
Keep a small recovery record: resource, backup identifier, creation time, copy location, retention, destination, checks performed and outcome. Include the person responsible and the next review date. A completed job is useful evidence; a successful application restore is stronger evidence for the recovery scenario you tested.
Distinguish the most recent recoverable point from the time needed to restore it. A ten-minute-old backup can still take substantial time to recover and validate. Set both requirements from the application's tolerance for lost writes and interruption.
Getting started
Open the resource's Backups & recovery settings, enable the intended policy and inspect the latest completed result. Confirm which local and object-storage copies exist. Then arrange an external copy if your recovery plan requires geographic separation.
Review DanubeData recovery paths and their location limits, or ask about a specific resource and recovery requirement. Do not count an untested copy, an unfinished export or a same-campus copy as evidence of recovery from every disaster.