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 BACKUPS3. GUARDADO Y RETENCIÓN DE BACKUPS
4. RESTAURACIÓN
5. HERRAMIENTAS
5.1. Sincronización
5.2. Copias5.3. Bases de datos
5.4. Snapshots
5.5. Continuous Data Protection
6. A TENER EN
CUENTA
7. CONCLUSIONES8. DERECHOS DE AUTOR
1. INTRODUCCIÓN.
Las copias de seguridad de las
plataformas son una parte esencial de la administración de sistemas. Es,
por lo tanto, un tema ampliamente estudiado y para el que se han creado
multitud de herramientas. Sin embargo, 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.
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.
El tiempo de restauración de un
backup en caso de pérdida de datos forma parte del tiempo en que no hay
servicio, por lo que cuanto menos tarde antes se restablecerá el proceso de
negocio soportado.
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
Con la infinidad de herramientas
disponibles, la elección puede hacerse complicada. Para simplificar la búsqueda
y reducir las opciones, es imprescindible definir las necesidades propias y lo
que ofrece cada solución, para encontrar la herramienta que mejor las cubra.
Algunas cuestiones que pueden ayudar en la elección de una herramienta son las
siguientes:
- 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
La variedad de opciones permiten
definir ampliamente la política de backups de forma que se pueda utilizar una o
varias herramientas para la misma plataforma, así como distintos niveles y
retenciones para distintos ficheros. A menudo no hay una solución única y
fija, y raramente la misma política sirve para dos plataformas diferentes.
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.
La presente obra y su título
están protegidos por el derecho de autor. Las denominadas obras
derivadas, es decir, aquellas que son el resultado de la transformación de ésta
para generar otras basadas en ella, también se ven afectadas por dicho derecho.
Sobre la autora:
Alba
Ferrer es Ingeniera
Informática por la Facultad de Informática de Barcelona (FIB/UPC) y Georgia
Tech (USA), y Administradora de Sistemas (SysAdmin) en CAPSiDE. Activa dentro de la “comunidad Perl de
Barcelona” y del grupo “Sudoers de Barcelona”. Miembro de las comunidades de
Software Libre de Ubuntu (ubuntu.cat) y Caliu.
No hay comentarios:
Publicar un comentario
Nota: solo los miembros de este blog pueden publicar comentarios.