Резервирование Lightning-узла
Оглавление курса «Bitcoin и Lightning: платежи на сайте» · Урок 27 из 30.
Восстановление сайта и восстановление Lightning-узла требуют разных данных. База может помнить заказ курса 17 и его payment hash, но эти сведения не заменяют резерв платёжной инфраструктуры. И наоборот, средства узла могут быть восстановлены, а назначение отдельных invoice останется неизвестным. В этом уроке составим карту резервирования и ограниченный план восстановления без опасного совета просто вернуть старый файл канала.
Никакие ключи, базы и резервные копии здесь не создаются. Узел не установлен и не запускался. Материал описывает границы и договор будущей эксплуатационной процедуры. В действительном внедрении используется документация закреплённой версии узла и заранее определённый способ восстановления, а не случайная команда из видеоролика.
Три разных слоя копии
Приложение хранит заказы, инструменты, получателей доступа, наблюдения и outbox. Узел хранит свои ключи и платёжное состояние. Эксплуатационный контур хранит конфигурацию источников, версии и безопасные метаданные резервирования. Все слои нужны для восстановления объяснимого сервиса, но у них разные секретность и согласованность.
Для LND документирован Static Channel Backup. Его назначение связано с восстановлением средств через предусмотренный путь, а не с возобновлением прежнего активного канала из старого состояния. Документация отдельно предупреждает об опасности произвольного возвращения устаревшей channel.db. Первичная инструкция LND по восстановлению.
Поэтому фраза «копия есть» недостаточна. Нужно знать, что именно сохранено, каким механизмом, для какой версии и какие результаты он поддерживает. Копия конфигурации не содержит средства. Запись payment hash не содержит все ключи. Снимок личного прогресса читателя не помогает восстановить канал.
Паспорт без секретов
Для обычного журнала заведём собственный объект. Он сообщает категории артефактов и их актуальность, но не включает seed, пароли, содержимое macaroon или реальные ключи. Такой паспорт можно обсуждать в проектной документации без копирования чувствительных данных.
from dataclasses import dataclass
@dataclass(frozen=True)
class BackupManifest:
environment_id: str
node_profile: str
application_snapshot_id: str
application_schema: str
node_recovery_method: str
node_backup_reference: str
created_at: int
application_cutoff: str
secret_material_present_in_document: bool = False
def review_manifest(manifest, expected_environment):
if manifest.secret_material_present_in_document:
return {'ready': False, 'reason': 'secret-in-manifest'}
if manifest.environment_id != expected_environment:
return {'ready': False, 'reason': 'environment'}
if not manifest.node_profile or not manifest.node_recovery_method:
return {'ready': False, 'reason': 'missing-profile'}
return {'ready': True, 'meaning': 'metadata-ready-not-recovery-proven'}Даже ready в этой функции относится только к полноте учебных метаданных. Она не читает архив, не проверяет его расшифрование и не подтверждает возможность возврата средств. Такие фактические результаты записываются отдельно после разрешённой эксплуатационной проверки. Наличие строкового пути не доказывает существование корректного артефакта.
Архив приложения также должен быть согласованным. Если отдельные таблицы копируются в разные моменты без подходящего механизма, settlement может попасть в журнал, но отсутствовать в таблице прав. После восстановления необходима сверка в пределах известного cutoff. Лучше сохранить договор атомарного снимка, чем надеяться на совпадение времён отдельных файлов.
Не запускать две истории одного узла
Старый экземпляр, который внезапно вернулся после восстановления, не должен продолжать действовать параллельно с новым владельцем того же состояния. План восстановления определяет, где находится действующий экземпляр и кто имеет право управлять секретами. Автоматическое масштабирование как для обычного статического сервера здесь не является универсальным решением.
У приложения могут работать несколько наблюдателей, если хранилище обеспечивает идемпотентность и атомарность. Это не означает возможность свободно клонировать платёжный узел с одинаковыми ключами. Различие между stateless чтением заказов и stateful управлением каналами необходимо записать прямо в операционном договоре.
Восстановление из SCB имеет собственные условия и ограничения, в том числе для незавершённых HTLC. Не обещаем возобновить все pending платежи только потому, что найден channel.backup. После возврата источника отдельно выясняем судьбу инструментов и сохраняем случаи, которые требуют дополнительного разбора. Нет достаточного наблюдения — нет права придумать settlement.
Порядок восстановления сайта
Сначала останавливаем выдачу новых инструментов в затронутом контуре, сохраняя доступ к безопасному статусу старых заказов. Затем устанавливаем выбранный профиль и согласованные копии. Дальше сверяем источник и незавершённые invoice, восстанавливаем журнал решений и outbox. Только после понимания покрытой области возобновляем новые операции по выбранной политике.
Это последовательность проектных действий, а не выполненная процедура. В статье мы не управляем процессами и не импортируем резерв. Для реального сервиса каждый этап получает ответственного, способ подтверждения и предел результата. Например, «узел отвечает» не заменяет «источник обслуживает сохранённые инструменты в нужной сети».
Если база приложения потеряла связь orderId с invoice, не угадываем получателя по совпадающей сумме. Сохраняем неназначенные наблюдения и ищем достоверную связь в разрешённых журналах. Если восстановить её нельзя, это отдельный инцидент. Полученные средства и уверенная выдача персонального доступа не являются одним автоматически восстановленным фактом.
Копии и доступ к материалам
После восстановления уже записанное право на курс должно иметь понятное происхождение. Если старая база сохранила право, но потеряла часть доказательств, требуется сверка и политика инцидента, а не массовое удаление читателей. Если журнал сохранил settlement, а право отсутствует, атомарный идемпотентный обработчик может достроить связь в подтверждённой области.
Публичные статьи по старым URL вообще не зависят от восстановления платёжного узла. Они остаются статическим материалом. Так сбой отдельной учебной платёжной подсистемы не должен закрыть всю библиотеку ProfessorWeb. Персональные функции показывают собственное состояние и ограничение, сохраняя обычный путь чтения.
Ожидаемая передача
Разработчик получает паспорт категорий, версий, cutoff и методов, но не секреты внутри Markdown. Оператор знает, какой результат гарантирует выбранный механизм, а какой ещё нужно наблюдать. Приложение хранит unresolved отдельно от подтверждённых заказов. Восстановление не создаёт новых invoice для всех потерявших статус читателей.
Мы получили карту резервирования, которая связывает средства, назначения и состояние сайта без смешения их гарантий. Следующая глава отделит полномочия этих участников, чтобы обычный запрос статуса никогда не получал административный доступ к платёжному узлу.
Контроль доступности копии
Паспорт должен сообщать, кто имеет право получить артефакт и как обнаруживается его отсутствие. Архив на том же повреждённом носителе не решает отдельную угрозу потери устройства. Политика независимого хранения определяется оператором, а публикация пути в Markdown не переносит секретную копию в надёжное место.