recomendaciones para una solución eficiente de respaldo remoto fuera del sitio de vm's

Estoy buscando recomendaciones para hacer una copia de seguridad de mis 6 vm actuales (y pronto creceré hasta 20). Actualmente estoy ejecutando un clúster proxmox de dos nodos (que es una base de Debian que usa kvm para la virtualización con un front-end web personalizado para administrar). Tengo dos cajas casi idénticas con amd phenom II x4 y placas base asus. Cada uno tiene 4 discos duros sata2 de 500 GB, 1 para el sistema operativo y otros datos para la instalación de proxmox, y 3 con mdadm + drbd + lvm para compartir los 1.5 TB de almacenamiento entre las dos máquinas. Monto imágenes lvm en kvm para todas las máquinas virtuales. Actualmente tengo la capacidad de hacer transferencias en vivo de una máquina a otra, generalmente en cuestión de segundos (se tarda unos 2 minutos en el vm más grande que ejecuta win2008 con servidor m $ sql). Estoy usando la utilidad vzdump incorporada de proxmox para tomar instantáneas de la vm ' sy almacenarlos en un disco duro externo en la red. Luego tengo el servicio jungledisk (usando rackspace) para sincronizar la carpeta vzdump para la copia de seguridad remota fuera del sitio.

Todo esto está bien y elegante, pero no es muy escalable. Por un lado, las copias de seguridad en sí mismas pueden demorar algunas horas cada noche. Con las transferencias incrementales de nivel de bloque de jungledisk, la sincronización solo transfiere una pequeña porción de los datos fuera del sitio, pero eso todavía lleva al menos media hora.

Por supuesto, la solución mucho mejor sería algo que me permita tomar instantáneamente la diferencia de dos puntos de tiempo (digamos lo que se escribió de 6 a.m. a 7 a.m.), comprimirlo y luego enviar ese archivo de diferencia al servidor de respaldo que se transferirá instantáneamente al Almacenamiento remoto en rack He mirado un poco en zfs y es la capacidad de enviar / recibir. Eso, junto con una tubería de datos en bzip o algo así, parecería perfecto. Sin embargo, parece que implementar un servidor nexenta con zfs esencialmente requeriría al menos uno o dos servidores de almacenamiento dedicados más para servir volúmenes de bloques iSCSI (a través de zvol's ???) a los servidores proxmox. Preferiría mantener la configuración lo más mínima posible (es decir, NO tener servidores de almacenamiento separados) si es posible.

También he leído brevemente sobre zumastor. Parece que también podría hacer lo que quiero, pero parece haber detenido el desarrollo en 2008.

Entonces, zfs, zumastor u otro?

Es posible que esto no sea posible en su situación, por lo que espero no ser rechazado en ese caso, pero podría ser más eficiente cambiar su estrategia de respaldo. Si realiza una copia de seguridad de datos específicos en lugar de las instantáneas de VM, sus copias de seguridad se ejecutarían mucho más rápido y sería más fácil capturar los cambios.

Dependiendo de sus máquinas virtuales y para qué se utilizan, puede hacer que realicen una copia de seguridad de los datos en el lugar donde almacena las instantáneas ahora a diario (o cualquier programa que sea apropiado), y luego JungleDisk puede hacer una copia de seguridad solo de los datos. Eso transferiría de manera más eficiente los archivos modificados, y se reduciría el espacio requerido para las copias de seguridad y el tiempo necesario. Además, aún podría tomar instantáneas para retener, y hacer eso con mucha menos frecuencia (semanalmente, por ejemplo).

En este caso, siempre puede abrir una nueva VM y restaurar los datos, o usar una instantánea anterior para restaurar la VM, y luego usar la copia de seguridad de los datos para restaurar al punto más reciente.

Si estuviera haciendo copias de seguridad externas, elegiría las siguientes opciones:

(a) script de shell que copia SCP al servidor remoto. De esta manera, podría agregar un trabajo cron que ejecute automáticamente el script que crea la copia de seguridad. Además, puede hacerlo para que cree un archivo de almacenamiento temporal antes de transferir realmente los archivos, ahorrando así el ancho de banda al no transferir mientras se bordea.

o

(b) Instale una herramienta de administración del servidor como Webmin y consiga que haga copias de seguridad automáticas. Actualmente estoy cantando esto en mis servidores de producción en este momento sin ningún problema, simplemente funciona a la perfección. También recomendaría cloudmin (pago) para administrar muchas máquinas virtuales, ya que proporciona una solución todo en uno.

algunos enlaces extra:

http://www.debianhelp.co.uk/backup.htm

http://ubuntuforums.org/showthread.php?t=35087

Espero que ayude, RayQuang

es posible que desee echar un vistazo a backuppc.

backuppc puede funcionar sobre rsync, lo que hace una copia incremental.

Además, puede escribir fácilmente una lista negra de carpetas que no tiene que ser copiada. Por ejemplo: temp / / tmp .garbages / ...

http://backuppc.sourceforge.net/

backuppc tiene una interfaz web limpia que le permite descargar algunas partes de una copia de seguridad directamente como un archivo zip. Puede ser monitoreado por nagios usando check_backuppc.

No estoy seguro de cuánto cambio arquitectónico planeabas hacer para aumentar tu escalabilidad. Sin embargo, si estuviera abierto a cambiar de plataforma VM, podría mirar VMWare.

Hay muchas buenas soluciones de respaldo VMWare, personalmente he usado VzionCore. Luego puede hacer algunas cosas ingeniosas con instantáneas y recuperación en un punto en el tiempo. Incluso existe la posibilidad de conmutar por error a un sitio remoto.

zfs lo hace muy bien, ya lo mencionaste sabiendo eso y la desventaja de no funcionar muy bien en la escala de 2 servidores. Tampoco le dará la conmutación por error DRDB, es decir, Nexenta será un punto único de falla.

Puede considerar intentar obtener VirtualBox en OpenSolaris o NexentaCore, pero no tan simple como ProxMox + DRDB para poder reutilizar sus máquinas existentes.

Si mide sus cambios y los encuentra lo suficientemente bajos, puede probar DRDB con un tercer espejo externo: solo funcionará si el número de escrituras es extremadamente bajo en sus máquinas virtuales.

Steve Radich - Hosting Windows y rendimiento SQL desde 1995 - http://www.BitShop.com/Blogs.aspx

Ejecuto un gran clúster proxmox y tengo que sugerirle que cambie su estrategia de copia de seguridad lejos de las copias de seguridad integradas de estilo de instantánea vzdump, que toman años, siempre son completas, por lo tanto de gran tamaño y hacen que la restauración de archivos individuales sea extremadamente larga.

Considere una solución de copia de seguridad de archivos 'en invitado' de la cual hay muchas. Backuppc, Urbackup, bacula, amanda, etc.

Será mucho más rápido, consumirá mucho menos espacio y será mucho más fácil restaurar archivos específicos.

Creo que he encontrado la respuesta definitiva a mi pregunta:

BUP https://github.com/bup/bup

caracteristicas:

• Utiliza un algoritmo de suma de comprobación continua (similar a rsync) para dividir archivos grandes en fragmentos. El resultado más útil de esto es que puede hacer una copia de seguridad de las imágenes de disco, las bases de datos y los archivos XML de máquinas virtuales (VM) enormes de forma incremental, a pesar de que generalmente están todos en un archivo enorme y no utilizan toneladas de espacio en disco para múltiples versiones.

  Utiliza el formato de archivo de paquete de git (el sistema de control de versiones de código abierto), por lo que puede acceder a los datos almacenados incluso si no le gusta la interfaz de usuario de bup.

  A diferencia de git, escribe paquetes de archivos directamente (en lugar de tener una etapa separada de recolección / reempaque de basura), por lo que es rápido incluso con grandes cantidades de datos de forma gratuita. Los formatos de índice mejorados de bup también le permiten rastrear muchos más nombres de archivo que git (millones) y rastrear muchos más objetos (cientos o miles de gigabytes).

  Los datos se comparten "automáticamente" entre las copias de seguridad incrementales sin tener que saber qué copia de seguridad se basa en cuál, incluso si las copias de seguridad se realizan desde dos computadoras diferentes que ni siquiera se conocen entre sí. Simplemente le dice a bup que haga una copia de seguridad, y solo guarda la cantidad mínima de datos necesarios.

  Puede realizar una copia de seguridad directamente en un servidor bup remoto, sin necesidad de toneladas de espacio temporal en disco en la computadora que se está realizando la copia de seguridad. Y si su respaldo se interrumpe a la mitad, la próxima ejecución continuará donde lo dejó. Y es fácil configurar un servidor bup: simplemente instale bup en cualquier máquina donde tenga acceso ssh.

  Bup puede usar la redundancia "par2" para recuperar copias de seguridad corruptas incluso si su disco no ha detectado sectores defectuosos.

  Incluso cuando una copia de seguridad es incremental, no tiene que preocuparse por restaurar la copia de seguridad completa, luego cada uno de los incrementales a su vez; una copia de seguridad incremental actúa como si fuera una copia de seguridad completa, solo ocupa menos espacio en disco.

  Puede montar su repositorio bup como un sistema de archivos FUSE y acceder al contenido de esa manera, e incluso exportarlo a través de Samba.

Editar: (19 de agosto de 2015) Y sale otra gran solución que es aún mejor: https://github.com/datto/dattobd

Permite instantáneas en vivo, esencialmente dando características similares a las de COW a cualquier sistema de archivos antiguo en Linux.

Editar: (15 de julio de 2016) E incluso otra gran solución que elimina el agua: https://github.com/borgbackup/borg

Es particularmente mejor que bup en la poda. Parece tener un gran soporte para la compresión, el cifrado y la deduplicación eficiente. dattobd + borg ftw !!!