hyggecloud / backups

A backup without a restore test is a rumour.

Most companies have backups. Very few have ever rehearsed a restore — and find out at the worst possible moment. We build backup and disaster recovery concepts that demonstrably work: with defined recovery times, encrypted offsite copies at a second EU provider, and restore tests in the calendar.

3-2-1copies / media / offsite — the iron rule
RPO ≤ 24hmax. data loss — down to minutes if needed
RTO def.recovery time defined by contract, not by hope
4× / yearrehearsed restore tests with a written record

The strategy

3-2-1, but done properly

Three copies of your data, on two different systems, one of them off-site — at a different provider's data centre. That last part is mandatory, not optional.

🗄️

Copy 1 — Production

Your live data with local snapshots (VM or volume level) for quick rollbacks after misconfigurations — the "oops, wrong table" insurance.

🏢

Copy 2 — Same DC, different system

Daily (or hourly) backups to separate storage — restic for files, pgBackRest/WAL archiving for databases with point-in-time recovery.

🌍

Copy 3 — Offsite, different provider

An encrypted copy at a second EU provider (e.g. production at Hetzner, offsite at OVH or Exoscale). If one provider fails entirely, your company still exists.

Ransomware protection: Offsite backups are written append-only or with object lock (S3 immutability). An attacker with production access can neither delete nor encrypt the backups — the most common total-loss vector, covered.

RPO & RTO

Two numbers your management should know

RPO — Recovery Point Objective

"How much can we afford to lose?"

The maximum data loss in a disaster, measured in time. Daily backups = up to 24 hours lost. Often unacceptable for transactional data — then we use continuous WAL archiving (minutes) or synchronous replication (seconds). It costs more; that's why the business case decides, not the engineer.

RTO — Recovery Time Objective

"How long can we afford to be down?"

The time from failure to recovery. Without a rehearsed process, every RTO figure is fiction. We define the RTO together, build the recovery as a documented runbook — and measure it in the restore test. It goes in the record, not in gut feeling.

restore-test — record.log
hygge restore-test --env staging --from offsite
# Fetch offsite backup (OVH → staging) ... ✓ 840 GB
# Restore database (PITR) ................ ✓ 11:42 yesterday
# Bring up app stack ..................... ✓ 6/6 services
# Integrity check (checksums) ............ ✓ 100 %

Measured RTO: 2h 14min (target: < 4h)
Record → compliance folder. Coffee earned.

Why the test matters so much

Backups fail silently: full storage, an expired key, a cron job disabled by an update. You only notice when you need to restore — the most expensive possible moment.

That's why our rule is: every backup concept includes scheduled restore tests (quarterly in Hygge Care), with a record for your auditor and your cyber insurer. The latter, by the way, increasingly asks for exactly this.

In practice

What we back up — and with what

LayerToolFrequency (typical)Notable
Databases (PostgreSQL/MySQL)pgBackRest / WAL-Gcontinuous (WAL) + daily fullPoint-in-time recovery to the minute
Files & volumesrestichourly to dailydeduplicated, encrypted (AES-256), append-only
Kubernetes workloadsVelerodailyCluster state + persistent volumes as one unit
VMs (Proxmox)Proxmox Backup Serverdailyincremental, live backup without downtime
Object storagerclone (cross-provider)dailySync to a second EU provider with object lock
Configuration & IaCGit (versioned anyway)on every changeThe environment itself is reproducible — by definition

// frequencies are starting points — the real intervals derive from your RPO, not the other way round

Straight talk

The three most common backup lies

  • "The provider does backups anyway." — Provider snapshots protect against hardware failure, not against dropped databases, ransomware or a cancelled account. Your data, your responsibility.
  • "RAID is a backup." — RAID protects against disk failure. A DROP TABLE is mirrored to all disks simultaneously. Reliably.
  • "We've never needed a backup." — Congratulations. You don't cancel your fire insurance because it's never burned either.

"Disaster recovery is like flossing: everyone knows they should, most only start after the first pain.

The difference: with data loss, there's no crown to replace it."

— The HyggeCloud principle

When was your last restore test?

If you have to think about it, that's the answer. In the Hygge Check we also assess your current backup situation — whether you migrate or stay.

→ Get your backups assessed

Part of the Hygge Check · or as a compact standalone assessment