Self-hostable · your storage, your keys

Backups you can actually restore — proven, not promised.

One control plane for servers, databases, hypervisors, cloud VMs and SaaS — scheduled snapshot orchestration where the platform does it best, and full copies into storage you own everywhere else. Those copies are deduplicated, compressed and encrypted before they leave your network, and every restore is verified chunk by chunk against its content address, so a corrupted or tampered backup fails loudly instead of quietly handing back bad data.

No credit card. Free tier is permanent. Self-host the whole stack if you prefer.

Data centre server racks with structured cabling
AES-256-GCM client-side S3 Object Lock BLAKE3 verified
50platforms in the catalog
9hypervisor & cloud VM platforms
12storage backends supported
100%of your data, on your own storage
The real problem

Most backup failures are discovered during the restore.

A green dashboard is not evidence. Backups silently truncate, credentials rotate, retention quietly deletes the copy you needed, and ransomware encrypts the repository along with production. RemoteBackups is built so each of those fails visibly, early, and in a way you can act on.

Ransomware reaches backups first

Attackers delete or encrypt the repository before touching production, so recovery is impossible when you need it.

Answer: write-time WORM + detection over the backups themselves

Silent corruption

A truncated archive still looks like a valid archive. Nothing complains until the day you try to read it back.

Answer: every chunk re-hashed on restore; size mismatch is an error

Vendor lock-in on your own data

Proprietary formats and per-socket licensing make leaving expensive, and make an air-gapped copy someone else's decision.

Answer: your buckets, your keys, self-hostable end to end
Under the hood

Six mechanisms, drawn rather than claimed.

Every backup product says “immutable, deduplicated, verified”. These are the parts that actually make those words true, and what each one does when it is working.

Tonight’s backup Repository 2 stored · 2 referenced

Deduplication, at the chunk

Content-defined chunking splits the stream on content, not offsets, so inserting a byte does not shift every boundary after it. A chunk the repository already holds is recorded by reference — never re-read, re-encrypted or re-uploaded — across every asset in the estate.

FastCDC · BLAKE3 content addressing · zstd per chunk
4 TB image · last night vs tonight 20 GB read Not 4 TB. The read is the churn.

Changed blocks only, where the platform allows

VMware CBT and Ceph’s own export-diff answer “what changed since this snapshot” without scanning. Ceph is the better of the two: the diff is the read, so there is no bitmap to hold and no change id to lose. Agent-protected machines get the same saving per file, from an index of what the last run saw.

vSphere · Ceph RBD · agent filesystems
One backup, three destinations Primary Immutable copy Archive tier Object Lock set at write, not after

Immutability that a compromised console cannot undo

The retention lock is applied by the write, in the same call that stores the object. Nothing in this product — no admin, no API token, no support engineer — can shorten it afterwards, because the bucket refuses. That is the property ransomware planning for your backups has to defeat.

S3 Object Lock · compliance mode · per-link retention
The agent looks at its own machine PostgreSQL — unprotected 3 container volumes — protect Redis — unprotected Found → named → scheduled, in one click

It tells you what you forgot to back up

Every agent reads its own machine — databases, hypervisor guests, container volumes, hosting panels — and reports what nothing is protecting. Read-only: a file that exists, a port that is listening, a process that is running. Never a command, never a config file.

30+ signatures · evidence for every finding · one-click schedule
Change rate & compressibility, per night Fourteen quiet nights Then this one

Ransomware is visible from the repository

A machine encrypted overnight produces a backup where every block is new and nothing compresses — a shape no ordinary Tuesday makes. The scan runs over the backups themselves, so it does not depend on an endpoint agent the attacker has already disabled.

Per-asset baselines · entropy & churn · IoC hunting inside backups
Restore · every chunk re-hashed Chunk 5 failed its hash — restore stopped A nearly-right file is worse than a failure

The restore is what gets verified

Every chunk is re-hashed on the way back and checked against the manifest, and a mismatch stops the restore instead of writing a file that is nearly right. Scheduled verification does the same on a calendar, so “we have backups” is a record rather than an assumption.

BLAKE3 on read · chain assembly checked · scheduled restore drills
Capabilities

One plane for everything you have to protect.

Agentless where it can be, agent-based where it must be — with the same repository format, retention model and restore path behind both.

Deduplication that pays for itself

Content-defined chunking with BLAKE3 content addressing means an unchanged block is referenced, never re-uploaded — across every backup and every asset in the repository.

FastCDC · BLAKE3 · zstd

Encrypted before it leaves

AES-256-GCM with per-chunk authentication, keyed from your organisation's master key. The storage provider holds ciphertext and cannot see your file names or content hashes.

Client-side · you hold the key

Container volumes, from inside the host

Docker and Podman named volumes, read through the local socket by the agent already on the machine — nothing exposed on the network, no certificates. They land as files, so a single config file can be browsed and pulled back out of a volume rather than restoring all of it.

Docker · Podman · optional container pause for databases

Ceph, from a cluster node

The one platform with no REST API to hold a credential for — librbd speaks the native protocol to the OSDs and the keyring is a file on a node. So the agent does it from inside the cluster, and rbd export-diff gives the best changed-block tracking of any platform here.

RBD as block · CephFS as files · snapshot-safe chains

Immutable by physics, not policy

Copies are written under S3 Object Lock, so the storage backend itself refuses deletion until retention expires. Stolen credentials cannot erase what the bucket will not delete.

Governance & compliance modes

Granular restore with undo

Browse a recovery point, restore a single file or a single database row, preview the diff before applying it — and roll the change back if it was wrong. Four-eyes approval on the sources that warrant it.

File · row · full asset

Point-in-time recovery

Replay the transaction log forward from a recovery point to a chosen moment — so the answer to "restore to just before 14:32" is a real answer, not the previous nightly.

Log replay for supported engines

One line to protect a server

Paste a single command into a root shell and the agent picks the right build for that host, verifies it, installs the service and enrols itself. It reports what it can protect — including every cPanel/WHM account on the box — and you tick the ones a policy should cover.

Linux · FreeBSD · behind NAT · control panels

Built for distant storage

Chunks are hashed, compressed, encrypted and uploaded in parallel, so throughput follows your bandwidth instead of your round-trip time. Uploads resume part by part, and a dropped connection costs one 16 MiB retry rather than the whole run.

Parallel pipeline · resumable parts

DR orchestration

Recovery plans are a boot-order DAG, not a wiki page. Run them non-disruptively as a rehearsal, or for real as a failover, and get measured RTO/RPO against your targets.

Test mode · failover · measured RTO/RPO
Coverage

50 platforms, one backup plane.

Every connector ships with a guided setup wizard and a live connection test, so you find out it works before you schedule anything — not at 3 a.m. six weeks later.

Copies into your storage

Databases, file and object storage, SaaS tenants, containers, and anything the agent protects. Data is chunked, deduplicated, compressed and encrypted on your side, then written to storage you own — off-site, immutable, and restorable to a different machine.

Snapshot orchestration

Hypervisors and cloud VMs. RemoteBackups schedules, tags, retains and expires the platform's own snapshots and can restore from them. They stay on the source platform, which makes them the fastest possible restore — and means they are not a substitute for an off-site copy.

9 Databases 8 Applications & SaaS 7 Hypervisors 6 Cloud 5 Hosting panels 5 Servers 4 Storage 3 Containers 3 Identity
What each connector can actually do, including what it cannot

Every platform above has a row in a published table: whether it copies data or only orchestrates snapshots, whether it reads changed blocks or changed files, whether it can receive a VM, and the strongest consistency it reaches — and what it falls back to when the guest agent is not there, which on the appliances and forgotten VMs that most need protecting is the common case.

The table is derived from the code by a test, not maintained by hand. A connector that gains changed-block tracking changes the table in the same commit; one that loses it cannot quietly keep the tick. Several of the blanks are permanent facts about somebody else’s platform rather than things we have not got to, and the table says which is which.

Two examples, because the blanks are the honest part

DigitalOcean and Hetzner have no backup column and cannot. Neither publishes any way to read a server’s disk — DigitalOcean’s own documentation says snapshots cannot be downloaded. So we orchestrate their snapshots, which is a real rollback point, and protect what is inside the machine with the agent. That is how everybody gets those bytes off those platforms, including every competitor who does not say so.

Proxmox has no changed-block column, and that one is a cost rather than a fact. QEMU keeps dirty bitmaps and there is a route to them — a plugin installed on every Proxmox node. We have not taken it, and the table says that rather than leaving a blank you would read as “impossible”.

Brand marks are shown to identify the platforms our connectors protect. All trademarks belong to their respective owners.

Cyber resilience

The backups are where you can still catch an attacker.

Production is compromised, but the backup stream is not — it is the one vantage point the intruder cannot tamper with. RemoteBackups analyses it.

  • Ransomware detection. A backup whose data suddenly stops compressing is a backup of encrypted files. Reduction ratio, entropy, churn and mass-deletion signals are scored together by a model that learns from your analysts' verdicts.
  • IoC threat hunting. Sweep every recovery point for known-bad hashes, ransom notes and filename patterns — including feeds you subscribe to — and get a timeline showing the last clean point to restore from.
  • Answers, grounded in your data. Ask "when was my last clean backup of the billing database?" and get an answer assembled from the catalogue — with the recovery points it used shown alongside it.
  • Rebuilding the directory, not just the servers. An Active Directory forest restored the ordinary way brings the compromise back with it: a stolen krbtgt key signs Kerberos tickets against the recovered forest too. The rebuild plan is generated from what was captured — isolate first, promote with the right command for a forest root or a child domain, seize all five operations masters even if this controller held none, reset krbtgt twice, and reconnect last. Entra ID tenants as well.
  • Recovery time you measured, not the one you wrote down. A DR plan run records the wall-clock seconds it actually took and whether that met your target. Industry surveys put untested DR setups at four in five; a plan whose RTO has never been measured is a number, and the difference only shows up on the day it matters.
  • It reaches the queue people actually work from — once. Findings and failures open one ticket per resource in ConnectWise Manage, Datto Autotask or HaloPSA. Tomorrow’s failure of the same machine is a note on that ticket, and a successful backup closes it. Most integrations open a new ticket per event, which after a fortnight is fourteen tickets about one problem and none of them closed. Your protected estate syncs into the PSA’s own inventory too, so a service review can see what is covered and not only what has broken — and findings forward to Splunk, Sentinel, QRadar or Elastic as RFC 5424 syslog or ArcSight CEF.
Combination padlock resting on a keyboard
How it works

Five stages between your data and the bucket.

The pipeline is the product. Everything else — scheduling, retention, the portal — exists to drive it and prove it worked.

01

Consistent read

Quiesce the app, snapshot the volume or open a transaction — then read a coherent point in time while the source stays live.

02

Chunk & address

Split on content boundaries, not fixed offsets, so an inserted byte does not reshuffle everything after it. Each chunk is named by its BLAKE3 hash.

03

Dedup & compress

A chunk already in the repository is referenced, not resent. What is new gets zstd-compressed.

04

Encrypt

AES-256-GCM, each chunk bound to its content address so a blob cannot be swapped for another. Keys never leave your control plane.

05

Place & lock

Write to the chain you defined — primary, copy, archive — applying Object Lock retention at write time on the tiers you marked immutable.

Restore is the part we take seriously

On the way back, every chunk is decrypted, decompressed and re-hashed. If the bytes do not hash to the address the manifest claims, the restore stops. If fewer bytes arrive than the manifest declares, the restore fails. The manifest itself is authenticated with a keyed MAC over every field, so an edited chunk list is detected before a single byte is read.

  • Per-chunk BLAKE3 verification on every restore
  • Keyed manifest authentication — a forged chunk list will not verify
  • Short reads are errors, never silent success
Open hard disk drive showing the platter and read head
Recovery

Five ways back, because “restore” is five different problems.

Getting one deleted file back and rebuilding a dead server on new hardware are not the same job, and a product that only does the first one has left you to improvise the second at three in the morning.

One file, without restoring the rest

Browse a recovery point in the portal and pull back a single path — out of a hosting account, a container volume or a CephFS tree. An incremental is assembled on the fly, so you browse what the machine looked like that night rather than what changed that night.

Server-side paging · works on chains, not just fulls

Boot it before it has finished copying

Instant recovery exposes the recovery point as a block device and starts the VM from backup storage in minutes, then migrates it onto production storage in the background while it serves traffic.

NBD-backed · background migration · no downtime to finish

Bare metal, onto different hardware

A whole-disk image restores the partition table, the boot code living in the gap before the first partition, and the EFI system partition — the parts that make a pile of hardware into that server again. The recovery tool rebuilds the initramfs and clears the interface-naming rules that would otherwise leave the machine up and unreachable.

Driver injection · UEFI & BIOS · bootable USB toolkit

A moment, not a nightly

The damage rarely lands at 2am when the backup ran. Point-in-time recovery replays the database’s own log forward from a recovery point into a scratch copy, so you can restore the state at 14:31 — a minute before somebody ran the wrong UPDATE — and take the rows back out of it. MySQL, PostgreSQL, MongoDB and SQL Server.

Binlog · logical decoding · oplog · change data capture

Migrate a live workload, with the downtime named

Cutover quiesces the guest through its own hypervisor, takes a final sync of only what changed while you were deciding, restores it on the far side and releases it. Nutanix, VMware and Proxmox — and the runbook says which minutes are the outage rather than leaving you to find out.

Ordered DAG · final sync · cross-hypervisor
Deployment

Run it yourself, or let us run it.

Same code either way. Choosing managed should be about who carries the pager, not about what you are allowed to keep.

Self-hosted

One VPS, one Compose file, your own MySQL and your own buckets. No component phones home, so it works air-gapped — the portal ships every icon and image it renders rather than fetching them.

Docker Compose · Kubernetes Helm chart · systemd

Managed

We run the control plane; your data still lands in storage you own and is encrypted with keys we cannot read. Multi-tenant with recursive sub-organisations and quotas, so MSPs can resell it cleanly.

MSP tenancy · per-tenant quotas · white-label roadmap
Three tiers

Your customer can see their own resilience, and ask for it back.

Several MSP platforms let an end customer look at a backup dashboard. Fewer let them do anything with it. The tier below you gets a read-only view of every resource you protect for them — including the ones with no successful backup, which is the row that makes the view worth having — and can raise a restore request against a specific recovery point. It lands in your queue with the resource and the point already chosen.

Cost is visible at both tiers: what a resource actually costs in storage, transfer, retention and effort, with your markup applied to what your customer sees. No invoices are generated — the numbers are there so a conversation about a bill starts from the same figures on both sides of it.

Pricing

Priced per workload, not per socket.

Storage is billed by your provider at their rates — we never mark it up, because it is your bucket.

Starter

Free

For a homelab, a side project, or proving the restore path before you commit.

  • Up to 3 protected sources
  • Full dedup, compression & encryption
  • Bring your own storage
  • Community support
Get started

Business

$49 /month

For teams protecting production. Everything in Starter, plus the parts an auditor asks about.

  • Unlimited sources
  • Immutable WORM repositories
  • Ransomware detection & threat hunting
  • Point-in-time recovery & DR plans
  • Tamper-evident audit log
Start free trial

Enterprise / MSP

Let's talk

For service providers and regulated estates that need tenancy, sovereignty and a contract.

  • Recursive multi-tenancy & quotas
  • Self-hosted or dedicated deployment
  • Air-gapped and sovereign-cloud options
  • Priority support & onboarding
Contact sales
Questions

The things people actually ask.

Where does my data physically live?

In storage you own and pay for directly — S3, Wasabi, Backblaze B2, Cloudflare R2, MinIO, Ceph and others. You add the bucket credentials; we never proxy or re-host your bytes. If you stop using us, the data is already where you put it.

Can you read my backups?

No. Chunks are encrypted with AES-256-GCM before upload using a key derived from your organisation's master key. On a self-hosted install that key never leaves your server. Storage providers see opaque blobs under HMAC-masked names — not your file names, not your content hashes.

What actually makes a backup "immutable"?

S3 Object Lock. Retention is applied at write time, and the storage backend itself refuses to delete the object until it expires — governance mode allows a privileged bypass, compliance mode allows none. This is enforced by the bucket, not by our software, which is the point: compromising the control plane does not grant deletion. Object Lock must be enabled when the bucket is created; it cannot be added later.

How do I know a restore will work before I need it?

Three ways. Every connector has a live connection test you run at setup. DR plans have a non-disruptive test mode that rehearses the recovery without touching production and reports measured RTO/RPO. And every restore verifies each chunk against its content address as it writes, so a corrupted or tampered backup fails rather than returning bad data.

Can I restore a database to a moment between two backups?

Yes, on MySQL, PostgreSQL, MongoDB and SQL Server. The database’s own transaction log is replayed forward from a recovery point into a scratch copy — never over the live one — so you can land on 14:31, a minute before the wrong UPDATE ran, and take the rows out of it. It needs the log to have been available when the backup was taken, which the portal tells you per recovery point rather than letting you find out at the moment you need it. Schema changes made during the window are not replayed, and the report says how many were skipped.

Do I need to install an agent?

Usually not. Databases, hypervisors, cloud VMs, object storage and SaaS are all protected agentlessly over their own APIs. The agent is for machines that cannot be reached that way — physical servers, hosts behind NAT, and anywhere you want LVM/ZFS block snapshots with application quiescing.

Is it open enough that I am not locked in?

The repository format is documented and the whole stack is self-hostable: control plane, portal, data mover and agent. There is no proprietary appliance and no per-socket licence. You can run it entirely on your own hardware without any component reaching the internet.

Which platforms are production-ready today?

Maturity is shown honestly on every connector in the catalogue rather than buried. A connector marked Stable has a verified end-to-end round trip against the real platform; Beta means the integration is implemented and contract-tested but has not yet completed live certification. Of 50 connectors, 18 are Stable and 32 are Beta. We would rather tell you which is which than claim everything is finished.

Find out whether your backups restore.

Connect one source, run one backup, and restore it somewhere harmless. That is the whole evaluation — and it takes about ten minutes.