Back up before you need to recover.

1. Keep both kinds of backup

You need both. Recovery words do not restore invoices, users, stores, API credentials or delivery history. A database without its matching encryption key cannot unlock encrypted wallet secrets.

External Monero wallets and Lightning nodes need their own provider-specific backups. A Wholly Crypto export does not back up Lightning channels or an external wallet’s spending keys.

2. Export each project’s wallets

Open Project → Wallets → Backup all. Choose plain .txt or the searchable, single-file HTML backup with QR codes. Complete the security confirmation and save the file privately.

Check that the expected chains are included. Open an HTML export only on a trusted offline device. Its scripts and QR codes are contained in the file; it does not need a website. Hiding a secret in the page is not encryption.

Keep receiving-address and derivation details. A primary private key covers the primary address, not every invoice address. A compatible wallet may need address discovery beyond its default range when restoring a phrase. Chain-specific recovery guides →

3. Create an application backup

For a native VPS installation, connect over SSH as root and run:

whollycrypto backup

The CLI prints the recovery archive’s location. Copy the whole backup directory, including recovery.tar.gz, recovery.tar.gz.sha256 and backup.json, to protected storage outside this VPS.

Record the application version, schema and backup time from the metadata. Keep your server rebuild notes too: firewall, domains, PostgreSQL version and any custom system configuration. This bundle is not a full disk image and does not preserve every OS setting or certificate.

Scheduled local backups and update recovery copies are useful, but a failed or compromised VPS can lose all of them together. Keep several dated off-server copies. For containers, follow the Docker guide and preserve both persistent data and configuration; these SSH steps describe native installs.

4. Verify and protect the copy

In the copied CLI backup directory, check the archive:

sha256sum --check recovery.tar.gz.sha256

An OK result verifies the file against that checksum. It does not encrypt it, prove its origin or prove a full restore works. Test restoration in an isolated environment too.

Refresh backups after important configuration changes and wallet additions. Choose a schedule based on how much recent invoice data you could afford to lose.

5. Restore into an isolated environment

There is no general one-command restore. Ask a server administrator to carry out this checklist if you are not comfortable restoring PostgreSQL and system services.

1. Preserve the current server and database. Confirm the backup timestamp, checksum and application/schema versions. Stop the original instance before any restored copy becomes active.
2. Prepare a separate server or recovery environment. Keep public traffic, background workers and outbound financial/callback traffic blocked so the copy cannot send funds, trade or resend notifications.
3. Restore the dump into a new, empty database. Use its matching application files, configuration and original wallet encryption key. Never generate a replacement key or run an older binary against a newer schema.
4. Recreate the database role/permissions and required service, Nginx and HTTPS configuration. Keep secrets root-only. Review the installed release’s recovery notes and PostgreSQL restore documentation ↗.
5. Compare wallets, address indexes, invoices and integrations. Reconcile payments, broadcasts and exchange orders after the backup before allowing automation. Keep both databases until reconciliation finishes.

Old backups can miss recently issued invoice addresses and payment records. Blockchain activity is not rolled back by restoring a database.

6. Check before reopening

On the restored native installation, run these diagnostic checks. They do not send funds:

whollycrypto status
whollycrypto doctor

Verify console access, scanner status, wallet addresses, recent invoices, callback history and pending sends. Review sweep and exchange rules before re-enabling workers and external access. Keep only one active instance using these wallets and the restored database state.

Make a fresh off-server backup after the restore is verified. Switch customer traffic only when the checks and reconciliation are complete.