Steam over the bath.The capybara is calm —last night’s copy holds.

copi.bar is agentless backup and recovery for VMware vSphere. It keeps its own hours, tidies up after itself and has every night’s copy ready when you need it back.

Not on sale yet Write to us

Built for our own fleet. Soon, for yours.

XServer has run a hosting business since 2007. We built copi.bar to back up our own VMware fleet. Full and incremental backup, whole-VM restore and restore in place are already proven on a live vCenter.

Now we are preparing it for others: copi.bar will be licensed to other hosting providers and to the system administrators of companies that run VMware vSphere.

XServer

hosting company
Hosting since
2007
Networks
AS202656 · AS48031
Data centres
UA · DE · NL · UK · PL · BG · US
Built for
XServer’s own VMware fleet
Next
licences for hosters and in-house IT teams
Status
in development, not on sale yet

How it works in your cluster

Six things copi.bar always does. Short, because there is not much to it.

You will need: vCenter, a Linux VM for copi.bar (Ubuntu 22.04 or 24.04, 4–8 vCPU, 4–8 GB RAM) and an NFS export or a local disk for the repository.

House rules

  1. No agents in your VMs.copi.bar uses VMware’s own backup interface (VADP). There is nothing to install or update inside guests.
  2. One program on one Linux VM.Scheduler, web UI and REST API are a single binary on a proxy VM inside your cluster. No Windows server, no SQL Server.
  3. Every chunk is checked again.A background scrubber keeps re-reading stored chunks and comparing each with its hash; deep verify and a store-wide consistency check run on demand.
  4. Everything has an API.A REST API with an OpenAPI spec, live events over WebSocket, Prometheus metrics and a Grafana dashboard.
  5. It speaks up only when needed.Email alerts, an audit log of every action, and pre- and post-job scripts for your own hooks.

Stored like an object store, deduplicated across everything.

copi.bar does not keep backups as files in folders. Every disk is cut into 4 MB chunks; each chunk is compressed with zstd, named by the hash of its content, written once and never rewritten. A restore point is a short manifest: the list of chunks it is made of.

VM disks, cut into chunks
web-01a3f7c10d29be0d2e91
web-02a3f7c10d25aa0d24bd
db-01a3f7c1c48c48c4831f
Repository: each chunk once
a3f7c10d29bee915aa4bdc4831f
Tonight’s Offsite Copy
e914bd31fsecond repository or S3 with Object Lock
Sample: 18 chunks from three VMs are stored as 9. The outlined ones are new tonight, and only they travel to the copy.
  • Deduplicated across the whole repositoryThe same block in a hundred VMs — the same OS, the same libraries — is stored one time. Dedup works across every VM and every restore point in the repository, not inside one VM’s chain.
  • Copies send only what is newOffsite Copy knows which chunks the target already holds and transfers only the missing ones; on S3 with Object Lock it extends the lock on the rest. A nightly copy is the size of the night’s changes.
  • A restore point costs a manifestKeeping another night adds only its new chunks and a small list. Retention removes a point by dropping its manifest; chunks nobody refers to any more are cleaned up afterwards.

Backups run on schedule, with nobody watching.

You set the schedule once in the web UI. From then on every job starts on time, every night, whether anyone is watching or not.

Each job takes a VMware snapshot, reads only the blocks that changed since last night (CBT) and sends them to the repository over HotAdd, or over the network when it has to.

If VMware Tools cannot quiesce a guest, the backup still runs, crash-consistent, and the restore point says so. If CBT gets reset, the run turns itself into a full backup. Nobody needs to be woken up for either.

Opening hours

Every night
  1. Back up production VMsnextIncremental through CBT, application-consistent where VMware Tools allow
  2. Offsite CopynextA second copy to another repository or to S3 with Object Lock
  3. RetentionnextKeep 14 nights, 8 weeks and 12 months; let the rest go
  4. ScrubnextRe-read stored chunks and check each against its hash

01:00. The capybara is asleep. That is the point.

A sample schedule. Yours is set in the web UI, job by job.

Every night is a restore point.

Each run leaves a restore point. Pick any of them: the newest comes first, the oldest is removed when the retention policy says so.

Sample restore points, dated by your calendar. Big dot: full, small dot: incremental.

In our own measurement a 50 GB VM came back whole in about three minutes. One measurement, on our hardware; yours will differ.

Bring it back the way you need it

From the newest point
  • Whole VMBack where it was, or to another host, datastore or name, with its configuration: NICs, port groups, tags, resource pool.
  • RewindRoll an existing VM back to this point. For a powered-off VM it writes back only the blocks that changed (CBT).
  • File PickupBrowse the guest’s disks in the browser (ext4, XFS, Btrfs, NTFS, FAT32, LVM) and download what you need.
  • Hot StartBoot the VM straight from the repository, then move it home with Storage vMotion while it runs.

Open Backup: any restore point as a folder

The repository mounts as a read-only filesystem (FUSE): every VM, every restore point and every disk appears as an ordinary .vmdk file, assembled from chunks as it is read. Shared with ESXi over NFS, the same files are what Hot Start boots from.

File Pickup needs nothing started: the web UI opens the restore point’s disks, finds partitions, LVM and filesystems, and lets you browse and download what you need. No helper VM, no agent in the guest.

/mnt/backups/
├─ web-01/
│  ├─ 2026-11-04_01-00_incr/
│  │  ├─ web-01.vmx
│  │  ├─ disk-scsi0-0.vmdk
│  │  └─ disk-scsi0-0-flat.vmdk
│  └─ 2026-11-03_01-00_incr/
└─ db-01/
Sample listing. The .vmdk files are assembled from chunks as they are read.

Availability

copi.bar is not on sale yet. This is where it stands.

Admission

Licence
not on sale yet
Trial
not yet
First installation
XServer’s own fleet

No prices until the product is ready to be sold. We would rather not guess.

Not in the product yet

  • More than one administrator, roles and single sign-on
  • Encryption of backups at rest
  • An installer package or a virtual appliance
  • Licensing and automatic updates
  • Hypervisors other than VMware

Questions, or want to hear when it is ready? Write to us.

Write to us