Backups (Copias de respaldo)

en estos párrafos intentó sintetizar lo que entiendo de copias de respaldo, para unificar criterios conmigo mismo

una aclaración!

La replicación  de archivos en servicios tipo Google Drive, OneDrive, Dropbox, etc no aplica a copias de respaldo. La alta disponibilidad que otorgan esas herramientas no se aplica al principio de la copia de respaldo (se corrompió un archivo? se sobrescribe el archivo sano con el dañado).

Y unas consideraciones:

  1. La copia de respaldo debe ser parte del DRP, es probable que cuando se genere un DRP el programa de copias de respaldo debe ser modificado.
  2. La infraestructura de copia de respaldo no es la misma que la infraestructura productiva.  Los elementos de configuración que componen el servicio de copia de respaldo no comparten credenciales de acceso, conectividad y herramientas de gestión. Esto significa que, por ejemplo, el servidor de copias de respaldo no aceptará credenciales de acceso declaradas en el entorno productivo.
  3. Es obligatorio, los servicios de copia de respaldo se conectan al entorno productivo con sus propias credenciales y copian los elementos de configuración alcanzados por la política de copia de respaldo, y nunca al revés.
  4. Como excepción, de no ser posible el punto anterior (Por ejemplo, incompatibilidad entre productos). Se deben crear puntos intermedios en la producción. y en última instancia, generar credenciales y espacios en la infraestructura de copia de respaldo, (una credencial y un espacio por Elemento de Configuración). lo más acotado que sea posible.

Ahora sí:

Inventario:  (que voy a respaldar?) Realizar el inventario de lo que debemos respaldar, y durante cuánto tiempo. Acá hay dos puntos a desarrollar:

  1. Continuidad de Negocio. no es una definición académica, pero la pregunta a responder es ¿Cuantas perdidas significa que algo no funcione por x cantidad de tiempo? Por ejemplo, No le vamos a asignar la misma prioridad a el servidor de base de datos de un ERP, que al servidor que contiene el sistema que cuenta las cantidad de impresiones.
  2. Política de retención,  basada en Regulaciones por las que se ve afectada la organización. Debemos garantizar, al menos, que los datos estén disponibles (de forma inmediata o no) por lo dictado por los entes reguladores de la actividad que realiza la organización, por ejemplo, si tengo digitalizados los legajos de RRHH, debe almacenarlos al menos 10 años.

Por eso es primordial realizar copias de lo que se va modificando. Esto aplica no solo al espacio consumido en medios digitales, si no al consumo de recursos (muchas veces durante el tiempo de producción) como conectividad y tiempo de procesador, de aquí la importancia de la realización de copias periódicas incrementales, o, a lo sumo, diferenciales. Evitar el uso de scripts de copia (solo usar scripts desarrollados in house en caso excepcionales y no como regla), y utilizar herramientas específicas de copia de respaldo que utilizan tecnicas de optimizacion de copia, compresión y control de errores, no voy a profundizar en estos temas específicos.

Teniendo en cuenta esto, vamos a tener en claro que se debe respaldar y como, y en base a los recursos disponibles y regulaciones por los que se ve afectado el cliente durante cuánto tiempo se guardan las copias.

Resguardo: (En donde lo guardo?) Donde se depositan las copias de respaldo. Qué tipos de medios se utilizan. y, cuantas copias guardo.

La copia de respaldo no solo debe ser útil en caso de pérdida de información por errores operativos (borrado de archivos por error de usuario), sino que también debemos estar preparada para ser utilizada en caso de siniestros más dañinos (ataques informáticos, por ejemplo). O incluso, catástrofes como incendios, terremotos, etc. En el primer caso una copia local alcanza. En el segundo, una copia ubicada físicamente en el mismo centro de datos y separada lógicamente de la producción alcanza, pero en caso de un incendio, la copia se pierde junto con el entorno productivo.

  1. Copia Local, si una máquina virtual se re configura y falla o se borra un archivo de forma accidental, se puede utilizar la copia local para restablecerla a un punto anterior.
  2. Copia Remota. Al día de la fecha, se puede optar por servicios en la nube específicos para este uso. Entonces, por ejemplo, si un servidor físico falla y sale de producción, desde la copia realizada en un NAS local, se lo puede volver a disponibilizar. Y en caso de catástrofe mayor, descargar esas copias de respaldo para restablecer los elementos de configuración correspondiente en otra ubicación, sea esta una nueva ubicación física o nuevo hardware.
  3. de no ser posible el punto anterior, automatizar la copia de estas copias de respaldo en unidades masivas y asignar roles para que guarden copias en otras ubicaciones (teniendo en cuenta que debe ser al menos a 3KM del centro de datos respaldado). pero asumiendo que en caso de catástrofe, la información disponible será la de la última rotación.
  4. Teniendo en cuenta la política de retención, ir separando las copias (esto debería ser automático, configurando las herramientas de backup) requeridas, por ejemplo, unas copias anuales, mensuales, diarias, etc.
  5. Se pueden sumar copias intermedias, por ejemplo, en base de datos, guardar las copias incrementales diarias en una unidad local y en caso de necesitar recuperar información, realizarlo desde esa unidad (la copia de estos incrementales en la infraestructura de copia de respaldo debe ser automática, y no copiar todas juntas).

Validación de copias de Seguridad: (Lo que estoy guardando, sirve?) Realizar restauraciones periódicas para validar que lo respaldado funciona.

Si bien en todos los niveles de la informática y telecomunicaciones hay implementadas técnicas de validación de datos, y las posibilidades son mínimas, sigue existiendo la posibilidad que una copia de respaldo pase todas estas validaciones y esté corrupta. Sin entrar en mucho detalle, históricamente, las cintas fallaban y mucho. Hoy en día, es posible que una copia falle. Un bloque de volumen validado puede contener un archivo dañado, la validación es por bloque de volumen, así que el archivo se almacenará dañado y la restauración devolverá el mismo archivo dañado que copio originalmente.

Debe ser parte de la persona o equipo que tenga asignadas las responsabilidades inherentes al rol de operador y responsable de copias de respaldo generar un cronograma de restauraciones periódicas para conocer el estado de las copias de seguridad.

Política de retención:

Resguardo de Backups Diarios:.

  • Base de datos: Últimos 7 dias.
  • VSS Snapshot: Últimos 7 días.

Resguardo de Backup Semanales:

  • Base de datos: Últimas 4 semanas
  • VSS Snapshot: Últimas 4 Semanas

Resguardo de Backup Mensuales:

  • Base de datos: Últimos 12 meses
  • VSS Snapshot: Último Mes

Resguardo de Backup Anuales:

  • Base de datos: Últimos 10 años
  • VSS Snapshot: no se realiza.

Aclaración, los VSS snapshot son para volver rápido a producción. con un mes alcanza.


Publicado

en

por

Etiquetas:

Comentarios

Una respuesta a “Backups (Copias de respaldo)”

  1. Matias Avatar

    Muy bueno!

Dejá una respuesta

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

A %d blogueros les gusta esto: