Treating Your Data Like a VIP

When it comes to digital security, one of the most
powerful tools in your arsenal has nothing to do with
software at all. It's a concept called Operational Security,
or OPSEC.

Think about how the Secret Service operates. They don't
publish the exact thickness of the armor on the presidential
limousine, and they certainly don't post blueprints of their
safe houses on social media. They treat their VIP with
absolute, silent protection. Your personal data is your VIP.
The best digital fortresses are the ones nobody even knows
exist.

Good OPSEC isn't just about hiding information. It's about
designing systems so that a single failure can't bring
everything down. Backups are where that philosophy becomes
practical.

Rather than describing a specific personal setup, we'll
walk through one potential reference architecture that
incorporates some ransomware-resistant principles.

Imagine a setup where you have a variety of computers
throughout your home. You could back up each of those
machines individually, with each machine using its own backup
drives, but that would be duplicating work. If a machine gets
infected with malware while the backup drive is plugged in,
your backup is encrypted along with your primary files.

The smarter approach is to dedicate a single, physical
machine on the LAN to act as a centralized backup server.

Every computer in the house is configured to automatically
back up to this central server over the network using the
BorgBackup backup utility.

Because this server lives physically inside the house,
behind the home router's firewall, we are operating on a
"trusted LAN" model. For this specific local server, we are
choosing not to encrypt the Borg repositories at rest.

Why? Because all the computers belong to you and are in
your physical possession, skipping repository encryption on a
trusted local server maximizes backup speed and reduces CPU
overhead. (Don't worry - as I'll cover later, when the data
eventually leaves the house for offsite cold storage, it will
be locked down tight with heavy encryption).

This centralized local server is the foundation. But just
having a server isn't enough to stop a modern threat. We have
to trap the server in a cage.

The Ransomware Trap

When ransomware infects a computer, it rarely triggers
immediately. Modern malware is patient. It quietly scans your
system for connected drives, mapped network shares (such as
standard NAS setups using SMB or CIFS), etc. If your backup
server is just a shared network drive that the machine has
full read/write access to, the ransomware will cheerfully
encrypt (or delete) your backups first, ensuring you have no
safety net when it finally detonates on your local
machine.

To defeat this, we do not mount the central backup server
as a standard network drive. Instead, BorgBackup communicates
over SSH.

First, turn off password authentication and require SSH
keys. However, simply giving your computers standard SSH
access creates a new vulnerability. If a machine is
compromised, the malware could theoretically hijack that SSH
key, log into the central backup server, and either run a
destructive command like rm -rf to delete the repository
entirely or encrypt the backups.

To solve this, we strip the client of all power and don't
give the client computers a normal shell. Instead, we trap
them in a highly restricted cage using a feature called SSH
forced commands.

On the central backup server, each client computer's
public SSH key is placed in the authorized_keys file. But
instead of just pasting the key, we prepend it with absolute
restrictions:

command="borg serve --append-only --restrict-to-path
/backups/machine1",restrict ssh-ed25519 AAAAC3...
machine1@home

The restrict keyword disables interactive terminal access,
port forwarding, and agent forwarding. The command="...":
tells the backup server to completely ignore whatever command
the client machine wants to run, and forcefully execute the
Borg server process instead. The --append-only tells the Borg
server that this specific client is only allowed to add new
data to the repository. It's stripped of the ability to
prune, delete, or overwrite any historical archives.

The Resulting Trap

Imagine one of the computers gets hit with a devastating
ransomware attack. The malware encrypts your local hard drive
and then tries to reach across the network to destroy your
backups.

Because the cage is append-only, the malware fails. It can
certainly upload the newly-encrypted files into today's
backup snapshot, but it can't modify or delete the pristine
backups from yesterday, last week, or last month. The
historical data remains perfectly preserved and entirely out
of the malware's reach.

If the client computers on the network are trapped in an
append-only cage, a practical problem arises: won't the
backup server eventually run out of hard drive space?

Yes, it will. Because client computers can't delete old
snapshots, the backup repositories will continue to grow
forever. To reclaim that space, we have to prune and compact
the old archives periodically. But here's the critical
security rule for this architecture: There's no "God-mode"
SSH key floating around the network.

If you create an administrative SSH key that can run borg
prune or borg delete and leave that key sitting on a machine,
you have just built a backdoor for the ransomware. Even if
you keep that key offline and only plug it in now and again,
while the malware is waiting, it can notice the drive
connecting and snatch the key for later use. If your machine
is compromised, the attacker steals that admin key, bypasses
your append-only cage, and wipes the server.

The Maintenance Ritual

For this reason, remote administration for destructive
commands isn't allowed by design. The only SSH stuff allowed
is with those keys that are limited to append-only backups.
When it's time to do server maintenance, the only way to
administer the backup server is to physically walk up to it
with a plugged-in keyboard and monitor.

This creates an air gap for administrative privileges.
Even if someone compromises every single machine on the local
network, they still don't have remote admin access to the
backup server, nor can they physically press the keys on its
keyboard.

Every few months, you can instead sit down at the server
console, log in locally, and run a maintenance script.

Borg handles deduplication brilliantly, so keeping a long
history of files doesn't take up as much space as you might
think. For this home architecture, a highly practical
Grandfather-Father-Son retention policy looks like this:

#!/bin/bash

REPOS=("/backups/machine1" "/backups/machine2"
"/backups/machine3")

for REPO in "${REPOS[@]}"; do

echo "Pruning $REPO..."

borg prune --list --stats \

• -keep-daily=14 \

• -keep-weekly=8 \

• -keep-monthly=12 \

• -keep-yearly=5 \

"$REPO"

echo "Compacting $REPO to free up physical space..."

borg compact "$REPO"

done

echo "Maintenance complete."

This script tells borg to look at the thousands of hourly
and daily snapshots that the append-only clients have piled
up, and thin them out. It keeps a dense history of the last
two weeks, rolls the rest into weekly and monthly milestones,
and retains a 5-year deep archive.

After pruning the index, the script runs borg compact,
which actually tells the server to physically delete
unreferenced data chunks and return the freed space to the
hard drive.

Once the script finishes, you log out of the console, turn
off the monitor, and walk away. The server goes back to
silently catching incoming append-only data, practically
invincible to anything happening on the network.

The Ultimate Failsafe: Deep Cold Storage on LTO
Tape

This reference design builds a local backup server that
can't be logically destroyed by ransomware over the network,
and we have physically isolated its administrative controls.
But it still has a fatal flaw: it exists in the physical
world.

If the building burns down in a fire or a burglar walks
out the front door with the physical machine and the drives,
the data's gone. Local backups, no matter how logically
secure, can't protect against a total site loss.

To survive a total site loss, the data must be removed
from the site. But remember our OPSEC rules: the moment our
data leaves our physically secure home network, it enters
untrusted territory. We can't just copy unencrypted Borg
repositories to external drives and leave them at a friend's
house.

The solution is deep cold storage using LTO tape. Tape is
inexpensive per terabyte, mathematically immune to
network-based ransomware once ejected, and perfect for
throwing in a safe deposit box.

Because the local server handles the day-to-day granular
recovery (like restoring a document you accidentally deleted
yesterday), we don't need to write to tape every day. A less
frequent schedule seems more appropriate. Perhaps quarterly,
but it really depends on your needs to provide a reasonably
fresh total-loss recovery point without turning tape rotation
into a tedious chore.

Writing to tape isn't like copying a file to a drive. Tape
drives stream data linearly, and they absolutely hate being
starved of data - a condition that causes "shoe-shining,"
where the tape stops, rewinds, and restarts, wearing out both
the tape and the drive mechanism.

To dump the entire unencrypted local Borg repository to an
encrypted tape smoothly for later offsite storage, you can
use a robust BASH pipeline:

#!/bin/sh

TAPE="/dev/nst0"

Calculate the total size of the Borg repository for the

progress meter

totalsize=$(du -csb . | tail -1 | cut -f1)

The Pipeline: tar -> gpg -> pipemeter -> mbuffer

• > tape

tar cf - . | \

gpg --symmetric --cipher-algo AES256 --compress-algo none |
\

pipemeter -s $totalsize -a -l | \

mbuffer -m 3G -P 95% -f -R 100M -o $TAPE \

• A "echo next tape; mt-st -f $TAPE eject ; read a <
/dev/tty"

Here's exactly what's happening:

• tar cf - .: This reads the raw Borg repository files
from the local hard drive and packages them into a
continuous data stream (standard output) rather than
creating a massive file on the disk.

• gpg --symmetric: This intercepts the tar stream and
encrypts it on the fly using AES. Notice the
• -compress-algo none flag? Borg already heavily compresses
its chunks. Trying to compress data that's already
compressed wastes CPU cycles and slows down the pipeline,
potentially starving the tape drive.

• pipemeter: This provides a visual progress bar based on
the total size we calculated at the beginning of the
script.

• mbuffer: This catches the encrypted stream and holds it
in a 3-Gigabyte RAM buffer (-m 3G). It waits until the
buffer is 95% full (-P 95%) before starting to write to the
tape at a steady, controlled rate (-R 100M). This
guarantees the tape drive is constantly fed and never
"shoe-shines."

• -A "echo next tape...": If your Borg repository is
larger than a single tape's capacity, mbuffer automatically
pauses, ejects the full tape, and prompts you to insert the
next one to span the archive across multiple volumes
seamlessly.

Offsite OPSEC

Once the script finishes, you eject the tape and
physically remove it from the building.

Because the data stream was encrypted before it ever
touched the magnetic tape, the physical location where you
store it doesn't need to be a digital fortress. You can drop
it in a bank vault, leave it in a locked desk drawer at your
office, or hand it to a trusted family member. If someone
steals the tape, they get a useless spool of cryptographic
noise.

Conclusion: We Do Not Negotiate

This builds a reference architecture that logically
defeats network-based ransomware using an append-only cage,
physically air-gaps its own administrative controls, and
survives a total site disaster through offsite encrypted LTO
tape storage.

In the event of a catastrophic ransomware infection or if
your house burns to the ground, you can walk into your bank
vault, grab the tape, and restore it on a brand-new computer
anywhere in the world with zero extra hardware. The only
thing you need is to keep the passphrase in your memory. It's
the ultimate zero-footprint recovery.

With this architecture in place, your response to a
catastrophic ransomware infection is no longer a panic
attack. It is a sterile, mechanical process:

• Do Not Negotiate: You don't email the attackers. You do
not check Bitcoin's price.

• Scorched Earth: You completely wipe the drives. You
don't try to clean them with antivirus software; you format
the drives and reinstall the operating systems from
scratch. In the worst-case scenario, you buy new computers
to ensure no persistence mechanisms survive.

You then connect the freshly installed, sterile machines
back to the network, point them at the uninfected historical
archives on your local Borg server, and restore your
files.

If a true disaster manages to destroy the local server
physically? You go to your offsite location, grab your tapes,
and use your memorized passphrase to restore from that.

The Final Word on OPSEC

This is one possible reference architecture, and it can be
improved in many ways. For example, the backup server should
notify you if some machine misses it's regularly-scheduled
backup appointment. Also, you should regularly test your
recovery procedures by restoring data from different points
in time. This practice verifies that your backup system
functions correctly and that your data can be reliably
recovered when needed.

But whatever specific details you establish, treat your
data like a VIP, which means giving it quiet, invisible, and
unforgiving protection. Strong processes and policies around
backups eliminate the leverage of extortionists and the risk
of facility losses.

Copyright © 2026 Jason Self. Unless otherwise noted
material on this site is licensed under the GNU General Public
License as published by the Free Software Foundation, either
version 3 of the License, or (at your option) any later
version. A copy of the license is included at gpl-3.0.shtml. Please copy and
share.