Defina la pérdida de datos aceptable y el tiempo de recuperación, mantenga una copia independiente consistente y pruebe la restauración de la aplicación real de forma aislada. Un trabajo de copia de seguridad completado o una comprobación de integridad por sí solos no demuestran que estén presentes todas las dependencias necesarias para la recuperación.
Comience con la recuperación que necesita
Un plan de copia de seguridad comienza con dos preguntas prácticas: ¿cuánto trabajo reciente podría perder y cuánto tiempo podría permanecer el servicio no disponible? Esas respuestas determinan la programación, los datos que se incluirán y el método de restauración. Una copia diaria puede encajar en un sitio web que cambia poco, mientras que deja un vacío demasiado grande para una aplicación muy activa.
Enumere lo que hace funcionar el servicio, no solo su carpeta más grande. Los datos de la aplicación, el contenido de la base de datos, la configuración, los archivos subidos y la información necesaria para reconstruir el entorno pueden ser importantes. Mantenga un inventario privado de dependencias y claves de recuperación. La copia de seguridad debe respaldar un sistema funcional, no solo producir un archivo cuyo propósito se olvida.
Mantenga una copia fuera del límite de fallo
Un segundo directorio en la misma máquina puede ayudar a recuperar una edición errónea, pero sigue expuesto a la pérdida de esa máquina. Las instantáneas locales pueden ser valiosas para una reversión rápida y aun así requieren una copia independiente para incidentes más amplios. Elija un destino de recuperación separado y decida qué acceso debe poder leer, escribir o eliminar la copia de seguridad.
Si las credenciales de producción pueden eliminar todas las copias de recuperación, una cuenta de aplicación comprometida puede anular toda la estrategia. Separe el acceso cuando sea posible y proteja las credenciales de almacenamiento. El cifrado ayuda a proteger el contenido almacenado, pero el proceso de recuperación también depende de conservar su clave de forma segura fuera del entorno dañado.
Capture un estado consistente de la aplicación
Copiar archivos de base de datos abiertos sin un método adecuado puede capturar un estado inutilizable. Utilice un enfoque de copia de seguridad compatible con la aplicación o la base de datos, y comprenda si requiere una instantánea consistente, una exportación lógica o una breve pausa en las escrituras. Coordine los datos relacionados para que un directorio de subidas y sus referencias en la base de datos describan el mismo punto del flujo de trabajo.
Documente las exclusiones de forma deliberada. Las cachés y los archivos temporales de compilación pueden ser reproducibles; las subidas de los clientes normalmente no lo son. Revise la lista después de añadir una función o mover un directorio. Un trabajo de copia de seguridad exitoso no puede preservar una ruta que nunca se incluyó.
Pruebe la restauración en un entorno aislado
Restaure datos representativos en una ubicación separada y verifique que se abren correctamente. Para una aplicación, pruebe tanto el servicio recuperado como los archivos. Desactive el correo saliente, los trabajos programados y las integraciones externas en el entorno de prueba para que el ensayo no actúe sobre usuarios reales ni duplique tareas de producción.
Las comprobaciones de integridad del repositorio y una prueba de restauración responden a preguntas diferentes. Una herramienta puede comprobar las estructuras y los datos almacenados mientras la aplicación aún necesita configuración faltante o una clave olvidada. Registre cuánto tarda la recuperación, qué pasos manuales se requieren y dónde debe mejorarse el procedimiento. Repita el ejercicio tras cambios significativos.
Un escenario práctico: ensaye la recuperación antes del lanzamiento
Considere una aplicación con una base de datos, subidas de usuarios y un pequeño conjunto de archivos de configuración privados. El propietario crea un inventario de recuperación y elige un método de consistencia compatible con la base de datos. Un destino de copia de seguridad separado almacena las copias necesarias, mientras que la clave de recuperación se conserva fuera de la máquina de producción. La primera prueba comienza con un entorno aislado vacío, de modo que las dependencias ocultas no puedan tomarse prestadas del servidor en funcionamiento.
El propietario restaura los datos y la configuración, y luego comprueba el inicio de sesión, un registro representativo y un archivo subido. El correo saliente, los trabajos programados y las acciones externas permanecen desactivados durante el ensayo. Si la base de datos arranca pero falta una ruta de subida o un secreto, la prueba ha encontrado una brecha que un trabajo de archivo exitoso no revelaría. El propietario corrige el inventario y repite la comprobación de recuperación afectada.
Por último, el propietario registra el tiempo de restauración y los pasos manuales. La programación y la política de retención se comparan con cuánto trabajo reciente podría perderse y cuánto tiempo podría permanecer indisponible el servicio. Son decisiones específicas del proyecto, no garantías proporcionadas por una etiqueta de almacenamiento. Un procedimiento probado hace que una copia de seguridad opcional o un producto de almacenamiento sean útiles como parte de una estrategia de recuperación más amplia.
| Evidencia de recuperación | Qué comprueba | Pregunta pendiente |
|---|---|---|
| Trabajo de copia de seguridad completado | El trabajo informó de éxito | ¿Se incluyeron todas las rutas necesarias? |
| Comprobación de integridad del repositorio | Comprobaciones de estructuras o datos almacenados | ¿Tiene la aplicación todas las dependencias? |
| Restauración aislada de la aplicación | Una recuperación representativa funciona | ¿Cumple el tiempo observado su objetivo? |
Haga visible el fallo y la retención intencional
Una copia de seguridad que se detiene en silencio es una sorpresa futura. Supervise la finalización del trabajo, la capacidad disponible y la antigüedad del último punto de recuperación utilizable. Conserve suficiente historial para recuperarse de un problema descubierto más tarde, y comprenda cómo afecta la poda a ese historial. Revise las operaciones de eliminación con cuidado, porque los errores de retención pueden eliminar la única versión útil.
Lea el alcance de cualquier opción de copia de seguridad en su servicio SwissOctet elegido y confirme el proceso de restauración. Vault Storage puede considerarse como un componente de capacidad, pero un producto de almacenamiento por sí solo no es una política de recuperación completa. Decida qué necesita restaurar, mantenga la copia independiente y demuestre el procedimiento antes de que el servicio sea crítico.
Su lista de verificación práctica.
- Establezca la pérdida de datos y el tiempo de recuperación aceptables.
- Incluya bases de datos, subidas e información de reconstrucción.
- Mantenga una copia independiente y claves de recuperación separadas.
- Restaure en aislamiento y pruebe la aplicación.
- Supervise la antigüedad, la capacidad y la retención de las copias de seguridad.
Los detalles que importan.
¿Es un segundo directorio en el mismo servidor una copia de seguridad independiente?+
No. Sigue expuesto a la pérdida de ese servidor, aunque puede ayudar a recuperar un error local.
¿Sustituye una comprobación de integridad a un ensayo de restauración?+
No. Un repositorio válido aún puede omitir configuración, claves o datos requeridos por la aplicación.
¿Por qué desactivar las integraciones durante una prueba de restauración?+
Para evitar que el entorno de prueba envíe correos a usuarios reales, repita trabajos o active acciones de producción.
Vaya a la fuente.
Estas referencias respaldan los conceptos técnicos de esta guía. Consulte la documentación actual antes de cambiar un sistema de producción.
- restic: Restaurar desde una copia de seguridad restic.readthedocs.io
- restic: Trabajar con repositorios restic.readthedocs.io
- PostgreSQL: Copia de seguridad y restauración www.postgresql.org
Orientación editorial de SwissOctet. Los ejemplos son ilustrativos. Las especificaciones del servicio, las opciones disponibles y las condiciones contractuales deben verificarse por separado.