How your data is backed up, and how restores are tested

What a backup actually is

It is worth being precise, because the word gets stretched. A copy of your files on the same disk is not a backup: it dies with the disk. A mirrored drive is not a backup: it faithfully mirrors your mistakes. A sync service is not a backup: delete a file and the deletion syncs too. We cover that distinction properly in how we prevent silent data corruption, but the short version is that redundancy protects you from hardware, while backups protect you from everything else: deletion, corruption, ransomware, a migration that went wrong, or the discovery that a file you last touched in 2024 is not what you thought it was.

A real backup is a point-in-time copy, held on separate systems, that can be restored. Every word in that sentence is doing work.

The questions that actually matter

When you are choosing where your business data lives, three questions cut through most backup marketing:

1. If we deleted everything tomorrow, could you get it back? This is a question about backups: a copy from before the deletion, restorable on request.
2. What happens when hardware fails mid-afternoon? This is a question about redundancy, which is a different mechanism. We answer it in what happens when a server dies.
3. How do you know the copy is any good? This is a question about testing, and it is the one most providers hope you will not ask.

An untested backup is a hope, not a backup

Restores fail for boring reasons. The credentials to the backup store expired. The job has been silently writing empty archives for months. The backup exists but nobody knows the order things must come back in. None of these show up in a dashboard that says "backup succeeded"; they show up the day you need the data, which is the worst possible day to learn.

That is why restore testing is part of the practice of backups, not an optional extra. On our platform, the clearest expression of this is disaster recovery: we maintain an independent standby foundation in a separate cloud region, our data is exported to it, and losing a primary site is a recovery we have designed and rehearsed rather than a scramble we would be attempting for the first time.

How the Node Platform runs backups

There are three lines of defence, each covering a different kind of failure. This is the same model described in How the platform is built, in more detail.

First, live redundancy. Databases replicate across nodes and storage is snapshotted on TrueNAS, whose ZFS filesystem gives us checksummed integrity and cheap snapshots. Most failures, a dead disk, a crashed process, a lost node, are absorbed here with no data loss, before anything resembling a restore is needed.

Second, scheduled backups. Whole tenants are backed up on a schedule with Velero at the cluster level, which backs up both the Kubernetes resources that define your apps and the volumes that hold their data, and with Kopia or Restic at the application level, which produce encrypted, deduplicated backups of the data itself. These land in object storage, separate from the systems they protect. Managed apps such as Nextcloud include nightly encrypted backups as a standard part of the service, not a paid tier.

Third, off-site disaster recovery. An independent copy of the data is exported to a standby foundation in a separate cloud region. This copy exists for the failure the first two lines cannot answer: the loss of an entire site. Because it is independent of the primary infrastructure, no single event can take both.

All of the tooling named above is open source. That matters for the same reason the rest of our stack being open matters: you do not have to take our word for how it behaves.

What this means for you

If a member of your team deletes the wrong folder, there is a nightly encrypted backup to restore from, and an engineer to run the restore with you. If a server fails mid-afternoon, redundancy absorbs it and the backup is never touched. If our primary site were lost entirely, there is an independent copy in another region and a rehearsed procedure for bringing it back. Each layer covers the failure mode the others cannot.

We do not publish recovery-time guarantees we have not evidenced, and we would rather tell you that plainly than print a number. A custom SLA is available for larger rollouts, agreed with the engineers who would actually be answering the page.

Frequently asked questions

How often is my data backed up?

Managed apps on the Node Platform include nightly encrypted backups as part of the service. Underneath that schedule, storage is snapshotted and databases replicate continuously across nodes, so day-to-day failures are usually absorbed before the nightly backup is ever needed.

Where are the backup copies kept?

Backups are written into object storage, separate from the systems that serve your apps. Beyond that, an independent copy of the data is exported to a standby disaster-recovery foundation in a separate cloud region, so even the loss of the primary site does not take the copies with it.

Are backups encrypted?

Yes. The nightly backups included with managed apps are encrypted. The backup tooling we use, Velero at the cluster level and Kopia or Restic at the application level, is open source, so how it handles data is inspectable rather than a matter of trust.

Do you actually test restores?

Recovery is something we rehearse, not something we assume. Our disaster-recovery foundation exists precisely so that losing a primary site is a procedure we have already run rather than an emergency we improvise. We hold the view that a backup that has never been restored is a hope, not a backup.

If we deleted something important tomorrow, could you get it back?

That is the scenario nightly backups exist for. A deletion, a bad import or a ransomware-encrypted file store can be rolled back to a previous backup. Tell support what was lost and when, and an engineer, not a ticket queue, works the restore with you.