Un plan útil de copias de seguridad web explica qué se puede recuperar, hasta qué momento anterior se puede volver y quién realizará la recuperación. Antes de aceptar «copias de seguridad incluidas», pide una lista de los sistemas cubiertos, los puntos de recuperación conservados y una demostración segura de que el sitio web acordado puede restaurarse. Una notificación de copia completada correctamente no responde por sí sola a esas preguntas.
Esta lista de control de copias de seguridad y restauración web ayuda a una empresa a acordar los requisitos de recuperación con su proveedor web o de alojamiento. La solución adecuada depende de lo que almacene el sitio y de cómo lo utilice la empresa. Un sitio de servicios de cinco páginas, un sitio editorial y una tienda online pueden tener necesidades de recuperación muy distintas.
1. Enumera de qué depende el sitio web
Empieza por los elementos necesarios para que el sitio funcione, en lugar de por el nombre de un producto de copias de seguridad. Incluye el contenido de las páginas, las imágenes, el código, la configuración y cualquier base de datos. Después, enumera por separado los servicios conectados: el destino de un formulario, un sistema de reservas, un proveedor de pagos o un sistema de gestión de relaciones con clientes pueden almacenar información fuera de la cuenta de alojamiento del sitio.
Una copia de las páginas visibles no incluye necesariamente esos otros registros. Por ejemplo, WordPress explica que una copia de seguridad completa habitual necesita tanto los archivos del sitio web como la base de datos. Descargar solo sus archivos no copia la base de datos. Los archivos y la base de datos también deben corresponder a un momento compatible del historial del sitio, especialmente cuando hay actualizaciones.
Si el sitio se genera a partir de un repositorio de código, pregunta qué más hace falta para reconstruirlo y publicarlo. La guía de copias de seguridad de GitHub distingue los datos incluidos en distintos métodos de copia. Una copia del repositorio es útil, pero no debe darse por hecho que contiene todos los recursos subidos, los registros externos, los ajustes de la cuenta o los requisitos de despliegue.
Utiliza una pequeña tabla de cobertura para hacer visibles estos límites. Es una hoja de trabajo para planificar, no una afirmación de que todos los sitios web necesitan todas las filas. Sustituye los ejemplos por los sistemas que tu empresa utiliza realmente y registra quién es responsable de cada uno.
| Elemento | Pregunta que resolver | Evidencias que conservar |
|---|---|---|
| Páginas, código y recursos de diseño | ¿Se puede reconstruir o restaurar la versión acordada? | Versión, ubicación e instrucciones de recuperación |
| Base de datos y archivos multimedia subidos | ¿Se incluyen ambos en un conjunto de recuperación compatible? | Fechas de las copias, cobertura y resultado de la restauración |
| Configuración y acceso | ¿Quién puede restaurar los ajustes y obtener acceso autorizado? | Responsable y procedimiento de acceso seguro |
| Consultas, reservas o pedidos | ¿Qué sistema conserva realmente estos registros? | Proveedor y mecanismos de recuperación independientes |
| Dominio y servicios conectados | ¿Qué dependencias deben funcionar para poder utilizar el sitio? | Responsables de las cuentas y lista de control de dependencias |
2. Acuerda la pérdida de datos y el tiempo de interrupción aceptables
Dos preguntas sencillas hacen que el plan resulte más útil: ¿cuánta información reciente podría permitirse perder la empresa y cuánto tiempo podría estar fuera de servicio la función afectada? Respóndelas pensando en el proceso de negocio, no solo en la página de inicio. Una página estática de presentación y un sistema que acepta pedidos pagados pueden necesitar respuestas distintas.
Estas preguntas corresponden al objetivo de punto de recuperación, o RPO, y al objetivo de tiempo de recuperación, o RTO. AWS define estos objetivos de recuperación en términos del intervalo aceptable de pérdida de datos y de la duración máxima aceptable de la interrupción del servicio. Trátalos como metas de planificación acordadas. No demuestran que un proveedor concreto pueda cumplirlas en cualquier incidente.
Por ejemplo, un punto de recuperación diario puede dejar un intervalo con cambios realizados después de la última copia completada correctamente. Su existencia no indica por sí sola cuánto tardará alguien en localizarlo, obtener acceso, restaurarlo y verificar el resultado. Pide al proveedor que relacione la frecuencia propuesta y el proceso de recuperación con los objetivos que has definido.
Evita elegir «sin pérdida de datos» o «recuperación instantánea» solo porque esas expresiones resulten tranquilizadoras. Explica qué información no se puede recrear y qué actividades de la empresa pueden utilizar temporalmente una vía alternativa. Después, acuerda una solución viable, su coste y sus limitaciones. Registra el horario en el que está disponible la asistencia para la recuperación, incluido cómo se gestionará un incidente fuera de ese horario.
3. Conserva puntos de recuperación utilizables durante suficiente tiempo
La frecuencia de las copias y su retención responden a preguntas distintas. La frecuencia indica cada cuánto se crea un nuevo punto de recuperación. La retención indica cuánto tiempo siguen disponibles los puntos anteriores. Una copia frecuente que sustituye una y otra vez la única copia existente puede servir de poco si un cambio no deseado se descubre varios días después.
Pregunta cuántas versiones se conservan, cómo se identifican sus fechas y qué sucede cuando se alcanzan los límites de almacenamiento o cambia la suscripción. Ten en cuenta el tiempo que tu equipo podría necesitar para detectar un problema. Si nadie revisa el contenido durante varias semanas, un periodo de retención muy corto puede agotarse antes de descubrir una eliminación accidental.
Aclara cómo se separan las copias de recuperación del entorno en producción y quién puede modificarlas o eliminarlas. Una copia afectada por la misma acción errónea en la cuenta o el mismo incidente de seguridad puede no ofrecer la independencia que esperabas. Habla de los controles de acceso y la protección con el proveedor responsable, en lugar de asumir que basta con una segunda carpeta o con la sincronización automática.
Mantén un plan práctico: identifica la ubicación de recuperación y la persona responsable de la cuenta sin incluir contraseñas, claves secretas ni registros de clientes en un documento de requisitos compartido. Registra dónde se mantienen las instrucciones de acceso autorizado. Acuerda también quién recibe las notificaciones de fallo y qué hace cuando una copia programada no se completa.
4. Distingue entre reversión, recuperación selectiva y restauración completa
Distintos problemas requieren distintos métodos de recuperación. La reversión de un despliegue devuelve el sitio publicado a una versión anterior. La recuperación selectiva recupera un archivo, una página o un registro concreto. Una restauración completa reconstruye el entorno cubierto a partir de un conjunto de recuperación. Pregunta cuáles de estos métodos admite la solución acordada y qué modifica cada uno.
Por ejemplo, Cloudflare Pages documenta la reversión a un despliegue anterior de producción completado correctamente. Esto resulta útil ante un problema introducido por un despliegue. No demuestra que una plataforma de reservas independiente o una base de datos externa de clientes también vayan a volver a ese momento. Confirma el comportamiento de cada dependencia, en lugar de tratar la «reversión» como un botón universal para deshacer.
Antes de restaurar datos antiguos, identifica los cambios realizados desde ese punto de recuperación. Una restauración completa de la base de datos puede sustituir información reciente válida junto con el cambio no deseado. Determina si esos registros posteriores pueden conservarse, conciliarse o recuperarse por separado. La persona que autorice la recuperación debe comprender ese compromiso antes de que empiece una operación destructiva.
Registra el proceso de decisión con un lenguaje sencillo: quién evalúa el problema, quién aprueba el punto de recuperación elegido y quién realiza el trabajo. Incluye una forma de conservar el estado actual para investigarlo cuando corresponda. El plan de recuperación debe explicar cómo elige el equipo un método, no animar a la persona responsable de la empresa a experimentar en el sitio en producción.
5. Demuestra una restauración en un entorno seguro
Pide una prueba coordinada de restauración antes de confiar en el plan. AWS recomienda pruebas periódicas de recuperación para comprobar que los datos de las copias se pueden recuperar y utilizar. La cuestión práctica es si el conjunto de recuperación acordado produce un sitio utilizable, no si existe un archivo de copia.
Utiliza un destino de pruebas aislado y acordado con el responsable técnico. Mantén el acceso controlado a la información de clientes restaurada e impide que las copias de prueba envíen notificaciones reales, acepten pagos o sobrescriban integraciones en producción. El equipo responsable debe decidir qué datos son adecuados para la prueba y cómo se eliminarán después.
Revisa las páginas restauradas, las imágenes, la navegación y la configuración necesaria. Comprueba un recorrido de negocio representativo con unas condiciones de prueba coordinadas. Que una página se muestre correctamente no demuestra que su servicio conectado esté bien configurado. Si no se puede probar una dependencia de forma segura, registra esa limitación en lugar de dar por demostrado todo el recorrido.
Conserva un breve registro de la prueba: el punto de recuperación utilizado, los sistemas cubiertos, el destino, las horas de inicio y fin, las comprobaciones realizadas y los problemas pendientes. Mide las etapas relevantes para el objetivo de recuperación acordado, incluidos el acceso y la verificación. Repite las comprobaciones pertinentes después de cambios importantes en el sitio, el alojamiento o la solución de recuperación, con una frecuencia de revisión acordada según tus circunstancias.
6. Analiza una decisión de recuperación realista
Considera una consultoría hipotética con un pequeño sitio web de servicios. Sus páginas se publican desde un repositorio y las consultas se conservan en un sistema independiente. El martes por la tarde, el equipo descubre que un despliegue del lunes eliminó una página de servicio. El martes por la mañana llegó una consulta nueva.
La primera pregunta es si el problema afecta solo a las páginas publicadas o también al sistema de consultas. Si un despliegue anterior contiene la página que falta, el equipo puede evaluar una reversión del despliegue sin asumir que también tiene que restaurar los registros de consultas independientes. Comprueba qué otros cambios del sitio se revertirían y si recuperar únicamente esa página es una opción mejor.
En una vista previa aislada, el proveedor responsable demuestra la versión propuesta y verifica los enlaces y la configuración del formulario acordados. La persona responsable de la empresa revisa los cambios afectados y autoriza la recuperación en producción mediante su proceso establecido. El registro más reciente del sistema de consultas se considera por separado porque sus mecanismos de almacenamiento y recuperación son independientes.
Este ejemplo describe un método de decisión, no un resultado comunicado de un cliente ni una promesa de tiempo de recuperación. Para una tienda online cuyos pedidos se almacenan en la base de datos del sitio, la misma decisión tendría que tener en cuenta los pedidos creados después del punto de recuperación propuesto. La lección útil es identificar dónde se almacena la información antes de decidir qué restaurar.
7. Incluye las responsabilidades de recuperación en el acuerdo
Termina con una breve lista de control que ambas partes puedan responder. Consérvala con los materiales de entrega del sitio web y revísala cuando cambie el sitio. Debe seguir siendo comprensible para quien necesite comunicar un incidente, aunque esa persona no haya encargado el proyecto original.
- Sabemos qué componentes del sitio web y qué sistemas externos están cubiertos.
- Hemos acordado los objetivos de recuperación, la frecuencia de las copias y su retención.
- Sabemos quién comprueba los fallos y quién puede obtener acceso autorizado para la recuperación.
- Entendemos los métodos de recuperación disponibles y el riesgo para los datos más recientes.
- Tenemos un registro fechado de la prueba de restauración, con sus limitaciones y siguientes acciones.
- Hemos acordado las responsabilidades, la disponibilidad y los posibles cargos de recuperación adicionales.
Añade los requisitos pendientes al documento de requisitos del proyecto web. Si la planificación de la recuperación acompaña a un sitio de reemplazo, utiliza la lista de control de rediseño para la transición general. Un acuerdo de recuperación claro reduce las conjeturas cuando se produce un incidente; debe describir lo que se ha acordado y demostrado.
El servicio de sitios web de Digital Studio parte de EUR 2.190 para una creación puntual de hasta cinco páginas con contenido proporcionado por el cliente, diseño adaptable, bases de SEO, un formulario de captación de contactos y lanzamiento en tu dominio. La solución de copias de seguridad, las pruebas de restauración y la asistencia continua para la recuperación deben comentarse y definirse expresamente para tu proyecto. Describe tu sitio web y tus requisitos de recuperación para acordar las responsabilidades y cualquier trabajo adicional antes de empezar la creación.
