One of my help desk techs called me about a full disk. Ordinary call, ordinary fix. A user at a major national retailer had run out of space on her Mac and could not save anything, so he did what any competent technician does in that situation. He emptied her trash and gave her back the room she needed.
She had been storing her legal documents in the trash bin.
Not by accident. She had worked out that she could right-click a file, send it to the trash, and it would sit there indefinitely without her having to open a folder, navigate to another folder, and drag anything anywhere. Fewer clicks. Same result, as far as she could tell. She had been doing it for a long time and it had worked every single time.
We are talking about tens of thousands of documents. Legal files and accounting records. Nothing recoverable, because the trash is the one location on a Mac that backup software is specifically told to leave alone. Why would you back up the place where deleted things go?
Nobody in that story did anything wrong in the moment. The tech applied the correct fix. She had found a workaround that saved her time and never failed. The machine did precisely what it was designed to do. And a decade of records stopped existing on a Tuesday afternoon.
The same mistake with a different container
I saw a screenshot recently that made me think about her for the first time in years. A Google account, disabled. No warning, no specific accusation, no human being to talk to. The notice said the account looked like it was being used in a way that violated policy, which is a classifier speaking, not an investigator. There is a link to appeal, and the appeal goes to another automated system.
The person on the other end of that notice had been using Gmail as a document archive.
Different container, identical error. Both of them put material they could not replace into a place that was never built to hold it, and both of them had years of successful use telling them it was fine. Neither had any reason to think otherwise until the day the container behaved the way it was designed to behave.
Why does storing documents in email fail?
An inbox is a delivery mechanism. People started treating it as storage because it never asked them to stop, and because search made retrieval good enough that filing seemed unnecessary. Twenty years of that habit builds an archive nobody ever decided to create.
Nothing about a mail service is built for retention. There is no integrity check. There is no version history for an attachment. There is no export you would want to bet on. Attachments get stripped, links to cloud files rot, and the whole structure hangs off one credential controlled by a company that has no contractual obligation to keep you.
The storage keeps getting bigger and it stays free, which teaches exactly the wrong lesson. Every signal the product sends says permanent. None of the terms say permanent.
What happens when a Google account is disabled?
Three things at once, and only the first one is obvious.
The mail becomes unreachable. That is the loss people picture, and it is the smallest of the three.
Then everything authenticated against that account dies with it. Cloud storage, photos, contacts, calendar. A person who kept a second copy of their documents in Drive discovers that the second copy was never a second copy, because it lived behind the same login.
Then the slow part. Every other service in their life has that address as the recovery contact. Password resets go to a mailbox that no longer accepts mail. Verification codes go nowhere. Banking, hosting, domain registration and social accounts start failing one at a time over the following weeks, and most people never connect those failures back to the original event.
A deletion clock is running through all of it. Disabled accounts are eventually purged along with everything in them, and nobody tells you how long you have.
The tools only work in advance
I keep a local copy of my email in Thunderbird, and it is worth being precise about what that does and does not protect against, because it is easy to set up in a way that fails silently.
An IMAP connection is a mirror and not a backup. It syncs state. Delete something on the server and Thunderbird removes the local copy on the next pass. More to the point, IMAP authenticates against the same account, so the moment the account is disabled the protocol dies with it. There is no separate credential and no separate door.
Which means the sync is a window that is open while the account is alive. What survives is whatever happened to be on your disk when it closed.
Getting a real local copy takes two steps. Turn on message synchronization for every folder instead of accepting the default, which leaves plenty of folders as headers only. On a Gmail account the All Mail folder is the one that matters, because that is where the archive lives. Then let it finish. Mine took two days, and most people who start that download close the laptop halfway through and never realise they have a partial archive.
The same constraint applies to Google Takeout. You cannot request an export from an account you can no longer sign into. Every mechanism that would save you requires an account that still works, which is why none of them are available at the moment you would think to use them.
The backup that was not running
This next part caught me, and it is why I am writing this instead of nodding along at somebody else’s misfortune.
My mail store sits inside my Documents folder, which is covered by an offsite backup. That should be the end of the problem. It was not. Backblaze does not support Volume Shadow Copy, so when a file is locked by another application it cannot read it. It skips the file and tries again about an hour later. Their own documentation names mail clients specifically and says to close the application at least daily if you leave it running.
I leave Thunderbird running permanently. So the single most important folder on my machine had been in a skip loop, and the backup client kept reporting success the entire time, because from its point of view nothing had failed.
That is what a silent failure looks like. Not an error, not an alert, just a thing quietly not happening while every indicator stays green. The fix is either closing the client daily, which depends on remembering, or a scheduled task that copies the profile folder somewhere the backup can read it. I prefer not to depend on my own habits.
The recovery address problem nobody thinks about
The archive question is about losing data. This one is about losing the ability to recover anything else, and it is both worse and cheaper to fix.
If your password reset emails arrive in the account you are trying to recover, that is not a recovery address. It is a loop, and it only reveals itself on the day the loop breaks.
I am guilty of this and I am correcting it. The move is a separate mailbox at a different provider, used for nothing except account recovery. Different company, different jurisdiction, different enforcement regime. A Google policy decision has no reach into it.
Keeping it empty is not tidiness. It is risk reduction. A mailbox with no attachments, no bulk sending, no forwarding rules and no storage pressure gives an automated system almost nothing to flag. You have removed the surface for the exact thing that happened in that screenshot.
The same reasoning applies to your second factor. If verification codes land in the dead account, or the authenticator backup lives in the same cloud storage, you have built the loop twice. Recovery codes printed and filed somewhere physical is the version that survives.
How long does a security audit like this take?
Longer than an afternoon. If you have eighty accounts, which is common, moving all of them to a separate recovery address will take weeks. Each one is a login, a settings page buried in a different place, a verification step, and occasionally a support ticket because the provider will not let you change it cleanly.
The saving grace is that you are doing it before anything is wrong. Nothing forces you to finish. Nothing breaks while it is half done. You can stop for a fortnight and pick it up again.
What makes eighty accounts tractable is not doing them in whatever order your password manager lists them. Work in three tiers. First the accounts that own everything else: domain registrar, hosting, the mail providers themselves, anything holding business payment details. That is maybe eight accounts and it carries most of the risk. Then the accounts with money or identity attached, meaning banking, brokerage, tax and insurance. Then everything else, which is the bulk of the eighty and matters least. A forum login with a dead recovery address is an inconvenience.
An evening on the first tier gets you most of the protection available. The remaining seventy can take a year.
What should you do about your email archive this week?
Not a backup regime. Regimes are things people intend to do.
Name the three things in your email you could not reconstruct from anywhere else. Everybody has an answer within about a minute, and it is usually a tax document, a signed contract, or photographs somebody sent years ago that exist nowhere else. Those three things are the entire problem, and downloading them takes five minutes instead of becoming a project.
Then check your recovery address on the four or five accounts that would hurt most to lose. If any of them point at the mailbox you are worried about, that is the loop, and moving one of them takes about two minutes.
Everything after that is optional and can wait for the audit.
The system worked as designed
What stays with me about the woman with the trash bin is that she was not careless. She was efficient. She found a shortcut, tested it against reality every day for years, and reality agreed with her every time. The failure was not in her judgment. It was a gap between what the container was built for and what she was using it for, and nothing in the design of the machine ever surfaced that gap.
The person whose Google account was disabled is in the same position. They almost certainly never considered that this could happen, and not because they were naive. It is because the category did not exist for them. We all plan for the failures we can picture. A dead drive, a stolen laptop, a fire. Those have been in the culture for fifty years. Nobody has a story about the account still existing and simply refusing to know them.
In both cases the machinery worked perfectly. The trash emptied. The policy enforced. Nothing malfunctioned, and that is precisely the problem. A system that fails loudly gets fixed. A system that works exactly as designed does not look like a risk until it takes something from you.
If you want the longer version of this thinking applied to a whole household, I wrote Family Cybersecurity about exactly this, and the same reasoning shows up in my work on twenty years of disaster recovery and on the years when ransomware turned laptops into bricks. The rest of the material sits in the Cybersecurity Hub. And if you have a body of hard-won operational knowledge like this and no book to put it in, that is what my ghostwriting service is for.
Go and look at your trash bin. Then look at what you would lose if your inbox stopped answering tomorrow.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.
