How a costly export led to data recovery

The Blueprint · shipped 2021–present

Role: Platform Architect / Sole Engineer
Timeframe: Web application from 2021. The export outage and the backend loss were separate events in different seasons. Exact dates unresolved.

After the backend was gone, rebuilt it and reseeded the user base from an old export rather than accepting the loss, on the judgment that the audience was the only part of the system that could not regenerate itself

About the project

The Blueprint is a free SXSW event guide for Austin whose community, editorial voice, and trusted spreadsheet predate the software. I began building the web application in 2021 and have owned its product and technical implementation end to end since.

Organization: When Where What
Timeframe: 2021–present

80,382
Registered users: 4,304
Activations across years: 358
Staff picks

Overview

An export that became the surviving copy

During peak SXSW traffic, I ran an unbounded user export against the production database and took the product down. I needed demographic information for sponsor reporting, but I had not built an operation that could produce it safely while the site was busy.

In a later season, the backend was gone. The export from that earlier incident was the surviving copy I could use to recover the user accounts. I rebuilt the backend and reseeded from it, accepting that accounts created after the export could not be recovered from that file.

Reporting during the busiest week

Sponsors supporting the Bluelist required demographic reporting about its audience. That was a recurring product obligation, and the reporting was needed during the same week the site saw its heaviest use.

I served it with an ad hoc production operation. There was no separate reporting path or read replica: the export used the PostgreSQL instance handling incoming requests. It competed with the work the product needed to stay available.

I remember the export causing the outage. I do not have the incident logs or query plan to identify which resource was exhausted first. The operational mistake was running that unbounded task against the serving database during peak demand.

Finding the backend gone

The loss happened after a long dormant period, separately from the export outage. The Strapi and PostgreSQL backend on Heroku was no longer available when the product needed it again. The exact dates and circumstances of that loss remain unresolved.

Seasonal use made the gap in my attention consequential. A problem could remain unnoticed between festivals because neither readers nor I were regularly exercising the product. By the time I returned, recovering from the provider was no longer an available route.

I had to distinguish the data the team could produce again from the data that represented accumulated use. Editors assembled fresh event listings for each festival. User accounts represented people who had already found the product and registered over several years.

Solution

Recovering from the surviving export

I rebuilt Strapi, revised the parts of the backend that needed it, and used the old export to reseed the user base. Starting the accounts over would have discarded the portion I could still recover.

The export date set the limit. Anyone who registered between that export and the backend loss was outside the recovery set. Once the backend was gone, registration was impossible, so that interval did not continue growing while the system was unavailable. I do not have a count for the missing accounts.

The file had been produced for reporting. I had not scheduled it, tested a restore from it, or maintained it as a backup. Its usefulness during recovery was fortunate; it did not make the operation that created it sound.

Event listings → Next event cycle: New editorial work
Audience accounts → Export retained: Export point

The unbounded export caused an earlier outage. Its surviving file later enabled partial recovery; it was not a planned backup. The interval is schematic, with no invented dates or counts.

Making routine operations explicit

I subsequently moved routine operations into admin tooling with bounded, batched behavior. Sponsor reporting needed to be treated as work the product supported, with a defined way to produce an export, rather than a query I improvised when it was due.

The Export users modal shows optional date inputs, zero matching users, a permission requirement, and server-batch wording. — The export control before use. No user records are present and Export CSV has not been selected. The screen shows the operation's options and stated behavior; it does not prove the historical query bounds or recovery outcome.

A scheduled export kept separately from the backend would also have made recovery less dependent on an old reporting file. That is a requirement I can identify in retrospect, not a backup system I am claiming to have implemented here. It would still need retention and a tested restore process.

A later dashboard capture, supplied on 8 September 2026, reported 80,383 total users. This is a separate observation from the earlier 28 August count of 80,382. Neither is a count of restored accounts or establishes how many accounts survived this recovery.

Reflection

Recovery could only reach as far as the export

I was responsible for the technical system and for the outage. The editorial team and community had created something that predated the software, and rebuilding the backend did not make the gap in their user records disappear.

The recovery let the product continue with the accounts present in the export. It also exposed how much I had left implicit: how reporting should run, what needed to survive a dormant season, and whether I could restore the product independently of its hosting provider.

I would separate those requirements before another seasonal launch. The reporting path has to coexist with reader traffic, and the recovery path has to be exercised before it is needed. This incident gives me a reason for both; the surviving file alone is evidence of neither.