Резервная копия Bitcoin-кошелька
Наличие узла и детерминированного кошелька не отменяет резервную копию. Библиотеке нужны секреты подписи, политика адресов, история выдачи и данные заказов. В уроке составим опись резервирования, где каждому виду данных соответствует собственный способ восстановления.
Мы не создаём резервные файлы кошелька и не проверяем их загрузку. Здесь готовится процедура и критерии для будущего отдельного локального исполнения. Приведённые команды являются инструкциями читателю, а не отчётом о проведённой работе.
Что требуется расходованию
Секретный материал или доступ к независимым подписантам обеспечивает возможность разрешить расходование. Если он потерян, публичная история сама не вернёт подпись. Политика нескольких участников помогает только при сохранении достаточного набора необходимых секретов и возможности выполнить процедуру.
Кошельковая копия может содержать не только один ключ, но и сведения о деривации, дескрипторы и внутреннюю историю. Её точное содержимое зависит от инструмента и версии. Поэтому нельзя заменять официальную процедуру случайным копированием файла во время записи, не понимая требований согласованности.
В Core существует метод backupwallet. В будущей лаборатории оператор указывает явный кошелёк и путь назначения. Сам вызов не гарантирует, что полученная копия потом будет доступна, защищена и совместима с выбранным восстановительным процессом. Резервирование включает последующую опись и хранение.
Публичная политика
Отдельно сохраняем полные дескрипторы, происхождение ключей, сеть, типы адресов и диапазоны. Если при аварии доступны секреты, но отсутствует скриптовая политика, восстановление может быть сложнее или неполным. Для Taproot и multisig это особенно заметно.
Публичные дескрипторы не дают обычного права расходования без секретов, однако раскрывают историю и будущие назначения. Поэтому они также требуют контролируемого хранения. Не помещаем действительную наблюдающую конфигурацию в общедоступный репозиторий под предлогом, что это «только открытые ключи».
Информация получения и сдачи сохраняется вместе. При наличии исторических профилей включаем их в опись. Новый активный дескриптор не позволяет автоматически найти все прежние выходы, сформированные другим способом.
Данные приложения
Блокчейн не хранит invoiceId нашего сайта. После восстановления кошелька библиотека может видеть поступления, но не знать, какой доступ выдан по каждому из них. Поэтому резервная копия базы счетов и журнала решений обязательна для восстановления коммерческого смысла.
Сохраняем адрес назначения, сумму предложения, время создания, срок, версию политики, наблюдаемые outpoint и действие выдачи. Личные данные защищаются по прикладной модели. Для досье полезно разделить техническую сверку и сведения, нужные только поддержке.
| Архив | Что восстанавливает | Что не восстанавливает |
|---|---|---|
| Секреты/подписанты | Полномочие расходования | Связь со счётом |
| Дескрипторы | Условия поиска и структуры | Потерянную подпись |
| База счетов | Назначение и решения | Сетевую историю автоматически |
| Блоки/источник | Проверяемые наблюдения | Коммерческий договор |
Эта таблица объясняет, почему копия одного каталога не является полным резервом сайта. Для существующей учебной библиотеки также архивируются сами выпуски материалов; деньги и контент восстанавливаются разными процедурами.
Согласованность снимка
Допустим, база счетов сохранена до выдачи адреса индекса 2499, а кошелёк — после. При восстановлении назначение существует, но его связь с заказом отсутствует. Обратная ситуация может дать счёт с адресом вне сохранённого состояния выдачи или диапазона наблюдения.
Нужна понятная граница снимка и журнал изменений после неё. Иногда удобен согласованный остановленный этап, иногда — транзакционный журнал и регулярное архивирование. Конкретный способ зависит от инфраструктуры, но досье должно объяснять, какие последовательности действий остаются восстановимыми.
Особенно важно не повторить выдачу уже использованного индекса после восстановления. Система сверяет максимальную сохранённую выдачу и восстановленную политику, затем продолжает с согласованного следующего значения. «Пустой адрес» не доказывает, что его никогда не показывали человеку.
Хранение копий
Копия рядом с основным файлом защищает только от части ошибок. Отказ устройства или компрометация каталога может затронуть обе. Для полезного резерва требуется независимое место и контролируемое право чтения. Платный или внешний поставщик не гарантирует это автоматически.
Секретная копия шифруется выбранным проверенным способом, а ключ расшифрования не хранится только на том же устройстве. При этом забытый ключ шифрования тоже лишит возможности восстановления. Нужно определить ответственных и доступный аварийный путь.
Публичная опись может фиксировать наличие копии, дату, профиль и контрольную сумму, не раскрывая содержимое. Проверка суммы показывает неизменность сохранённого файла относительно известного значения, но не доказывает достаточность его данных для расходования.
Критерии восстановления
Для будущего локального разбора зададим известные контрольные назначения и выходы. После загрузки копии инструмент должен обнаружить их при достаточной истории, а подписант — подготовить разрешённое действие. Затем приложение должно сопоставить поступления и не повторить уже выполненную выдачу.
Мы пока не выполняли эти операции. Поэтому статус досье — подготовленная процедура, а не «резервная копия проверена». Различие важно: файл может выглядеть исправным и всё же не содержать необходимую часть политики.
Человеческая доступность процедуры
Опись должна быть понятна оператору, который не создавал исходный кошелёк. В ней названы ответственные, порядок получения ключей расшифрования и причины, по которым некоторые данные нельзя копировать в обычный рабочий каталог. Если восстановление зависит от памяти одного человека, независимая копия файла остаётся неполной организационной защитой. Для совместной политики нужны доступные контакты и правила замены ролей, но секреты не помещаются в общую инструкцию. Так документ остаётся полезным при аварии, сохраняя необходимое разделение полномочий.
При передаче резервов составим отдельный список ожидаемых результатов: доступ к копии, чтение её формата, восстановление наблюдения и сопоставление счёта. Отметка об одном пункте не закрывает остальные. Если оператор получил зашифрованный файл, но аварийный путь к ключу недоступен, в описи остаётся незавершённое восстановление, а не успешная передача.
Официальные методы описаны в backupwallet и restorewallet. Результат урока — опись данных, независимых копий и критериев. Следующая страница соединит их в сценарий восстановления библиотеки после потери наблюдающей среды.