Hace unos d\u00edas junto al equipo de desarrollo de Itap\u00faa nos reunimos para pensar c\u00f3mo ser\u00eda nuestro nuevo control de respaldos. La idea es clara, tener un script que analice y determine si se cuenta con un respaldo v\u00e1lido y alertar en caso contrario. Esto es importante para poder asegurar que tenemos la capacidad operativa de recuperarnos de un desastre. Parec\u00eda ser una cuesti\u00f3n simple que iba a tener una r\u00e1pida respuesta hasta que alguien pregunt\u00f3: \u00bfqu\u00e9 es un respaldo v\u00e1lido? <\/p>\n\n\n\n
\u00bfEs por ejemplo suficiente decir que el \u00faltimo respaldo se hizo con \u00e9xito y se encuentra en el disco? Bueno, para algunos casos s\u00ed, pero tomando el ejemplo de una infraestructura que cuenta con un respaldo completo semanal y uno diferencial por d\u00eda la respuesta se hace m\u00e1s compleja. \u00bfAlcanza con decir “el \u00faltimo respaldo full est\u00e1 disponible” en el caso de una organizaci\u00f3n que pretende nunca perder m\u00e1s de 15 minutos de informaci\u00f3n? En este escenario me inclino a decir que no, no alcanza. <\/p>\n\n\n\n
Ni siquiera podemos decir que “el respaldo” es un \u00fanico archivo generado por un proceso singular, se convierte en una librer\u00eda de archivos complementarios, encadenados y codependientes. Estos a su vez son generados por una colecci\u00f3n de distintas l\u00f3gicas. 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. <\/p>\n\n\n\n
Con esto en mente buscamos una definici\u00f3n simple y objetiva del “respaldo v\u00e1lido” utilizable como m\u00e1xima que nuestro control tuviera que responder, llegamos a esto: “Un respaldo se determina como v\u00e1lido si se cuenta con un juego de archivos que permita reconstruir la base de datos en un estado que satisface el punto de recuperaci\u00f3n objetivo definido por la organizaci\u00f3n”. Con esta definici\u00f3n en mano, vemos que se contrastan dos elementos, el juego de archivos que reconstruye la base por un lado y el punto de recuperaci\u00f3n objetivo (RPO es su sigla en ingl\u00e9s) definido que act\u00faa como vara contra la que debemos medirlo. <\/p>\n\n\n\n
Todo dato almacenado por una organizaci\u00f3n 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\u00e9n 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\u00f3n de sus posibilidades y sus necesidades cuanta informaci\u00f3n es tolerable llegar a perder en caso de una falla. <\/p>\n\n\n\n
Es de este cuestionamiento que nace el concepto de punto de recuperaci\u00f3n objetivo<\/strong> (RPO<\/strong>). El que define ante un evento disruptivo cual es la m\u00e1xima cantidad de datos que el negocio puede permitirse perder. Es una medida de tiempo y a la hora de dise\u00f1ar una pol\u00edtica de respaldos determina que tan antigua puede ser la imagen de la base de datos tras restaurar nuestro respaldo m\u00e1s reciente. <\/p>\n\n\n\n Para poner algunos ejemplos t\u00edpicos, una instancia de base de datos que cuenta con respaldo completo al d\u00eda 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\u00f3n. Un caso como una instancia de MSSQL Server con respaldos full acompa\u00f1ados de respaldos de logs cada 15 minutos implementa una RPO de 15 minutos, an\u00e1logamente se pueden implementar estrategias similares con archivado de logs en Oracle o de WALs en Postgres. Se entiende que la cifra es un m\u00e1ximo, si logramos perder menos informaci\u00f3n mucho mejor. <\/p>\n\n\n\n Implementar estrategias m\u00e1s ambiciosas va a requerir mayores necesidades de infraestructura y representa una mayor complejidad a la hora de mantener y monitorear. Dentro de una organizaci\u00f3n t\u00edpicamente se manejan datos de distintas importancias y es com\u00fan que distintos juegos de datos tengan distintas RPOs, requiriendo de distintas estrategias. Tambi\u00e9n es com\u00fan 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\u00f1os y hoy en d\u00eda solo se consultan tal vez fue cr\u00edtica al punto de no poder perder m\u00e1s de un par de minutos de informaci\u00f3n, pero hoy en d\u00eda restaurar una imagen de hace un d\u00eda o 30 es lo mismo. Por esto es necesario tener en cuenta estos par\u00e1metros a\u00fan al momento de dise\u00f1ar nuestras bases, compartimentando y particionando los datos de un modo que facilite una pol\u00edtica de respaldos eficiente. <\/p>\n\n\n\n Vimos como la RPO puede variar en funci\u00f3n 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\u00e1 en un disco montado dentro del mismo equipo, podremos recuperarlo en su \u00faltima versi\u00f3n 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 \u00faltimos archivos de respaldo (tal vez porque la latencia de la red no lo permite) habremos perdido m\u00e1s tiempo de datos. Distintas fallas estresan nuestro sistema de distintas maneras. <\/p>\n\n\n\n \u00bfCu\u00e1nto puede permitirse perder el negocio ante una falla en un disco? \u00bfY ante un delete sin where? \u00bfY si el datacenter se incendia con p\u00e9rdidas 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\u00f3mico que crece a medida que la soluci\u00f3n necesaria se torna m\u00e1s compleja. Algunos de estos escenarios adem\u00e1s son m\u00e1s ex\u00f3ticos que otros y esto lleva a que la RPO termine variando seg\u00fan la escala del tipo de evento disruptivo al que nos enfrentamos. <\/p>\n\n\n\n De todo esto se desprende que definir nuestra RPO es una decisi\u00f3n estrat\u00e9gica fundamental para una organizaci\u00f3n, 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\u00e1logo continuo y transparente entre quienes generan y consumen los datos, el \u00e1rea de infraestructura, el equipo de DBAs encargados de mantener los respaldos y la gerencia a cargo de estas \u00e1reas. Requiere tambi\u00e9n 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\u00f3n y adapt\u00e1ndola constantemente seg\u00fan las necesidades cambiantes de una organizaci\u00f3n moderna. Adem\u00e1s, el equipo debe ser capaz de mantener y monitorear los procesos de forma constante y proactiva para as\u00ed poder asegurar la calidad de los respaldos disponibles. <\/p>\n\n\n\n Finalmente, esta medida no es la \u00fanica a tomar en cuenta a la hora de asegurar la resiliencia de los datos de una organizaci\u00f3n y tampoco son los respaldos la \u00fanica herramienta de la que disponemos para recuperarnos ante un evento. Es importante tambi\u00e9n 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\u00f3n<\/strong> (RTO<\/strong> en ingl\u00e9s). Este tema est\u00e1 estrechamente relacionado con el que estamos tratando hoy y amerita un art\u00edculo propio, ya que implica considerar conceptos de alta disponibilidad en complemento a nuestra capacidad de recuperaci\u00f3n. <\/p>\n","protected":false},"excerpt":{"rendered":" En este art\u00edculo nos preguntamos: \u00bfQu\u00e9 es un respaldo v\u00e1lido para una base de datos? \u00bfQu\u00e9 son el RTO y el RPO? \u00bfC\u00f3mo podemos usar esos conceptos para dise\u00f1ar una pol\u00edtica confiable y segura de recuperaci\u00f3n ante desastres?<\/p>\n","protected":false},"author":5,"featured_media":11745,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[43,42],"tags":[29,33,31,34,41,39,40,37,38,36,35,32,30],"class_list":["post-11739","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-database","category-technology","tag-backup","tag-database","tag-dba","tag-disasterrecovery","tag-mariadb","tag-mssql","tag-mysql","tag-oracle","tag-postgresql","tag-recovery","tag-respaldos","tag-rpo","tag-rto"],"_links":{"self":[{"href":"https:\/\/itapua.com.uy\/es\/index.php\/wp-json\/wp\/v2\/posts\/11739","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/itapua.com.uy\/es\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/itapua.com.uy\/es\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/itapua.com.uy\/es\/index.php\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/itapua.com.uy\/es\/index.php\/wp-json\/wp\/v2\/comments?post=11739"}],"version-history":[{"count":0,"href":"https:\/\/itapua.com.uy\/es\/index.php\/wp-json\/wp\/v2\/posts\/11739\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/itapua.com.uy\/es\/index.php\/wp-json\/wp\/v2\/media\/11745"}],"wp:attachment":[{"href":"https:\/\/itapua.com.uy\/es\/index.php\/wp-json\/wp\/v2\/media?parent=11739"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/itapua.com.uy\/es\/index.php\/wp-json\/wp\/v2\/categories?post=11739"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/itapua.com.uy\/es\/index.php\/wp-json\/wp\/v2\/tags?post=11739"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}