Políticas, retención, storage, restauración y herramientas.
Resumen: Realizar buenos backups sigue siendo una tarea compleja en la que interviene la definición de la política, el estudio y la elección de la(s) herramienta(s) y su implementación.
Autor del artículo Colaboración
ALBA FERRER (CAPSiDE)
Actualizado 20 de Diciembre de 2012
ÍNDICE.
1. INTRODUCCIÓN 2. POLÍTICA DE BACKUPS
3. GUARDADO Y RETENCIÓN DE BACKUPS
4. RESTAURACIÓN
5. HERRAMIENTAS
5.1. Sincronización 5.2. Copias
5.3. Bases de datos
5.4. Snapshots
5.5. Continuous Data Protection
6. A TENER EN CUENTA 7. CONCLUSIONES
8. DERECHOS DE AUTOR
1. INTRODUCCIÓN.
2. POLÍTICA DE BACKUPS
La política de backups es la definición de los diferentes aspectos de las copias de seguridad: ¿de qué se debe hacer backup? ¿Cada cuánto se realiza la copia de seguridad? ¿Qué retención deben tener? ¿Dónde se guardan las copias? ¿Cuánto tiempo es aceptable que se pueda tardar en recuperar datos?
Obviamente, siempre es deseable tener copias diarias de todos los ficheros con una retención alta y almacén local para recuperar rápidamente, así como externo para mayor protección. Sin embargo, esto está reñido con la eficiencia y con los costes: robots de cintas, ocupación de disco, espacio físico para guardar las copias, etc. Por lo tanto, es necesario encontrar un compromiso marcando máximos en los costes, y priorizando los backups de los recursos más críticos.
Cada proyecto o plataforma tiene sus propias necesidades que es necesario definir para establecer la política. Para ello, es útil:
- Diferenciar entre distintos entornos (preproducción, desarrollo, test, producción, etc.)
- Determinar los costes de las posibles pérdidas de datos
- El tiempo que se tardaría en la recuperación
- Valorar los recursos disponibles (hardware, velocidad de la red, discos remotos, etc.)
- Analizar qué es imprescindible copiar y qué no.
3. GUARDADO Y RETENCIÓN DE BACKUPS
Un aspecto importante de seguridad a la hora de establecer una política de backups es dónde se van a guardar las copias de seguridad. Cuando se definen planes de prevención de riesgos en cuanto a tecnología se suele considerar el vaulting para mitigar los efectos de un posible incidente en el site donde se realizan los backups. Esta práctica consiste en mover a otra localización periódicamente una copia completa de los datos, por ejemplo una vez al mes. Esto es habitual cuando el soporte físico es en cinta.
Esto es distinto del archiving, que consiste en mover datos antiguos que no se están utilizando a una localización distinta. Un backup es siempre una copia, mientras que el archiving consta de los datos originales que son trasladados porque no se utilizan pero no se quieren eliminar definitivamente.
Aunque hay diversas opciones de storage es interesante considerar el servicio “Glacier de Amazon”. Su bajo coste es una gran ventaja, pero el hecho que la restauración no esté asegurada en un tiempo concreto y que pueda tardar algunas horas lo descarta para el vaulting mientras que lo convierte en interesante candidato para archiving, donde no hay exigencias de recuperación de datos en tiempos limitados.
4. RESTAURACIÓN
El objetivo final de un backup es poder restaurarlo en caso de pérdida de los datos. Por lo tanto, tener presente la restauración a la hora de definir una política de backups o escoger una herramienta es clave. Para ello, es importante haber decidido previamente (en la gestión de riesgos) los siguientes puntos:
- RTO (Recovery Time Objective. Es el tiempo máximo en el que se debe alcanzar un nivel de servicio mínimo tras una caída del servicio (por ejemplo, debido a pérdida de datos) para no causar consecuencias inaceptables en el negocio.
- RPO (Recovery Point Objective). Es el periodo de tiempo máximo en el que se pueden perder datos de un servicio. Si el periodo de tiempo es de 6 horas, se deben realizar backups cada menos tiempo y poder recuperar la información antes de agotar el periodo.
5. HERRAMIENTAS
Las herramientas nos permiten implementar la política de backup. Dada la variedad de plataformas, se han creado muchísimas herramientas que actúan a diferentes niveles. Algunos tipos de backups y herramientas (hay muchos más) se muestran a continuación:
5.1. Sincronización
Este tipo de backup permite que dos directorios en localizaciones distintas (en la misma máquina o en hosts separados) contengan los mismos ficheros. Muchas de las herramientas que permiten la sincronización se basan en “rsync” o en su librería.
- Rsync: la herramienta más conocida de sincronización de ficheros, tiene muchas opciones que dan gran flexibilidad.
- Duplicity: se basa en la librería de “rsync” para realizar backups de ficheros comprimidos y encriptados.
- Unison: permite la sincronización de directorios aprovechando características de distintos sistemas y herramientas.
5.2. Copias
El sistema básico de realizar backups es la copia de los ficheros a un espacio aparte. En este caso, se pueden utilizar herramientas de un gran rango de diversidad y complejidad.
- fwbackups: herramienta con una interfaz simple pero con muchas opciones, permite programar backups a distintos niveles.
- Bacula: herramienta muy completa que permite realizar backups de varios niveles (total, diferencial, incremental), de distintos clientes (linux, solaris, windows) y a diversos soportes (cinta y disco). Es software libre aunque tiene opción de soporte comercial.
- Mondorescue: este software permite realizar backup de una instalación entera, y puede dejar las copias en numerosos soportes físicos.
5.3. Bases de datos
Las bases de datos piden un trato especial. Guardar los ficheros que contienen las bases de datos no suele ser un buen sistema de backup, ya que una copia del fichero en un momento cualquiera puede generar una base de datos inconsistente. Por ello, cada servidor suele proporcionar un sistema de copias de seguridad, a menudo basadas en volcados de datos en distintos formatos.
- MySQL: “mysqldump” realiza un volcado en los datos de la base de datos en SQL. Esto permite realizar backups y crear esclavos entre otros usos.
- PostgreSQL: “pg_dump” hace, igual que “mysqldump”, un volcado de los datos en lenguage SQL.
- SQL Server: el servidor de bases de datos de Microsoft ofrece la utilidad SQL Server Management Studio que permite programar las distintas tareas de backups, además de tareas previas y posteriores, especificando cuándo, de qué y a qué nivel se realiza la copia de seguridad de forma que sea consistente y fácilmente recuperable.
5.4. Snapshots
Los snapshots son “fotografías” del sistema o de una parte que permiten recuperarlo en un estado que se sabe que es correcto. Los snapshots se pueden realizar a distintos niveles:
- Sistema de ficheros: hay sistemas de ficheros que permiten realizar backups en forma de snapshots. ZFS dispone de esta utilidad.
- Volúmen de disco: LVM ofrece esta posibilidad para recuperar volúmenes.
- Máquinas virtuales: muchos gestores de máquinas virtuales permiten realizar snapshots de las mismas. KVM, Xen o VMWare entre otros disponen de esta característica.
- Ficheros: con rsnapshot se pueden realizar backups en forma de snapshot aprovechando el rsync y mediante hardlinks de forma transparente. Back In Time también realiza snapshots de directorios, aunque únicamente para entornos de escritorio.
5.5. Continuous Data Protection
Consiste en guardar automáticamente una copia de todos los cambios realizados en los datos, adquiriendo una copia remota de todas las versiones. Esto permite realizar recuperación de los datos de cualquier momento. Aunque hay sistemas optimizados para guardar únicamente las diferencias y ocupar poco espacio en disco, este sistema tiene penalizaciones en la red dada la continua transferencia de datos.
- AIMstor: permite definir fácilmente políticas mediante una interfaz gráfica y soporta distintos tipos de backup, replicación y archiving.
- RecoverPoint: soporta replicación remota de datos mediante protocolos síncronos y asíncronos.
- InMage DR-Scout: tiene un repositorio de capacidad optimizada y soporta diversas plataformas (Windows, Linux, Solaris,…).
6. A TENER EN CUENTA
- Instalación: ¿Está paquetizada o es necesario compilar? ¿Es fácil de instalar? ¿Tiene requerimientos especiales?
- Configuración y mantenimiento: ¿Es fácil de mantener? ¿Es capaz de implementar la política? ¿Cuánto tiempo de aprendizaje requiere? ¿Tiene interfaz gráfica?
- Restauración: ¿La restauración es fácil y rápida? ¿Puede un usuario restaurar un fichero suyo o debe ser siempre el administrador?
- Compatibilidad: ¿Sirve para todos los sistemas de la plataforma? ¿El servidor debe correr en un sistema concreto?
- Soporte físico: ¿Permite backup a cinta, DVD, sistemas de ficheros remotos, disco…?
- Licencia: ¿Es software libre o comercial? ¿Dispone de soporte para empresas?
7. CONCLUSIONES
Aunque es recomendable ser flexible para los pequeños cambios (la política o los recursos pueden sufrir modificaciones), realizar grandes cambios en el sistema de backups puede ser complejo, por lo que es importante realizar un buen estudio para escoger la mejor opción. La clave se encuentra en definir y cubrir las necesidades de cada plataforma ajustando el sistema a los recursos disponibles.
Nota del editor: Como ampliación del tema, existe un artículo relacionado en este mismo Blog que trata sobre DRaaS o Recuperación de Desastres en el CLOUD: DRaaS: La Recuperación de Desastres como Servicio
8. DERECHOS DE AUTOR
Imágenes bajo licencia 123RF
internacional.
Sobre la autora:
Puede verse el artículo original en: Blog de CAPSiDE