Un backup que de verdad usas
La mayoría de las empresas descubre que su backup no funciona solo cuando llega el desastre. Por eso aconsejamos tratar el backup como un proceso, no como una casilla que marcar: copias automáticas, guardadas lejos del servidor de producción y restauraciones probadas con regularidad. En cPanel el backup diario se ejecuta automáticamente y lo restauras desde el panel; en VPS y servidores dedicados, el equipo de DevOps puede configurar pruebas de restauración programadas con tus horas incluidas.
Qué backup incluye cada plan
El hosting cPanel tiene un backup diario automático que restauras desde el panel. Un VPS tiene snapshots, copias completas del estado del servidor, sin frecuencia garantizada. Los servidores dedicados no incluyen backup por defecto: los discos NVMe vienen por pares y el RAID se configura en la instalación, pero el RAID no es un backup. El backup externo, el PITR para bases de datos y las pruebas de restauración los configura nuestro equipo con las horas de DevOps incluidas (5–10 h/mes en dedicados).
| Plan | Backup | Restauración | Ubicación |
|---|---|---|---|
| Hosting cPanel | Backup diario automático | Desde el panel de cliente | UE (Fráncfort) |
| VPS | Snapshots, sin frecuencia garantizada | Desde un snapshot | UE (Fráncfort) |
| VPS: backup externo | Bajo petición, con horas de DevOps | Según la estrategia configurada | Acordada con el equipo |
| Servidor dedicado | No incluido por defecto: se configura bajo petición | Según la estrategia (3-2-1, PITR) | UE (Fráncfort) + almacenamiento externo bajo petición |
RPO y RTO: las cifras que debes fijar tú
En lugar de «backup cuanto antes», conviene fijar dos valores concretos. El RPO (Recovery Point Objective) indica cuántos datos puedes permitirte perder. El RTO (Recovery Time Objective) indica cuánto puede tardar una restauración. El equipo construye la estrategia en torno a estos valores.
La pérdida máxima de datos que puedes aceptar. Un backup diario supone perder hasta un día; con streaming de WAL una base de datos baja de un minuto, configurado bajo petición.
El tiempo de restauración depende del volumen de datos y de la estrategia elegida. No garantizamos un RTO: la única cifra fiable es la medida en una prueba de restauración.
Escenarios de desastre y cómo protegerte
Los desastres son raros pero de gran impacto. Estos son los escenarios más habituales y la protección que recomendamos para cada uno. En VPS y servidores dedicados, el equipo configura estas medidas con las horas de DevOps incluidas.
Fallo de hardware (disco, RAM)
La causa más común de pérdida de datos. Los servidores dedicados tienen discos NVMe por pares con RAID configurado en la instalación, además de RAM ECC en los niveles EPYC y Xeon. El RAID mantiene el servidor en marcha cuando falla un disco, pero no sustituye al backup: sigue haciendo falta una copia externa.
Protección: RAID + backup externoRansomware o cuenta comprometida
El atacante cifra los archivos del servidor y cualquier copia a la que el servidor tenga acceso. Por eso al menos una copia debe estar fuera del servidor, donde la cuenta de producción no pueda modificarla (inmutable o sin conexión). La configuramos bajo petición, con las horas de DevOps.
Protección: copia aisladaBorrado accidental de datos
Un “DROP TABLE users” ejecutado en producción. El error humano más común. Si la base de datos tiene recuperación a un punto en el tiempo (PITR) configurada, vuelves a justo antes del fallo; un backup diario solo te lleva hasta la última copia.
Protección: PITR bajo peticiónCaída completa del centro de datos
Incendio, inundación, caída prolongada del operador. La protección es una copia en otra ubicación, como un segundo centro de datos. La replicación y el failover no se incluyen por defecto; el equipo los configura bajo petición, con las horas de DevOps.
Protección: copia en otra ubicaciónUn error de la aplicación corrompe los datos
Un despliegue introduce un error que corrompe registros de la base de datos. Con un backup de base de datos independiente restauras solo la base de datos (no todo el servidor): los archivos de la aplicación se quedan y los datos retroceden.
Protección: backup de base de datos independienteMigración a otro servidor
El plan actual se te queda pequeño. Un VPS sube a un nivel superior con más vCPU, RAM y disco; para pasar a otro servidor planificamos la migración con antelación para que la interrupción sea breve.
Consejo: planifica la migración con tiempoBackup de bases de datos: estrategias por motor
Un backup completo del VPS no siempre basta. Las bases de datos tienen sus propios mecanismos de recuperación a un punto en el tiempo (PITR): permiten volver exactamente al momento elegido, no solo al último snapshot. Los configuramos bajo petición, con las horas de DevOps incluidas.
Qué está incluido y qué se configura bajo petición
No existe un “backup premium” que se venda por separado: lo que está incluido se indica en cada plan, y todo lo que vaya más allá lo construye el equipo con las horas de DevOps de tu suscripción. Las horas que superen la cuota se facturan aparte, por horas.
- cPanel: backup diario automático, restauración desde el panel (incluido)
- VPS: snapshots, sin frecuencia garantizada (incluido)
- Servidores dedicados: discos NVMe por pares, RAID configurado en la instalación; backup no incluido por defecto
- Backup externo siguiendo la regla 3-2-1: bajo petición, con horas de DevOps (5–10 h/mes en dedicados)
- PITR para bases de datos (WAL, binlog, oplog): bajo petición, con horas de DevOps
- Pruebas de restauración y periodo de retención: se acuerdan con el equipo y se configuran con horas de DevOps
Restaurar un backup en 4 pasos
Abre el panel
Inicia sesión en el panel de cliente. En cPanel restauras ahí el backup diario; en VPS eliges un snapshot.
Elige un punto en el tiempo
Elige la copia anterior al problema. La más reciente no siempre es la correcta si el error lleva un tiempo ahí.
Haz clic en “Restaurar”
Una restauración sobrescribe el estado actual. Si tienes dudas, pide al equipo que restaure primero en un entorno aparte para poder comparar.
Comprueba el resultado
Comprueba que la aplicación funciona y que los datos están donde deben. Lo que tarda la restauración depende del volumen de datos.
Preguntas frecuentes
¿Hay que detener el servidor para hacer un snapshot?
Normalmente no: el snapshot de un VPS se hace con el servidor en marcha. En una base de datos, sin embargo, el snapshot de un servidor en funcionamiento no siempre es consistente, por lo que recomendamos un backup de base de datos aparte (dump o WAL/binlog), que el equipo configura bajo petición.
¿Cuánto tarda restaurar un snapshot muy grande (por ejemplo, de 500 GB)?
Depende del volumen de datos, del disco y de dónde se guarde la copia: restaurar desde una copia externa tarda más que desde una local. No prometemos un tiempo fijo: la cifra realista sale de una prueba de restauración, que podemos hacer contigo.
¿Los backups están cifrados?
El cifrado de los backups externos forma parte de la estrategia que configuramos bajo petición, por ejemplo copias que salen del servidor solo cifradas, con las claves guardadas aparte de producción. Indica tus requisitos al equipo cuando solicites la configuración.
¿Y si quiero una retención superior a 30 días?
La retención de los backups externos se fija cuando el equipo configura la estrategia, según tus necesidades y tus obligaciones legales de archivo. El almacenamiento para una retención más larga se acuerda con el equipo; los planes los encontrarás en la página de precios.
¿Puedo descargar un snapshot en local?
En VPS y servidores dedicados tienes acceso root y copias tus datos con las herramientas que prefieras (rsync, tar). El equipo también puede configurar copias automáticas hacia almacenamiento externo con las horas de DevOps, como AWS S3, Google Cloud Storage o Azure Blob.
Tus datos valen demasiado para dejarlos al azar
cPanel incluye backup diario y VPS incluye snapshots. En los servidores dedicados, el equipo construye la estrategia de backup con las horas de DevOps incluidas. Consulta los precios para más detalles.
Ver planes →