You can get started for FREE with a 10GB vault. I think that’s really cool, because it’s enough to actually give it a try and use it productively. It’s not time-limited, so you can set up a vault, stream some backups to it, and let it keep working to really test the service.

So I decided to do just that.

I have a small box I use for VPN purposes on DigitalOcean. It’s a 512MB “droplet” (ick – it’s a VPS people). I already back it up to my home lab, but it’s a good candidate for a Restic-based backup.

In general, when I backup, I capture the following:

• Essential file and filesystems, using a “default include” model. I exclude a bunch of directories such as /dev, but by default I include everything.
• I also include “status” dumps, such as dpkg -l, ps -ef, df -h, and other info.
• Finally I do database dumps.

In the case of my VPN server, the things I care about are:

• /etc, where all the OpenVPN config lives
• because I use @Nyr’s Road Warrior script and I put the .ovpn file in /root, I should back that up, too.
• My own backups put data in /backup (dpkg -l output, etc.) so I’ll back that up.

People seem to approach this from the wrong angle. The question here should always be what data do we actually genuinely need to be able to back up and restore? //

The problem was this was 30+ years ago. Imagine even in a small salon we'd backed up decades of booking data on the basis that we could easily store it given the cheapness of storage.

Now compound that problem across all businesses and throw in loads of AI toss. How much stuff is actually in backups that is never going to see the light of day again?

The volume of data that you could back up in comparison to what you genuinely need gets more and more skewed over the years. Which is part of this problem and a reason why so many people either don't have a proper strategy or find it just doesn't work when they need a restore.

If systems designed to withstand war cannot cope with sustained physical attacks, civilian bit barns have little chance. The episode also underlines a familiar but easily neglected lesson: resilience within one cloud region is not the same thing as maintaining an independent backup elsewhere.

Physical destruction is not the only threat. A major outage of the UK air traffic control system in September, which stranded hundreds of thousands of passengers and led to thousands of flight cancellations, was reportedly triggered by a military aircraft filing an incompatible flight plan. Presumably Flight Lieutenant Bobby Tables has been reprimanded.

The apparent failure to validate the flight plan data was not the worst of it. NATS, which runs the UK's air traffic control system, reportedly told airports and airlines that no backup system was available because it was undergoing a "complete overhaul." Nor was there a backup of the live data, supposedly because of the "vast amounts" involved.

If your system produces too much data to back up, you had better be running a particle collider or a giant telescope. Otherwise, you may be in the wrong business. More charitably, backup strategies are complicated, expensive, and difficult to test. They also suffer from the insurance problem: while nothing is going wrong, management sees only capital and operating expenditure with no obvious return. //

The development of marine insurance in 14th-century Italian city-states spread risk and helped make what became today's global trading network viable. The loss of a vessel was no longer an existential disaster for its owner. Provided insurers understood and priced the risks correctly, the market could grow in lockstep with mercantile activity. Data resilience has a similar dynamic, although it is rarely described in those terms. Modern IT would be impossible without it, and moving off-premises amounts to sharing some of that risk with an outside provider. //

It may take the combination of geopolitical instability and intense competition for storage to make enterprises perform similar calculations about their own precious cargoes of information. When AWS can lose an entire region and critical national infrastructure can fail without an adequate backup, those risks have plainly not been priced in properly. There is no global market where AWS, NATS, or your organization can buy the data equivalent of war-risk insurance, although imagining what one might look like suggests some intriguing possibilities.

Until something like that happens, we'll have to play by the old rules. Work through what happens if your primary data store disappears. Match backup provision to the actual risks, and if you cannot afford to protect all the data your organization needs to survive, determine how to survive with less. Backups, like insurance, are all too easy to let slide.

“The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand,” the AWS update said.

Backup Service Offers

Free

• 10GB storage
• 1 device
• 7-day retention
• $0/month, no card required

Starter

• 200GB storage
• 1 device
• 30-day retention
• Coupon: LEB25
• $3.75/month or $45/year (prices after coupon)

Bottom line

3 copies, 2 media types, 1 offsite -- the classic rule still works.

Add a 4th rule for 2026: at least one copy must be immutable (append-only, WORM, or object-lock) to survive ransomware that targets your backup client.

Rotation: daily incremental local, daily offsite, weekly to immutable tier, quarterly cold/offline. The cold/offline copy is what saves you when everything else is compromised.

What is the 3-2-1 rule?

• 3 copies:
  • Your primary data plus two backups. If you only have one backup and it is corrupt, you have nothing.
• 2 media types:
  • Your primary on one type of storage, backup on another. If both are hard drives in the same machine, a firmware bug or power surge can take both out.
• 1 offsite copy:
  • Physically separate from your primary location. This is the copy that survives fire, flooding, theft, and ransomware that spreads through the local network.

Tarsnap is the original "backups for the truly paranoid" - written by a cryptographer, billed in picodollars, encrypted to a fault. Restic is what most people use in 2026 for one reason: cost. Below is the honest comparison, including where Tarsnap still wins.

Most backups fail silently. You find out the night your drive dies. We test that your data actually restores, every single day, and show you the proof. Encrypted on your machine in a vault we can't read. US West Coast, flat pricing, no egress fees, real humans on tickets.

1. Restic encrypts on your machine -- AES-256 encryption with your key. We never see, store, or transmit your encryption key. Period.
2. Encrypted blobs travel over HTTPS -- Standard TLS transport over Restic's REST protocol. Even in transit, all data is already encrypted ciphertext.
3. Stored in your private ZFS vault -- Per-customer dataset with ZFS checksums. Hardware-isolated from other customers' data.
4. Only you can decrypt -- Lose the key, lose the data - including from us. That's the tradeoff of real privacy.

The Trilogy Nobody Wanted¶

Let me be real about what this three-part series documents:

Part 1: A cloud provider deletes a decade of work because of a broken verification process and a Java parameter parsing quirk. Support gaslights the customer for 20 days.

Part 2: One human inside the machine fights the bureaucracy, escalates to the CEO, and restores the account. Hope restored. Faith in humanity renewed.

Part 3: That human gets fired. The systemic issues remain unfixed. The machine continues.

This is the arc of modern tech. The system breaks. A human fixes it despite the system. The system removes the human. Repeat.
The Real Lesson¶

In Part 2, I wrote: “My trust isn’t fully restored. What is restored is my faith that even in massive corporations, one person can make a difference.”

I still believe that. But I’ll add a corollary: the difference that person makes is often inversely proportional to how long the corporation keeps them around.

The people who challenge broken systems, who go off-script, who escalate when the template says “close the ticket”. Those people are threats to institutional inertia. They’re expensive. They’re inconvenient. They make leadership answer uncomfortable questions.

And eventually, they get optimized away. Just like a “low-activity” AWS account.
A Note to AWS¶

You don’t need me to tell you this, but I will anyway: Tarus Balog was worth more to your reputation than any GenAI keynote. Every developer who read my story and thought “maybe AWS isn’t so bad after all”? That was because of him. Not your PR team. Not your marketing budget. One human being who decided to do the right thing.

You’ll replace him with someone who hits KPIs and doesn’t ask uncomfortable questions. And you’ll wonder why developers keep building exit strategies from your platform. //

To AWS: You had a human circuit breaker. You removed it. Good luck with the next cascade failure.

To everyone else: Keep your backups distributed. Keep your exit strategies current. And if you find a Tarus inside your cloud provider, thank them before the system optimizes them away.

Remember my article about AWS deleting my 10-year account? The one where support gaslit me for 20 days while claiming my data was “terminated”?

Here’s the plot twist: My data is back. Not because of viral pressure. Not because of bad PR. But because one human being inside AWS decided to give a damn.

This is that story.

Our History

rsync.net began providing cloud storage for offsite backups in the fall of 2001, for our original corporate parent, JohnCompanies.

In 2005, we became a stand-alone firm dedicated only to offsite backup. We provide this simple product and nothing else.

Our Team

Discounted "borg accounts" are available for technically proficient users:

$0.008 per GB, per month - 200 GB Minimum

  Free ZFS filesystem snapshots are not included since you'll be doing versioning and retention with borg.
 We will not configure subaccounts, or additional logins, for these borg accounts.
  There is NO borg specific technical support or integration engineering. You're here because you're an expert.
 You must pay annually.

No other costs. No contracts. Unlimited borg repositories. All transfer/bandwidth/usage is free.

Experts Only No Support
Single Region - 99.9999% resilient
$0.008 per GB per Month

Experts Only No Support
Single Region - 99.9999% resilient
$0.008 per GB per Month

Append-Only backups with rclone serve restic --stdio ... ZFS vdev rebalancing ... borg mount example

📂🛡️Suite of tools for file fixity (data protection for long term storage⌛) using redundant error correcting codes, hash auditing and duplications with majority vote, all in pure Python🐍

Here are some tools with a similar philosophy to pyFileFixity, which you can use if they better fit your needs, either as a replacement of pyFileFixity or as a complement (pyFileFixity can always be used to generate an ecc file):

With the above strategy, you should be able to preserve your data for as long as you can actively curate it. In case you want more robustness against accidents or the risk that 2 copies get corrupted under 5 years, then you can make more copies, preferably as LTO cartridges, but it can be other hard drives.

For more information on how to cold store LTO drives, read pp32-33 "Caring for Cartridges" instruction of this user manual. For HP LTO6 drives, Matthew Millman made an open-source commandline tool to do advanced LTO manipulations on Windows: ltfscmd.

In case you cannot afford a LTO drive, you can replace these by external hard drives, as they are less expensive to start with, but then your curation strategy should be done more frequently (ie, every 2-3 years a small checkup, and every 5 years, a big checkup).

Why are data corrupted with time? One sole reason: entropy. Entropy refers to the universal tendency for systems to become less ordered over time. Data corruption is exactly that: a disorder in bits order. In other words: the Universe hates your data.

Long term storage is thus a very difficult topic: it's like fighting with death (in this case, the death of data). Indeed, because of entropy, data will eventually fade away because of various silent errors such as bit rot or cosmic rays. pyFileFixity aims to provide tools to detect any data corruption, but also fight data corruption by providing repairing tools.

The only solution is to use a principle of engineering that is long known and which makes bridges and planes safe: add some redundancy.

There are only 2 ways to add redundancy:

the simple way is to duplicate the object (also called replication), but for data storage, this eats up a lot of storage and is not optimal. However, if storage is cheap, then this is a good solution, as it is much faster than encoding with error correction codes. For replication to work, at least 3 duplicates are necessary at all times, so that if one fails, it must replaced asap. As sailors say: "Either bring 1 compass or 3 compasses, but never two, because then you won't know which one is correct if one fails." Indeed, with 3 duplicates, if you frequently monitor their integrity (eg, with hashes), then if one fails, simply do a majority vote: the bit value given by 2 of the duplicates is probably correct.
the second way, the optimal tools ever invented to recover from data corruption, are the error correction codes (forward error correction), which are a way to smartly produce redundant codes from your data so that you can later repair your data using these additional pieces of information (ie, an ECC generates n blocks for a file cut in k blocks (with k < n), and then the ecc code can rebuild the whole file with (at least) any k blocks among the total n blocks available). In other words, you can correct up to (n-k) erasures. But error correcting codes can also detect and repair automatically where the errors are (fully automatic data repair for you !), but at the cost that you can then only correct (n-k)/2 errors.
Error correction can seem a bit magical, but for a reasonable intuition, it can be seen as a way to average the corruption error rate: on average, a bit will still have the same chance to be corrupted, but since you have more bits to represent the same data, you lower the overall chance to lose this bit.

pyFileFixity provides a suite of open source, cross-platform, easy to use and easy to maintain (readable code) to protect and manage data for long term storage/archival, and also test the performance of any data protection algorithm.

The project is done in pure-Python to meet those criteria, although cythonized extensions are available for core routines to speed up encoding/decoding, but always with a pure python specification available so as to allow long term replication.

Here is an example of what pyFileFixity can do: