Skip to main content

Continuous Backup & Point-in-Time Recovery

Kuploy continuously protects the databases behind your deployment — mail, platform data, and supporting services — by streaming every change to encrypted, offsite object storage as it happens. This is continuous backup with point-in-time recovery (PITR): instead of a handful of nightly copies, you get a recovery timeline you can rewind to any moment within your retention window.

Two different tools

This page covers the continuous protection of the platform's databases. The separate Backup & Restore tool creates one-shot archives of the kuploy application itself. They complement each other; this one is what protects live data like mailboxes minute-to-minute.

How it works​

  • Continuous: the database's write-ahead log is archived offsite within minutes of each change. Your exposure to data loss is measured in minutes, not in "since last night's backup."
  • Per category: backups are organized by what they protect — Email (mailboxes, webmail), Platform (organizations, users, projects), and Infrastructure (supporting services). Each category has its own backup stream, retention, and recovery timeline.
  • Offsite: backups live in object storage outside your cluster — a different provider and failure domain than the machines they protect. Losing the cluster does not lose the backups.
  • Watched: backup health and freshness are part of your instance's outage alerts. If archiving stops or the latest backup grows stale, the people responsible get told — you never discover a backup gap during a restore.

Your license page on kuploy.app shows one status strip per category: health, whether backups are on, retention, the age of the latest backup, and its destination.

What point-in-time recovery gives you​

The scenario that matters: someone deletes a mailbox at 14:07. With PITR you restore the Email category alone to 14:02 — five minutes before the mistake — while your organizations, projects, and billing keep running untouched.

Because each category has its own timeline, recovery is surgical: the blast radius of a restore is one category, never your whole platform.

Why not just virtual-machine snapshots?​

Many teams assume VM or hypervisor snapshots make database backups unnecessary. They don't — the two solve different problems, and for live data snapshots fall short in ways that only show up on the worst day:

  • Everything rewinds together. Restoring a VM snapshot rolls the whole machine back — every database, every application, every tenant on it — to whenever the snapshot happened to be taken. PITR restores one category to one chosen moment.
  • You can only go back to when a snapshot exists. If the newest snapshot is from last week, last week is your only option. A continuous timeline lets you pick the minute.
  • Snapshots are crash-consistent, not database-consistent. A snapshot of a busy database captures it mid-write; recovery may work, or may not. Write-ahead-log recovery is how databases are designed to be restored.
  • Same failure domain. Snapshots usually live on the same storage as the machines they protect. Offsite object storage survives the loss of the entire site.
  • Snapshot chains degrade the host. Long-lived hypervisor snapshot chains are a well-documented cause of VM performance problems. Hypervisor vendors themselves say snapshots are not backups.
  • Rehearsed, not hoped. Every kuploy recovery shape is restore-tested as part of the platform's own drills. Ask yourself when your VM snapshot restore was last rehearsed end-to-end.

VM snapshots remain useful for what they're for — a quick revert point before host maintenance. For your data, use a real recovery timeline.

Restoring​

Restore plans are generated from your license page on kuploy.app (Restore… on the instance's health panel, Enterprise plan): pick a category and a target time, and kuploy produces a step-by-step, tested recovery plan for your operator to apply. Generating a plan never touches your running platform — applying it is always a deliberate operator action.

If you're not on Enterprise, your backups are still taken and watched; recovery is a manual operation for your platform operator.

Retention​

Each category keeps its recovery timeline for a configured window (commonly 7 days); older backup data is pruned automatically. Within the window, any point in time is recoverable. Talk to your platform operator if your compliance needs call for a longer window.