NubliVault for PostgreSQL
Bring the database back to any second.
Continuous PostgreSQL backup, encrypted on the VM itself and sent straight to two destinations with different retention. Restore takes the database to the instant you choose, on another server.
In production
To-the-second restore
The transaction log (WAL) leaves the VM continuously. Restore picks the point — “today at 14:32:10” — and stops at the last record before it.
Two destinations, two retentions
For example, 30 days in the source cloud (OCI) and 3 days outside it (AWS), for disaster recovery. Each destination holds a full chain and restores on its own.
Secure by default
AES-256 encryption on the VM, with a key unique to each VM. On AWS, a 1-hour temporary credential and a bucket with Object Lock: not even the VM's credential can delete the backup.
How it works
- 1
A lightweight agent is installed on the database VM. It only makes outbound connections (HTTPS) and opens no ports.
- 2
At enrollment, the VM generates its own key, which never leaves it, and receives a certificate with its name. That certificate is what grants access to storage.
- 3
A full backup runs periodically and an incremental one every day. The incremental is block-level: it sends only the database pages that changed.
- 4
WAL goes to both destinations continuously, within minutes. The agent tracks the sequence and alerts if a segment is missing.
- 5
To restore, you choose the point in time and the target server. It downloads straight from storage, with a read-only credential.
Data never goes through the console
Each VM sends backup and WAL straight to the destinations. The NubliVault console only exchanges state and commands with the agent.
Database VM
- PostgreSQL
- Backup engine: encrypts and compresses on the VM
- NubliVault agent: schedules, throttles reads, reports
OCI Object Storage
long retention · versioned bucket
AWS S3
disaster recovery · Object Lock
NubliVault consolestate and commands only
Security at every layer
Encryption
AES-256 on the VM itself, before anything leaves, with a key unique to each VM. TLS in transit. Storage only receives data that is already encrypted.
Credentials
No fixed AWS key on the VM. The VM's certificate issues a 1-hour credential, renewed automatically, that can only see that VM's prefix.
Against deletion
On AWS, a versioned bucket with Object Lock: the VM's credential cannot delete, unlock or shorten the lock. On OCI, a versioned bucket, and the VM's key writes but cannot delete versions.
Network
Outbound HTTPS only. No new port opened on the database VM.
Performance
The agent throttles disk reads during backup, tuned to the VM's disk, so transactions are not weighed down.
Restore
Always on another server, with a read-only credential. Restoring over the source database in use is blocked.
Console
A NubliVault module, next to file backup. Mandatory second factor, access profiles and an audit trail of every action. No one sees an encryption key through the console.
Integration
Integrated with AWS (IAM Roles Anywhere, S3 Object Lock). The backup engine is a mature open source component that Nublify integrates, tests and keeps on a pinned version.
Requirements
What the database VM and the restore server need.
- PostgreSQL
- Version 16. Other versions on request.
- System
- Linux x86_64 with systemd.
- Network
- Outbound HTTPS (443) to the console and to each destination (AWS S3, OCI Object Storage). No inbound port.
- Free disk
- Room to accumulate WAL if a destination is down. Guideline: twice one day's WAL.
- Activation
- If WAL archiving is off, one PostgreSQL restart, always in a window agreed with you.
- PostgreSQL in a container
- The container must run with an init process (for example, --init in Docker).
- Restore server
- The agent installed, the same PostgreSQL (major version) and disk for the whole database. It does not need access to the source server.
Technical questions
- Does the backup slow the database down?
- Backup reads the database disk, so the agent throttles that read during backup, with a ceiling tuned to the VM's disk. The throttle is always on. WAL is sent continuously with no noticeable load.
- What is a block-level incremental?
- Instead of resending every database file that was touched, the incremental backup sends only the pages that changed since the previous one. In databases with scattered changes, it is the difference between resending almost the whole database and sending only what changed.
- How far back can I go?
- To any second within each destination's retention. Restore stops at the last transaction record before the requested instant and checks the database's consistency at the end.
- Why do two destinations mean two backups?
- Each destination holds a full, independent chain. If one fails, the other restores on its own. Backups for the two destinations are scheduled at different times.
- What if the internet goes down?
- PostgreSQL keeps running normally. WAL is kept on the VM and sent when the connection returns, with no loss, as long as there is free disk to hold it.
- What happens if a piece of WAL is lost?
- The agent tracks the WAL sequence in the destinations. If a segment is missing, the console alerts and a new full backup is triggered, so the restore point moves forward again.
- Can a compromised VM delete the backup?
- On AWS, no: the VM's credential lasts 1 hour, sees only its own prefix and cannot delete, unlock Object Lock, turn off versioning or delete the bucket. On OCI, the VM's key cannot delete versions, so history survives through versioning.
- Can anyone at Nublify read my data?
- Backup leaves your VM encrypted. Each VM's key is kept encrypted in the NubliVault vault, because it is what makes restore possible. Access to the vault is limited to a few people at Nublify, requires a second factor and every use is logged.
Want to protect your databases?
Tell us how many database VMs you have, where they run and how long you need to keep backups. Nublify engineering replies with the design and the activation plan.
Talk to engineering