Migrar imagen de disco sin formato a través de LAN

Aquí está mi situación:

• Dos servidores dedicados en el mismo centro de datos con ethernet gigabit entre ellos.
• Ambos servidores dedicados arrancaron en un entorno de rescate basado en Debian Squeeze con herramientas y utilidades adicionales agregadas. También mucho espacio tmp (32 GB de RAM en ambas cajas) para descargar software, instalar paquetes y / o compilar según sea necesario.
• Ambos servidores dedicados tienen aproximadamente 3 TB de espacio utilizable.
• El servidor "fuente" tiene 4 discos de 1.5TB en Hardware RAID-10 con un controlador Adaptec de 4 puertos.
• El servidor "destino" tiene 2 discos de 3TB en hardware RAID-1 con un controlador de puerto Adaptec 2, la misma generación que el otro, pero con un número diferente de puertos.
• El número de bloques utilizables /dev/sdadifiere en menos de 10 MB, pero la matriz del servidor de destino es, por alguna razón, un poco más pequeña.
• Ambas matrices RAID están configuradas para usar toda la superficie del disco de todos los discos constituyentes para crear un único volumen RAID.
• El sistema operativo arranca en modo MBR; no se usa el arranque UEFI.

Lo que quiero hacer:

• Copie, en la capa de bloques, toda la imagen del sistema operativo (esto solo consiste en el cargador de arranque GRUB2 en la tabla de partición GPT, / partición de arranque y / partición) desde el servidor "fuente" al servidor "destino".
• Si es posible , la copia debe realizarse "en vivo": esto significa que no tengo suficiente espacio para almacenar un archivo adecuado de la imagen del disco en el lado de destino, a menos que esté desempacando la imagen del disco en el disco duro como copia que está teniendo lugar . La conexión de ethernet gigabit entre los servidores es lo suficientemente confiable como para que me sienta cómodo con esto y, por supuesto, ejecutaré fscken ambos extremos (origen y destino) para verificar que el sistema de archivos esté bien antes y después de la transferencia.
• Si es posible , no transfiera bloques a través de la red, que no son utilizados por los sistemas de archivos constituyentes en cada partición (todas las particiones están formateadas como ext4). Esto se debe a que más del 50% del disco "fuente" es espacio libre en la /partición.
• Ajuste el tamaño de la /partición para que, cuando se copie, se redimensione para ajustarse al tamaño apenas más pequeño del disco de destino.
• Una vez que la copia se realiza correctamente, monte cada volumen y arregle las referencias a IP estáticas para reflejar las IP del nuevo servidor. (Puede hacer esto bien sin ninguna otra ayuda)

Mis preguntas:

• ¿Debería calcular primero la diferencia (en bytes) entre el tamaño de /dev/sdacada servidor y luego usar e2resizepara reducir de forma no destructiva el tamaño de la /partición en el lado de origen para que se ajuste al espacio del lado de destino?
• ¿Debo ejecutar dden el dispositivo de bloque sin formato, /dev/sdadesde el origen hasta el destino (finalizado ssh), o debería crear un diseño de partición equivalente en el destino y ejecutarlo dden cada partición ? Tenga en cuenta que el manejo de una partición a la vez me deja el problema del gestor de arranque, pero si no lo hago una partición a la vez, dddebe saber dejar de transferir datos una vez que ha escrito tantos bytes como puede contener el destino (que con suerte "cerrará" el final de la /partición en el último bloque, que está lógicamente "a la derecha de" todas las otras particiones en el diseño de la partición de la fuente).

Unos cuantos misceláneos. detalles específicos:

• El sistema operativo host en el cuadro de origen es Ubuntu Server 12.04 que ejecuta varios invitados OpenVZ
• Dado que ambos cuadros se inician en rescate, el acceso directo al disco es posible sin esperar ningún cambio en los datos subyacentes por parte del sistema operativo en ejecución.

Esto es desordenado, pero factible.

Presumo aquí que /está encendido /dev/sda3y que /bootestá encendido /dev/sda1.

1. Reduzca el sistema de archivos en el servidor anterior a su tamaño mínimo posible.

   oldserver # resize2fs -M /dev/sda3
   

2. Particione el disco del nuevo servidor con un tamaño idéntico /boot, espacio de intercambio y una nueva /partición (y cualquier otra cosa que necesite).

   newserver # parted /dev/sda
   

3. Copie los sistemas de archivos /y /boot.

   oldserver # dd if=/dev/sda1 | ssh root@newserver "dd of=/dev/sda1"
   oldserver # dd if=/dev/sda3 | ssh root@newserver "dd of=/dev/sda3"
   

   Debido a que la partición en el nuevo servidor será un poco más pequeña que la del servidor anterior, recibirá un No space left on devicemensaje espurio al final de este. Sin embargo, dado que redujo el sistema de archivos en el paso 1, esto no importa.

4. Cambie el tamaño del sistema de archivos en el nuevo servidor al tamaño de la partición.

   newserver # resize2fs /dev/sda3
   

5. Instale GRUB en el nuevo disco.

   newserver # mount /dev/sda3 /mnt
   newserver # mount /dev/sda1 /mnt/boot
   newserver # mount -o bind /dev /mnt/dev
   newserver # mount -o proc proc /mnt/proc
   newserver # chroot /mnt /bin/bash
   
   newserver(chroot) # grub-install /dev/sda
   newserver(chroot) # exit
   

6. Termine el resto de sus reparaciones (dirección IP, etc.).

Probablemente pueda encontrar una manera de evitar copiar el espacio libre de la partición, pero probablemente le llevará más tiempo investigar que simplemente copiarlo todo ...

Tenía mkfsnuevos sistemas de archivos en el nuevo servidor, luego rsynclos del servidor anterior. Eso es reiniciable, consistente y cada archivo es fácilmente verificable individualmente. Cuando descarta secciones no utilizadas del sistema de archivos (no una copia forense), no veo ninguna razón para no usar este método. Tendría que volver a ejecutar GRUB, pero eso no debería ser un desafío.

Explicar una copia en bruto que tenga en cuenta el sistema de archivos me llevaría un tiempo, por lo que, a menos que comente por qué mi solución rsync no funciona, me ahorraré el tipeo.

Si REALMENTE desea transferir datos a un nivel de dispositivo de bloque, puedo pensar en un truco bastante útil que estaba usando para migrar servidores con un tiempo de inactividad mínimo involucrado.

La cuestión es que puede crear un espejo degradado en el servidor de origen con su partición de datos como la única mitad activa del espejo, luego exportar la partición de destino desde el segundo servidor a través de AOE (supongo que ambos servidores están en el mismo dominio de transmisión). En el servidor de origen, luego conecta el dispositivo de bloqueo de red a su espejo degradado para que comience la reconstrucción. Espere hasta que se complete la reconstrucción, detenga su espejo, retire el dispositivo exportado AOE y estará bien.

Siguen un poco más de detalles (intentaré mantenerlo breve).

Componentes:

• mdadmcon su modo de construcción (espejo ad-hoc sin metadatos);
• vblade para exportar dispositivo de bloque como dispositivo de red AOE;
• aoe-tools para importar un dispositivo de bloqueo de red AOE.

Debe crear una tabla de particiones en su servidor de destino, luego reducir la partición de origen para que se ajuste al destino. Puede instalar GRUB fácilmente en su nuevo MBR; sincronizar solo particiones sobre una tabla de particiones recién creada es un poco menos propenso a errores.

En el lado receptor, debe exportar su partición con la vbladeherramienta, en el servidor de origen puede ver los dispositivos exportados después de la instalación aoe-tools(ejecute aoe-discovery busque /dev/ether/dispositivos).

Luego, debe compilar el dispositivo raid1 en el servidor de origen con su unidad de origen :

mdadm --build /dev/md0 -n2 -l1 --force /dev/sda

Después de esto, puede examinar el espejo recién construido:

mdadm --detail /dev/md0
cat /proc/mdstat

En este punto, puede adjuntar de forma segura la partición de destino exportada a este espejo:

mdadm /dev/md0 --add /dev/ether/eX.Y

Luego solo vigila el progreso de la sincronización:

watch -n5 cat /proc/mdstat

Una vez realizada la sincronización, simplemente detenga el espejo: mdadm --stop /dev/md0en el servidor de origen, finalice el vbladeproceso en el servidor de destino, instale GRUB en el segundo servidor, cambie sus direcciones IP, etc.

En realidad, con este truco es posible mover el servidor entre cajas casi en vivo, con tiempo de inactividad solo para reiniciar cajas sincronizadas.

Por razones de rendimiento, también le sugiero que aumente la MTU de su enlace (o configure una VLAN separada con marcos jumbo habilitados, si es posible).

Tenga en cuenta que también puede usar algo como nbd-server/ nbd-client(o incluso iSCSI, si lo desea) como una alternativa a AOE, pero AOE ( vblade+ aoe-tools) tiene una interfaz muy simple y un gran rendimiento (sin sobrecarga de TCP / IP),