CoreProtect: откат грифа и расследование инцидентов на Minecraft сервере

CoreProtect логирует каждое действие игроков и позволяет откатить гриф одной командой. Разбираемся как поставить, что писать в config.yml, как искать виновника и возвращать мир в исходное состояние без бэкапа.

Зачем CoreProtect нужен каждому серверу

Если у вас открыт сервер с whitelist выключен или хотя бы 5 игроков, рано или поздно случится одно из двух: кто-то выкачает алмазы из чужого сундука или обольёт лавой чужой дом. Без логов вы не докажете кто виноват, без отката будете чинить регион руками или катить бэкап (а это потеря всех изменений с момента бэкапа для остального мира).

CoreProtect делает обе вещи. Это плагин-логгер для Paper / Spigot, который пишет в БД каждое размещение и слом блока, открытие сундука, чат, выполненную команду, выпитое зелье. Дальше любое действие за указанный период можно откатить или, наоборот, восстановить обратно. На практике CoreProtect стоит на 90%+ серверов от 10 до 1000 онлайн именно потому, что альтернативы по совокупности скорости, поддержки и совместимости в 2026 году нет.

Этот гайд покрывает установку, конфиг, команды для расследования, откат и тонкости с базой данных. Версии плагина: CoreProtect 22.x под Minecraft 1.20-1.21, ядра Paper и его форки.

Установка на Paper и Spigot

Скачайте jar с официального Modrinth или SpigotMC. Кладёте в plugins/, перезапускаете сервер, плагин сам создаёт plugins/CoreProtect/config.yml и базу database.db (SQLite).

Минимальные требования: Java 17+, Paper 1.20.1 и выше. На Spigot тоже работает, но Paper рекомендую: события идут быстрее, плагин их успевает залогировать без лагов.

Проверка установки:

# В консоли сервера или с правами оператора
/co help
/co status

Если выдаёт версию и Database is operational - значит работает. Прав по умолчанию игрокам не выдаёт ничего, нужны явные пермы (через LuckPerms или аналог).

База данных: SQLite или MySQL

По умолчанию CoreProtect пишет в SQLite (database.db рядом с конфигом). Этого хватает до примерно 50 онлайн или пока файл не дорастёт до 50-100 GB. После этого SQLite начинает тормозить на запросах lookup с большим радиусом, и стоит мигрировать на MySQL или MariaDB.

Когда переключать на MySQL:

• стабильно больше 50 одновременных игроков
• database.db больше 100 GB
• запросы /co lookup идут дольше 5-10 секунд
• сервер в сети с другими (BungeeCord/Velocity), и хотите общую базу логов

Конфиг MySQL в config.yml:

mysql: true
mysql-host: "127.0.0.1"
mysql-port: 3306
mysql-database: "coreprotect"
mysql-username: "coreprotect_user"
mysql-password: "***"
table-prefix: "co_"

После смены пересоздайте структуру: сначала плагин создаст таблицы, перезапустите сервер ещё раз. Старые данные из SQLite автоматически НЕ переносятся, есть только сторонние скрипты-миграторы.

Что писать в config.yml

Полный лог жрёт диск. Если у вас шахтёрский сервер на 200 онлайн, block-break: true плюс item-pickup: true дадут гигабайты в день. Реально нужно логировать не всё, а то что используется при расследовании.

Базовый рабочий конфиг:

# Что писать в БД
block-place: true
block-break: true
natural-break: false      # ломание блока водой/гравитацией - спам, выключаем
explosions: true          # криперы, тнт, end crystal - всегда нужно
fire: true                # пожары
liquid-tracking: true     # лава/вода flow
sign-text: true
container-transactions: true   # сундуки, шалкеры, бочки
item-transactions: true        # дроп/пикап с интересных целей
item-pickup: false        # обычно не нужно, жрёт диск
player-interactions: true # двери, рычаги, кнопки
chat: true
commands: false           # включайте если юзеры могут /sudo, /tp
worldedit: true           # критично если открыт WorldEdit операторам

# Хранение
default-radius: 10
date-format: "yyyy-MM-dd HH:mm:ss"
api-enabled: true

# Производительность
table-version: 9
disable-wal: false        # WAL ускоряет SQLite, не выключайте

commands: true пишет каждую введённую команду включая аргументы. Полезно при подозрении на дюп через команды, но если в чате юзеры пишут /msg с приватными темами, это потенциальная утечка. Решайте по ситуации.

Inspector mode: режим инспекции

Самая частая команда после грифа - встать рядом и проверить кто что трогал. Включаете режим:

/co inspect
# или коротко:
/co i

Дальше любой левый клик по блоку показывает кто его поставил/сломал и когда. Правый клик по сундуку - все транзакции с ним. Очень удобно когда жалоба звучит "у меня из сундука пропали алмазы": становитесь рядом, правый клик по сундуку, видите весь лог транзакций с ником и временем.

Выключить режим - повторно /co i.

Inspector работает только с правом coreprotect.inspect. Не выдавайте обычным игрокам, иначе модераторы не нужны: каждый сам проверит соседа.

Поиск действий: /co lookup

Когда нужен системный поиск по логам, не клик по блокам, а выборка по фильтрам:

# Все действия Steve за последние 7 дней
/co lookup u:Steve t:7d

# Что Steve копал в радиусе 100 блоков от вас за 24 часа
/co lookup u:Steve t:24h r:100

# Все взрывы за 6 часов
/co lookup a:+block t:6h b:tnt

# Поиски в сундуках за неделю
/co lookup t:7d a:container

Вывод идёт в чат постранично, переключение страниц /co l <page>. Если нужна выгрузка - смотрите webhook-плагины или парсите БД напрямую SQL-запросом.

Параметры команды:

• u: - ник игрока (или #environment для сурвайва, #tnt, #fire)
• t: - время назад: 1m, 1h, 7d, 30d, можно комбинировать t:1d2h
• r: - радиус от вас в блоках, r:#world - весь мир, r:#chunk - текущий чанк
• a: - тип действия: block, +block (только place), -block (только break), chat, command, container
• b: - конкретный блок: b:diamond_ore, b:tnt
• e: - исключить: e:#dirt,grass_block уберёт из выдачи мусор
• i: - предмет: i:diamond для контейнерных транзакций

Откат грифа: /co rollback

После того как нашли виновника и оценили масштаб, откатываете:

# Откатить всё что Steve делал за последний час в радиусе 50
/co rollback u:Steve t:1h r:50

# Откатить все взрывы TNT за 30 минут на всём мире
/co rollback t:30m a:+block b:tnt r:#world

# Откатить весь pour лавы за 2 часа
/co rollback t:2h a:liquid e:water

Команда работает асинхронно: на больших регионах сервер не лагает, но операция занимает минуты. Прогресс пишется в консоль. Прерывать не надо - дождитесь Rollback complete.

Важный момент: rollback откатывает к состоянию ДО первого действия в выборке. То есть если Steve поставил блок, потом сломал, rollback вернёт ситуацию как до постановки (чистое поле). Проверяйте параметры дважды на тестовом регионе.

Восстановление: /co restore

Что если после rollback'а часть откатилась зря? Например, откатили грифера, но вместе с ним снесли постройку соседа, который чинил его дыры. Тогда:

/co restore u:Steve t:1h r:50

Это обратная операция: возвращает мир в состояние ПОСЛЕ действий. По сути undo для rollback. Если нужно частично, играйтесь с фильтрами b: и e: чтобы зацепить только нужные блоки.

Очистка логов: /co purge

База растёт быстро. На сервере с 100 онлайн без item-pickup это примерно 5-10 GB логов в месяц. Через полгода у вас 30-60 GB, lookup'ы тормозят. Чистите старое:

# Удалить всё старше 30 дней
/co purge t:30d

# Только определённый мир
/co purge t:30d w:world_nether

Запускайте purge ночью или в окно низкой активности: операция блокирующая на уровне БД. На SQLite после purge ещё VACUUM через sqlite-cli, иначе файл не сжимается:

sqlite3 plugins/CoreProtect/database.db "VACUUM;"

На MySQL OPTIMIZE TABLE co_block, co_container, co_chat;. На больших таблицах может занять час, делайте на стопе сервера.

Производительность и мониторинг

Что отслеживать:

• размер БД: следите за ростом. Если растёт быстрее чем 10 GB/неделя - что-то логируете лишнее, режьте item-pickup, natural-break, liquid-tracking
• TPS при lookup: запросы с r:#world и t:30d тяжёлые. На SQLite они блокируют запись, мир не успевает писать новые события - возможны спайки лагов
• диск IOPS: SQLite пишет много мелких операций. SSD обязателен, на HDD CoreProtect ляжет на 50+ онлайн

Индексы плагин ставит сам (co_block(time, user), и т.д.), вручную трогать не надо. Если делаете кастомные SQL-запросы для отчётов, добавляйте свои индексы по нужным полям.

Реальный сценарий: гриф ночью

Утром заходите, в спавне пробит туннель в админ-зал. Никого онлайн, кто и когда непонятно. Действия:

1. Встаньте у первого взорванного блока. /co i, левый клик. Видите ник и время первого взрыва.
2. /co lookup u:Griefer123 t:12h r:#world a:+block b:tnt - смотрите все TNT-постановки за 12 часов на всём мире. Выясняете что грифер ставил TNT с 03:14 по 03:42.
3. /co lookup u:Griefer123 t:12h a:container - проверяете лазил ли по сундукам. Часто грифер сначала вытащил админ-сундук, потом замёл следы взрывом.
4. /co rollback u:Griefer123 t:12h r:#world - откатываете все его действия за период. Возвращаются и блоки, и содержимое контейнеров.
5. Баните игрока, проверяете права через LuckPerms - как он вообще пробил защиту WorldGuard. Часто грифер заходил по альт-аккаунту с правами, которые получил социалкой.

На откат админ-зала уходит 2-5 минут. На откат масштабного грифа на пол-мира - 10-30 минут.

Что НЕ восстанавливается

CoreProtect мощный, но не всемогущий. Что не вернёт:

• дроп предметов с мобов: убитый эндермен и его перлы - не логируется
• печь-крафт: предметы переплавлены, исходник не вернётся
• зачарования и анвил-операции: новый предмет не помнится как комбинация двух старых
• изменения мира вне игроков: эрозия спавнером, обновления чанков от водопада - частично логируется через liquid-tracking, но не всегда чисто
• сам мир если был форматнут: CoreProtect хранит изменения, не сам мир. Если стерли world/, нужен бэкап мира

Под инвентарь игрока - только container transactions (содержимое сундуков). Личный инвентарь Steve команда /co rollback не восстанавливает: для этого нужны отдельные плагины типа InventoryRollback Plus.

Интеграция с другими плагинами

CoreProtect API публичный, многие плагины с ним дружат:

• WorldGuard: события WorldGuard деней пишет в лог как bypass_attempt
• Citizens: NPC взаимодействия логируются с ником NPC
• MythicMobs: кастомные мобы и их атаки видно в /co lookup a:kill
• WorldEdit: операции //set, //paste пишутся целиком, можно откатить большой WE-косяк через /co rollback u:OperatorName a:worldedit

Для разработчиков - в CoreProtect есть API для запроса данных программно: получаете список действий по координатам, фильтруете по нику, дёргаете в свой плагин.

FAQ

Можно ли восстановить мир если был форматнут?

Нет. CoreProtect хранит изменения в БД, не сам мир. Если папка world/ удалена, нужен бэкап мира. CoreProtect полезен только когда мир есть, но в нём что-то пошло не так. Поэтому отдельно настраивайте бэкапы мира (например через AutoSaveWorld или серверный snapshot хостинга).

Сколько диска занимает CoreProtect за месяц?

Зависит от трафика и настроек. На 100 онлайн со стандартным конфигом без item-pickup - примерно 5-10 GB в месяц. С item-pickup: true плюс commands: true может быть 20-30 GB. Чистите /co purge t:60d раз в месяц чтобы база не разрасталась бесконтрольно.

Что лучше: CoreProtect, Prism или LogBlock?

CoreProtect в 2026 году самый поддерживаемый и быстрый. Prism мощнее в плане API и веб-интерфейса, но обновляется медленнее. LogBlock старый и редко обновляется, не рекомендую новые сервера на нём поднимать. Если уже сидите на LogBlock и работает - не трогайте, но миграция на CoreProtect упростит жизнь.

Можно ли откатить инвентарь игрока?

Только содержимое контейнеров через /co rollback ... a:container. Личный инвентарь игрока CoreProtect не пишет. Для этого ставьте InventoryRollback Plus или PlayerInventoryRollback, они логируют слоты инвентаря отдельно.

Работает ли CoreProtect на Folia?

Есть форк под Folia, но не все функции стабильны: rollback на больших регионах может крашить из-за региональной потоковой модели Folia. На обычном Paper CoreProtect работает без оговорок. Если у вас Folia критична для производительности и нужен лог - смотрите альтернативы или ждите более стабильной версии.

Как защитить базу логов от самого грифера?

Если у грифера были права оператора, он мог зайти в БД и почистить свои следы. Защита: вынесите MySQL на отдельный сервер с доступом только по белому списку IP, регулярно делайте бэкапы базы (mysqldump в cron), храните копии оффлайн. Для SQLite - бэкап database.db раз в сутки в S3 или на отдельный диск.

Сколько по времени идёт rollback на 100к блоков?

На SSD с SQLite примерно 1-3 минуты, на MySQL быстрее. На HDD не запускайте такой rollback вообще, ждать 20+ минут с подвисаниями. Прогресс смотрите в консоли сервера, в чат он не пишется построчно.

Что делать дальше

Поставьте CoreProtect сразу при создании сервера, до первого грифа. Через неделю работы проверьте размер БД, отключите лишнее логирование, настройте /co purge t:60d в плановом скрипте раз в месяц. Раздайте coreprotect.inspect только модераторам и админам, обычным игрокам он не нужен и создаёт нагрузку.

И защищайте сам сервер от внешних атак: даже идеальный лог не поможет если сервер ляжет под DDoS и игроки уйдут. На MineGuard есть фильтрация под Minecraft без потери TPS, можно прикрыть продакшен заранее.