Backnix

How Backnix protects your data, step by step

A backup is a chain: if one link fails, the whole chain fails. These diagrams show each link of the chain for the different systems Backnix is designed to protect.

View Pricing

The problem

A copy is not the same as a backup

Copying files to another disk feels safe until you need a version from last Tuesday, a database that was being written during the copy, or a restore after the whole server is gone. A real backup is versioned, consistent, offsite, protected and restorable.

The consequence

Weak links break during incidents

Unencrypted copies leak data, unverified copies fail to restore, and copies stored next to the original disappear together with it. These weaknesses rarely show up in daily operation; they show up when everything else has already gone wrong.

The solution

1. Server backup

The Backnix agent reads the directories you select, compresses and encrypts the data locally, and uploads it to cloud storage. After the upload, integrity is verified so the backup can be restored with confidence.

Server backup flow: a server runs the Backnix agent, data is encrypted, sent to cloud storage, verified, and can be restored.
Server backup flow: Server → Backnix Agent → Encryption → Cloud Storage → Verification → Restore.
The solution

2. Database backup

Databases need consistent backups. Backnix is designed to use the native tools of each engine, such as transactional dumps for MySQL and MariaDB or pg_dump for PostgreSQL, before compressing and encrypting the result.

Database backup flow: MySQL, PostgreSQL or MariaDB produce a consistent backup that is compressed, encrypted and stored in S3.
Database backup flow: MySQL / PostgreSQL / MariaDB → Consistent Backup → Compression → Encryption → S3.
The solution

3. Docker backup

Images can be pulled again and containers can be recreated, but persistent volumes hold data that exists nowhere else. Backnix focuses on volumes and configuration so a Docker host can be rebuilt from its backups.

Docker backup flow: containers use persistent volumes, Backnix backs up the volumes and stores them in cloud storage.
Docker backup flow: Docker Containers → Persistent Volumes → Backnix Backup → Cloud Storage.
The solution

4. Proxmox backup

Proxmox VE backs up virtual machines and containers, and Proxmox Backup Server stores them with deduplication. Backnix is designed to add the offsite layer: a copy that survives the loss of the whole site.

Proxmox backup flow: Proxmox VE sends backups to Proxmox Backup Server, which keeps an offsite copy used for recovery.
Proxmox backup flow: Proxmox VE → Proxmox Backup Server → Offsite Storage → Recovery.
The solution

5. Multi-region storage

When you contract multi-region storage, your backups can be stored in two independent regions. Each copy is shown separately, and a replica only counts as redundancy after replication is configured and confirmed.

Multi-region flow: a customer sends backups through Backnix to storage region A and storage region B.
Multi-region storage: Customer → Backnix → Storage Region A + Storage Region B (only when this option is contracted and configured).

Questions about the process

Does the agent need inbound ports?
No. The agent is designed to connect outbound to the platform and the storage endpoint over HTTPS.
Who holds the encryption keys?
Backnix is designed for client-side encryption with keys that stay under your control. If a key is lost, encrypted data cannot be recovered, so key backup is part of the setup.
How do I know a backup is restorable?
Each backup is verified after upload, and you should still schedule regular restore tests. Our articles explain how to plan them.

These diagrams describe the designed architecture. See the features page for the availability of each capability.

Choose where your backups will live

Storage plans from 100 GB to 10 TB, in USD or BRL.

View Pricing Talk to us