Treating Your Data Like a VIP
Sat, 7 Mar 2026
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.
