Your Homelab Backup Strategy Has a Single Point of Failure: Your House
Reciprocal backups with a friend solve the offsite problem without cloud bills, but the usual setup means opening rsync or SSH ports to the internet. A Twingate Connector on each side lets you scope access to a single backup target with no exposed ports and no network-level trust. See the Twingate Connector docs for deployment specifics.
Your NAS is fine. Your snapshots are fine. Your ZFS pool has parity, your Proxmox backups run nightly, and you feel pretty good about the whole setup right up until the moment a pipe bursts in the utility closet above the rack, or a lightning strike takes out the entire subpanel, or somebody walks off with the box during a break-in.
Every copy of your data lives in the same building. That building is the single point of failure.
The 3-2-1 rule exists for exactly this reason: three copies, two different media, one offsite. Most homelab operators nail the first two and quietly ignore the third, because Backblaze B2 at $6/TB/month starts to sting once you're pushing 20TB of media and VM images. So the elegant workaround has always been reciprocal backups with a friend. You back up to their NAS, they back up to yours, everybody sleeps better.
The problem is what you have to do to make that work.
The trust boundary problem with reciprocal backups
The standard reciprocal backup recipe looks something like this: pick a protocol (rsync over SSH, restic to an SFTP target, Syncthing, Borg, whatever), open a port on your friend's router, forward it to their NAS, generate a keypair, exchange keys, run a nightly cron job. Done.
You have now:
Exposed a service on your friend's public IP
Trusted their patching cadence for a piece of software that will have a CVE eventually
Given a remote key holder network-level reachability to a machine on their LAN
Created a persistent inbound firewall rule that will outlive the reason you created it
Any one of these is manageable in isolation. Together, they compound.
The January 2025 rsync disclosures are the recent worked example. Six CVEs landed at once, including CVE-2024-12084, a heap buffer overflow in the rsync daemon that could allow remote code execution, and CVE-2024-12085, an information leak in the checksum comparison logic. Chained together, they could be exploited against internet-exposed rsync daemons with default configurations. Synology, TrueNAS, and QNAP all had to ship patches. Anyone running an rsyncd module on a forwarded port was a target for as long as it took their vendor to release a fix and them to apply it.
You can argue that rsync-over-SSH was less exposed than rsyncd, and you'd be right. But SSH has its own history (regreSSHion, terrapin, and the periodic key exchange downgrade issues), and the more relevant point is that the mitigation posture is the same regardless of protocol: pray that nobody weaponizes the CVE faster than your friend patches.
The other problem: network-level access is too much access
Even if the software is bulletproof, the access model is wrong.
When you SSH into your friend's NAS to run a backup, you can reach the NAS. You can also reach anything else the NAS can reach, if you can find a way to pivot. From that shell you can scan their LAN, hit their router's admin interface, poke at their Home Assistant instance, or notice that their Jellyfin server has an old auth bypass.
You almost certainly won't do any of this, because they're your friend. But the network doesn't know that. It just knows the SSH connection is authenticated and the packets are allowed.
This is the same problem enterprises hit with vendor VPNs. Give a contractor VPN access so they can maintain one appliance, and you've now given them routing to the entire flat network the appliance sits on. The blast radius of a credential compromise is enormous compared to what the access was supposed to accomplish.
The fix, in both cases, is to stop thinking about "network access" and start thinking about "resource access."
What resource-scoped access actually looks like
Zero Trust Network Access (ZTNA) inverts the model. Instead of putting a user on a network and letting them reach whatever the network routes to, you grant access to a specific resource (a hostname, a service, a share) and nothing else exists as far as that user is concerned.
Here's how the reciprocal backup pattern looks with Twingate on both sides:
Each of you deploys a Connector inside your own LAN. The Connector is a small container or systemd service. It makes outbound-only connections to Twingate's Controller. No ports open on your router. No port forwarding. No dynamic DNS.
Each of you defines a single Resource: the FQDN or IP of the backup target, scoped to the port your backup protocol runs on. Not the subnet. Not the NAS. Just the SMB share, or the rsync module, or the SFTP endpoint.
Each of you grants the other person's identity access to exactly that Resource.
Backups run over the Twingate tunnel. The remote side sees an authenticated, identity-bound connection to one endpoint.
The friend backing up to your NAS cannot see your Home Assistant, your Unifi controller, your Proxmox hosts, your printer, or the fact that you have a Jellyfin server at all. Their Client only knows about the one Resource you gave them. DNS queries for anything else on your LAN don't route through the tunnel.
There's nothing to enumerate because there's nothing to see.
Legacy vs. Twingate mitigations for reciprocal backup
Concern | Port-forward + SSH/rsync | Twingate Connector |
|---|---|---|
Public attack surface | rsyncd/SSH exposed on router IP | None — Connector is outbound-only |
Dependency on remote patching | Direct exposure to any CVE in the exposed service | CVE in backup protocol is still relevant, but only reachable over authenticated tunnel |
Access scope after auth | Full network reachability from remote key holder | Single Resource, port-scoped |
Lateral movement risk from compromised credential | High — pivot to LAN | None — no other Resources exposed |
Identity binding | SSH key (portable, shareable, hard to revoke cleanly) | Tied to IdP identity, revocable in seconds |
Audit trail | SSH logs on the target machine only | Connection logs at the Controller, per-Resource |
Setup requires DDNS / static IP | Yes | No |
The CVE in your backup protocol is still a CVE. Twingate doesn't patch rsync. What it does is make sure the only way to reach rsync at all is through an authenticated, identity-bound tunnel, which means the drive-by scanning population that finds internet-exposed rsync daemons on port 873 simply cannot see yours.
Setting it up: the shape of the config
The full walkthrough lives in our docs, but the shape is worth seeing.
On each side, deploy a Connector. The Docker one-liner looks something like this — this pulls the Connector image and runs it with credentials you generate in the admin console:
docker run -d \ --name twingate-connector \ --restart=always \ --sysctl net.ipv4.ping_group_range="0 2147483647" \ --env TWINGATE_NETWORK="yournetwork" \ --env TWINGATE_ACCESS_TOKEN="<access-token>" \ --env TWINGATE_REFRESH_TOKEN="<refresh-token>
In the Twingate Admin Console, define a Resource pointing at just the backup endpoint. For rsync-over-SSH to a NAS at nas.lan on port 22, the Resource address is nas.lan and the protocol restriction is TCP/22. For an SMB share on port 445, it's nas.lan TCP/445. You are not exposing the NAS. You are exposing one port on one hostname.
Add your friend's Twingate identity to the policy for that Resource. They install the Twingate Client on their backup host, sign in, and their backup job can now resolve and reach nas.lan, and nothing else on your network.
Their nightly rsync command doesn't change:
The Client intercepts DNS for nas.lan, routes that traffic through the Connector on your side, and passes everything else out their normal internet connection. Split tunneling is the default, not a feature you configure.
Why this pattern generalizes
If you're reading this as a homelab operator, the reciprocal-backup use case is the whole point. But the same shape applies anywhere you'd otherwise hand out network-level access to accomplish a resource-level task.
A startup CTO deciding how to give a vendor access to one production database faces the same architectural question as a homelab operator deciding how to give a friend access to one backup share. In both cases, the intuitive answer (VPN them in, or open a port) creates blast radius that has nothing to do with the actual work being done. In both cases, the better answer is to expose exactly the one resource that matters and let everything else remain unreachable and unenumerable.
The reason to care about this pattern in the homelab is that it's low-stakes practice for a habit that gets very expensive to develop the wrong way at work.
Closing
For a full walkthrough of deploying Connectors, defining Resources, and managing access policies, the Twingate documentation covers the specifics for Docker, systemd, Synology, TrueNAS, and Kubernetes deployments.
New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
Your Homelab Backup Strategy Has a Single Point of Failure: Your House
Reciprocal backups with a friend solve the offsite problem without cloud bills, but the usual setup means opening rsync or SSH ports to the internet. A Twingate Connector on each side lets you scope access to a single backup target with no exposed ports and no network-level trust. See the Twingate Connector docs for deployment specifics.
Your NAS is fine. Your snapshots are fine. Your ZFS pool has parity, your Proxmox backups run nightly, and you feel pretty good about the whole setup right up until the moment a pipe bursts in the utility closet above the rack, or a lightning strike takes out the entire subpanel, or somebody walks off with the box during a break-in.
Every copy of your data lives in the same building. That building is the single point of failure.
The 3-2-1 rule exists for exactly this reason: three copies, two different media, one offsite. Most homelab operators nail the first two and quietly ignore the third, because Backblaze B2 at $6/TB/month starts to sting once you're pushing 20TB of media and VM images. So the elegant workaround has always been reciprocal backups with a friend. You back up to their NAS, they back up to yours, everybody sleeps better.
The problem is what you have to do to make that work.
The trust boundary problem with reciprocal backups
The standard reciprocal backup recipe looks something like this: pick a protocol (rsync over SSH, restic to an SFTP target, Syncthing, Borg, whatever), open a port on your friend's router, forward it to their NAS, generate a keypair, exchange keys, run a nightly cron job. Done.
You have now:
Exposed a service on your friend's public IP
Trusted their patching cadence for a piece of software that will have a CVE eventually
Given a remote key holder network-level reachability to a machine on their LAN
Created a persistent inbound firewall rule that will outlive the reason you created it
Any one of these is manageable in isolation. Together, they compound.
The January 2025 rsync disclosures are the recent worked example. Six CVEs landed at once, including CVE-2024-12084, a heap buffer overflow in the rsync daemon that could allow remote code execution, and CVE-2024-12085, an information leak in the checksum comparison logic. Chained together, they could be exploited against internet-exposed rsync daemons with default configurations. Synology, TrueNAS, and QNAP all had to ship patches. Anyone running an rsyncd module on a forwarded port was a target for as long as it took their vendor to release a fix and them to apply it.
You can argue that rsync-over-SSH was less exposed than rsyncd, and you'd be right. But SSH has its own history (regreSSHion, terrapin, and the periodic key exchange downgrade issues), and the more relevant point is that the mitigation posture is the same regardless of protocol: pray that nobody weaponizes the CVE faster than your friend patches.
The other problem: network-level access is too much access
Even if the software is bulletproof, the access model is wrong.
When you SSH into your friend's NAS to run a backup, you can reach the NAS. You can also reach anything else the NAS can reach, if you can find a way to pivot. From that shell you can scan their LAN, hit their router's admin interface, poke at their Home Assistant instance, or notice that their Jellyfin server has an old auth bypass.
You almost certainly won't do any of this, because they're your friend. But the network doesn't know that. It just knows the SSH connection is authenticated and the packets are allowed.
This is the same problem enterprises hit with vendor VPNs. Give a contractor VPN access so they can maintain one appliance, and you've now given them routing to the entire flat network the appliance sits on. The blast radius of a credential compromise is enormous compared to what the access was supposed to accomplish.
The fix, in both cases, is to stop thinking about "network access" and start thinking about "resource access."
What resource-scoped access actually looks like
Zero Trust Network Access (ZTNA) inverts the model. Instead of putting a user on a network and letting them reach whatever the network routes to, you grant access to a specific resource (a hostname, a service, a share) and nothing else exists as far as that user is concerned.
Here's how the reciprocal backup pattern looks with Twingate on both sides:
Each of you deploys a Connector inside your own LAN. The Connector is a small container or systemd service. It makes outbound-only connections to Twingate's Controller. No ports open on your router. No port forwarding. No dynamic DNS.
Each of you defines a single Resource: the FQDN or IP of the backup target, scoped to the port your backup protocol runs on. Not the subnet. Not the NAS. Just the SMB share, or the rsync module, or the SFTP endpoint.
Each of you grants the other person's identity access to exactly that Resource.
Backups run over the Twingate tunnel. The remote side sees an authenticated, identity-bound connection to one endpoint.
The friend backing up to your NAS cannot see your Home Assistant, your Unifi controller, your Proxmox hosts, your printer, or the fact that you have a Jellyfin server at all. Their Client only knows about the one Resource you gave them. DNS queries for anything else on your LAN don't route through the tunnel.
There's nothing to enumerate because there's nothing to see.
Legacy vs. Twingate mitigations for reciprocal backup
Concern | Port-forward + SSH/rsync | Twingate Connector |
|---|---|---|
Public attack surface | rsyncd/SSH exposed on router IP | None — Connector is outbound-only |
Dependency on remote patching | Direct exposure to any CVE in the exposed service | CVE in backup protocol is still relevant, but only reachable over authenticated tunnel |
Access scope after auth | Full network reachability from remote key holder | Single Resource, port-scoped |
Lateral movement risk from compromised credential | High — pivot to LAN | None — no other Resources exposed |
Identity binding | SSH key (portable, shareable, hard to revoke cleanly) | Tied to IdP identity, revocable in seconds |
Audit trail | SSH logs on the target machine only | Connection logs at the Controller, per-Resource |
Setup requires DDNS / static IP | Yes | No |
The CVE in your backup protocol is still a CVE. Twingate doesn't patch rsync. What it does is make sure the only way to reach rsync at all is through an authenticated, identity-bound tunnel, which means the drive-by scanning population that finds internet-exposed rsync daemons on port 873 simply cannot see yours.
Setting it up: the shape of the config
The full walkthrough lives in our docs, but the shape is worth seeing.
On each side, deploy a Connector. The Docker one-liner looks something like this — this pulls the Connector image and runs it with credentials you generate in the admin console:
docker run -d \ --name twingate-connector \ --restart=always \ --sysctl net.ipv4.ping_group_range="0 2147483647" \ --env TWINGATE_NETWORK="yournetwork" \ --env TWINGATE_ACCESS_TOKEN="<access-token>" \ --env TWINGATE_REFRESH_TOKEN="<refresh-token>
In the Twingate Admin Console, define a Resource pointing at just the backup endpoint. For rsync-over-SSH to a NAS at nas.lan on port 22, the Resource address is nas.lan and the protocol restriction is TCP/22. For an SMB share on port 445, it's nas.lan TCP/445. You are not exposing the NAS. You are exposing one port on one hostname.
Add your friend's Twingate identity to the policy for that Resource. They install the Twingate Client on their backup host, sign in, and their backup job can now resolve and reach nas.lan, and nothing else on your network.
Their nightly rsync command doesn't change:
The Client intercepts DNS for nas.lan, routes that traffic through the Connector on your side, and passes everything else out their normal internet connection. Split tunneling is the default, not a feature you configure.
Why this pattern generalizes
If you're reading this as a homelab operator, the reciprocal-backup use case is the whole point. But the same shape applies anywhere you'd otherwise hand out network-level access to accomplish a resource-level task.
A startup CTO deciding how to give a vendor access to one production database faces the same architectural question as a homelab operator deciding how to give a friend access to one backup share. In both cases, the intuitive answer (VPN them in, or open a port) creates blast radius that has nothing to do with the actual work being done. In both cases, the better answer is to expose exactly the one resource that matters and let everything else remain unreachable and unenumerable.
The reason to care about this pattern in the homelab is that it's low-stakes practice for a habit that gets very expensive to develop the wrong way at work.
Closing
For a full walkthrough of deploying Connectors, defining Resources, and managing access policies, the Twingate documentation covers the specifics for Docker, systemd, Synology, TrueNAS, and Kubernetes deployments.
New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
Your Homelab Backup Strategy Has a Single Point of Failure: Your House
Reciprocal backups with a friend solve the offsite problem without cloud bills, but the usual setup means opening rsync or SSH ports to the internet. A Twingate Connector on each side lets you scope access to a single backup target with no exposed ports and no network-level trust. See the Twingate Connector docs for deployment specifics.
Your NAS is fine. Your snapshots are fine. Your ZFS pool has parity, your Proxmox backups run nightly, and you feel pretty good about the whole setup right up until the moment a pipe bursts in the utility closet above the rack, or a lightning strike takes out the entire subpanel, or somebody walks off with the box during a break-in.
Every copy of your data lives in the same building. That building is the single point of failure.
The 3-2-1 rule exists for exactly this reason: three copies, two different media, one offsite. Most homelab operators nail the first two and quietly ignore the third, because Backblaze B2 at $6/TB/month starts to sting once you're pushing 20TB of media and VM images. So the elegant workaround has always been reciprocal backups with a friend. You back up to their NAS, they back up to yours, everybody sleeps better.
The problem is what you have to do to make that work.
The trust boundary problem with reciprocal backups
The standard reciprocal backup recipe looks something like this: pick a protocol (rsync over SSH, restic to an SFTP target, Syncthing, Borg, whatever), open a port on your friend's router, forward it to their NAS, generate a keypair, exchange keys, run a nightly cron job. Done.
You have now:
Exposed a service on your friend's public IP
Trusted their patching cadence for a piece of software that will have a CVE eventually
Given a remote key holder network-level reachability to a machine on their LAN
Created a persistent inbound firewall rule that will outlive the reason you created it
Any one of these is manageable in isolation. Together, they compound.
The January 2025 rsync disclosures are the recent worked example. Six CVEs landed at once, including CVE-2024-12084, a heap buffer overflow in the rsync daemon that could allow remote code execution, and CVE-2024-12085, an information leak in the checksum comparison logic. Chained together, they could be exploited against internet-exposed rsync daemons with default configurations. Synology, TrueNAS, and QNAP all had to ship patches. Anyone running an rsyncd module on a forwarded port was a target for as long as it took their vendor to release a fix and them to apply it.
You can argue that rsync-over-SSH was less exposed than rsyncd, and you'd be right. But SSH has its own history (regreSSHion, terrapin, and the periodic key exchange downgrade issues), and the more relevant point is that the mitigation posture is the same regardless of protocol: pray that nobody weaponizes the CVE faster than your friend patches.
The other problem: network-level access is too much access
Even if the software is bulletproof, the access model is wrong.
When you SSH into your friend's NAS to run a backup, you can reach the NAS. You can also reach anything else the NAS can reach, if you can find a way to pivot. From that shell you can scan their LAN, hit their router's admin interface, poke at their Home Assistant instance, or notice that their Jellyfin server has an old auth bypass.
You almost certainly won't do any of this, because they're your friend. But the network doesn't know that. It just knows the SSH connection is authenticated and the packets are allowed.
This is the same problem enterprises hit with vendor VPNs. Give a contractor VPN access so they can maintain one appliance, and you've now given them routing to the entire flat network the appliance sits on. The blast radius of a credential compromise is enormous compared to what the access was supposed to accomplish.
The fix, in both cases, is to stop thinking about "network access" and start thinking about "resource access."
What resource-scoped access actually looks like
Zero Trust Network Access (ZTNA) inverts the model. Instead of putting a user on a network and letting them reach whatever the network routes to, you grant access to a specific resource (a hostname, a service, a share) and nothing else exists as far as that user is concerned.
Here's how the reciprocal backup pattern looks with Twingate on both sides:
Each of you deploys a Connector inside your own LAN. The Connector is a small container or systemd service. It makes outbound-only connections to Twingate's Controller. No ports open on your router. No port forwarding. No dynamic DNS.
Each of you defines a single Resource: the FQDN or IP of the backup target, scoped to the port your backup protocol runs on. Not the subnet. Not the NAS. Just the SMB share, or the rsync module, or the SFTP endpoint.
Each of you grants the other person's identity access to exactly that Resource.
Backups run over the Twingate tunnel. The remote side sees an authenticated, identity-bound connection to one endpoint.
The friend backing up to your NAS cannot see your Home Assistant, your Unifi controller, your Proxmox hosts, your printer, or the fact that you have a Jellyfin server at all. Their Client only knows about the one Resource you gave them. DNS queries for anything else on your LAN don't route through the tunnel.
There's nothing to enumerate because there's nothing to see.
Legacy vs. Twingate mitigations for reciprocal backup
Concern | Port-forward + SSH/rsync | Twingate Connector |
|---|---|---|
Public attack surface | rsyncd/SSH exposed on router IP | None — Connector is outbound-only |
Dependency on remote patching | Direct exposure to any CVE in the exposed service | CVE in backup protocol is still relevant, but only reachable over authenticated tunnel |
Access scope after auth | Full network reachability from remote key holder | Single Resource, port-scoped |
Lateral movement risk from compromised credential | High — pivot to LAN | None — no other Resources exposed |
Identity binding | SSH key (portable, shareable, hard to revoke cleanly) | Tied to IdP identity, revocable in seconds |
Audit trail | SSH logs on the target machine only | Connection logs at the Controller, per-Resource |
Setup requires DDNS / static IP | Yes | No |
The CVE in your backup protocol is still a CVE. Twingate doesn't patch rsync. What it does is make sure the only way to reach rsync at all is through an authenticated, identity-bound tunnel, which means the drive-by scanning population that finds internet-exposed rsync daemons on port 873 simply cannot see yours.
Setting it up: the shape of the config
The full walkthrough lives in our docs, but the shape is worth seeing.
On each side, deploy a Connector. The Docker one-liner looks something like this — this pulls the Connector image and runs it with credentials you generate in the admin console:
docker run -d \ --name twingate-connector \ --restart=always \ --sysctl net.ipv4.ping_group_range="0 2147483647" \ --env TWINGATE_NETWORK="yournetwork" \ --env TWINGATE_ACCESS_TOKEN="<access-token>" \ --env TWINGATE_REFRESH_TOKEN="<refresh-token>
In the Twingate Admin Console, define a Resource pointing at just the backup endpoint. For rsync-over-SSH to a NAS at nas.lan on port 22, the Resource address is nas.lan and the protocol restriction is TCP/22. For an SMB share on port 445, it's nas.lan TCP/445. You are not exposing the NAS. You are exposing one port on one hostname.
Add your friend's Twingate identity to the policy for that Resource. They install the Twingate Client on their backup host, sign in, and their backup job can now resolve and reach nas.lan, and nothing else on your network.
Their nightly rsync command doesn't change:
The Client intercepts DNS for nas.lan, routes that traffic through the Connector on your side, and passes everything else out their normal internet connection. Split tunneling is the default, not a feature you configure.
Why this pattern generalizes
If you're reading this as a homelab operator, the reciprocal-backup use case is the whole point. But the same shape applies anywhere you'd otherwise hand out network-level access to accomplish a resource-level task.
A startup CTO deciding how to give a vendor access to one production database faces the same architectural question as a homelab operator deciding how to give a friend access to one backup share. In both cases, the intuitive answer (VPN them in, or open a port) creates blast radius that has nothing to do with the actual work being done. In both cases, the better answer is to expose exactly the one resource that matters and let everything else remain unreachable and unenumerable.
The reason to care about this pattern in the homelab is that it's low-stakes practice for a habit that gets very expensive to develop the wrong way at work.
Closing
For a full walkthrough of deploying Connectors, defining Resources, and managing access policies, the Twingate documentation covers the specifics for Docker, systemd, Synology, TrueNAS, and Kubernetes deployments.
New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.
Solutions
Solutions
The VPN replacement your workforce will love.
Solutions