La interrupción ocurre un martes: ransomware en el VPS, o simple "DROP TABLE" después de una migración peligrosa. El equipo tranquiliza al cliente: “tenemos copias de seguridad”. Cuatro horas más tarde, descubrimos que las instantáneas no eran de ayer, que los archivos subidos vivían en un disco no incluido y que nadie había probado nunca una restauración completa.
Una copia de seguridad útil no comienza con un complemento o un cron. Comienza con una frase: en caso de desastre X, debemos volver al estado Y en Z minutos, con como máximo N minutos de pérdida de datos.
Establecer el perímetro antes de la herramienta
Enumere lo que debe ser resucitado:
| Componente | Ejemplo | Olvidado con frecuencia |
|---|---|---|
| Base de datos | MySQL, PostgreSQL | Transacciones entre dos vertederos |
| Archivos de aplicación | Cargas, medios | Almacenamiento de objetos separado |
| Configuración | .env, nginx, TLS | Secretos fuera del repositorio de git |
| DNS / certificados | Zona DNS, claves ACME | Registrador no “respaldado” |
| Código | Git remoto | Ramas no crecidas |
Luego configure RPO y RTO por componente crítico. Un blog de exhibición: RPO de 24 horas aceptable. Una tienda: RPO 15 min, RTO < 2 h.
Hacer una copia de seguridad sin RPO/RTO significa archivar en la niebla.
Regla 3-2-1 adaptada para la web
3 copias: producción + copia de seguridad local o instantánea + copia remota.
2 soportes: disco + objeto frío u otra región.
1 fuera del sitio: otro centro de datos, otra cuenta en la nube, banda fuera de línea si es confidencial.
En los sitios compartidos, la copia externa suele ser el único valor agregado real de su script interno: las instantáneas del host permanecen correlacionadas con su infraestructura.
Copias de seguridad incluidas frente a scripts internos
| Fuente | Ventaja | Límite |
|---|---|---|
| Anfitrión VPS instantáneo | Rápido, integrado | Misma región, corta duración |
| Copia de seguridad compartida “incluida” | Sencillo | Alcance borroso, restauración lenta |
| mysqldump + cron rsync | Control total | Operación para mantener, cifrado para administrar |
| Herramienta tipo Restic/Borg | Deduplicación cifrada | Curva de aprendizaje |
Lea las exclusiones del SLA: algunos hosts realizan copias de seguridad del disco del sistema pero no de los volúmenes adjuntos. Consulte nuestra encuesta de copias de seguridad incluida si compara ofertas.
Errores que matan la restauración
Copia de seguridad sin verificación de integridad. Un volcado de MySQL truncado permanece en silencio hasta que ocurre la crisis.
Solo una retención. Eliminar diariamente después de 7 días sin mensualidad = no hay devolución antes de que la falla se detecte tarde.
Secretos en la copia de seguridad no cifrada. .env en un archivo público S3 = doble incidente.
Olvídese del orden de restauración. DNS antes que TLS, base antes que trabajadores, objeto antes que URL firmadas.
La parte superior: la copia de seguridad más reciente no es la correcta
Este es el punto máximo que evitan las frases de “copia de seguridad diaria incluida”: frescura no es limpieza. Proporcione puntos de restauración inmutables y pruebe una reversión anterior.
Decide y avanza sin puntos ciegos
Escriba dos o tres escenarios (eliminación de base, ransomware, mala implementación). Establezca RPO y RTO por escenario. Automatice las exportaciones y las copias cifradas fuera del sitio. Programe una [prueba de restauración] trimestral(/fr/blog/tester-restauration/). Compare los hosts en una copia de seguridad real a través del directorio y el comparador.
Preguntas frecuentes
¿Cuál es la diferencia entre RPO y RTO?
El RPO establece la cantidad de datos que está dispuesto a perder; por ejemplo, un máximo de una hora de pedidos. El RTO establece qué tan pronto debe reanudarse el servicio (por ejemplo, cuatro horas). Los dos números guían la frecuencia de la copia de seguridad y el procedimiento de restauración.
¿Son suficientes las instantáneas del host?
A menudo, una reversión rápida en la misma infraestructura es insuficiente por sí sola: mismo centro de datos, sin protección contra la eliminación maliciosa. Completo con copias externas e inmutables.
¿Deberíamos guardar los registros?
Sólo si existe una necesidad legal o análisis forense. De lo contrario, inflan la factura sin ayudar a que el sitio vuelva a estar en línea.
Compartido: ¿qué podemos salvar realmente?
A menudo, la base mediante exportación y los archivos mediante FTP/rsync, si está permitido. Consulta exclusiones y detalles de “copia de seguridad incluida”.
La pregunta correcta no es “¿estamos ahorrando?” » pero “¿qué hora de ayer podemos revivir adecuadamente y en cuánto tiempo? »