Backups and continuity
What happens if something goes wrong: how often the information is copied, where those copies are kept and how far back you can go.
Two independent backups
Information is backed up through two separate paths. A single backup mechanism is a single point of failure: if it breaks silently, you find out the day you need it.
| Mechanism | Frequency | Where it is kept | Retention |
|---|---|---|---|
| Point-in-time recovery | Continuous | The database provider's infrastructure | Depends on the contracted plan |
| Full database copy | Daily | Cloudflare R2, separate from the database | 30 days |
The daily copy lives with a different provider for a specific reason. A backup hosted on the same infrastructure as the database shares its failure modes: if the provider has a serious problem, both are lost at once.
Point-in-time recovery
It restores the database to an exact moment, not just to the moment of the last copy. It covers the most common case of data loss, which is not a server outage but human error: a mistaken bulk deletion at 10:47.
The restore is done on a new service, without touching the one in production, so the content can be checked before deciding to switch.
Verification
The status of the latest backup (when it ran, whether it finished successfully, how large it was and whether there was an error) is exposed on the platform's health endpoint, which we check after every release.
A backup nobody looks at is an assumption, not a guarantee. It almost never fails because the backup does not exist. It fails because it stopped running three weeks ago and nobody noticed, since in the meantime nothing visible broke. That is why the status is published instead of sitting in a log.
Availability
Nodux does not currently offer a service level agreement with penalties. We do not publish a guaranteed availability figure because we do not yet have the measured history to back it up, and promising one without that would be a made-up number.
What there is: releases with no noticeable downtime in the normal case, monitoring with error alerts, and a public health endpoint that anyone can check.
If your company needs a written availability commitment, write to us at soporte@nodux.link and we will talk it through for your specific case.
If you lose information
Write to us at soporte@nodux.link or on WhatsApp as soon as possible, telling us what was lost and roughly when. The sooner you let us know, the simpler the recovery. In the case of an accidental deletion, the less activity there is afterwards, the less there is to reconcile.