What Is a... Site-to-Site Sync?

Another entry in the "What Is a…" series, but this one comes with a confession. Most of these posts explain a VergeOS concept cleanly. This one starts with me ignoring it, and paying for it.

The night my demo box became production

It started innocently. After a call with the VergeIO sales team, I spun up a single-node VergeOS box in my basement to kick the tires: a minimum-viable-product for my homelab, the way I test ideas before I bring them to work. It worked great. Almost too well.

So I kept adding to it. A VM here, a service there. Each time I upped the ante a little, without really deciding to. And the more I piled on, the more a quiet voice in the back of my head started saying: you should set up site-to-site sync. Someday. Soon. I knew, I genuinely knew, that any single event could take the whole thing out. One node. One basement. No copy anywhere else.

Then I crossed the line without noticing. I put my blog on it: Cloudflare tunnels, Kubernetes, the works. And right there, in that moment, the demo box became production. Not because I decided it should be. Because I stopped noticing it wasn't. My public presence, my content, my projects, all of it now lived on one un-replicated machine on a basement floor, protected by snapshots that lived on that same machine.

I told myself I'd fix it. I didn't even know if anyone offered a service for syncing a VergeOS environment offsite, and it never occurred to me to just ask the Verge team. So the dread just… sat there. Daily. I knew better.

Then my sump pump died. Silently, one night, right as the spring run-off hit its peak. No alarm, no warning. I came downstairs in the morning to two inches of water across the basement floor, and my single, accidentally-critical node sitting in it.

The box was a total loss. Two inches of standing water doesn't care what you paid for the hardware; the machine was dead, and everything on it went down with it. My blog, my VMs, months of work: gone, because a $40 pump quit in the dark and the only copies I had lived on that same drowned box.

There was no clever rescue. I didn't try to resurrect it; I started fresh. And "start fresh" is a tidy phrase for rebuild everything from nothing: no VMs, no config, no networks, no blog. A miserable way to spend a spring, and every hour of it avoidable.

This post is about the one feature that would have made that morning a shrug instead of a from-scratch rebuild: site-to-site sync. And about the thing I didn't even know existed at the time: a hosted VergeOS I could have synced to, no second site of my own required, that would have let me spin my whole environment back up on someone else's hardware in minutes. More on that (KorGrid) below, but first, the basics.

In one sentence

Site-to-site sync replicates your VergeOS system's snapshots (VMs, tenants, networking, NAS, and all) to a second, separate VergeOS system, automatically and on a schedule, so a disaster at one site can't take your data with it.

How it actually works

VergeOS calls it a "complete-system, off-site backup," and the "complete-system" part is the bit people underestimate: it's the difference between "rebuild everything from scratch" and "you're already back." A sync doesn't just grab a few VMs; it replicates whole-system snapshots that include "your networking, VMs, tenants, NAS, and system configuration." The thing you restore isn't a pile of files you then have to reassemble; it's your whole environment, ready to run, onto whatever hardware you point it at.

The mechanics that make it practical:

• Block-level, changed-data-only transfer, with in-flight deduplication and compression, so after the first seed, an hourly sync is moving a small delta, not your whole system every time.
• Automatic AES-256 encryption in transit.
• Scheduling, queuing, and manual options: "hourly" is just a schedule you set. Without a schedule, snapshots sync immediately as they're created.
• Granular recovery: you can recover at a fine grain on the remote site, or sync back to the source once it's rebuilt.

The model is two systems: a receiving (incoming) side that holds the copies, and a sending (outgoing) side, yours, that pushes snapshots to it. It's one-way by design: source → destination.

Try it yourself

Here's the honest part: unlike the internal network you could build solo, a sync needs a second VergeOS system to receive it. That's the whole point: the copy has to live somewhere else. But once you have a destination, wiring it up is straightforward (all in the UI):

1. On the receiving system: open the network for sync traffic. Add a PAT rule on Networks > … > Rules: Action Translate, Protocol TCP, Direction Incoming, Destination Port 14201, Target IP ui.
2. Create the incoming sync: on Backup / DR > Incoming Syncs > New, give it a Name, the reachable URL of this system, leave vSAN Port at 14201. Open it and Copy the Registration Code.
3. On your (sending) system: on Backup / DR > Outgoing Syncs > New, paste the Registration Code, click Verify, name it, then Connect and Register.
4. Choose what syncs: under Auto Sync Configuration > Add Item, set Sync Snapshots From (e.g. Hourly), the Remote Retention, and priority.
5. Set the schedule (optional): under Sync Schedule Configuration, add Enable/Disable tasks for sync windows, or leave it off to sync continuously as snapshots are created.

That's it. From then on, every hour, your whole system quietly lands somewhere that isn't your basement.

The part I was missing: who hosts the other end?

Here's the question I never thought to ask, and it's the one that would have saved me: I don't have a second site, so where does the copy go?

It turns out there's a whole answer to that question I didn't know existed: KorGrid, a hosted VergeOS platform built to be exactly that receiving end. You point your outgoing sync at them, and your replicated copy lands on real VergeOS infrastructure you don't have to own, rack, or power. That's the piece I was missing entirely: I assumed "site-to-site" meant I needed a second site. I didn't. Someone else can be the site.

And this is the part I want to be clear about, because I almost dismissed it as a homelab-only convenience: KorGrid isn't just a parking spot for snapshots; it's a hosted VergeOS that runs sync and compute, for businesses of any size. That matters because of what a VergeOS sync actually is. Remember, it ships your whole environment. So your copy at KorGrid isn't a cold archive; it's a ready-to-run DR site. If your primary is gone (flood, fire, ransomware, a failed upgrade, a single dead pump), you can launch your actual workloads on their compute in minutes, keep running while you rebuild, and then re-sync home when you're ready. That's not a homelab toy; that's genuine business continuity, the same model whether you're protecting one blog VM or a production datacenter.

What makes it a real DR target and not just storage:

• It runs your VMs, not just stores them. Because it's a full VergeOS platform, failover means operating there, not just having a backup sitting somewhere. Warm standby, active-active, or simple offsite protection: your call, one-way or bi-directional.
• The snapshots are immutable. They can't be altered, so even ransomware or a compromised account on your source can't reach across and corrupt the copies.
• They don't bill for data transferred in or out, so syncing every hour, or replicating a large environment, doesn't quietly turn into an egress bill.
• It scales with you. The exact same setup that gives a homelabber a $-something-a-month offsite copy gives a business a full DR-and-compute site. You don't outgrow it; you just turn the dial up.

For me, it's the thing I should have set up the day the blog went on the box. If you'd rather host your own destination, the other answer is a second node, which dovetails neatly with the e-waste demo box build: a $500 second machine in a different building is a perfectly good sync target. But the honest truth is that for most people, and most businesses, standing up and maintaining a second site is the reason "someday soon" never arrives. A hosted target removes that excuse entirely. Either way, the rule is the same: the copy cannot live in the same basement as the original.

And to be clear, this isn't a hypothetical I'm recommending from the sidelines: the blog you're reading this on DR-syncs to KorGrid right now. After the flood, my off-site copy lives on their VergeOS (a ready-to-run recovery site, not a box on a basement floor), and I'm planning to migrate the whole thing over to run there when time permits. The "someday soon" I deferred for months turned out to be an afternoon, once a flooded basement finally made me stop making excuses.

Why it matters

Here's the lesson, and it's bigger than backups: there is no such thing as a demo box. There's only production you haven't admitted to yet.

Nobody decides to run their blog on an unprotected single node. They set up a toy, it works, they lean on it a little more, and one day it's load-bearing and they never threw the switch from "experiment" to "protected." The box didn't become critical the night it flooded. It became critical the day I put real work on it, months earlier. The flood just sent the invoice.

Site-to-site sync is how you make the "demo box became production" moment a non-event instead of a catastrophe. It's the difference between "I knew better" and "it didn't matter that the pump failed."

What trips people up

• Local snapshots feel like a backup. They aren't, if they live on the same node. A snapshot protects you from a bad change. It does nothing against the machine itself being destroyed; they go down together. Off-site is the whole point.
• "I'll just rebuild it" is not a recovery plan. Starting fresh after a total loss means recreating every VM, network, tenant, and setting by hand, days or weeks of work, if it's even all documented. A whole-system sync snapshot brings the entire environment back, ready to run. The point of sync isn't just keeping your data; it's not having to reassemble your world from memory.
• "Someday soon" is the actual risk. The technical setup is an afternoon. The dangerous part is the months of deferral while the box quietly gets more important.
• The destination has to be genuinely elsewhere. A second node in the same room, on the same power, in the same basement, is not disaster recovery; it's two things that drown together. Different building, different site, or a hosted target.
• Seed the first sync over a good link. The initial full copy is large; the hourly deltas after it are small. Plan the first one accordingly.

Next in the series

I replaced the sump pump and added a water alarm: the physical "never again." Site-to-site sync is the digital one, and now it's not a someday. Next in the series: "What Is a VergeOS Snapshot?" The thing sync is actually shipping offsite, and why whole-system snapshots are different from the file-level backups you're used to.