Who Raided My Base? Investigating a Raid From Your Logs

A step-by-step playbook for the situation every admin knows: a player logs in, their walls are gone, their loot is gone, and they want names. You weren't online. The only witness is the log files — and if you work them in the right order, they usually talk.

Background reading: Reading DayZ admin logs covers the ADM file basics (where the files live, how they rotate, what each line type means). This guide assumes that and goes straight to the raid procedure.

Ground rule: adjudicate data, not credibility. The victim is angry and will name a suspect in their first message — usually the last person they saw near the base. Write the suspect down, then ignore it until Step 6. Investigations that start from a suspect find that suspect; investigations that start from the coordinates find the raider.

Step 0 — Can this investigation succeed at all?

Two things decide the case before you open a single file, and both were decided before the raid happened:

1. Was the logging on? The vanilla server only writes build/placement lines if the flags were enabled in serverDZ.cfg before the raid:

adminLogPlacement = 1; — players placing items (fence kits, traps, explosives)
adminLogBuildActions = 1; — vanilla basebuilding build/dismantle actions
adminLogPlayerHitsOnly = 0; — full damage lines, not just hits (you want the kills and connects too)

Turning them on today helps the next victim. If they were off, skip to the honest verdict in Step 8.

2. Do the files still exist? ADM files rotate — a new file per server start — and hosts prune old ones. If the raid was ten days ago and your host keeps seven, the evidence is gone, full stop. Know your retention now, and lengthen it if you can; raid complaints routinely arrive days late because the victim was offline.

3. Which logs does your basebuilding actually write? This is the part nobody warns you about: modded basebuilding does not log like vanilla, and some destruction paths never log at all.

Destruction path	Where it logs
Vanilla build/dismantle	ADM file (only with `adminLogBuildActions`)
BBP (BaseBuildingPlus) dismantle	ADM file, tagged `[BBP]`, with Steam64 and location
Breaching charge mods (e.g. HDSN)	The mod's own log file, not the ADM
Codelock mod access	The mod's own `Access.log` files
Expansion and other basebuilding mods	Varies — check the mod's docs and profile folder for its own logs
Explosive/raw damage destroying a wall	Often nothing. Many damage-destruction paths produce no build-action line
Server cleanup / persistence despawn	Nothing. No player was involved, so no player line exists

Inventory this for your mod list on a quiet day, not mid-complaint. If your raid meta is "C4 the wall" and that path doesn't log on your setup, your raid investigations will run on indirect evidence (presence, hits, codelock accesses) — plan accordingly.

Step 1 — Pin the time window

Interview the victim. Three questions:

When did you last see the base intact? (their last logout at the base)
When did you discover the damage?
What timezone are those times in? — then convert to the log clock. The server writes timestamps in the server's local time (often the host datacenter's, often UTC), which is almost never the player's timezone. Confirm the offset by finding the victim's own connect line and asking what time they think they logged in. Getting this wrong sends you reading the wrong day's files with total confidence.

The window between (1) and (2) is your search space. Everything else in this guide happens inside it.

Step 2 — Pull the files

Collect every log that overlaps the window, plus an hour of buffer on both sides:

Every ADM file from the window (one per restart — a 12-hour window on a 4-hour restart cycle is at least 3 files)
Your basebuilding/raid mod logs for the same window (breaching charge logs, etc.)
Codelock Access.log files for the window — the filename carries the date, e.g. [07-28-2023][12.10.46] Access.log

Copy them out of the live log directory into a working folder before you start. You'll want them intact later (Step 9), and you don't want rotation eating them mid-investigation.

Step 3 — Search by place, not by name

Get the base coordinates (victim can read them off iZurvive, or you teleport there and note your position). Then search the files for those coordinates — not for any player name.

The one thing you must know: log positions are <X, altitude, Y> — the middle number is height, not a map coordinate. A base at map position 5558 / 10938 shows up as <5558.263672, 291.127960, 10938.318359>. Search on the first and third numbers, and search on the integer prefix ("5558" and "10938"), because the decimals vary per event. Players move, so also try a few hundred meters of prefix slack (5557, 5559...).

A plain text editor's find-all across files (Notepad++ "Find in Files", or grep) is entirely sufficient. You are looking for any line whose position is at or near the base.

Step 4 — Find the breach

Inside the window, near the coordinates, you're hunting for destruction and entry events. What they look like depends on your mods — these are real formats:

BBP dismantle (appears in the ADM itself):

02:33:19 | [BBP] 'Rook' (76561198000000002) DISMANTLED [T2] Left Hanger Door using Crowbar LOCATION:<5558.263672, 291.127960, 10938.318359>

(Names and ids in every example on this page are invented.)

Name, Steam64, exactly what came down, the tool, and where. One line like this at the victim's walls, from a non-owner, is your smoking gun.

Breaching charges (the mod's own log — note all three phases):

[11/04/2026-02:31:12]   [PLACED]    ... | HDSN_BreachingCharge, Position: <5558.263672, 291.127960, 10938.318359>, Target: BBP_SDoor_T1_Door_T1 | Player: Rook [76561198000000002]
[11/04/2026-02:33:40]   [EXPLODED]  ... | HDSN_BreachingCharge, Position: <5558.263672, 291.127960, 10938.318359>, Target: BBP_SDoor_T1_Door_T1, Damage done: 1 | Player: Rook [76561198000000002]
[11/04/2026-02:33:40]   [DESTROYED] ... | HDSN_BreachingCharge, Position: <...>, Target: BBP_SDoor_T1_Door_T1 | Player: Rook [76561198000000002]

PLACED marks the start of the breach; DESTROYED names exactly which door or roof panel died.

Codelock accesses (the mod's Access.log):

[02:41:03] Player (Vex, 76561198000000003)(<5560.181152, 291.127960, 10940.212891>) quick accessed a lock!

Every lock open at the base, with who and where. During the raid window these tell you who was inside.

Vanilla basebuilding (with the Step 0 flags on) writes build, dismantle, and placement lines into the ADM with the player, action, part, and tool — same idea, vanilla part names. See Reading DayZ admin logs for the vanilla line reference.

If you find no destruction lines but the victim swears walls are gone — hold that thought for Step 7. It does not automatically mean no raid.

Step 5 — Identify the actors

The unit of identity is the Steam64 ID — the 17-digit number starting 7656119.... Modded lines (BBP, codelocks, breaching charges) hand it to you directly. Record it for every actor.

One trap here: vanilla ADM lines do not contain Steam64s. Their id= field is a long hashed identity string. It's stable per player, so you can correlate lines within the logs by it, but to turn it into a Steam64 you need your server tooling (CFTools, RCon tools, whitelist records) or a matching modded line from the same session. Do that translation before you write anything down as a finding.

Names are decoration. Players rename freely, and two players can share a name. Never let a name into your case notes without its ID next to it.

Step 6 — Reconstruct the timeline

Now expand the search around your breach events — same coordinates, wider time — and build a simple chronological table. A real raid has a shape:

Phase	What you'll find in the logs
Approach	Raiders' connect lines; hits/kills near the base before the first breach if defenders were on
Breach	The Step 4 events, usually clustered — raids chew through multiple walls/doors
Loot window	Codelock accesses inside; often 20–60 quiet minutes between breach and exit
Exit	Raiders' disconnect lines shortly after activity stops

The corroborating lines, verified formats:

01:58:18 | Player "Rook"(id=Qm9dXHboAgimx4YjtUhIbeU4opowqglb7jg4O7AB4o=) is connected
03:07:15 | Player "Moss"(id=Unknown) has been disconnected

Hit and kill lines carry positions for both parties — Player "A" (id=... pos=<...>) killed by Player "B" (id=... pos=<...>) with <weapon> from <N> meters — so kills at the base coordinates during the window tell you whether the base was defended and who was standing where.

A coherent timeline — connect, approach, breach, accesses, disconnect, all by the same Steam64s — is what turns "a dismantle line exists" into "these players raided this base between 02:10 and 03:05". It is also what survives an appeal.

Step 7 — Was it even a raid?

Before delivering names, rule out the three impostors. This step is where admin reputations are saved.

It looks like a raid, but...	Tell-tale signs
Persistence cleanup / despawn	Everything vanished at once — walls, containers, contents — with zero player lines at the site. Often right after an update, wipe, or storage issue; or the flag/pole lapsed and the lifetime ran out. No actor exists because no actor was involved.
Glitched collapse / crash damage	Damage appears exactly at a restart or crash boundary; odd partial destruction (one wall, nothing looted); no accesses, no nearby connects.
The owner's own team	The dismantle/access Steam64s are the victim's teammates. Check the codelock access history before the window — the "raider" who opened the lock in one try has been opening that lock all month. Ask the victim for their team's IDs early; it's a two-minute check that regularly ends the case.
Offline raid with nothing destroyed	Loot gone, walls intact, no destruction lines. Wall-glitch entry ("boosting"/glitching through geometry) and server-hop ghosting into base interiors are real and mostly invisible in logs. Codelock accesses and connect lines near the base are often the only trace. Don't tell the victim "nothing happened" — tell them what the logs do and don't cover.

Step 8 — Delivering the verdict

Raid confirmed (share per your server's rules — some servers deliberately don't hand out raider names; decide the policy before the first case, not during it):

Went through the logs for your window. Your base at ~5558/10938 was breached on <date> between 02:10 and 03:05 server time: 2 players connected at 01:58, breached the T2 hanger door at 02:33, accessed 3 locks inside over the next 25 minutes, and disconnected at 03:07. No rule broke — raiding is allowed here — but the report of "admin must have deleted my base" is closed: it was a raid, and it's documented.

The logs don't show it (say it straight — a confident wrong answer is worse):

I checked every log covering <window>: no destruction, dismantle, or lock events at your coordinates, and no way to attribute what you lost. Two honest possibilities: the loss happened through a path our logs don't record (some destruction and glitch entries don't log), or it was persistence cleanup rather than players — that leaves no trace by design. I can't name anyone on this evidence, and I won't guess. What I have done: <enabled the build-action logging / extended retention>, so next time there will be a record.

Never name a suspect the timeline doesn't support. "Probably X, he's always up there" is how innocent players get hounded off servers.

Step 9 — Evidence hygiene

Do this while it's fresh, not when the appeal lands three weeks later:

Copy the exact log excerpts (full lines, not paraphrases) into a case note, with the source filename for each line.
Record every actor as Steam64 + name-at-the-time, and the window in server time with the UTC offset stated.
Keep the raw log files from the window — retention will eat the originals.
Note what you ruled out (cleanup, teammates) and how. That's the part future-you forgets.

If you're on a platform that ingests these logs continuously (dayz.fyi among them), the breach, dismantle, and codelock events are also available as live map pins and raid alarms — convenient for catching it in the moment, but for a disputed verdict the raw excerpts above remain your ground truth.

Traps (each one has burned someone)

Name-only identification. Names change and duplicate. No Steam64, no finding.
Vanilla id= is not a Steam64. It's a hash. Translate it before accusing anyone.
Timezone confusion. Victim says "around 9pm", logs run UTC, admin reads the wrong three hours and declares "nothing happened". Anchor with the victim's own connect line.
The middle coordinate is altitude. Searching <x, y> as the first two numbers finds nothing. It's <X, altitude, Y>.
"Nothing in the logs" ≠ "nothing happened." Unlogged destruction paths and glitch/ghost entries are real. Report what the logs cover, not more.
"Something destroyed" ≠ "raid." Cleanup and collapse destroy bases with no raider. Step 7 before names, every time.
Blaming the last person seen nearby. The victim's suspect is an anchor, not evidence. Proximity yesterday is not a breach event today.
Logging enabled after the raid. The flags only help going forward. Check your config and retention today.