Estimated reading time: 6 minutos
Puntos Clave
- El plan de recuperación ante desastres debe incluir la priorización de documentos según su urgencia en procesos críticos.
- Los conceptos RTO y RPO son clave para determinar el tiempo y punto de recuperación de la documentación.
- Recuperar solo los archivos PDF no es suficiente; también hay que restaurar metadatos y relaciones con sistemas.
- Es importante tener un control sobre la documentación generada durante la caída del sistema para evitar pérdida de información.
- Las pruebas de recuperación son esenciales para validar la efectividad del plan de recuperación ante desastres.
Tabla de contenidos
- No toda la documentación tiene la misma urgencia
- RTO y RPO aplicados a los documentos
- Recuperar los PDF puede no ser suficiente
- Mientras tanto, la organización puede seguir trabajando
- La recuperación termina cuando podemos volver a trabajar
- Qué debería tener claro la parte documental de un DRP
- Preguntas frecuentes sobre planes de recuperación ante desastres
Son las ocho y cuarto de la mañana y el gestor documental no responde.
Puede ser un problema si finanzas necesitara comprobar unas facturas antes de autorizar pagos. O para compras si se pone a buscar un contrato. Recursos Humanos ya a esta hora tiene una gestión abierta que depende de varios expedientes.
Hay una copia de seguridad reciente. Bien. Pero ahora empiezan las preguntas.
¿Qué recuperamos primero? ¿Podemos trabajar mientras vuelve el sistema? ¿Qué ocurre con los documentos que se generan durante esas horas? ¿Basta con restaurar los archivos o también necesitamos recuperar metadatos, permisos y relaciones con otras aplicaciones?
Un plan de recuperación ante desastres o DRP tiene que prever también esta parte.
Disponer de una copia es fundamental. Saber cómo devolver la información al trabajo lo es igualmente.
No toda la documentación tiene la misma urgencia
Cuando se cae el sistema a todos nos entra la prisa, todo parece importante.
Pero un expediente necesario esa misma mañana para cumplir un plazo no tiene la misma urgencia que documentación que puede permanecer unas horas sin consulta.
Por eso el orden de recuperación debería guardar relación con los procesos que dependen de esa información.
NIST sitúa precisamente el análisis de impacto y la definición de prioridades entre las bases de la planificación de contingencias. Desde el prisma de la gestión documental podemos añadir otra referencia útil y de la que ya os hemos hablado anteriormente: los documentos esenciales. Estos documentos son los necesarios para mantener funciones críticas o proteger derechos y obligaciones durante una emergencia.
Si una organización ya sabe cuáles son, tiene parte del trabajo hecho, pero hay que saber decidir cuándo necesita recuperarlos y con qué nivel de actualización.
RTO y RPO aplicados a los documentos
Aquí aparecen dos conceptos habituales en un DRP (Disaster Recovery Plan o plan de recuperación ante desastres).
El RTO (Recovery Time Objective u objetivo de tiempo de recuperación) marca el objetivo temporal para volver a disponer de un recurso después de una interrupción.
El RPO (Recovery Point Objective u objetivo de punto de recuperación) indica hasta qué punto temporal debemos recuperar los datos y, por tanto, cuánta información reciente podemos permitirnos perder.
Aplicarlo a los documentos resulta bastante intuitivo.
¿Cuándo necesitamos volver a consultar estos expedientes? ¿Y hasta qué momento tienen que estar actualizados cuando los recuperemos?
Las respuestas pueden ser muy distintas.
La documentación de un proceso que cambia continuamente puede necesitar una recuperación muy reciente. Un conjunto de documentos cerrados y que ya no se modifica puede admitir otras condiciones.
Por eso un único RTO o RPO para todo «el archivo» no es útil sobre las necesidades reales de la organización.
Recuperar los PDF puede no ser suficiente
Imaginemos que conseguimos restaurar todos los documentos de varios expedientes.
Los PDF están ahí. Pero la base de datos con sus metadatos todavía no funciona. O se ha recuperado el repositorio, pero siguen caídos los permisos de acceso. Quizá el ERP ya está operativo, aunque todavía no consigue recuperar la documentación justificativa asociada a cada operación.
La situación es que los documentos existen, pero todavía no podemos trabajar correctamente con ellos.
Ahí aparecen las dependencias, una parte importante de la recuperación documental.
IBM incluye precisamente la identificación de dependencias entre sistemas dentro de la planificación de recuperación. En gestión documental ese mapa puede incluir repositorios, bases de datos, metadatos, índices, permisos, sistemas de firma, gestores de expedientes, ERP y otras aplicaciones.
El orden en el que recuperamos esos elementos importa.
No basta con que vuelva el fichero. Tiene que volver también el contexto que permite encontrarlo, relacionarlo y utilizarlo.
Mientras tanto, la organización puede seguir trabajando
Una caída no siempre permite detener la actividad hasta que todo vuelva a estar disponible.
Puede haber procesos que necesiten continuar mediante procedimientos alternativos.
Eso plantea otro problema documental.
Si durante varias horas se generan solicitudes, autorizaciones, comunicaciones o informes fuera del sistema habitual, hay que mantener algún control sobre ellos.
Cuando vuelva el entorno normal, esa actividad deberá incorporarse correctamente.
De lo contrario podemos recuperar perfectamente la información que teníamos a las ocho de la mañana y encontrarnos con un agujero en todo lo ocurrido después.
La recuperación termina cuando podemos volver a trabajar
Una restauración puede completarse técnicamente y seguir sin estar preparada para el uso diario.
Conviene comprobar que los documentos se abren, que mantienen los metadatos adecuados, que siguen vinculados al expediente correcto y que permisos, búsquedas e integraciones funcionan como deberían.
También habrá que incorporar de forma controlada la información generada durante la caída.
El objetivo es recuperar un estado conocido y fiable. Este concepto sirve para abordar las pruebas de recuperación y reconstitución de los sistemas.
Y aquí las pruebas son importantes.
Descubrir durante una incidencia real que falta una dependencia, que recuperar cierta documentación lleva mucho más de lo previsto o que nadie sabe cómo acceder a una copia alternativa significa que el DRP tenía demasiadas cosas sin comprobar.
Las pruebas sirven también para verificar si los RTO y RPO definidos sobre el papel son realistas.
Qué debería tener claro la parte documental de un DRP
No hace falta crear un plan independiente del de TI. Sí conviene que el DRP permita responder a unas cuantas preguntas concretas:
- qué documentación necesita recuperarse antes
- qué RTO y RPO requiere
- de qué sistemas, metadatos, permisos e integraciones depende
- cómo se accederá a ella mientras los sistemas habituales estén indisponibles
- qué ocurrirá con los documentos creados durante la contingencia
- y cómo comprobaremos que la recuperación ha terminado correctamente
En Normadat trabajamos en custodia de soportes de backup y gestión segura de información. El DRP conecta ambos al establecer cómo recuperar las copias y devolver la información a un estado en el que la organización pueda volver a trabajar con ella.
Si mañana deja de responder el gestor documental, saber que existe un backup será una buena noticia. Pero el verdadero valor del DRP estará en haber decidido de antemano qué información debe recuperarse primero, de qué sistemas depende y cómo devolverla al trabajo sin improvisar.
Preguntas frecuentes sobre planes de recuperación ante desastres
Los vinculados a procesos que deben continuar o reanudarse antes y aquellos necesarios para proteger derechos, obligaciones o decisiones críticas. Esa prioridad debería establecerse antes de que ocurra una incidencia.
El RTO establece el objetivo temporal para volver a disponer de la documentación. El RPO determina hasta qué momento deben recuperarse los datos y qué pérdida de información reciente puede tolerarse.
Cuando no solo se han restaurado los archivos, sino que vuelven a funcionar su acceso, metadatos, permisos, relaciones con expedientes y aplicaciones, y se ha incorporado correctamente la documentación generada durante la contingencia.
