Зроби резервну копію до потреби у відновленні.

1. Зберігай обидва види резервних копій

Потрібні обидва види. Слова відновлення не відновлюють рахунки, користувачів, магазини, облікові дані API чи історію доставлення. База даних без відповідного ключа шифрування не може розблокувати зашифровані секрети гаманців.

Зовнішні гаманці Monero та вузли Lightning потребують власних резервних копій відповідно до вимог провайдера. Експорт Wholly Crypto не створює резервної копії каналів Lightning або ключів витрачання зовнішнього гаманця.

2. Експортуй гаманці кожного проєкту

Відкрий Проєкт → Гаманці → Резервна копія всіх. Вибери звичайний .txt або доступну для пошуку однофайлову резервну копію HTML з QR-кодами. Пройди підтвердження безпеки та збережи файл приватно.

Перевір, що всі очікувані мережі включено. Відкривай HTML-експорт лише на довіреному пристрої без підключення до мережі. Скрипти та QR-коди містяться у файлі; вебсайт йому не потрібен. Приховування секрету на сторінці - не шифрування.

Зберігай відомості про адреси отримання та деривацію. Основний приватний ключ охоплює основну адресу, а не кожну адресу рахунку. Під час відновлення за фразою сумісному гаманцю може знадобитися пошук адрес поза його стандартним діапазоном. Посібники з відновлення для окремих мереж →

3. Створи резервну копію застосунку

Для нативної інсталяції на VPS підключися через SSH як root і виконай:

whollycrypto backup

CLI виводить розташування архіву відновлення. Скопіюй увесь каталог резервної копії, зокрема recovery.tar.gz, recovery.tar.gz.sha256 і backup.json, у захищене сховище поза цим VPS.

Запиши з метаданих версію застосунку, схему та час резервного копіювання. Також зберігай нотатки для відбудови сервера: брандмауер, домени, версію PostgreSQL і будь-які власні налаштування системи. Цей комплект не є повним образом диска й не зберігає всі налаштування ОС чи сертифікати.

Заплановані локальні резервні копії та копії для відновлення після оновлення корисні, але збій або компрометація VPS може призвести до втрати їх усіх разом. Зберігай кілька датованих копій поза сервером. Для контейнерів дотримуйся Посібник Docker та зберігай і постійні дані, і конфігурацію; ці кроки через SSH описують нативні інсталяції.

4. Перевір і захисти копію

У скопійованому каталозі резервної копії CLI перевір архів:

sha256sum --check recovery.tar.gz.sha256

Результат OK підтверджує відповідність файлу цій контрольній сумі. Він не шифрує файл, не доводить його походження та не підтверджує працездатність повного відновлення. Також протестуй відновлення в ізольованому середовищі.

Оновлюй резервні копії після важливих змін конфігурації та додавання гаманців. Вибирай розклад з огляду на те, скільки нещодавніх даних рахунків ти можеш дозволити собі втратити.

5. Віднови в ізольованому середовищі

Універсального відновлення однією командою немає. Якщо ти не впевнено відновлюєш PostgreSQL і системні служби, попроси адміністратора сервера виконати цей контрольний список.

1. Збережи поточні сервер і базу даних. Підтвердь час резервної копії, контрольну суму та версії застосунку/схеми. Зупини початковий екземпляр, перш ніж будь-яка відновлена копія стане активною.
2. Підготуй окремий сервер або середовище відновлення. Заблокуй публічний трафік, фонові воркери та вихідні фінансові запити й callbacks, щоб копія не могла надсилати кошти, торгувати або повторно надсилати сповіщення.
3. Віднови дамп у нову порожню базу даних. Використовуй відповідні їй файли застосунку, конфігурацію та оригінальний ключ шифрування гаманців. Ніколи не створюй ключ на заміну й не запускай старіший бінарний файл із новішою схемою.
4. Відтвори роль/дозволи бази даних і потрібну конфігурацію служб, Nginx та HTTPS. Надавай доступ до секретів лише root. Переглянь примітки щодо відновлення встановленого випуску та документацію з відновлення PostgreSQL ↗.
5. Порівняй гаманці, індекси адрес, рахунки та інтеграції. Перш ніж дозволяти автоматизацію, звір платежі, трансляції транзакцій та біржові ордери, що з’явилися після резервної копії. Зберігай обидві бази даних до завершення звіряння.

У старих резервних копіях можуть бути відсутні нещодавно видані адреси рахунків і записи платежів. Відновлення бази даних не відкочує активність у блокчейні.

6. Перевір усе перед відновленням доступу

У відновленій нативній інсталяції виконай ці діагностичні перевірки. Вони не надсилають кошти:

whollycrypto status
whollycrypto doctor

Перевір доступ до панелі, стан сканерів, адреси гаманців, нещодавні рахунки, історію callbacks та незавершені надсилання. Переглянь правила sweep і бірж перед повторним увімкненням воркерів та зовнішнього доступу. Залиш лише один активний екземпляр що використовує ці гаманці та відновлений стан бази даних.

Після перевірки відновлення створи свіжу резервну копію поза сервером. Перемикай клієнтський трафік лише після завершення перевірок і звіряння.