[[TOC(headinfÍndice)]]
Actualmente no están utilizando las imágenes sincronizadas por tener una serie de problemas:
En está página mostraremos los resultados de las últimas pruebas que estamos haciendo.
Observando como trabaja rsnapshop vemos que al crear una nueva copia de seguridad de un dispositivo toma como punto de partida una anterior y luego aplica rsync entre el equipo origen y el nuevo backup. OpenGnsys podría utilizar este procedimiento para imágenes similares.
| Primera copia: | rsync user@equipo_remoto::/carpeta backup1 |
|---|---|
| Segunda copia: | cp -al backup1 backup2 rsync user@equipo_remoto::/carpeta backup2 |
La opción -l del comado cp crea enlaces “duros” a los archivos en vez que copiarlos, de esta forma no se ocupa nuevo espacio en el disco duro y es mucho más rápido.
En rsync es imprescindible __no usar la opción “--inplace”
Si no se usa esta opción, rsync copia el archivo que está sincronizando en un fichero temporal y al final sustituye el original, eliminando el enlace entre los archivos de distintas imágenes.
Si ponemos esta opción rsync modifica directamente el archivo, no rompe el enlace y modifica todas la imágenes que tengamos.
Podría desaparecer el concepto de diferencial, ya que todas contienen los datos completos. Tendríamos imágenes clonadas, tomando como partida una imagen parecida y luego sincronizándola con la partición del equipo modelo.
Las imágenes serían tipo directorio, ya que es la única forma de hacer enlaces entre archivos de varias imágenes.
Más información en [Easy Automated Snapshot-Style Backups with Linux and Rsync (rsnapshop se basa en este artículo).
__Pruebas velocidad al crear una imagen
Tamaño de la imagen: 3,7Gb → 0m 56s
cdc@ogdevel:/opt/opengnsys/bin$ sudo ./cloneimage Ubuntu16Sync UbuntuClone
Copiamos los archivos de una imagen a otra.
* cd /opt/opengnsys/images
* cp -lrP /opt/opengnsys/images/Ubuntu16Sync /opt/opengnsys/images/UbuntuClone
La copia ha terminado correctamente.
Fin del script. Tiempo total: 0m 56s
Permite montar con compresión de forma transparente. Pero:
__Prueba creación de una
| Partición cliente | df /dev/sda1 14G 3,8G 9,5G 29% /mnt/sda1 |
|---|---|
| Imagen en cliente | ls OGIMG !UbuntuSync df /dev/sda4 39G 1,9G 35G 6% /opt/opengnsys/cache |
| Imagen en servidor | du -sh !UbuntuSync 3,7G !UbuntuSync |
__Prueba creación de dos imágenes una clonada de
Tamaño de los datos en las particiones del cliente (con df):
| Partición 1 cliente | /dev/sda1 14632408 3877776 9988280 28% /mnt/sda1 | 3,7G |
|---|---|---|
| Partición 2 cliente | /dev/sda2 29397972 20644320 7237848 75% /mnt/sda2 | 20G |
Al crear la segunda imagen el primer paso es clonar la imagen del mismo sistema operativo que tenga el tamaño más parecido.
Tamaño de las imágenes en la partición cache (con df):
| Creo imagen de la primera partición | /dev/sda4 40000000 2030032 36181552 6% /opt/opengnsys/cache | 2,0G |
|---|---|---|
| Creo imagen de la segunda partición | /dev/sda4 40000000 11574108 27603108 30% /opt/opengnsys/cache | *11G * |
Nota: al copiar la imagen en Btrfs es necesario incluir la opción -P para que no siga los enlaces simbólicos. En ext4 no se presenta este problema.
Creo diferencial
'''En servidor: cp -al Ubuntu14 Ubuntu14bis
En cliente: rsync -aHAX --password-file/scripts/passrsync --exclude 'coredump' --numeric-ids --progress --inplace --delete /mnt/sda1/ opengnsys@$ogrepo::syncimages/Ubuntu14bis'''
Error: diff Ubuntu14/etc/hosts Ubuntu14bis/etc/hosts → son iguales
Solución: Para que no se mantenga el enlace y no reescriba los ficheros de otras imágenes hay que eliminar la opción –inplace.
Hasta ahora para transferir una imagen a la partición destino se utiliza rsync, ya esté en el repositorio o en cache. Vamos a utilizar multicast si la transferencia es desde el repositorio y tar de la partición cache a la definitiva si está en local.
Se realizan varios pasos:
La primera vez que copiamos a la cache el comando restaurar realiza dos pasos:primero pasa la imagen del servidor a la cache y luego de la cache. Aunque estos pasos son independientes en las pruebas se aprecia que el paso de transferir la imagen de la cache a la partición dura mucho más si se ha realizado antes un updateCache de la imagen completa.
Repetimos la última prueba sin borrar la cache, ni modificar la imagen en el servidor (4 pruebas)
| updateCache | rsync | total |
|---|---|---|
| 0m 35s | 2m 4s | 2m 51s |
Nota: no hemos probado que pasa si la modificación de la imagen en el servidor es menor.
Encontramos varios procedimientos:
sshfs -o nonempty,sshfs_sync,compression=yes username@host:/path/archives/ /mounted/compress
Según su página en [github] "El archivo se vuelve ilegible cuando llega a una condición de espacio insuficiente." Descartado.
Parece que el proyecto está abandonado: últimas informaciones de 2009. Descartado
Permite montar con compresión de forma transparente. Pero:
En un equipo cliente al actualizar una imagen en la cache en zfs por multicast se queda completamente colgado. Descartamos está opción
Las pruebas se hacen con Ubuntu16, ya que los nuevos kernel traen mejor soporte para este sistema de ficheros.
ZFS permite gestionar varios dispositivos (discos o archivos) para crear un pool y en el puede definir los sistemas de ficheros que queramos.
Por comodidad usamos un archivo para el dispositivo.
Creamos un sistema de fichero con compresión y acl:
truncate --size="10"G /opt/opengnsys/images/store
zpool create sync /opt/opengnsys/images/store
zfs create sync/images
zfs set compression=on sync/images
zfs set acltype=posixacl sync
Opciones de montaje:
Mount
sync/images on /sync/images type zfs (rw,relatime,xattr,posixacl)
Configuramos el demonio rsync en el servidor para compartir el directorio de las imágenes sincronizadas. En /etc/rsyncd.conf:
[ogimages]
comment = Carpeta de imagenes sincronizadas
path = /sync/images
read only = no
list = yes
uid = root
gid = root
auth users = opengnsys
secrets file = /etc/rsyncd.secrets
Tamaño de los datos
En Ubuntu 16.04
| Recién creado | df -h → sync/images 10094464 0 10094464 0% /sync/images |
|---|---|
| Creamos imagen Ubuntu14 origen 1.1Gb | df -h → sync/images 9.7G 584M 9.1G 6% /sync/images sudo du -sh Ubuntu14 → 609M Ubuntu14 |
| Creo Ubuntu 16 origen 3,9G | df -h → sync/images 9.7G 2.6G 7.1G 27% /sync/images sudo du -sh * → 609M Ubuntu14 → 2.1G Ubuntu16 |
|---|---|
| Creo diferencial cp -al Ubuntu14 Ubuntu14bis rsync (sin opción --inplace) | df -h → sync/images 9.7G 2.6G 7.1G 27% /sync/images sudo du -sh * → 609M otra → 2.1G Ubuntu16 → 629M Ubuntu14bis |
Rsync compara correctamente los ficheros de la partición origen a la imagen comprimida.
Observamos que hay diferencias entre los archivos de las distintas imágenes:
diff Ubuntu14/etc/hosts Ubuntu14bis/etc/hosts
10a11,12
>
> 192.168.2.10 ogrepo
Sustituir el rsync para pasar de la partición cache a la partición definitiva por el comando tar.
De la imagen del servidor a la cache transfiere por multicast y de la cache a la partición se pasa con un archivo tar:
cd $OGCAC$OGIMG/$NOMBRE_IMG
tar -c | - tar -x -C /mnt/sdaX
Se han hecho pruebas de velocidad y se descarta.
Restauramos una imagen básica borrando antes la cache y la partición. El comando utilizado es el siguiente:
RestoreBaseImage CACHE UbuntuSync 1 1 MULTICAST 9010:full-duplex:239.194.17.2:200M:20:60
Resumen de 4 pruebas
| updateCache | TAR | rsync | total |
|---|---|---|---|
| 5m 16s | 5m 31s | 39s | 11m45s |
Eliminamos el paso del TAR (tampoco hay que crear las diferencias) (2 pruebas)
| updateCache | rsync | total |
|---|---|---|
| 5m 24s | 5m 5s | 10m 45s |
Al descartar el tar se ha pensado como alternativa el comando cp, también se descarta. Copiar la misma imagen de la cache a la partición tarda prácticamente lo mismo.
| cp -rp OGIMG/UbuntuSync/* /mnt/sda1 |
|---|
| 1m 56s |