Состав резервной копии
Копия должна позволять восстановить не только ресурсы, но и идентичность, доступ и данные игроков. Сохраняйте:
- Версию комплекта, исходный 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-дампа и ошибки копирования. Храните несколько поколений: новая повреждённая копия не должна немедленно заменять последнюю рабочую. Для внешнего хранилища проверьте возможность чтения и восстановления без доступа к основному компьютеру.
Определите допустимую потерю времени данных и допустимый простой. Из них следует частота копирования. Ежедневная копия не обеспечивает восстановление последних пяти минут. Автоматическая задача должна сообщать об ошибке и слишком старой последней успешной копии.
Проверочное восстановление
- Подготовьте отдельный каталог и отдельную тестовую БД; рабочие данные не перезаписывайте.
- Восстановите файлы и согласованную версию СУБД/схемы.
- Проверьте dataPath, ACL, приватную строку БД и порты.
- Отключите публикацию тестовой копии и изолируйте её от игроков. Не допускайте одновременно двух издателей с одним ID.
- Запустите профиль и проверьте администратора, ресурсы, наличие персонажей и сохранение изменений в тестовой БД.
- Запишите фактическое время восстановления и недостающие файлы.
Восстановление старой копии не возвращает отозванные ключи в действующее состояние. После компрометации используйте новые ключи и проверьте их в портале. Копия считается проверенной только после такого восстановления, а не после успешного создания ZIP.