¿Se pueden "copiar" los servidores RHEL6?

Mi empresa necesita configurar un servidor de desarrollo y ya tenemos 2 servidores RHEL 6 de producción trabajando bajo un conmutador L4.

Una de las soluciones para configurar el servidor de desarrollo fue simplemente copiar todos los archivos de uno de los servidores de producción y modificarlos un poco.

Nunca lo he hecho antes, pero suena similar a la imagen fantasma ... ¿se puede hacer? ¿Es recomendable? ¿Sería propenso a errores?

Copiar todos los archivos podría funcionar. Dependerá del sistema operativo y del tipo de método de copia.

Un problema general es intentar copiar el sistema mientras se está ejecutando. Por lo general, al menos algunos de los archivos estarán bloqueados y, por lo tanto, no se copiarán correctamente. El uso de algún tipo de software de imágenes mientras el sistema está apagado suele ser más seguro (usted mencionó Ghost, que es un ejemplo)

¿Por qué no convertir los sistemas en ejecución a máquinas virtuales? La mayoría de los hipervisores como VMware o Hyper-V tienen una herramienta para convertir fácilmente un sistema en ejecución en una máquina virtual.

Luego puede trabajar con un sistema que no sea de producción como desee antes de hacer cualquier cosa en un servidor de producción.

Gracias a @WernerCD

VMware

Hyper-V

Se puede hacer?

Definitivamente si. Copié un servidor Linux completo simplemente empacando los archivos tary los extraje nuevamente en el servidor de destino. La única advertencia que recuerdo fue tener que recordar usar --numeric-ownercuando extraje. No puedo hablar por otro sistema operativo y otras herramientas, pero imagino que es factible con todos los principales sistemas operativos.

¿Debería hacerse?

Esta pregunta es un poco más complicada de responder. No recomendaré simplemente clonar un sistema de producción para fines de desarrollo. Es muy posible que contenga muchos datos de usuario, así como material clave, que no desea tener presente en los sistemas de desarrollo.

Pero clonar su sistema de producción puede ser una buena idea para otros fines.

El enfoque que recomendaría para crear un clon del sistema de producción es restaurar desde la copia de seguridad. Puede evitar el impacto en el rendimiento del sistema de producción mediante la restauración desde una copia de seguridad y puede probar el procedimiento de restauración, lo cual es algo bueno.

Es importante mantener el clon que restauró de la copia de seguridad aislado del resto del mundo. Como se restauró a partir de una copia de seguridad de un sistema de producción, puede contener trabajos automatizados, que se comunicarán con otros sistemas de producción, y tendrá las credenciales para hacerlo.

Potencialmente, podría causar mucho daño si el clon se comunicara con sistemas de producción reales.

Pero si lo mantiene aislado, le da la oportunidad de probar que el sistema restaurado funciona según lo previsto. Además, dicho sistema restaurado podría ser un entorno útil para la última prueba de código nuevo antes de que se implemente en producción. Esta puede ser su única oportunidad para probar el código en datos reales del usuario, antes de que esté realmente en condiciones de romper el sistema de producción.

Factibilidad

Claro, es posible, porque no es difícil "instalar" Linux usando medios no convencionales. Podría, por ejemplo, replicar el servidor usando rsync a través de SSH.

1. Arranque la máquina de destino en una imagen de "rescate", ya sea usando un DVD de Red Hat, Ubuntu live boot, Knoppix, lo que sea.
2. Particione y formatee la máquina de destino y monte los sistemas de archivos bajo a /target.
3. rsync todos los sistemas de archivos pertinentes más de SSH (saltándose /proc, /sys, swap).
4. Arreglo /target/etc/fstab, especialmente si UUID hace referencia a las particiones.
5. Ajuste el nombre de host y la configuración de red según corresponda.
6. Instala el cargador de arranque.

El paso 3 podría consistir en múltiples pases rsync, posiblemente ayudados por instantáneas LVM en la máquina fuente, la última pasada con todos los servicios en la máquina fuente detenida para garantizar la consistencia de los datos.

Conveniencia y mejores prácticas

Solo porque puedas no significa que debas. He recomendado el proceso anterior como una forma de hacer una migración del centro de datos. Sin embargo, su caso de uso es bastante diferente. Recurrir a la clonación destaca algunas deficiencias:

• La virtualización sería una buena capacidad y facilitaría la replicación.
• ¿Tiene copias de seguridad de sus servidores de producción? ¿Por qué no solo restaurarlos? Esta sería una buena prueba de su procedimiento de restauración de copia de seguridad.
• ¿Tiene documentación de cómo reproducir todo desde cero? Eventualmente, probablemente necesitará instalar desde cero, tal vez cuando actualice el sistema operativo. Esta sería una buena validación para su documentación.
• Mejor aún, ¿tiene automatización que lo ayude a reproducir su configuración? Un script de shell podría funcionar; una solución de gestión de configuración como CFengine, Puppet, Chef o Ansible sería aún mejor.

Si clona ciegamente el servidor de producción, perderá una valiosa oportunidad para aclarar exactamente qué se está ejecutando en él.