After the GCP ban: a data rescue log

2 a.m. My phone buzzed. An email from Google Cloud Platform with the subject line "Your account has been suspended".

I stared at the screen for about ten seconds. Not out of panic — I knew this day would come eventually. For two years I had been running too much on that GCP free instance: the blog, several Telegram bots, an experimental API gateway, and piles of notes that were never backed up.

First reaction: assess the damage

The reason given was vague: "violation of the Terms of Service." No specifics, no appeal channel, no recovery timeline. When I tried to log into the console: "This account has been suspended. You cannot access any resources."

Which meant:

• The blog database (MySQL) → inaccessible
• Static file storage (GCS bucket) → inaccessible
• Session logs of three Telegram bots → inaccessible
• DNS records (Cloud DNS) → inaccessible

The good news: the domain wasn't bought through Google, so DNS could be moved. The bad news: apart from DNS, I didn't have a single complete offline backup.

The rescue plan: pulling data out of caches

Once I calmed down, I started mapping out where data could still be recovered from. The key insight: before you lose access, Google has already distributed your content across countless edge nodes. Find the right doors and you can salvage it.

Step one: hijack the DNS

I moved the domain's DNS from Cloud DNS to Cloudflare (free plan). Took less than 20 minutes. Once the domain resolved again, at least the website could point at a new server.

Step two: pull posts from Google Cache

Searching site:scolv.com on Google and clicking "Cached" next to each result — an old-school trick, but it still works. Google had cached roughly 80% of the pages. I used a simple script to open every result and copy it into local Markdown files.

# Pseudocode: scraping posts from Google Cache
for url in cached_urls:
    text = fetch(f"webcache.googleusercontent.com/search?q=cache:{url}")
    clean = strip_html(text)
    save_to_markdown(clean)

This trick recovered about 40 long-form posts. The images, sadly, were all gone.

Step three: the Wayback Machine

The Internet Archive's Wayback Machine was the other lifeline. web.archive.org/web/*/scolv.com had snapshots from 2019 to 2024, covering about 60% of the content. Combined with Google Cache, I recovered everything that could be recovered.

Step four: bot logs

The Telegram bot conversation logs were gone completely. The bots ran in pure in-memory mode with no external persistence. That part I had to accept.

Lessons and actions

After this incident, I set a few rules for myself:

• Never depend on a single cloud provider's free tier — free things vanish without notice, and there is no support desk.
• Static first — the new blog is all static HTML. No database, no backend. One rsync and it's backed up.
• Export regularly — every new post automatically generates a Markdown backup pushed to a private GitHub repo.
• DNS independence — registrar and DNS hosting kept separate, ready to switch at any time.
• Don't trust "automatic backups" — a cloud provider's automatic backups disappear the moment your account does. Only copies you hold yourself count.

The cost of rebuilding

What was lost: roughly 20 old posts that can't be recovered, all images, bot logs, and the source code of a few experimental projects.

Honestly though, the outcome was better than I expected. The things that really mattered — the long-form posts — mostly came back through caches and archives. And the things I "thought mattered" turned out not to matter much once they were gone.

This site is the product of that rebuild. No database, no backend, purely static. Every post is a manual backup. If you're running on a cloud provider's free tier, go make an offline backup right now.

---

If you've been through something similar, or want to talk backup strategy, write to ryu@scolv.com.