What do you do after a raid on Discord?
7
Configuration steps
5
Final tests
4
Errors solved
~8 min
Reading time
The answer
The short answer
After a raid, act in four steps and in this order: first stop whatever is still going on, then restore the damaged configuration from a backup, then review the penalties issued automatically and undo the wrong ones, and finally close the gap the attackers came through. The reverse order costs the most — restoring channels during an ongoing attack means restoring them a second time. In Venon Security you check the lockdown state in Panel → Security → Emergency mode, the copies in Panel → Server → Backups, and the list of penalties issued in Panel → Moderation → Moderation centre.
The content is checked against the bot's configuration — last verified: 2026-08-08.
Context
What the problem is
A raid rarely ends the moment new accounts stop arriving. What it leaves behind is a mix of damage of different kinds: deleted or renamed channels, changed role permissions, hundreds of messages to clear, a queue of automatically issued penalties — some of them against people who did nothing. On top of that comes a question that has to be answered before the server returns to normal: how did they actually get in? Without that answer, recovery is only a postponement of the next raid.
Without an extra bot
What you can do with Discord alone
- 01
Raise the server's verification level in Discord's settings — that stops new accounts arriving, but does not remove the ones already inside.
- 02
Check Discord's audit log (Server settings → Audit log) — it shows who deleted a channel or changed a role, but keeps a limited range and cannot be filtered by incident.
- 03
Take permissions away from the roles the attackers managed to take over. Discord has no bulk undo — every change has to be reconstructed by hand from memory.
- 04
Unban the people banned by mistake, one at a time from the ban list. With a few hundred entries that is hours of work.
Venon Security
What Venon Security adds
A configuration backup lets you restore the roles, channels and permissions as they were before the attack, instead of reconstructing them from memory.
The moderation centre keeps every penalty from the incident in one place — you can see which was automatic and on what basis.
The logs record the sequence of events split into categories, so reconstructing the order does not depend on the window of Discord's audit log.
Emergency mode shows whether the lockdown is still running and what decisions were taken — so you know what still needs unlocking.
Configuration
Configuration step by step
0 of 7 steps
Check whether the attack has actually ended
Panel → Security → Emergency modeBefore you restore anything, make sure you are not restoring it during an ongoing attack. The Current session card shows whether the lockdown is still active, and Administrator decisions shows what has already been approved. Only move on once the influx has stopped.
- Current session — whether the lockdown is still running
- Administrator decisions — what was approved during the incident
Make a copy of the state AFTER the attack, before you restore anything
Panel → Server → Backups/backup createThis seems illogical — why save a damaged state? Because restoring overwrites the current configuration, and the post-attack state is the only record of what was changed. If the pre-attack copy turns out to be older than you thought and also undoes legitimate changes from the last few days, you will have something to come back to.
- New copy — description: “state after the raid, before restoring”
Restore the configuration from a pre-attack copy
Panel → Server → Backups/backup listIn the backup history pick the most recent copy dated before the incident. The panel asks for confirmation in the Restore the configuration from a copy? dialog — read it, because the operation overwrites the current settings. Restoring concerns the server's configuration, not message content: deleted messages will not come back.
- Backup history — pick an entry dated before the attack
- Confirm in the “Restore the configuration from a copy?” dialog
Review the penalties issued during the incident
Panel → Moderation → Moderation centreAutomatic defence works on thresholds, and thresholds can be too sensitive during a wave of traffic. Review the penalties from the hours of the incident and undo those that hit ordinary members. This is the most commonly skipped step — and at the same time the one that most affects how the community remembers the whole event.
- Filter by the time of the incident
- Undo the penalties issued wrongly
Reconstruct the sequence of events from the logs
Panel → Moderation → LogsLogs split into categories show the order: when the influx started, what was deleted, which roles changed and when the defence fired. You are looking for one thing — the moment of entry. It is usually an invite with no limit, an account with permissions it should not have, or a bot added earlier and left dormant.
- Categories: penalties, deleted messages, role and channel changes
- Pay attention to events BEFORE the first wave of joins
Close the gap and raise the thresholds
Panel → Security → Raid protectionIf the defence fired too late, lower the join count threshold in the time window. If it fired but too broadly — raise it and add verification at the entrance, so accounts are filtered rather than everyone penalised. Also revoke the invites they came through and take permissions away from roles that should not have them.
- Thresholds: the number of joins in the time window
- Revoke the invites used during the attack
Make a fresh copy of the final state
Panel → Server → Backups/backup createOnce recovery is finished, save the state you arrived at. The pre-attack copy is now out of date — it does not carry the raised thresholds or the closed gap. Without this step the next incident starts by restoring the configuration that let the previous one in.
- New copy — description: “after recovery, thresholds raised”
The steps you tick are saved in your browser — you can come back and finish later.
Verification
How to check the configuration worked
- 1
Join the server on an account with no roles — the channel structure and the permissions should look as they did before the attack.
- 2
No penalty in the moderation centre is left marked as needing review.
- 3
Emergency mode shows that the lockdown is finished, not suspended.
- 4
The backup history contains an entry made AFTER recovery, not only the one from before the attack.
- 5
The invite used during the attack no longer works when pasted into a browser.
Diagnostics
When something does not work
After restoring a copy, channels created in the last few days disappeared.
- Cause
- The copy predates their creation, and restoring recreates the state from the moment it was made.
- Fix
- Recreate the missing channels by hand using the copy made AFTER the attack — which is why step two of these instructions tells you to make it before restoring.
Deleted messages did not come back after the copy was restored.
- Cause
- A copy saves the server's configuration — roles, channels and permissions — not message content.
- Fix
- The content cannot be recovered by any bot; Discord exposes no such API. The record of what was deleted stays in the logs.
Some people still cannot write, even though the lockdown was lifted.
- Cause
- A lockdown changes channel permissions, and restoring the previous state requires ending the session, not just suspending it.
- Fix
- On the Emergency mode screen check the Current session and end it. If the permissions were overwritten, restore the configuration from a copy.
Nobody knows how the attackers got in.
- Cause
- The review started from the first wave of joins, and the moment of entry is usually earlier.
- Fix
- Go back in the logs to the hours BEFORE the wave and look for permission changes, new invites or bots that were added.
Honestly
What this configuration does not solve
You will not recover the content of deleted messages — no bot has access to them once they are gone.
Restoring recreates the configuration from the moment the copy was made, so changes introduced later have to be repeated by hand.
If no copy was made before the attack, there is nothing to restore — that scenario is settled before the incident, not after it.
Recovery does not replace a conversation with the community: people banned by mistake need an explanation, not only the penalty undone.
Commands
The commands used in this guide
Read on
Related guides
How do you prepare a Discord server for an attack?
How to prepare a Discord server for an attack: a permission audit, 2FA, a backup, protection thresholds, emergency mode and a procedure for the staff.
Read the guideHow do you protect a Discord server from a raid?
How to protect a Discord server from a raid: entry verification, AntiRaid thresholds, content protection and logs. Concrete settings, a test and the usual mistakes.
Read the guideHow do you check Discord moderation logs?
How to check Discord moderation logs: the audit log, the bot's log categories, the penalty channel, the access role and data retention.
Read the guide
FAQ
FAQ – common questions
Where do you start recovering a server after a raid?+
By checking whether the attack has actually ended. Restoring the configuration during an ongoing influx means it will have to be restored a second time. You can check the lockdown state in Panel → Security → Emergency mode.
Can messages deleted during a raid be recovered?+
No. Discord gives no access to the content of deleted messages, so no bot can do it. The record of what was deleted and when stays in the moderation logs — the content does not.
Will restoring a copy undo the bans issued during the attack?+
No. A copy concerns the server's configuration — roles, channels and permissions. You review the penalties separately in Panel → Moderation → Moderation centre and undo those that hit ordinary members.
Why make a copy of the server after the attack?+
Because restoring overwrites the current configuration. A copy of the post-attack state is the only record of what was changed — useful if the pre-incident copy turns out to be older than you assume and also undoes legitimate changes.
How do you establish how the attackers got in?+
Review the logs from the hours BEFORE the first wave of joins, not from during it. The moment of entry is usually an invite with no limit, an account with excessive permissions, or a bot added earlier and left unused.
Set this up in your own Venon Security panel
Every screen mentioned in the guide is in the web panel. You save the configuration by hand and see its state before anything takes effect on the server.