Soy Oscar Mas y os quiero enseñar cómo realizar los backups de nuestras plataformas de Zimbra en Amazon S3, mediante el sistema de AWS Storage Gateway. Este procedimiento, se podría usar tanto para los backups como para el sistema de HSM de nuestro Zimbra y de esta manera reducir costes.
Antes de empezar a realizar el procedimiento, es de vital importancia tener una conexión a internet con una baja latencia y un ancho de banda considerable. Una de las posibles soluciones, es solicitar un AWS Direct Connect http://aws.amazon.com/es/directconnect/, el cual nos ofrece un ancho de banda dedicado con los CDP de Amazon.

El ser un procedimiento largo (pero no complicado), lo he desglosado en varios puntos:
- Descarga
- Configuración
- Conexión
1.- Descarga
En este apartado, descargaremos el Store Gateway y lo implementaremos en nuestra infraestructura de VMWare.
Lo primero que haremos, es ir a nuestra consola de AWS Storage Gateway: https://console.aws.amazon.com/storagegateway. Desde aquí, empezaremos la solicitud del appliance que desplegaremos en nuestra ubicación local y posteriormente lo enlazaremos con AWS.
En nuestro caso, ejecutaremos el AWS Storage Gateway en Gateway-Cached. Para saber más sobre esta opción, os dejo el link de la documentación oficial de Amazon: http://docs.aws.amazon.com/storagegateway/latest/userguide/storage-gateway-cached-concepts.html
Le indicaremos que el appliance que nuestra infraestructura está basado en VMWare ESXi:
Nos descargaremos el appliance de 695 MB, en una ubicación local de nuestra infraestructura:
Descomprimimos el ZIP que nos hemos descargado y podremos observar que es un formato OVF, el cual lo desplegaremos desde nuestro Virtual Center:
Seleccionaremos el OVF que nos hemos descargado y le haremos un deploy:
He escogido Thin Provision, pero no es nada recomendado
Es de vital importancia, que nuestro Host Virtual (ESXi) y el equipo que hemos desplegado, tengan la hora correctamente, ya que si hay un desfase de 15 min tendremos problemas al integrar AWS Storage Gateway con el sistema de Amazon Web Services (AWS).
Como podréis observar al arrancar el sistema, el appliance está basado en CentOS. Una vez arrancado veríamos esta opción:
2.- Configuración
En este apartado integraremos el appliance que hemos desplegado anteriormente con el sistema de AWS Storage Gateway, que está en Amazon. Primero de todo, nos apuntaremos en un papel la IP del appliance (en mi caso es 192.168.250.100) y continuaremos con el Wizard, el cual nos solicitará la IP del appliance que hemos desplegado:
Le añadiremos un par de discos duros al aplliance de 50 GB, uno para el upload buffer y el cache storage. Cabe destacar, que desde la consola de AWS sotrage Gateway, podremos gestionar el ancho de banda usado por nuestro appliance, para tener un control del uso de nuestro acceso a internet. Crearemos los volúmenes y le asignaremos una dirección de correo para el sistema de alertas.
3.- Conexión
En este ultimo apartado, configuraremos el driver iSCSI dew nuestro equipo de Zimbra basado en CentOS 7, para conectarse con el volumen que hemos creado en nuestro apliance. Cabe destacar, que le podríamos entregar el volumen a un ESXi, Sistemas basados en Microsoft, etc. Os dejo el enlace de la documentación oficial: http://docs.aws.amazon.com/storagegateway/latest/userguide/ConfiguringiSCSIClientInitiatorRedHatClient.html
Instalaremos el initiator de iSCSI en nuestro sistema de Zimbra:
[syntax type=”php”][root@zimbra ~]# yum install -y iscsi-initiator-utils[/syntax]
Verificaremos que el demonio del sistema iSCSI este arrancado y que en futuros reinicios del equipo, se arranque de manera automática:
[syntax type=”php”]
[root@zimbra ~]# systemctl start iscsid
[root@zimbra ~]# systemctl status iscsid
[root@zimbra ~]# systemctl enable iscsid
[/syntax]
Haremos un discovery del target:
[syntax type=”php”][root@zimbra ~]# iscsiadm –mode discovery –type sendtargets –portal 192.168.250.100:3260[/syntax]
Nos conectaremos y podremos observar que nos ha creado una nueva partición llamada “sdc”, la cual formateremos y lo pondremos en el fstab, para que en futuros reinicios del equipo se monte la partición de manera automática:
[syntax type=”php”]
[root@zimbra ~]# iscsiadm -m node –login
[root@zimbra ~]# iscsiadm -m session -o show
[root@zimbra ~]# cat /proc/partitions [/syntax]
[syntax type=”php”]
[root@zimbra ~]# chattr +i /opt/zimbra/backup
[root@zimbra ~]# cfdisk /dev/sdc
[root@zimbra ~]# mkfs.ext4 /dev/sdc1
[root@zimbra ~]# vim /etc/fstab
/dev/sdc1 /opt/zimbra/backup ext4 defaults,_netdev 0 0
[root@zimbra ~]# mount -a
[root@zimbra ~]# df -h
[/syntax]
Espero que os sirva de ayuda. Un saludo






















LA verdad es que me parece una buena solución.Lo que pasa es que cuando tenemos en cuenta temas legales etc.. es dificil de justificarla.
Al final otra de las opciones es usar un backup a una unidad de disco deduplicada, por ejemplo el post que pusisteís atacando a una unidad de un server w2k12 con dedup.
Nosotros lo hacemos atacando a un almacenameinto de backup a disco con dedup, específco Quantum.
Sin embargo tengo una duda que estoy seguro que no os es desconocida.
Mi problema es que quiero hacer una rotación GFS para backup. A la hora de implementarla intento usar carpetas para poder dejar en ellas los backups diarios,semanales, mensuales y anuales. El problema es que la herramienta de backup de zimbra NE, no permite hacer backups incrementales, sobre carpetas que no sean el default backup target, no asi para fulls que no tiene problema.
Conociaís este problema , sabeís como solucionarlo.
Esta es mi pólitica de backup
#####################################################################
#Backup Semanales:
0 18 * * 6 /opt/zimbra/bin/zmbackup -f -a all -t /backup/semanal –mail-report
0 0 * * * /opt/zimbra/bin/zmbackup -del 28d -t /backup/semanal
#Backup Diarios
0 18 * * 0-5 /opt/zimbra/bin/zmbackup -f –mail-report
0 1 * * * /opt/zimbra/bin/zmbackup -del 15d
#Backup Mensuales (Primer domingo del mes):
0 4 * * sun [ $(date +%d) -le 07 ] && /opt/zimbra/bin/zmbackup -f -a all -t /backup/mensual –mail-report
0 2 * * * /opt/zimbra/bin/zmbackup -del 365d -t /backup/mensual
# #######################################
Como veís hago el backup sobre una partición /backup que esta en un disco de mi quantum.
Tambien podeís comprobar que los backups son full por lo que os he comentado , que no se puede hacer incrementales sobre carpetas que no sean el backup target. Son sin comprimir
porque no tiene sentido en mi caso, dado que destino , comprime y deduplica .
Finalmente en las mensuales, podeís comprobar que hace el backup el primer domingo del mes. Esto me costo en especial , hasta que di con el comando.
NO se si teneís alguna idea que me permita trabajar con incrementales.
SAludos
Buenas, lo primero gracias por el post.hoy he conocido el appliance storage gateway y me ha surgido una duda. Al conectarme al appliance tenia la hora de Irlanda (en amazon pone lo mismo), pero el esxi esta con horario de España, me puede generar problemas esta diferencia de horario?
Saludos y gracias
Buenos días,
Tengo una pregunta con la implementación, tenemos un proyecto donde un cliente nos solicita que el espacio en disco pueda ser escalable debido a que usaran la configuración en IMAP. Mi duda es se puede utilizar la capa S3 para guardar la información de los correos en vez de ser alojada en los EBS.
O que se puede sugerir para este caso.