Exportaciones privadas de wallets, un paquete de recuperación verificado fuera del servidor y una lista de restauración.
1. Mantén ambos tipos de copia de seguridad
| Copia de seguridad | Qué protege |
|---|---|
| Exportación de wallets del proyecto | Frases de recuperación, claves y detalles de wallets/direcciones gestionados localmente. |
| Paquete de recuperación de la aplicación | Base de datos, clave de cifrado correspondiente, configuración y archivos de la aplicación. |
Necesitas ambos. Las palabras de recuperación no restauran facturas, usuarios, tiendas, credenciales API ni historial de entregas. Una base de datos sin su clave de cifrado correspondiente no puede desbloquear los secretos cifrados de las wallets.
Las wallets Monero externas y los nodos Lightning necesitan sus propias copias de seguridad específicas del proveedor. Una exportación de Wholly Crypto no respalda los canales Lightning ni las claves de gasto de una wallet externa.
2. Exporta las wallets de cada proyecto
Abre Proyecto → Wallets → Copia de seguridad de todas. Elige texto simple .txt o la copia de seguridad de un solo archivo con búsqueda en HTML con códigos QR. Completa la confirmación de seguridad y guarda el archivo de forma privada.
Comprueba que se incluyen las cadenas esperadas. Abre una exportación HTML solo en un dispositivo de confianza sin conexión. Sus scripts y códigos QR están incluidos en el archivo; no necesita un sitio web. Ocultar un secreto en la página no es cifrarlo.
Conserva los detalles de direcciones de recepción y derivación. Una clave privada principal cubre la dirección principal, no todas las direcciones de factura. Una wallet compatible puede necesitar descubrir direcciones más allá de su rango predeterminado al restaurar una frase. Guías de recuperación por cadena →
3. Crea una copia de seguridad de la aplicación
Para una instalación nativa en VPS, conéctate por SSH como root y ejecuta:
whollycrypto backupLa CLI muestra la ubicación del archivo de recuperación. Copia el directorio completo de copia de seguridad, incluido recovery.tar.gz, recovery.tar.gz.sha256 y backup.json, a almacenamiento protegido fuera de este VPS.
Anota la versión de la aplicación, el esquema y la hora de la copia de seguridad de los metadatos. Conserva también tus notas para reconstruir el servidor: firewall, dominios, versión de PostgreSQL y cualquier configuración personalizada del sistema. Este paquete no es una imagen de disco completa ni conserva todos los ajustes o certificados del sistema operativo.
Las copias locales programadas y las de recuperación de actualizaciones son útiles, pero un VPS averiado o comprometido puede perderlas todas a la vez. Mantén varias copias fechadas fuera del servidor. Para contenedores, sigue la guía de Docker y conserva tanto los datos persistentes como la configuración; estos pasos SSH describen instalaciones nativas.
4. Verifica y protege la copia
En el directorio copiado de copia de seguridad de CLI, comprueba el archivo:
sha256sum --check recovery.tar.gz.sha256Un resultado OK verifica el archivo frente a esa suma de comprobación. No lo cifra, no demuestra su origen ni que una restauración completa funcione. Prueba también la restauración en un entorno aislado.
Las exportaciones de wallets y los archivos locales de recuperación no están cifrados. Cifra el almacenamiento fuera del servidor, guarda la clave de descifrado por separado y limita el acceso. Nunca subas copias sin proteger a una unidad pública, repositorio Git, Telegram ni formulario de soporte.
Actualiza las copias tras cambios importantes de configuración y al añadir wallets. Elige una frecuencia según la cantidad de datos recientes de facturas que puedas permitirte perder.
5. Restaura en un entorno aislado
No existe una restauración general con un solo comando. Pide a un administrador de servidores que siga esta lista si no te sientes cómodo restaurando PostgreSQL y servicios del sistema.
- Conserva el servidor y la base de datos actuales. Confirma la marca de tiempo, la suma de comprobación y las versiones de aplicación/esquema de la copia. Detén la instancia original antes de que cualquier copia restaurada se active.
- Prepara un servidor o entorno de recuperación separado. Mantén bloqueados el tráfico público, los procesos en segundo plano y el tráfico saliente financiero/de callbacks para que la copia no pueda enviar fondos, negociar ni reenviar notificaciones.
- Restaura el volcado en una base de datos nueva y vacía. Usa sus archivos de aplicación, configuración y clave de cifrado original de wallets correspondientes. Nunca generes una clave de reemplazo ni ejecutes un binario antiguo contra un esquema más reciente.
- Recrea el rol/permisos de la base de datos y la configuración necesaria de servicios, Nginx y HTTPS. Mantén los secretos accesibles solo para root. Revisa las notas de recuperación de la versión instalada y la documentación de restauración de PostgreSQL ↗.
- Compara las wallets, los índices de direcciones, las facturas y las integraciones. Concilia los pagos, las transmisiones y las órdenes de exchange posteriores a la copia antes de permitir la automatización. Conserva ambas bases de datos hasta terminar la conciliación.
Las copias antiguas pueden no incluir direcciones de factura y registros de pagos recientes. Restaurar una base de datos no revierte la actividad blockchain.
6. Comprueba antes de reabrir
En la instalación nativa restaurada, ejecuta estas comprobaciones de diagnóstico. No envían fondos:
whollycrypto status
whollycrypto doctorVerifica el acceso a la consola, el estado de escáneres, las direcciones de wallets, las facturas recientes, el historial de callbacks y los envíos pendientes. Revisa las reglas de envío de fondos y exchanges antes de reactivar los procesos y el acceso externo. Mantén solo una instancia activa usando estas wallets y el estado restaurado de la base de datos.
Crea una nueva copia fuera del servidor tras verificar la restauración. Cambia el tráfico de clientes solo cuando terminen las comprobaciones y la conciliación.
¿Es lo mismo que whollycrypto recover?
No. whollycrypto recover gestiona una actualización interrumpida cuando el esquema no ha cambiado o reanuda los temporizadores cuando la actualización no había empezado a reemplazar archivos. No es una restauración general de bases de datos. Tras un fallo con cambio de esquema, conserva el diario de recuperación y pide asistencia al operador; no fuerces una vuelta a una versión anterior.