What is the 3-2-1 backup rule?

It means three copies, two storage types and one copy offsite. DanubeData object-storage copies are on separate storage servers within the same Falkenstein campus. For a recovery plan that requires a copy outside that location, arrange an independent external backup.

How often are backups taken?

Automated snapshots run daily when enabled, or according to the resource's backup policy. Manual recovery points are available from the dashboard. Managed PostgreSQL also archives WAL continuously; its scheduled base backups have a separate setting.

Where are backups stored?

Local snapshots stay with the underlying storage. Object-storage copies use separate storage servers on the same Falkenstein campus in Germany. These copies are not replicated to a second region.

How long are backups retained?

The default PostgreSQL archive retention is 30 days; a resource's backup policy can set a shorter window. Automated local snapshots default to three days. Manual snapshots and kept database backups have their own lifecycle. Check the retention and available recovery points shown for your resource.

Can I restore to a specific point in time?

Yes, for supported managed PostgreSQL with a healthy, continuous WAL archive, within the available recovery window. MySQL and MariaDB restore from a specific backup. Cache and VPS restore from a saved snapshot or supported exported copy.

Is backup data encrypted?

Encryption depends on the backup mechanism and storage destination. Local snapshots do not add disk encryption. If your policy requires encrypted backup storage, confirm the requirements and applicable protection with our support team.

How fast can I restore from a backup?

Restore time depends on the amount of data, the available copy and the recovery method. Follow the operation status and test the restored application before moving traffic. A restore drill is the way to measure recovery time for your workload.

What happens if my primary datacenter goes offline?

A separate object-storage copy can help when your instance's host or local storage fails. All platform backup copies remain in Falkenstein, so a campus-wide outage can affect both the workload and its backups. Include an external copy in a plan that needs recovery outside Falkenstein.

Do you test backup integrity?

Backup and copy status are visible in Backups & recovery. A completed copy alone does not verify that your application can recover. Periodically restore to a supported destination, check the data and application, and record the result for your own recovery plan.

Recovery starts with the right copy.

Local snapshots, object-storage copies and PostgreSQL point-in-time recovery. Understand what each resource can restore before you need it.

Create an account Explore recovery options

German data centers
EU hosted

Start with your workload

Database changes: A saved backup, or a timestamp for supported PostgreSQL.
Cache or VM storage: A ready snapshot and the copies available for it.
A wider recovery plan: A tested restore and an external copy when your requirements call for one.

Understand the backup copies

Recovery follows the resource

Backup engines differ. Choose the product you run to understand its recovery path.

Managed databases

PostgreSQL uses base backups and continuous WAL archiving for point-in-time recovery within the available retention window. MySQL and MariaDB restore from a completed backup.

Explore Managed databases

Managed caches

Redis, Valkey and Dragonfly use snapshots of their persistent storage. Recovery options depend on the deployment type and the copies available for that snapshot.

Explore Managed caches

Cloud VPS

KubeVirt snapshots capture VM disks. A local snapshot and a completed exported copy offer different recovery paths; the dashboard shows which actions are available.

Explore Cloud VPS

A snapshot and a backup copy do different jobs

A recovery point can have more than one copy. Its status tells you what is ready to restore.

Local snapshot
A captured storage state, used by the native snapshot restore path. It relies on the underlying storage remaining available.
Object-storage copy
A separate backup artifact on S3-compatible storage. Database backup engines and snapshot exports create these copies; check that the copy has completed before relying on it.

Separate storage, same location

Object-storage copies are held on separate storage servers on the same Falkenstein campus. The platform does not keep a backup copy outside Falkenstein. Add an independent external backup if your recovery plan requires geographic separation.

Make recovery a tested workflow

Select a recovery point, review the destination and validate the result.

Check the recovery point
Open Backups & recovery. Check the backup date, retention and copy status. For supported PostgreSQL, choose a timestamp inside the available recovery window.
Choose a supported destination
Operator-managed databases restore to a new instance. Other restore choices depend on the provider and account; review the available action before replacing a resource.
Verify before moving traffic
Follow the recovery operation, then check your data and application against the restored resource. Reconnect clients when those checks pass.

Set the schedule. Know the cost.

Enable automated protection for the resources you want to cover, and review their retention settings.

Automated snapshots and scheduled database backups have resource-specific settings. Check the latest completed point and available copies rather than relying on the schedule alone.

Manual VPS and cache snapshots, plus kept database backups, use billed storage. Restoring to a new instance also creates a billed resource, including when you run a recovery drill.

See current pricing

What customers say

“As a developer and cloud enthusiast, I’ve tried a lot of infrastructure platforms — but DanubeData genuinely stands out as one of the most intuitive, modern, and reliable cloud services I’ve used. From signup to deployment, everything feels thoughtfully designed and developer-centric. Deploying a VPS, cache, or database instance takes under a minute — and that’s not an exaggeration! Their intuitive dashboard and instant provisioning make launching new services effortless, even if you’re just getting started with cloud infrastructure”

Keoma WrightCEO/Founder at OpenWeb.co.za

“I’m running my new project’s backend on DanubeData and the experience has been smooth from day one—deployment is fast, the dashboard feels genuinely developer-friendly, and everything has been stable with no issues so far. Any time I had a question or hit a small blocker, the support was excellent: quick to respond, clear in explanations, and focused on getting me unblocked rather than sending me in circles. If you want EU-based infrastructure without the usual DevOps friction, DanubeData delivers.”

Cristian TorzsaCEO at InnovaSoftware SRL

“ruby/Sinatra invoicing application on a Docker container. Danube data was an obvious choice given its incredibly user friendly dashboard and automatic deployment directly from my GitHub repository via webhook. I've used many other platforms (Google, AWS, Azure), but Danube is the clear winner in terms of ease to configure, clear and honest pricing not to mention the excellent response time. Everything works perfectly so I hardly ever have to pull up the dashboard since I moved to Danube Data.”

Bo PereiraParis-Brest srl

Backups, explained

Schedules, retention and the limits of each recovery path.

Have a specific recovery requirement? Talk to us.

It means three copies, two storage types and one copy offsite. DanubeData object-storage copies are on separate storage servers within the same Falkenstein campus. For a recovery plan that requires a copy outside that location, arrange an independent external backup.
Link to this answer
Automated snapshots run daily when enabled, or according to the resource's backup policy. Manual recovery points are available from the dashboard. Managed PostgreSQL also archives WAL continuously; its scheduled base backups have a separate setting.
Link to this answer
Local snapshots stay with the underlying storage. Object-storage copies use separate storage servers on the same Falkenstein campus in Germany. These copies are not replicated to a second region.
Link to this answer
The default PostgreSQL archive retention is 30 days; a resource's backup policy can set a shorter window. Automated local snapshots default to three days. Manual snapshots and kept database backups have their own lifecycle. Check the retention and available recovery points shown for your resource.
Link to this answer
Yes, for supported managed PostgreSQL with a healthy, continuous WAL archive, within the available recovery window. MySQL and MariaDB restore from a specific backup. Cache and VPS restore from a saved snapshot or supported exported copy.
Link to this answer
Encryption depends on the backup mechanism and storage destination. Local snapshots do not add disk encryption. If your policy requires encrypted backup storage, confirm the requirements and applicable protection with our support team.
Link to this answer
Restore time depends on the amount of data, the available copy and the recovery method. Follow the operation status and test the restored application before moving traffic. A restore drill is the way to measure recovery time for your workload.
Link to this answer
Automated VPS and cache snapshots and regular database backups are not charged as manual snapshot storage. Manual VPS and cache snapshots, plus kept database backups, use billed storage. A restored instance is billed as a resource. See current pricing for applicable rates.
Link to this answer
A separate object-storage copy can help when your instance's host or local storage fails. All platform backup copies remain in Falkenstein, so a campus-wide outage can affect both the workload and its backups. Include an external copy in a plan that needs recovery outside Falkenstein.
Link to this answer
Backup and copy status are visible in Backups & recovery. A completed copy alone does not verify that your application can recover. Periodically restore to a supported destination, check the data and application, and record the result for your own recovery plan.
Link to this answer

Explore more solutions

Build a recovery plan you can use

Choose your resources, enable the protection you need and test a restore against your own application.

Create an account Discuss your requirements

Start free

Compute

Storage

Managed apps

Caching

Databases

Messaging

Monitoring

DanubeData CLI

Automation & Agents

Tools

Developer docs

Learn

Support