Por qué las copias de seguridad nativas de cPanel no bastan en producción
WHM incorpora un sistema de copias de seguridad básico que copia cada cuenta en forma de archivo comprimido. Funciona para una restauración de emergencia completa, pero le falta todo lo que un servidor de producción exige a diario: restauración parcial (un solo archivo, una sola tabla, un solo buzón de correo), almacenamiento fuera del servidor automatizado, visibilidad para el cliente sin intervención del administrador y retención configurable por tipo de copia. En un servidor que aloja decenas de cuentas de clientes, esas carencias son riesgos reales: restaurar el archivo completo de una cuenta de 20 GB para recuperar un solo archivo de configuración es lento y arriesgado a la vez. JetBackup se diseñó para cubrir precisamente esas diferencias.
Lo que JetBackup añade por encima de cPanel/WHM
- Copias de seguridad granulares: cada cuenta se guarda de forma independiente; la restauración apunta a un archivo, un directorio, una base de datos o un buzón de correo sin tocar el resto.
- Restauración en autoservicio: cada usuario de cPanel encuentra sus propias copias de seguridad en su interfaz, sin abrir un ticket — el soporte de primer nivel desaparece para este caso.
- Destinos múltiples simultáneos: local, SFTP/SSH, compatible con S3 (AWS, Wasabi, Backblaze B2), FTP — cada trabajo puede enviar hacia varios destinos en paralelo.
- Copias de seguridad incrementales: solo se transfieren las diferencias entre dos pasadas, lo que reduce el ancho de banda y el tiempo de ejecución entre un 60 y un 90 % tras la primera pasada completa.
- Programación avanzada: diaria, semanal, mensual, con reglas de retención distintas por destino y por tipo.
- Panel de control WHM centralizado: el administrador ve el estado de cada trabajo, los últimos resultados y las cuotas consumidas sin salir de WHM.
- Restauración de prueba sin impacto: JetBackup puede restaurar en un directorio temporal para validar la integridad sin sobrescribir la producción.
- Transferencia de cuenta asistida: migración de una cuenta de un servidor a otro a partir de una copia de seguridad JetBackup, sin acceso SSH directo al servidor de origen.
Requisitos previos antes de la instalación
JetBackup requiere acceso root a WHM en un servidor cPanel con AlmaLinux 8/9 o CloudLinux 8/9 (las versiones anteriores CentOS 7 ya no reciben actualizaciones de JetBackup 5). Se recomienda un espacio en disco de al menos el doble del tamaño de los datos que se van a guardar para el destino local — menos si solo conserva los destinos remotos. La licencia JetBackup se vende por IP de servidor y se activa a través del portal JetApps; es distinta de la licencia cPanel/WHM.
Instalar JetBackup desde WHM
Comprobar la versión de cPanel/WHM
Conéctese a WHM, vaya a Server Information y anote la versión de cPanel. JetBackup 5 exige cPanel 110 o superior. Si la versión es anterior, lance primero la actualización de cPanel desde Upgrade to Latest Version.
Lanzar el script de instalación de JetApps
Por SSH como root, ejecute el script oficial de JetApps:
curl -fsSL https://repo.jetlicense.com/centOS/jetapps-installer.sh | bash. Este script instala el gestor de paquetes JetApps, que sirve para instalar y actualizar todos los productos Jet.Instalar el paquete JetBackup
Una vez JetApps en su sitio:
jetapps --install jetbackup5-cpanel. El instalador configura las dependencias, registra el plugin en WHM y arranca el serviciojetbackupd. La duración varía entre 2 y 5 minutos según la conexión.Registrar la licencia
En WHM, vaya a JetBackup 5 → Dashboard. Si la licencia no se detecta automáticamente, introduzca la clave facilitada por JetApps o indique la IP del servidor en su área de cliente de JetApps. La verificación es instantánea; sin licencia válida, los trabajos permanecen inactivos.
Configurar el primer destino de copia de seguridad
En JetBackup 5 → Backup Destinations, haga clic en Add Destination. Para empezar, elija Local y apunte a un directorio dedicado (por ejemplo
/backup/jetbackup), distinto del directorio predeterminado de WHM. Active la opción Test Connection para comprobar que el servicio puede escribir en ese directorio.Crear el primer trabajo de copia de seguridad
En JetBackup 5 → Backup Jobs, haga clic en Create New Job. Seleccione el tipo Accounts (para guardar cuentas cPanel completas), elija el destino configurado en el paso anterior, ajuste la programación (por ejemplo: diaria a las 02:00) y defina la retención (7 copias diarias). Guarde. El primer trabajo saldrá a la hora programada, o puede lanzarlo manualmente con Run Now para comprobar que funciona correctamente.
Configurar los destinos de copia de seguridad
JetBackup admite varios tipos de destino. La elección depende de su tolerancia a los fallos, de su presupuesto y del ancho de banda disponible.
Comparativa de los destinos JetBackup
Desplace la tabla
| Destino | Ventajas | Puntos a vigilar |
|---|---|---|
| Local (mismo servidor) | Restauración rápida, ningún coste de red | Datos perdidos si cae el disco o el servidor — no usarlo nunca en solitario en producción |
| SFTP/SSH | Cifrado por defecto, compatible con cualquier servidor Linux, autenticación por clave | Caudal limitado por la conexión SSH; configure una clave dedicada sin acceso completo a shell |
| Compatible con S3 (AWS, Wasabi, Backblaze B2) | Almacenamiento de objetos fuera del servidor, retención precisa, coste previsible | Requiere un bucket y credenciales IAM con los permisos `s3:PutObject`, `s3:GetObject`, `s3:ListBucket` |
| FTP | Sencillo de implantar en NAS o en alojamientos compartidos antiguos | Sin cifrado por defecto (se recomienda FTPS); evítelo si el servidor FTP está en la misma red física |
Programación y retención
JetBackup distingue tres frecuencias de trabajo: Daily (diaria), Weekly (semanal) y Monthly (mensual). La buena práctica es apilar las tres: un trabajo diario hacia el destino local (retención de 7 días), un trabajo semanal hacia S3 (retención de 4 semanas) y un trabajo mensual hacia un destino de archivado a largo plazo (retención de 12 meses). Esta pila cubre a la vez los errores detectados rápidamente (un archivo borrado ayer) y las corrupciones silenciosas descubiertas semanas más tarde. Las retenciones son independientes por trabajo y por destino — un trabajo mensual en S3 puede conservar 12 copias mientras que el trabajo diario local solo guarda 3, según el espacio disponible. JetBackup aplica las reglas de retención automáticamente al final de cada trabajo correcto: las copias que superan el límite se eliminan, nunca en desorden (siempre es la más antigua la que sale primero).
Endurezca su configuración desde el principio
Para el destino SFTP, cree un usuario de sistema dedicado con un directorio restringido (chroot) y una clave SSH sin contraseña — no reutilice nunca las credenciales de root. Para S3, cree una política IAM mínima: s3:PutObject, s3:GetObject, s3:DeleteObject y s3:ListBucket sobre el único bucket de copias de seguridad. Por último, programe una prueba de restauración mensual: elija una cuenta de prueba, restaure una copia de hace una semana en un directorio temporal y compruebe la integridad de los archivos. Una copia de seguridad no probada es una promesa, no una garantía.
Restauración: cuentas, bases de datos y correos por separado
Aquí es donde JetBackup se distingue con más claridad de la copia de seguridad nativa de WHM. En JetBackup 5 → Restore, elige el tipo de objeto que quiere restaurar: Account (cuenta completa), Home Directory (solo los archivos), Database (una base MySQL aislada), Email (un buzón de correo o un solo mensaje), Cron Jobs, DNS Zone o SSL Certificate. Cada restauración puede hacerse hacia la ubicación de origen (sobrescribe lo existente) o hacia un directorio temporal para inspeccionarla antes. Del lado del cliente, la interfaz cPanel muestra un submenú JetBackup con exactamente las mismas opciones, restringidas a los datos de la cuenta: un usuario puede recuperar un archivo borrado a las 14:00 sin llamar al soporte, lo que convierte una interacción de ticket en autonomía del cliente.
Solución de problemas: errores habituales
Estos son los errores más frecuentes que aparecen al poner JetBackup en producción, con su causa y su remedio.
Errores y soluciones
- Espacio en disco insuficiente al arrancar el trabajo: JetBackup comprueba el espacio libre antes de empezar. Si el destino local está lleno, el trabajo se cancela con el mensaje
Not enough disk space. Amplíe el espacio o reduzca la retención (menos copias). La opción Disk Usage Limit en los parámetros del destino permite bloquear JetBackup antes de alcanzar el 100 % del disco. - Destino SFTP rechazado (Permission denied): compruebe que la clave pública esté en
~/.ssh/authorized_keysdel usuario SFTP en el servidor de destino, que los permisos del directorio de destino sean 700 y que el serviciosshdacepte la autenticación por clave (PubkeyAuthentication yesensshd_config). Utilice el botón Test Connection de JetBackup para diagnosticar sin lanzar un trabajo completo. - Destino S3: error 403 Forbidden: la causa es casi siempre una política IAM demasiado restrictiva o un nombre de bucket incorrecto. Compruebe que la clave IAM tenga los permisos
s3:PutObjectys3:ListBucketsobrearn:aws:s3:::nom-du-bucket/*. Para Backblaze B2 o Wasabi, asegúrese de que elendpointdel destino esté bien configurado (los endpoints compatibles con S3 varían según el proveedor y la región). - Restauración bloqueada (trabajo en estado Pending indefinidamente): puede que el servicio
jetbackupdesté parado o saturado. Compruebe su estado consystemctl status jetbackupdy, si hace falta, reinícielo consystemctl restart jetbackupd. Un trabajo anterior que no haya terminado correctamente también puede bloquear la cola — cancélelo manualmente en el panel de control de JetBackup. - Copias de seguridad ausentes tras una migración de servidor: JetBackup almacena los metadatos de las copias en una base local (
/usr/local/jetapps/var/lib/jetbackup5/). Tras una migración, esos metadatos no se trasladan automáticamente. Utilice la función Import Backups para reindexar los archivos existentes desde los destinos configurados.
JetBackup en el ecosistema cPanel/WHM
JetBackup se integra de forma natural con las demás herramientas del ecosistema cPanel. En un servidor CloudLinux, el aislamiento LVE garantiza que un trabajo de copia de seguridad intensivo no penalice a las demás cuentas. Imunify360 (del mismo editor, CloudLinux) detecta los archivos maliciosos antes de guardarlos — útil para no archivar una infección. Las cuentas WHM disfrutan de las mismas copias de seguridad granulares que las cuentas cPanel: un revendedor puede restaurar sus propias configuraciones DNS, certificados SSL y trabajos cron con independencia de sus clientes. Por último, la función de transferencia de cuenta asistida de JetBackup simplifica las migraciones entre servidores cPanel: en lugar de depender de la Transfer Tool nativa de WHM (que copia en directo, sin pasar por un archivo preexistente), JetBackup restaura a partir de una copia de seguridad almacenada fuera del servidor — lo que reduce el riesgo de interrupción y deja intacto el servidor antiguo hasta la validación.
