Hace unos días junto al equipo de desarrollo de Itapúa nos reunimos para pensar cómo sería nuestro nuevo control de respaldos. La idea es clara, tener un script que analice y determine si se cuenta con un respaldo válido y alertar en caso contrario. Esto es importante para poder asegurar que tenemos la capacidad operativa de recuperarnos de un desastre. Parecía ser una cuestión simple que iba a tener una rápida respuesta hasta que alguien preguntó: ¿qué es un respaldo válido? 

¿Es por ejemplo suficiente decir que el último respaldo se hizo con éxito y se encuentra en el disco? Bueno, para algunos casos sí, pero tomando el ejemplo de una infraestructura que cuenta con un respaldo completo semanal y uno diferencial por día la respuesta se hace más compleja. ¿Alcanza con decir “el último respaldo full está disponible” en el caso de una organización que pretende nunca perder más de 15 minutos de información? En este escenario me inclino a decir que no, no alcanza.  

Ni siquiera podemos decir que “el respaldo” es un único archivo generado por un proceso singular, se convierte en una librería de archivos complementarios, encadenados y codependientes. Estos a su vez son generados por una colección de distintas lógicas. Un error que haga fallar alguno de los pasos o pierda un archivo de la cadena afecta la validez del respaldo y compromete a todas las piezas posteriores.   

Con esto en mente buscamos una definición simple y objetiva del “respaldo válido” utilizable como máxima que nuestro control tuviera que responder, llegamos a esto: “Un respaldo se determina como válido si se cuenta con un juego de archivos que permita reconstruir la base de datos en un estado que satisface el punto de recuperación objetivo definido por la organización”. Con esta definición en mano, vemos que se contrastan dos elementos, el juego de archivos que reconstruye la base por un lado y el punto de recuperación objetivo (RPO es su sigla en inglés) definido que actúa como vara contra la que debemos medirlo. 

Todo dato almacenado por una organización tiene un valor, ya sea por el potencial futuro para extraer conocimiento mediante herramientas de business inteligence o por ser necesario para la operativa del negocio. Por esto es que se desplegamos motores de base de datos para conservarlos y desarrollamos estrategias para asegurar que sean preservados en caso de emergencia. También es cierto que estas estrategias conllevan costo y complejidad que es necesario contrastar con la criticidad de los datos. Las organizaciones deben entonces plantearse en función de sus posibilidades y sus necesidades cuanta información es tolerable llegar a perder en caso de una falla. 

Es de este cuestionamiento que nace el concepto de punto de recuperación objetivo (RPO). El que define ante un evento disruptivo cual es la máxima cantidad de datos que el negocio puede permitirse perder. Es una medida de tiempo y a la hora de diseñar una política de respaldos determina que tan antigua puede ser la imagen de la base de datos tras restaurar nuestro respaldo más reciente. 

Para poner algunos ejemplos típicos, una instancia de base de datos que cuenta con respaldo completo al día tiene en los hechos una RPO de 24 horas. En el peor de los casos, digamos si el respaldo se hace a las 00:00 horas y tenemos una falla a las 23:59, perderemos 24 horas de información. Un caso como una instancia de MSSQL Server con respaldos full acompañados de respaldos de logs cada 15 minutos implementa una RPO de 15 minutos, análogamente se pueden implementar estrategias similares con archivado de logs en Oracle o de WALs en Postgres. Se entiende que la cifra es un máximo, si logramos perder menos información mucho mejor. 

Implementar estrategias más ambiciosas va a requerir mayores necesidades de infraestructura y representa una mayor complejidad a la hora de mantener y monitorear. Dentro de una organización típicamente se manejan datos de distintas importancias y es común que distintos juegos de datos tengan distintas RPOs, requiriendo de distintas estrategias. También es común que la RPO de un juego de datos cambie con el tiempo, para poner un ejemplo: una base con tablas en el orden de las centenas de millones de filas que se insertaron hace años y hoy en día solo se consultan tal vez fue crítica al punto de no poder perder más de un par de minutos de información, pero hoy en día restaurar una imagen de hace un día o 30 es lo mismo. Por esto es necesario tener en cuenta estos parámetros aún al momento de diseñar nuestras bases, compartimentando y particionando los datos de un modo que facilite una política de respaldos eficiente. 

Vimos como la RPO puede variar en función de los datos, a esto podemos sumar que no todos los eventos disruptivos son equivalentes. Si falla el disco en el que se aloja la base de datos y nuestro respaldo está en un disco montado dentro del mismo equipo, podremos recuperarlo en su última versión sin problemas. No obstante, si la falla fue generalizada y se pierden ambos discos dependemos de que el respaldo haya sido copiado a otro equipo y si esta copia no incluye los últimos archivos de respaldo (tal vez porque la latencia de la red no lo permite) habremos perdido más tiempo de datos. Distintas fallas estresan nuestro sistema de distintas maneras.  

¿Cuánto puede permitirse perder el negocio ante una falla en un disco? ¿Y ante un delete sin where? ¿Y si el datacenter se incendia con pérdidas totales en los equipos? Los tres son escenarios muy diferentes, pero enteramente posibles (los tres los hemos visto en nuestros clientes). Generan diversas necesidades en cuanto a infraestructura para cubrir cierta RPO lo que se traduce en un coste económico que crece a medida que la solución necesaria se torna más compleja. Algunos de estos escenarios además son más exóticos que otros y esto lleva a que la RPO termine variando según la escala del tipo de evento disruptivo al que nos enfrentamos. 

De todo esto se desprende que definir nuestra RPO es una decisión estratégica fundamental para una organización, esta debe ser negociada y consensuada de acuerdo con las necesidades del negocio y las posibilidades de la infraestructura. Para esto es necesario una diálogo continuo y transparente entre quienes generan y consumen los datos, el área de infraestructura, el equipo de DBAs encargados de mantener los respaldos y la gerencia a cargo de estas áreas. Requiere también de un equipo con experiencia y conocimiento que sea capaz de definir una estrategia eficaz y eficiente de acuerdo con las opciones provistas por el motor de base de datos, reduciendo el impacto en consumo de recursos, maximizando la robustez de la solución y adaptándola constantemente según las necesidades cambiantes de una organización moderna. Además, el equipo debe ser capaz de mantener y monitorear los procesos de forma constante y proactiva para así poder asegurar la calidad de los respaldos disponibles. 

Finalmente, esta medida no es la única a tomar en cuenta a la hora de asegurar la resiliencia de los datos de una organización y tampoco son los respaldos la única herramienta de la que disponemos para recuperarnos ante un evento. Es importante también pensar en la complejidad y el tiempo que consume el acto de recuperarnos de una falla, para esto se define un tiempo objetivo de recuperación (RTO en inglés). Este tema está estrechamente relacionado con el que estamos tratando hoy y amerita un artículo propio, ya que implica considerar conceptos de alta disponibilidad en complemento a nuestra capacidad de recuperación.