For a while, my definition of a successful backup was simple: an archive was created on schedule, its size looked reasonable, and the job reported no errors.

If the dashboard showed a green check mark, I felt safe.

I eventually realized that this only proved that a file had been created. It did not prove that the data inside was consistent, and it certainly did not guarantee that I could use it to bring an application back online.

When I started working on Nitrobase, I had to think about this problem more seriously. A backup is not just a task that runs at 2 a.m. It is a process: knowing what to save, where to store it, and how to restore it when a VPS fails.

Nitrobase has only recently launched and is currently in Beta. At this stage, I do not want to emphasize a long list of features. I want to focus on the problem the product aims to solve: giving people who self-host a clearer backup and recovery process instead of leaving them with backup files they may not be able to use.

Copying a volume may not save a database

The first backup method many people think of — myself included — is to archive a container volume and copy it somewhere else.

That may be enough for static files. Databases are different.

PostgreSQL, MySQL, or MongoDB may be writing data, updating indexes, or processing transactions while the backup tool reads the volume. The copied files can therefore represent different moments in time.

The backup job still succeeds. The archive size still looks correct. The problem only becomes visible when the database fails to start after a restore, or worse, starts with inconsistent data.

This is why Nitrobase approaches backup according to the type of application instead of treating every container in the same way. A reliable process may need to:

  1. pause tasks that are writing data;
  2. create a consistent database dump;
  3. collect the required volumes and configuration files;
  4. preserve the metadata needed for recovery;
  5. move the backup away from the server running the application.

The goal of Nitrobase templates is to describe which data must be saved and how a database should be prepared. To me, solving that problem matters much more than simply adding a “Backup” button to a dashboard.

A backup should live outside the failure zone

Keeping a backup on the source VPS is convenient. It is fast, easy to configure, and requires no additional service.

But if the disk fails, the VPS is deleted by mistake, or the entire server becomes unavailable, that backup disappears with the original data.

The process Nitrobase is working toward can send backups to external storage such as S3-compatible services, Cloudflare R2, or Backblaze B2. The important part is not the number of storage options. It is preventing the original data and its rescue copy from disappearing in the same incident.

Schedules and retention policies also need to be considered. Keeping too few backups limits the available recovery points. Keeping everything forever eventually consumes all available storage.

For a small project, I usually start with a simple plan:

  • create a backup every day;
  • keep at least the seven most recent copies;
  • store one copy outside the production VPS;
  • periodically restore a backup into a separate application.

The exact numbers matter less than whether they match the amount of data you can afford to lose and how long you can wait for the application to recover.

The real problem appears when you need to restore

This may be the most important lesson I have learned: if I have never tested a restore, I do not really know whether I have a backup.

An active incident is the worst time to discover that an archive is missing environment variables, expects a different image version, or requires a password nobody remembers how to find.

Nitrobase is designed so that a backup can be restored into the existing application or used to create a new one. The second option makes it possible to test the recovered copy without touching production.

The process I want is straightforward:

  1. create a separate application from the backup;
  2. confirm that its containers start;
  3. check the data and critical functionality;
  4. move traffic only after the restored application is ready.

A periodic restore test usually tells me more than dozens of “backup successful” notifications.

Application updates also need a way back

Not every incident starts with hardware failure. Many begin with an ordinary change: a new container image, a configuration update, or a freshly deployed commit.

One of the problems Nitrobase aims to solve is making backup part of the update process:

  1. create a recovery point before making a change;
  2. deploy the new version;
  3. run a health check;
  4. roll back if the new version does not work.

I used to think of backup and rollback as the same thing. In practice, they protect different parts of the system. A rollback restores the previous application version. A backup protects the data state when an update changes a database or volume.

Together, they make an update less like a leap of faith. It becomes a process with a starting point, a verification step, and a path back.

Moving to another VPS is also a restore problem

When upgrading a server, changing providers, or moving a workload to another region, I used to create a backup, copy files, recreate the Compose project, update the domain, and check every container manually.

Missing a single environment variable could add hours to the process.

That is why Nitrobase's application migration flow is designed to:

  1. back up the application on the source server;
  2. restore it on the destination server;
  3. verify the new deployment;
  4. remove the old copy only after the destination is healthy.

If the process fails, the incomplete destination is cleaned up and the original application is started again.

What matters to me is that the source server is not removed too early. I want to preserve a way back until I know the application's new home is working.

The management tool can become a point of failure too

There is another blind spot I noticed relatively late: we often back up our workloads but forget to back up the tool managing them.

The Nitrobase panel contains information about servers, applications, and backup configuration. If the panel machine fails without a copy of that state, I would have to rebuild the management environment from memory.

Nitrobase aims to address this blind spot with an encrypted self-backup of the panel state. It does not replace protecting SSH keys, credentials, or incident-response documentation, but it provides a clearer starting point for rebuilding the panel elsewhere.

The checklist I use

After working on this feature, I started using these questions to evaluate a recovery plan:

  • Which databases, volumes, uploads, and configuration files am I backing up?
  • Is at least one copy stored outside the production VPS?
  • When did the most recent successful backup run?
  • Who has access to the credentials required for recovery?
  • How long would it take to rebuild the application on a new VPS?
  • Has the latest backup ever been restored successfully?
  • If an update fails, how will the application version and its data return to a known state?

If I cannot answer even one of these questions clearly, I know the process still has a gap.

The problem Nitrobase Beta aims to solve

I used to think of a backup as an output: a .tar.gz file, a database dump, or a successful log entry.

Now I see it as a cycle: create the right copy, move it outside the failure zone, test the restore, and update the process as the application changes.

That is the problem Nitrobase is trying to solve in its Beta release: making backup and recovery a visible, repeatable, and testable process instead of a collection of files and commands remembered only after an incident.

Because the product has only recently launched, Nitrobase still needs feedback and testing in real environments. It does not promise to eliminate every operational risk. Its current goal is simpler: help people who self-host prepare a clear recovery path before they actually need it.

If you run a self-hosted application and have never tested your latest backup, today may be a good time to do it.

Nitrobase source code: https://github.com/AydenGroup/nitrobase