Daniel sent us this one — and it's basically a real-world case study in backup paranoia versus backup prudence. Three thousand episodes of this show, all going into a Cloudflare R2 bucket as primary storage, then simultaneously replicated to Wasabi as a second cloud copy, and finally cloned down to a local NAS. That's three copies, two clouds, one local. The question is whether this is the gold standard or just gold-plating, and more importantly, what should actually be tested to make sure any of it works when it matters.
The thing that jumps out immediately is that this setup has all the right instincts. Three copies, two different providers, one local. That's textbook three-two-one. But the textbook was written in two thousand nine by a photographer named Peter Krogh for digital asset management — it predates the modern reality where your production pipeline itself can be the single point of failure that makes all three copies vanish simultaneously.
Three copies of nothing is still nothing.
And that's where the three-two-one-zero evolution comes in. The zero is zero errors — automated integrity verification. Without that, you're just moving bits around and hoping. Think of it like a spellchecker that never actually underlines the misspelled words. You've got the document saved in three places, but every copy has the same typos, and you won't know until someone reads it aloud.
Let's map out exactly what this pipeline looks like, and where the gaps might be hiding.
The core architecture is Cloudflare R2 as the production bucket, Wasabi as the secondary cloud, and a local NAS as the tertiary copy. R2 and Wasabi are both S3-compatible object storage, which means they speak the same API. That's convenient but it's also a double-edged sword — anything that can talk to one can probably talk to the other if it has the credentials. It's like having two different bank vaults that both open with the same key. Great for convenience, terrifying if that key ever gets copied.
The automation is uploading to both simultaneously?
That's what the prompt describes. Every new episode gets pushed to R2 and Wasabi at the same time, then Wasabi gets cloned down to the NAS. The rationale for the second cloud is smart — if Cloudflare locks the account, Wasabi still has everything. And the NAS is the air-gapped hedge against any commercial cloud dependency.
On paper this sounds solid. Three copies, two clouds, one local. But the devil is in the replication details. How does that simultaneous upload actually work in practice? Is it two separate API calls, or one call that somehow fans out?
That's exactly the right question, and the answer changes everything. If it's two independent upload operations in the script — push to R2, then push to Wasabi — you've got a sequential dependency. If the Wasabi upload fails silently, you're running with one cloud copy and don't know it. If it's a single operation that writes to both, you've got a single point of failure in the upload logic itself. The ideal is parallel independent uploads with separate error handling and separate logging. Most people don't do that on their first pass. They write a script that works when everything goes right, and that's not the same as a script that fails safely.
Let's start with the R2 to Wasabi replication. Both claim eleven nines of durability — ninety-nine point nine nine nine nine nine nine nine nine nine percent. Cloudflare advertises this for R2, Wasabi advertises the same. Those numbers are essentially identical, and they're about hardware failure. Bit rot on disk. Drive failures in the data center. They're not about what happens when someone deletes the bucket by accident or an API key gets leaked.
Eleven nines means if you store ten million objects, you might lose one object every ten million years. That's the theoretical math. But those numbers assume the data center is operating normally, the software is bug-free, and no human being ever touches a configuration file. None of those assumptions hold in the real world.
The durability numbers are a distraction.
They're not meaningless, but they answer a question nobody should be asking. The real question is not will my bits survive on disk, it's will my data survive my own operational mistakes. Backblaze did a survey in twenty twenty-four and found that sixty-eight percent of businesses that experienced data loss had a backup strategy in place. They just hadn't tested it. That number should haunt you. More than two-thirds of people who thought they were protected weren't.
That's the equivalent of having a smoke detector with no batteries.
The batteries in this setup are the replication mechanisms. What's actually doing the upload to Wasabi? Is it rclone sync? Is it an S3 SDK call in a script? Is it something like restic or borg? The tool determines whether you're getting a true copy or just a metadata mirror. And the difference between those two things is the difference between a backup and a wish.
Break that down — metadata mirror versus true copy. I want to make sure we're clear on why this distinction matters so much.
Okay, imagine you've got a directory with three thousand audio files. A metadata mirror says "the destination should look exactly like the source right now." So if the source has files A, B, and C, the destination gets A, B, and C. If you delete file B from the source, the mirror says "the destination should match the source," so it deletes file B from the destination too. You haven't backed up file B. You've just delayed its deletion by however long the sync interval is.
It's not a backup at all. It's a reflection.
It's a reflection with a time lag. A true backup, by contrast, says "I'm going to keep a history of what the source looked like at different points in time." So you've got Monday's version with A, B, and C, and Tuesday's version with just A and C. If you realize on Wednesday that deleting B was a mistake, you go back to Monday's snapshot and there it is. That's the difference between a mirror and a backup. The mirror shows you what you have now. The backup remembers what you had then.
If the pipeline uses something like S3 sync with the delete flag, it's making the destination look exactly like the source — including deletions. So if an episode gets accidentally removed from R2, the next sync might remove it from Wasabi too. That's not a backup, that's a delayed delete.
This is where the tool choice becomes existential. A proper backup tool like restic or borg creates snapshots with history. You can go back to any point in time. Wasabi also supports object locking and versioning — if those aren't enabled, you're one misplaced delete flag away from losing the backup. The delete flag is a single character in a command. One typo, one misplaced hyphen, and three thousand episodes become zero.
The first question to ask is whether Wasabi has versioning turned on.
Whether object lock is configured. Object lock prevents anyone from deleting or overwriting an object for a specified period, even the root account. It's Wasabi's compliance mode. If that's not on, a compromised credential can wipe everything. And here's the thing about object lock — you have to enable it when you create the bucket. You can't add it later. So if Daniel set up the Wasabi bucket six months ago without object lock, the only fix is to create a new bucket with it enabled and migrate everything over.
Which nobody wants to do after the fact.
Which is why you think about it before you need it. Object lock is the seatbelt you install in the factory, not the one you try to bolt on while the car is moving.
Which brings us to the single points of failure. And the biggest one isn't the storage — it's the pipeline itself.
This is the part that keeps me up at night. The production pipeline that triggers these uploads — if it fails silently, you have a gap. If it gets compromised, you have a disaster. Think about it. The pipeline has credentials for R2, Wasabi, and probably the NAS. If someone gets access to those, they can delete from all three destinations. Or worse, they can corrupt the files and let the sync propagate the corruption everywhere. It's the digital equivalent of having three separate houses but keeping all the keys on the same keyring in the same pocket.
The three copies share a single authentication surface.
That's the term. And it's the misconception that multiple cloud copies means you're protected from everything. If all copies are accessible from the same network or share the same authentication pipeline, a single compromise can hit all of them. LastPass in twenty twenty-three demonstrated this painfully — cloud-to-cloud backups got compromised because the backup provider shared authentication infrastructure. The attacker didn't need to breach three separate systems. They breached one system that had the keys to all three.
R2 and Wasabi use separate accounts, separate credentials. That's good. But the pipeline that holds both sets of keys is the bottleneck. It's like having two different safety deposit boxes at two different banks, but keeping both keys in the same jacket.
The NAS is likely on the same local network as the production machine. So a ransomware attack that encrypts the production machine can walk right over to the NAS and encrypt that too, unless the NAS has immutable snapshots enabled. Ransomware is surprisingly good at lateral movement. It checks for mounted network shares, it looks for connected drives, it tries common NAS protocols like SMB and NFS. If the NAS shows up as a drive letter on the production machine, ransomware treats it exactly the same as the local C drive.
Which most people don't set up — the snapshot protection, I mean.
Most people plug in the NAS, create a share, and call it a day. Synology and QNAP both support immutable snapshots — Synology calls it Snapshot Replication with immutable snapshots, QNAP has a similar feature. But they're not on by default. You have to configure them, set a retention policy, and then test that you can actually restore from them. The default configuration on most consumer NAS devices is wide open. Convenience wins over security in the out-of-box experience every time.
Because the manufacturer wants you to feel successful in the first five minutes.
"Look, I can see my files from anywhere!" is a great unboxing experience. It's also a great unboxing experience for anyone who compromises your network.
Let's go through the failure scenarios this setup actually protects against, and the ones that slip through. I want to do this systematically.
Scenario one — Cloudflare account compromise. Someone gets the R2 API key and deletes the bucket. The Wasabi backup survives because it's a separate account with separate credentials. The NAS survives because it's local. This setup handles that scenario beautifully. You'd have to reconfigure your pipeline to point to Wasabi as the new primary, but the data is safe.
Scenario two — Wasabi has a data center fire or goes out of business.
R2 still has the primary copy, the NAS still has the tertiary. You're down one copy, but you've got two left, which is exactly why we have multiple copies.
Scenario three — the production machine dies. Hard drive failure, spilled coffee, whatever.
Everything's in the cloud. Redeploy the pipeline, you're back. This is the cloud working exactly as advertised. Your local machine is essentially a thin client that orchestrates uploads.
Scenario four — the pipeline itself is compromised.
This is where it gets ugly. If an attacker gets into the CI/CD system — whether that's GitHub Actions, a custom server, whatever — they can modify the upload script to silently skip episodes, or upload corrupted versions, or delete everything. And because the pipeline has credentials for all three destinations, the damage propagates everywhere. The NAS clone runs after the Wasabi upload, so it clones the corrupted or empty state. You've got three destinations all faithfully replicating the attacker's intent.
This is the scenario that turns three copies into three copies of garbage.
Or three copies of nothing. And the worst part is you might not notice for months. How often does anyone actually go back and spot-check old episodes? If episode two thousand four hundred and seven got corrupted six months ago, would you know?
Probably not until a listener complained. "Hey, at minute fourteen there's just static for thirty seconds.
By then, the good copies might have been overwritten by sync operations. If you're running a mirror-style sync with no versioning, that corruption has propagated to Wasabi and the NAS. The original clean file is gone. You're now in the uncomfortable position of explaining to a listener that a piece of podcast history is permanently damaged.
Which is a different kind of pain. It's not just data loss, it's cultural loss. Three thousand episodes is a time capsule.
That's what makes this particular case study so compelling. We're not talking about backing up tax documents where the emotional stakes are "I don't want to get audited." We're talking about a creative body of work that represents years of someone's life. The backup strategy isn't just about bit preservation. It's about legacy preservation.
We've identified the theoretical gaps. Now let's talk about how to actually test them — because a backup you've never restored is just a prayer.
This is my hill and I will die on it. If you haven't tested recovery, you don't have a backup. You have a hope. And hope is not a data protection strategy.
That should be on a poster.
I want it on a mug. So let's walk through four testing protocols that would validate every component of this setup. First, the Delete and Restore drill. This is the simplest and most important test you can run. Once a quarter, pick a random episode — actually random, use a random number generator — and delete it from the R2 bucket. Then restore it from Wasabi. Document every step. Note any permission issues, any configuration that tripped you up.
Do this during normal business hours, not at three in the morning when nobody's watching.
You want to simulate a real incident. If it takes four hours to restore a single episode because you can't find the right credentials or the IAM policy is wrong, you've just learned something extremely valuable. Multiply that by three thousand episodes and you know whether a full restore is a weekend project or a career change. And here's the thing — most people discover during their first drill that they can't actually restore anything. They've got the IAM role wrong, or the bucket policy is too restrictive, or they don't remember which command to run. The drill isn't a pass-fail test. It's a diagnostic. If you fail, congratulations, you just prevented a real disaster.
The second test?
Pipeline failure simulation. Intentionally break the Wasabi upload step. Invalidate the API key, or change the endpoint URL to something invalid. Then run the pipeline and see what happens. Does anything alert you? Does the NAS sync still run? How long does it take before you notice the gap?
Most people would discover this when they go to do the next episode and notice the count is off.
By then you've lost the window where the original file still exists on the production machine. If the pipeline doesn't have alerting — and most don't — you're flying blind. A simple health check that verifies episode counts match across R2 and Wasabi after every upload would catch this in minutes instead of weeks. Even a basic script that says "count objects in R2 bucket, count objects in Wasabi bucket, if they don't match, send an email" — that's maybe fifteen lines of Python. Fifteen lines could save you from discovering a six-month gap.
Third test — the ransomware scenario.
This one's uncomfortable but necessary. Simulate a local network compromise. Take a test file on the NAS, encrypt it manually — just use openssl to scramble it — and then try to recover the original using the NAS's snapshot or versioning features. If you have immutable snapshots enabled, this should be trivial. You roll back to the snapshot before the encryption. If you don't have snapshots enabled, you've just learned that your local backup is not ransomware-resistant.
A lot of people assume the NAS is safe because it's not the cloud. "It's in my house, it's physically here, nobody can touch it." But ransomware doesn't care where the bits live.
Ransomware is egalitarian. It encrypts everything it can reach. If the NAS is mounted as a network drive on the production machine, it's reachable. The only defense is snapshots or a truly offline copy. And snapshots only work if they're immutable — if the ransomware can delete the snapshots too, you're back to square one. Some ransomware strains specifically target NAS snapshot directories now. They know what a Synology snapshot looks like and they go after it.
Fourth test — the cloud provider lockout.
This is the nightmare scenario that motivated the second cloud in the first place. What happens if Cloudflare terminates your account? Terms of service violation, billing failure, whatever. Can you restore the entire three thousand episode catalog from Wasabi alone? And I don't mean theoretically — I mean actually do it. Spin up a new R2 bucket, or better yet a completely different provider, and run the full restore. Calculate the egress costs.
Wasabi charges egress fees after the first one times data stored per month.
Wasabi's pricing is six tenths of a cent per gigabyte per month — that's zero point zero zero five nine dollars — and they allow egress up to the amount of data you have stored each month without additional charges. After that, it's one cent per gigabyte. For three thousand podcast episodes, depending on the audio quality, you're probably looking at somewhere between fifty and two hundred gigabytes total. That's not going to break the bank. But you should still know the number before you need it. Nothing worse than discovering during an emergency that your restore is going to cost three hundred dollars you didn't budget for.
Cloudflare R2 charges zero egress. That was their big differentiator when they launched in general availability back in September twenty twenty-two.
Which is genuinely disruptive. Most cloud providers make their margin on egress. R2 flipped that model. Zero egress fees means you can download your data as often as you want without surprise bills. That's a real advantage for a restore scenario where you might be pulling down the entire catalog. It also means you can verify your backups more aggressively — download random files and check them without worrying about the meter running.
If you're locked out of Cloudflare, zero egress doesn't help you.
Which is exactly why the Wasabi copy exists. But here's another wrinkle — both R2 and Wasabi are likely in the same geographic region. If they're both US East, a regional outage could hit both simultaneously. True geographic diversity means different regions or different continents. For a podcast backup, that might be overkill. But it's worth knowing what region each bucket is in. You might discover that your "two different clouds" are actually in the same physical data center building.
That's happened. Different providers colocating in the same facility.
More often than people realize. The cloud is someone else's computer, and sometimes it's the same someone else's building with a different brand on the door.
Let's talk about the zero in three-two-one-zero. Automated integrity checking. What does that actually look like in practice?
At minimum, you store a SHA-two-fifty-six hash alongside every episode file. After every upload, you compute the hash of what's in the destination and compare it to the hash of what you sent. If they don't match, something went wrong in transit. Rclone can do this with rclone check. It compares source and destination without downloading full files, using server-side hashing where the provider supports it.
Both R2 and Wasabi support server-side hashing?
S3-compatible storage supports ETags, which are MD5 hashes of the object. It's not SHA-two-fifty-six, but it's sufficient for detecting transmission errors. For stronger integrity guarantees, you'd want to store a separate checksum file alongside each episode and verify it independently. Tools like rclone support the hashsum command to generate and verify checksums across remotes. The nice thing about storing your own SHA-two-fifty-six is that you're not relying on the cloud provider's hashing. If their ETag calculation has a bug, your independent checksum catches it.
The pipeline would look something like upload the episode, generate the checksum, store it as a separate object, then verify it post-upload.
Do this for every destination independently. Don't assume that if the upload to R2 was clean, the upload to Wasabi was also clean. Verify each one. I've seen cases where an upload to one S3-compatible endpoint succeeds perfectly and the same file uploaded to a different provider has a single-bit error. It's rare, but with three thousand episodes, rare events happen.
How much does this slow down the pipeline?
Computing a SHA-two-fifty-six hash of a fifty-megabyte audio file takes milliseconds on modern hardware. The verification step adds a few seconds of API calls. For a podcast that publishes episodically, not continuously, this is background noise. The bottleneck in any podcast pipeline is almost always the human — the editing, the mixing, the show notes. A few extra seconds of automated verification is invisible.
Now we've got testing protocols and integrity verification. Let's talk about the cold storage gap.
This is the recommendation I'd add to the setup. A fourth copy on a truly offline medium. A USB hard drive or an LTO tape that sits in a drawer, physically disconnected, updated once a month. This protects against ransomware that has network access to both clouds and the NAS. If the drive isn't plugged in, ransomware can't touch it. It's not on the network, it's not addressable, it's a lump of metal and plastic in a drawer.
The digital equivalent of keeping cash under the mattress.
For the same reason. It's not your primary store of value, but it's there when the systems fail. Backblaze B2 offers cold storage at half a cent per gigabyte per month with no egress fees if you're downloading through one of their bandwidth alliance partners. AWS Glacier Deep Archive is even cheaper — point zero zero zero nine nine cents per gig per month, but retrieval takes twelve hours. For a podcast archive, that retrieval time is perfectly acceptable. You're not restoring episodes in a crisis where every second counts. You're rebuilding a catalog over a weekend.
The cost of a fourth copy is essentially the cost of the drive plus the electricity to update it once a month.
A four-terabyte USB drive costs about a hundred dollars. That's cheap insurance against a scenario that could wipe three thousand episodes of work. And here's a fun fact — the drive doesn't even need to be fast. A five-thousand-four-hundred-RPM portable drive is fine. You're writing to it once a month and reading from it hopefully never. Speed is irrelevant. Reliability and offline-ness are the only things that matter.
Which brings us to the uncomfortable question — at what point does backup resilience become a distraction from content creation?
I knew you were going to go there.
Three thousand episodes is an enormous body of work. The pride in protecting it is understandable. But the effort spent designing, implementing, and testing this pipeline — is that effort better spent on making episode three thousand and one?
It's a fair question, and I think the answer depends on whether the backup strategy is a one-time investment or an ongoing maintenance burden. If the pipeline is automated, the checksums are verified automatically, the quarterly fire drills take an hour each, and the cold storage sync is a monthly five-minute task — that's maybe twenty hours a year. Twenty hours to protect three thousand episodes of work. That strikes me as a good trade. Twenty hours out of eight thousand seven hundred and sixty is a rounding error.
If it's twenty hours of tinkering every month because something keeps breaking, that's a different equation.
That's the complexity trap. Each additional copy adds operational overhead. Cloud credentials need rotation. API endpoints change. Storage formats evolve. The question is no longer can I afford another copy, it's can I afford the complexity of managing another copy. I've seen people build backup systems so elaborate that the backup system itself becomes a part-time job. At that point, you've lost the plot. The backup exists to serve the creative work, not the other way around.
Which ties back to testing. A perfect three-two-one-zero setup with no testing is worse than a simple two-one-zero setup that you verify monthly.
Because the untested setup gives you false confidence. You think you're protected, so you don't think about it. The person with the simpler setup who tests it regularly knows exactly what they have and what they don't. Confidence without verification is just arrogance with better branding.
Let's distill this down to four concrete actions someone could take this weekend to validate their backup strategy, whether it's for a podcast or anything else.
Action one — implement automated checksum verification. Add a post-upload step in the pipeline that runs rclone check between R2 and Wasabi, and between Wasabi and the NAS. This turns a three-two-one setup into a true three-two-one-zero. Rclone is free, it supports over forty cloud providers, and the check command can run as a cron job or a CI step. Ten minutes to configure, a lifetime of knowing your copies are bit-identical. That's an incredible return on investment.
Action two — schedule a quarterly fire drill.
Pick a random episode, delete it from R2, restore it from Wasabi. Time the process. Document every credential you needed, every command you ran, every permission that blocked you. Store that document somewhere you can find it at two in the morning during an actual incident. If you do nothing else, do this. One drill per quarter. Four times a year. If that's all you take away from this episode, that alone will put you ahead of the vast majority of people with backup strategies.
Action three — add a cold storage tier.
A USB drive or external hard disk that gets updated monthly and then physically disconnected. Use rclone to sync the Wasabi bucket to it, verify the checksums, unplug it, put it in a drawer. Total cost maybe a hundred dollars and five minutes a month. This is your ransomware insurance. And label the drive. Nothing worse than having a drawer full of identical black rectangles and not knowing which one has your podcast archive.
Action four — review credential management.
Where are the API keys for R2, Wasabi, and the NAS stored? Are they in environment variables on the production machine? In a dot env file committed to a git repo? In a proper secrets manager with rotation policies? A single compromised CI slash CD token can bypass all three copies. If you're using GitHub Actions, use their encrypted secrets. If you're running a custom server, consider HashiCorp Vault or even just a separate machine that holds the keys and exposes a limited API. The principle is least privilege — each component should have access to only what it needs, not everything.
Rotate those keys. Not every week, but at least every quarter.
Key rotation is the dental flossing of infrastructure — everyone agrees it's important, nobody does it.
Speaking from experience?
I plead the fifth. But seriously, most cloud providers make key rotation straightforward now. Generate a new key, update the pipeline, verify it works, revoke the old one. Twenty minutes if you've documented the process, two hours of panic if you haven't. The documentation is the difference between routine maintenance and a crisis.
To wrap this back to the original question — how does this setup fare for a thorough backup approach?
It's a solid B-plus, maybe an A-minus. The architecture is sound. Three copies, two providers, one local. The rationale for each tier makes sense. The gaps are in verification, testing, and the shared authentication surface of the pipeline. Close those gaps and it's an A. And honestly, closing those gaps is not a massive project. It's a weekend of configuration and documentation. The hard part — the multi-cloud architecture — is already done.
The things to test?
Start with the Delete and Restore drill. That one test will tell you more about the health of your backup strategy than any amount of documentation or theoretical analysis. Then the pipeline failure simulation, the ransomware scenario, and the cloud lockout drill. Four tests, maybe two hours each the first time, faster once you've documented them. After the first quarter, you'll have them down to thirty minutes each. That's eight hours a year for complete confidence in your backup strategy.
Before you go buy another hard drive or spin up another cloud bucket, though, let's ask the uncomfortable question — when is enough actually enough?
I think enough is when you can answer yes to three questions. One, have you tested a full restore from every tier in the last six months? Two, would you notice within twenty-four hours if the backup pipeline stopped working? Three, if ransomware hit your production machine right now, would at least one copy survive that has nothing to do with your production network?
If the answer to any of those is no, you've got work to do.
If the answer to all three is yes, stop optimizing and go make something. The best backup strategy in the world doesn't matter if you're not creating anything worth backing up. At some point, you have to trust the system and return your attention to the work that the system exists to protect.
Which is the tension at the heart of all of this. The engineering is fun. The testing is satisfying. But three thousand episodes happened because someone spent time recording, not because someone spent time configuring rclone.
Although I'd argue that knowing the backups are solid makes the recording more enjoyable. You're not carrying that low-grade anxiety about losing everything. There's a freedom in knowing that even if your hard drive catches fire and your cloud account gets locked and your NAS gets hit by lightning all on the same day, your work survives. That peace of mind lets you take creative risks.
That's fair. Peace of mind has real value.
As object storage keeps getting cheaper — Cloudflare's zero-egress model, Wasabi's flat pricing, Backblaze B2's continued price drops — the calculus shifts. The question stops being can I afford another copy and becomes can I afford the complexity of managing another copy. Storage is approaching free. Attention and complexity are the new scarce resources.
The bottleneck is no longer money, it's attention.
Which is the one thing you can't back up to the cloud.
One more thought and then we should wrap. The three-two-one rule came from photography — Peter Krogh's book The DAM Book in two thousand nine. It was designed for a world where storage was expensive and cloud was nascent. The fact that we're still using it as a baseline in twenty twenty-six, with a zero bolted on, tells you it captured something fundamental. But the specifics have evolved. Two different media types used to mean hard drive and optical disc. Now it means two different cloud providers with separate authentication, or one cloud and one local NAS with immutable snapshots.
The principle endures, but the implementation has to keep up. Cloud durability numbers are so high now that hardware failure is almost never the cause of data loss. It's always operational error, account compromise, or ransomware. The zero in three-two-one-zero addresses that shift — it's saying that bit preservation is solved, what matters now is bit integrity and recovery testing. The original rule assumed the hard part was keeping the bits from degrading. Now the hard part is keeping the bits from being deleted or corrupted by the systems meant to protect them.
The best backup strategy is the one you actually test.
I still want that on a mug.
And now: Hilbert's daily fun fact.
Hilbert: In the nineteen seventies, researchers studying permafrost methane in the Azores discovered that certain frozen soil layers emitted gas in rhythmic pulses that matched the lunar cycle, a behavioral anomaly that remains unexplained to this day.
Permafrost in the Azores.
Which are famously not permafrost territory. I have questions. Starting with "how" and ending with "what.
Don't we all.
This has been My Weird Prompts. Our thanks to producer Hilbert Flumingtop for keeping the show running, and to everyone who's stuck with us for three thousand episodes — may your backups be tested and your checksums match.
If you enjoyed this episode, rate us on your podcast app. It helps other backup nerds find us, and it means a lot.
See you next time.
