Документация / Обслуживание

Резервная копия и восстановление

Согласованная копия профиля, ресурсов и БД; контрольное восстановление.

Состав резервной копии

Копия должна позволять восстановить не только ресурсы, но и идентичность, доступ и данные игроков. Сохраняйте:

  • Версию комплекта, исходный ZIP и результат проверки целостности.
  • txData целиком: профиль, администратора, сохранённые настройки и приватные ключи.
  • Активный каталог server-data, все конфиги exec и ресурсы, включая данные вне стандартного game.
  • SQL-дамп или согласованную резервную копию СУБД.
  • Отдельные файлы, в которые ресурсы пишут состояние, и сведения о внешних зависимостях.
  • Перечень портов, правил NAT, учётной записи Windows и пользовательских ACL.

Резервная копия содержит секреты. Храните её с ограниченным доступом и шифрованием на отдельном носителе/хранилище. CDN и публичная папка сайта для этого не подходят. Название архива не является защитой.

Подготовка согласованного снимка

Назначьте окно обслуживания, уведомите игроков, завершите сохранение режима и остановите игровой процесс. Убедитесь, что ресурсы больше не меняют файлы и SQL. Завершите монитор перед копированием его изменяемого состояния. Если один экземпляр БД обслуживает другие приложения, не останавливайте его без учёта этих приложений.

Запишите время, версию, активный dataPath и ID сервера. Копия только стандартной папки game недостаточна, если профиль использует внешний каталог.

Пример копирования файлов Windows

Пример копирует комплект в новый каталог на другом диске. Проверьте пути до выполнения; не направляйте резервную копию внутрь исходного каталога.

$source = 'C:\OpenM-Server'
$stamp = Get-Date -Format 'yyyyMMdd-HHmmss'
$destination = "D:\OpenM-Backups\$stamp\bundle"
New-Item -ItemType Directory -Path $destination -ErrorAction Stop | Out-Null
robocopy $source $destination /E /COPY:DAT /DCOPY:DAT /R:2 /W:2 /XJ
if ($LASTEXITCODE -ge 8) { throw 'Копирование завершилось с ошибкой' }

/XJ исключает переход по junction: внешние каталоги данных нужно копировать отдельно. /COPY:DAT не сохраняет исходный NTFS ACL; назначьте закрытые права каталогу резервных копий заранее и восстановите права на новом хосте. Не добавляйте /MIR к примеру: зеркалирование может удалять файлы в назначении.

Пример дампа MySQL

Используйте клиент совместимой версии и учётную запись резервирования с необходимыми правами. Пароль вводится по запросу, а не в командной строке:

& 'C:\Program Files\MySQL\MySQL Server 8.4\bin\mysqldump.exe' `
  --host=127.0.0.1 --user=backup_user --password `
  --single-transaction --routines --triggers --events `
  --result-file='D:\OpenM-Backups\REPLACE_TIMESTAMP\openm_game.sql' openm_game
if ($LASTEXITCODE -ne 0) { throw 'SQL-дамп не создан корректно' }

Путь, имя пользователя и каталог заменяются реальными. --single-transaction обеспечивает согласованность транзакционных таблиц, например InnoDB; нетранзакционные таблицы и параллельные DDL-изменения требуют отдельного плана. Права для routines/events и других объектов зависят от версии и схемы. Проверяйте ошибки, а не только наличие файла. См. официальную документацию mysqldump.

--result-file избегает зависимости кодировки SQL от перенаправления вывода PowerShell. Не копируйте каталог работающей СУБД как обычные файлы в надежде получить корректный дамп.

Контроль и хранение

Создайте перечень файлов и контрольные суммы, проверьте размер SQL-дампа и ошибки копирования. Храните несколько поколений: новая повреждённая копия не должна немедленно заменять последнюю рабочую. Для внешнего хранилища проверьте возможность чтения и восстановления без доступа к основному компьютеру.

Определите допустимую потерю времени данных и допустимый простой. Из них следует частота копирования. Ежедневная копия не обеспечивает восстановление последних пяти минут. Автоматическая задача должна сообщать об ошибке и слишком старой последней успешной копии.

Проверочное восстановление

  1. Подготовьте отдельный каталог и отдельную тестовую БД; рабочие данные не перезаписывайте.
  2. Восстановите файлы и согласованную версию СУБД/схемы.
  3. Проверьте dataPath, ACL, приватную строку БД и порты.
  4. Отключите публикацию тестовой копии и изолируйте её от игроков. Не допускайте одновременно двух издателей с одним ID.
  5. Запустите профиль и проверьте администратора, ресурсы, наличие персонажей и сохранение изменений в тестовой БД.
  6. Запишите фактическое время восстановления и недостающие файлы.

Восстановление старой копии не возвращает отозванные ключи в действующее состояние. После компрометации используйте новые ключи и проверьте их в портале. Копия считается проверенной только после такого восстановления, а не после успешного создания ZIP.

Введите название, параметр или текст ошибки.

Esc — закрыть · Tab — выбрать результат