Sauvegarde avant d'avoir besoin de récupérer.

1. Garde les deux types de sauvegarde

Il te faut les deux. Les mots de récupération ne restaurent pas les factures, utilisateurs, magasins, identifiants API ni l'historique de livraison. Une base de données sans sa clé de chiffrement correspondante ne peut pas déverrouiller les secrets chiffrés des portefeuilles.

Les portefeuilles Monero externes et nœuds Lightning exigent leurs propres sauvegardes spécifiques au fournisseur. Un export Wholly Crypto ne sauvegarde pas les canaux Lightning ni les clés de dépense d'un portefeuille externe.

2. Exporte les portefeuilles de chaque projet

Ouvre Projet → Portefeuilles → Tout sauvegarder. Choisis le texte brut .txt ou le fichier unique avec recherche de sauvegarde HTML avec QR codes. Termine la confirmation de sécurité et enregistre le fichier en privé.

Vérifie que les blockchains attendues sont incluses. Ouvre un export HTML uniquement sur un appareil hors ligne fiable. Ses scripts et QR codes sont contenus dans le fichier ; il n'a pas besoin d'un site. Masquer un secret dans la page n'est pas du chiffrement.

Garde les détails d'adresses de réception et de dérivation. Une clé privée principale couvre l'adresse principale, pas chaque adresse de facture. Un portefeuille compatible peut nécessiter la découverte d'adresses au-delà de sa plage par défaut lors de la restauration d'une phrase. Guides de récupération par blockchain →

3. Crée une sauvegarde de l'application

Pour une installation VPS native, connecte-toi par SSH en root et exécute :

whollycrypto backup

La CLI affiche l'emplacement de l'archive de récupération. Copie tout le répertoire de sauvegarde, y compris recovery.tar.gz, recovery.tar.gz.sha256 et backup.json, vers un stockage protégé hors de ce VPS.

Note la version de l'application, le schéma et l'heure de sauvegarde depuis les métadonnées. Garde aussi tes notes de reconstruction du serveur : pare-feu, domaines, version de PostgreSQL et toute configuration système personnalisée. Ce paquet n'est pas une image disque complète et ne conserve pas chaque réglage du système ni certificat.

Les sauvegardes locales programmées et copies de récupération des mises à jour sont utiles, mais un VPS défaillant ou compromis peut toutes les perdre ensemble. Garde plusieurs copies datées hors serveur. Pour les conteneurs, suis le guide Docker et conserve les données persistantes ainsi que la configuration ; ces étapes SSH décrivent les installations natives.

4. Vérifie et protège la copie

Dans le répertoire copié de sauvegarde CLI, vérifie l'archive :

sha256sum --check recovery.tar.gz.sha256

Un résultat OK vérifie le fichier par rapport à cette somme de contrôle. Il ne le chiffre pas, ne prouve pas son origine ni qu'une restauration complète fonctionne. Teste aussi la restauration dans un environnement isolé.

Actualise les sauvegardes après d'importantes modifications de configuration et ajouts de portefeuilles. Choisis une fréquence selon la quantité de données récentes de factures que tu pourrais te permettre de perdre.

5. Restaure dans un environnement isolé

Il n'existe pas de restauration générale en une commande. Demande à un administrateur serveur d'effectuer cette liste de contrôle si tu n'es pas à l'aise pour restaurer PostgreSQL et les services système.

1. Conserve le serveur et la base de données actuels. Confirme l'horodatage de sauvegarde, la somme de contrôle et les versions de l'application/schéma. Arrête l'instance d'origine avant qu'une copie restaurée devienne active.
2. Prépare un serveur ou environnement de récupération distinct. Garde bloqués le trafic public, les workers en arrière-plan et le trafic financier/callback sortant pour que la copie ne puisse pas envoyer de fonds, négocier ou renvoyer des notifications.
3. Restaure le dump dans une base de données nouvelle et vide. Utilise les fichiers d'application correspondants, la configuration et la clé de chiffrement originale des portefeuilles. Ne génère jamais de clé de remplacement et n'exécute jamais un ancien binaire sur un schéma plus récent.
4. Recrée le rôle/les droits de base de données et les configurations nécessaires de service, Nginx et HTTPS. Garde les secrets accessibles uniquement à root. Consulte les notes de récupération de la version installée et la documentation de restauration PostgreSQL ↗.
5. Compare les portefeuilles, index d'adresses, factures et intégrations. Rapproche les paiements, diffusions et ordres d'exchange postérieurs à la sauvegarde avant d'autoriser l'automatisation. Garde les deux bases jusqu'à la fin du rapprochement.

Les anciennes sauvegardes peuvent manquer les adresses de factures récemment émises et les enregistrements de paiement. Restaurer une base de données n'annule pas l'activité blockchain.

6. Vérifie avant de rouvrir

Sur l'installation native restaurée, exécute ces contrôles de diagnostic. Ils n'envoient pas de fonds :

whollycrypto status
whollycrypto doctor

Vérifie l'accès console, le statut des scanners, les adresses de portefeuilles, les factures récentes, l'historique des callbacks et les envois en attente. Vérifie les règles de sweep et d'exchange avant de réactiver les workers et l'accès externe. Garde uniquement une instance active utilisant ces portefeuilles et l'état restauré de la base de données.

Crée une nouvelle sauvegarde hors serveur après vérification de la restauration. Bascule le trafic client uniquement lorsque les contrôles et le rapprochement sont terminés.