I ran a DayZ mod server for about ten years. Somewhere in the middle of that I migrated the forum to new hosting, didn’t take a backup first, and lost it. Roughly 1,400 posts. I’ve written before that it’s the one piece I actually regret, and I’d made my peace with it being gone.
It is mostly gone. But going looking properly, rather than typing the domain into web.archive.org and skimming, turned up more than I expected — including two things that happened to my own site that I have no memory of at all.
If you ran something like this and assumed the record died with it, spend twenty minutes on this before you accept that. The tool is free, needs no account, and the useful half of it isn’t the part with the calendar.
Start with the index, not the calendar
The Wayback Machine’s front page gives you a calendar with dots on it. It’s fine for browsing and useless for finding out what actually exists, because it only ever shows you one URL at a time.
What you want is the CDX API — a plain text index of every capture the archive holds, queryable, no key required. Ask it for one capture per year of your front page:

Eight lines, and already three things worth knowing. The site was captured every year from 2018 to 2025, so it never lapsed. 2023 and 2025 are 301s — by then the front page was redirecting, which dates a change I’d have had to guess at otherwise. And 2024 has a bare - for its status: that’s a revisit record, the archive’s way of saying “identical to the last time I looked”. Nothing changed that year.
collapse=timestamp:4 is what reduces it to one row per year — it collapses on the first four characters of the timestamp. Drop the collapse and you get every capture; use collapse=timestamp:6 for one a month.
To see everything the archive has under the domain, not just the front page, add a wildcard:
curl -s "https://web.archive.org/cdx/search/cdx?url=example.com*\
&fl=timestamp,original,statuscode,mimetype&collapse=urlkey"
That’s the query that changes what you think you lost. For me it returned 147 distinct URLs, including a stack of forum pages and five pages of a player-statistics section I’d forgotten the site ever had.
The status code will lie to you
Here is the part I got wrong for an hour, and the reason I’m writing this at all.
The index showed ten viewforum.php pages — ten different forum ids — all returning 200. I read that as ten pages of recovered forum content and got briefly excited.

A 200 means the server answered. It does not mean the server answered with anything. Every one of those captures is a maintenance page — the forum was closed when the crawler came through, so the archive faithfully stored ten identical copies of a notice pointing everyone at Discord.
The lesson generalises past the archive: when you’re recovering anything, check the body, not the status line. The cheapest check is to grep for a structural element the page must contain if it worked. On a page of topics, that’s a link to a topic. Zero is your answer.
The same applies in the other direction — a 404 in the index isn’t always a dead end. Most of my viewtopic.php?...&t= URLs are 404s because the crawler visited them after I’d already moved the forum. The archive stored my 404 page. The topic ids in those URLs are still real, and still tell you the forum had at least twelve hundred topics.
One mechanical note: when fetching a specific capture, the URL you ask for has to match what the archive indexed, query string and all. Ask for viewforum.php?f=12 when the capture is of viewforum.php?f=12&sid=… and you get a 404 that is itself 150 KB of HTML — which looks like a page, and isn’t. Copy the URL out of the CDX output rather than typing it.
Append id_ to the timestamp — /web/20181220113119id_/http://… — to get the original bytes without the archive’s toolbar and URL-rewriting injected into them. Essential if you’re parsing; skip it if you’re screenshotting, because the toolbar is your proof of provenance.
What actually survived
Six months earlier in the index, before the forum closed, there’s a capture of /forum/index.php that is entirely real:

That single page gave me back the whole structure: every forum name, the descriptions I wrote for them, per-forum topic and post counts, and the last post in each with its author and date. The statistics line at the bottom is the one I’d have paid for — 1,453 posts, 1,207 topics, 94 members, and a most-ever-online figure of 13.
I can’t recover the posts themselves. I can recover exactly how big the thing was, what it was organised into, and who was still turning up in the last months. For a record I’d written off entirely, that’s a lot.
It also explains something. Look at the last-post column on the two busiest forums: one is selling fake documents, the other is Russian spam. By June 2018 the forum was being posted to almost exclusively by bots. Six months later it was closed for maintenance and never really came back. I remembered the closure. I’d forgotten — or never registered — that spam is what did it.
The archive keeps your failures too
This is the part I wasn’t prepared for.
February 2019: the hosting account was suspended. There’s a capture of /cgi-sys/suspendedpage.cgi — “This Account has been suspended. Contact your hosting provider for more information.” I have no memory of this at all.
March 2021: the homepage was a stack trace.

mysqli::real_connect(): Connection refused, with a full CodeIgniter backtrace and my server paths printed to anyone who loaded the page. The dashboard never came back after that. The next capture is the static page that carried the site to 2022.
And then the one that made me sit up. The dashboard published lifetime statistics, and the archive caught them in two different years:
| August 2018 | May 2019 | |
|---|---|---|
| Total logins | 42,435 | 38,880 |
| Unique players | 838 | 584 |
| Characters created | 5,048 | 5,187 |
Lifetime counters do not go down. Something reset the hive between those two captures, and the suspension three months before the second one is sitting right there as a candidate. I’m not going to claim I remember it, because I don’t — but the archive is telling me it happened, and that’s a thing I only know because a crawler happened to be indifferent to whether the numbers were flattering.
The twenty-minute version
collapse=urlkeyoveryourdomain.com*to get every distinct URL the archive holds.- Filter to
text/htmland status 200 first, then look at the 301s and 404s for dates. - Grep every “recovered” page for a structural element before believing it recovered anything.
- Walk the front page year by year with
collapse=timestamp:4. Sites break in ways their owners forget. - Use
id_when parsing, plain captures when screenshotting. - Pull whatever has numbers in it. Statistics pages, leaderboards, member counts and “most users ever online” are the things nobody thinks to save and nobody can reconstruct later.
One thing not to do
My site’s player pages published a playerUID next to every name — Steam64 ids, sitting in the archive, ten to a page.
They were public once. That isn’t a reason to republish them now. The stats beside them are mine to write about; the identifiers belong to the people who earned them, most of whom I haven’t spoken to in a decade and none of whom agreed to be indexed forever. Take the numbers, leave the ids.
The archive doesn’t make that distinction for you. It kept everything, which is the whole point of it, and is also why the judgment has to be yours.


