Una copia de seguridad del sitio web solo es útil si puede restaurarla: cree un plan de recuperación antes de que comience el problema

La palabra "respaldo" resulta tranquilizadora. Un panel indica que la tarea se completó, una carpeta de almacenamiento contiene un archivo y todos asumen que el sitio web se puede recuperar.

Esa confianza se justifica sólo después de una prueba de restauración.

Un plan de recuperación útil responde a cuatro preguntas: qué se debe copiar, con qué frecuencia cambia, dónde se almacenan las copias y cómo la empresa volverá a funcionar. Esta guía le ayuda a responderlas antes de que una interrupción, una actualización fallida o un incidente de seguridad le obligue a improvisar.

Comience con el impacto empresarial

No todos los sitios web necesitan el mismo cronograma. Un sitio de folletos actualizado una vez al mes puede tolerar un punto de recuperación diferente al de una tienda en línea que acepta pedidos durante todo el día.

Defina dos objetivos prácticos:

• Objetivo de punto de recuperación (RPO): ¿cuántos datos recientes puede permitirse perder la empresa?
• Objetivo de tiempo de recuperación (RTO): ¿cuánto tiempo puede permanecer el servicio sin estar disponible?

Si perder una hora de pedidos crearía un problema grave, una copia de seguridad de la base de datos cada noche no es suficiente. Si un sitio cambia sólo cuando se publica un anuncio trimestral, las copias cada hora pueden añadir complejidad sin ningún beneficio significativo.

Estas son primero decisiones comerciales. La tecnología debe apoyar al objetivo, no definirlo accidentalmente.

Identifique todo lo que necesita el sitio web

Copiar public_html puede no ser una copia de seguridad completa. Un conjunto de recuperación típico puede incluir:

• archivos de aplicación y medios cargados; Contenido de la base de datos
• ; Archivos de configuración
• ; Variables de entorno
• y documentación de ubicación secreta; Exportación de zona DNS
• ; Configuración de enrutamiento y cuenta de correo electrónico
• ; Tareas programadas
• ; Notas de instalación de
• SSL; Instrucciones de implementación de
• ; Licencias
• o configuraciones de integración necesarias para reconstruir el servicio.

No coloque secretos de texto plano dentro de un archivo de fácil acceso. Documento donde el personal autorizado pueda recuperarlos de forma segura.

Para una cuenta web-hosting administrada, revise qué funciones de respaldo están incluidas y cuáles el cliente debe descargar de forma independiente. Para un VPS, el propietario del servidor suele tener más responsabilidad sobre el sistema operativo, la aplicación y la estrategia de la base de datos.

Utilice más de un punto de recuperación

Una copia es frágil. Puede estar incompleto, dañado, sobrescrito o ya infectado.

Un plan de retención práctico mantiene varios puntos en diferentes períodos de tiempo. Por ejemplo, la empresa podría conservar copias diarias durante un período breve, copias semanales durante más tiempo y un archivo mensual para la recuperación histórica. El cronograma exacto debe reflejar el valor del sitio, la frecuencia de cambios, los límites de almacenamiento y las obligaciones legales.

El historial de versiones importa después de un incidente lento. Si el código malicioso pasó desapercibido durante doce días, restaurar la copia de ayer puede solucionar el mismo problema.

Mantenga una copia fuera del sistema que protege

Una copia de seguridad almacenada solo en la misma cuenta de hosting puede desaparecer con la cuenta, el disco o las credenciales que causaron la interrupción.

Mantenga al menos una copia independiente en una ubicación de almacenamiento separada con acceso restringido adecuadamente. La separación puede ser lógica y administrativa además de geográfica: diferentes credenciales, diferentes límites de servicio y protección contra la eliminación rutinaria.

Cifre archivos confidenciales en reposo y en tránsito. Registre quién puede recuperar la clave de cifrado y cómo funcionará ese acceso durante una emergencia.

Automatice la copia, pero supervise el resultado

La automatización reduce las tareas olvidadas, pero un trabajo programado puede fallar silenciosamente. El almacenamiento puede llenarse, las credenciales pueden caducar, las rutas pueden cambiar o una exportación de base de datos puede completarse con un error.

Supervisar más que la existencia del trabajo: estado de finalización de

• ;
• tamaño del archivo en comparación con el historial normal;
• edad de la copia exitosa más reciente; Almacenamiento disponible
• ; Resultados de integridad o suma de comprobación de
• ; Entrega de notificaciones
• ;
• Exportaciones de bases de datos parciales o fallidas.

Un archivo sorprendentemente pequeño suele ser más útil como alarma que una insignia verde de "completado".

Restaurar en prueba, no en el sitio activo

La prueba más segura normalmente restaura una copia seleccionada en un entorno de prueba aislado. Eso le permite inspeccionar el resultado sin sobrescribir el sitio de producción.

Pruebe las funciones de las que dependen los clientes:

1. abra páginas representativas;
2. verificar imágenes y descargas;
3. inicie sesión con una cuenta de prueba;
4. busca en el catálogo o contenido;
5. envía formularios importantes;
6. inspeccionar registros recientes de la base de datos;
7. probará un flujo de órdenes de bajo riesgo cuando corresponda;
8. verifica las tareas e integraciones programadas;
9. escanea el sitio restaurado antes de declararlo limpio.

Registre la duración de la restauración. Si se necesitan seis horas para localizar las credenciales y reconstruir la base de datos, el tiempo real de recuperación es de seis horas, independientemente de la rapidez con la que se copiaron los archivos.

Las copias de seguridad y los incidentes de seguridad necesitan cuidado adicional

Después de un compromiso, no sobrescriba inmediatamente la producción con el archivo más reciente. Conserve registros y pruebas, identifique el punto de entrada, determine cuándo comenzó el compromiso y seleccione un punto de recuperación anterior a esa fecha.

Luego parchee el componente vulnerable, rote las credenciales afectadas, restaure los datos limpios, pruebe el resultado y controle la recurrencia. Un archivo limpio colocado en el mismo entorno vulnerable puede volver a verse comprometido.

Nuestra guía para website security layers explica cómo las copias de seguridad encajan con la seguridad de la cuenta, las actualizaciones, el monitoreo, el filtrado y el DNS protegido.

Proteja el dominio y la ruta de recuperación de DNS

Una copia de seguridad de un sitio web que funcione no restaura una cuenta de dominio perdida o una zona DNS indocumentada. Mantenga segura la cuenta del registrador, registre servidores de nombres y exporte registros DNS antes de cambios importantes.

Utilice el SoxDomains WHOIS and RDAP tool para confirmar los detalles del registrador y del registro público. Si una recuperación requiere mover el dominio, siga el domain-transfer checklist y evite cambiar los servidores de nombres simplemente porque cambia el registrador.

Asignar roles de recuperación

Anote quién puede autorizar una restauración, quién tiene acceso de alojamiento, quién controla el DNS, quién se comunica con los clientes y quién verifica que el sitio recuperado sea seguro.

El plan debería funcionar cuando el administrador habitual no está disponible. Guarde las instrucciones de contacto y acceso en algún lugar al que el equipo pueda acceder incluso si el sitio web, el correo electrónico de la empresa o el administrador de contraseñas principal se ven afectados.

Un Runbook de recuperación que puede seguir

Utilice una secuencia corta y probada:

1. confirma el incidente y detiene los cambios riesgosos;
2. preserva los registros y el estado actual cuando la seguridad está involucrada;
3. elija el punto de recuperación adecuado;
4. prepara un objetivo de restauración aislado;
5. restaurar archivos, base de datos y configuración requerida;
6. corrige la causa antes de volver a conectar el tráfico;
7. verificar el recorrido del cliente;
8. actualiza DNS solo si la arquitectura de recuperación lo requiere;
9. supervisa de cerca la devolución del servicio;
10. documenta lo sucedido y mejora el plan.

Evite cambiar el alojamiento, el DNS, el correo electrónico y el código de la aplicación simultáneamente a menos que la recuperación realmente lo requiera. Los pasos controlados más pequeños hacen que los problemas sean más fáciles de diagnosticar y revertir.

La prueba es la prueba

Un archivo de respaldo es evidencia de que un proceso creó algo. Una restauración de prueba exitosa es evidencia de que la empresa puede recuperarse.

Elija un punto de recuperación realista, restáurelo a la etapa de preparación, programe el tiempo del proceso y documente cada credencial faltante o paso poco claro. Esos descubrimientos son el motivo para realizar pruebas antes de la emergencia.