Перейти к основному содержанию
Надёжные процедуры резервного копирования и восстановления необходимы для поддержания доступности нод и защиты от потери данных. В этом разделе описано, что следует резервировать, как часто, где хранить и как восстанавливаться после сбоя.
Планируйте хранилище резервных копий объёмом в 1,5–2 раза больше текущего размера данных цепочки. Операции резервного копирования обычно добавляют 10–20% нагрузки I/O во время выполнения.

Что резервировать

Не-валидирующие ноды хранят критическое состояние и данные конфигурации, необходимые для продолжения работы. Ключевые компоненты:
  • База данных блокчейна
    Хранит полное состояние цепочки Plasma. Восстановление из резервных копий значительно быстрее полной ресинхронизации.
  • Файлы конфигурации
    Включают файлы Docker Compose, переменные .env и любые пользовательские скрипты.
  • Keystore и состояние пиров
    Обеспечивает чистый перезапуск без ручной переконфигурации. Может включать токены аутентификации и сетевые метаданные.

Стратегия резервного копирования

Частота

Устанавливайте интервалы резервного копирования на основе использования и профиля рисков. Ежедневные снапшоты достаточны для большинства не-валидирующих нод. Развёртывания с высокой пропускной способностью могут требовать более частых резервных копий для минимизации потери данных при сбое.

Соображения по хранению

Храните резервные копии на отдельной инфраструктуре: облачных бакетах, удалённых хостах или офлайн-дисках. Избегайте размещения резервных копий рядом с основной нодой.
Не храните резервные копии на той же физической машине, что и работающую ноду. Один аппаратный сбой может привести к полной потере данных.
Внедряйте шифрование резервных копий для защиты конфиденциальных данных, особенно при использовании внешних поставщиков хранения. Убедитесь, что хранилище резервных копий имеет достаточную ёмкость для требований хранения и прогноза роста.

Сценарии восстановления

Частичное восстановление

Используйте целевое восстановление, когда затронуты только определённые файлы:
  • Восстановление файлов конфигурации после случайных правок
  • Восстановление повреждённой базы данных без сброса прогресса синхронизации
  • Повторное применение состояния пиров для сохранения существующей сетевой настройки
Частичное восстановление сокращает время простоя и избегает полной ресинхронизации.

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

Требуется при потере ноды или хост-системы:
  1. Подготовьте новую машину или VM
  2. Восстановите базу данных блокчейна и конфигурации из резервной копии
  3. Запустите ноду и переподключитесь к сети
  4. Подтвердите синхронизацию с последним финализированным блоком
Ожидайте, что время восстановления зависит от размера данных, пропускной способности и хранилища.

Валидация

Регулярно проверяйте целостность резервных копий:
  • Проверяйте контрольные суммы хранящихся файлов
  • Периодически выполняйте тестовое восстановление на некритической инфраструктуре
  • Отслеживайте успешность, длительность и размер данных резервного копирования

Лучшие практики

  • Автоматизируйте резервное копирование и оповещайте о сбоях
  • Используйте контроль версий для файлов конфигурации
  • Тестируйте процедуры восстановления ежеквартально
  • Отслеживайте время восстановления для оценки целей RTO/RPO

Устранение неполадок

Сбои резервного копирования

  • Проверьте дисковое пространство, права доступа и соединение с хранилищем
  • Просмотрите логи на наличие ошибок I/O или таймаутов

Обнаружение повреждений

  • Регулярно проверяйте контрольные суммы
  • Отслеживайте логи синхронизации на признаки несогласованности базы данных

Производительность восстановления

  • Оптимизируйте восстановление, используя быстрые хранилища и локальные диски
  • Используйте параллельный I/O, если это поддерживается бэкендом хранилища
Надёжный план резервного копирования и восстановления защищает от потери данных и минимизирует время простоя. Регулярно тестируйте, безопасно храните резервные копии и следуйте структурированному процессу восстановления для поддержания надёжной работы нод.