Hay muchos problemas potenciales con lo que está tratando de hacer, y, por supuesto, como sabe, sería mejor desconectar el servidor y clonarlo mientras no se almacenan datos dinámicamente.
Sin embargo, lo que busca hacer es totalmente plausible, como lo he hecho antes. Si lo usa dd, puede clonar el servidor completo en el nivel de bloque a otra unidad u otro servidor. Sin embargo, requerirá una configuración adicional en el nuevo servidor, y probablemente no podrá simplemente apagar el otro y encender el nuevo. Para que podamos entender esto, necesitamos saber algunas cosas sobre el hardware y software de su servidor.
En primer lugar, para determinar la mejor estrategia de datos, sería útil saber qué se actualiza regularmente. ¿Tiene un servidor SQL que se actualiza dinámicamente pero tiene contenido estático? Alternativamente, ¿tiene un equipo de desarrolladores sobre un sistema de subversión como git enviando actualizaciones constantes de datos a su contenido? Dependiendo de lo que se actualice, se determinará el mejor curso de acción completo.
Si, por ejemplo, solo el SQL se actualiza regularmente, puede migrar a un nuevo servidor mientras ese servidor está activo de la siguiente manera:
dd para clonar todos los datos del nuevo servidor.- Comience a configurar el nuevo servidor, puede tomar algo de trabajo, especialmente si es un hardware diferente, pero aún puede ser más rápido que la configuración desde cero.
- También puede tomar algunos cambios de DNS, ya que no puede usar el mismo DNS en otro servidor si necesita trabajar en el segundo servidor en vivo mientras el primer servidor aún está activo.
- Una vez que el nuevo servidor esté completo y se ejecute de forma independiente, realice una copia de seguridad final del servidor sql en el servidor original e impórtelo al nuevo servidor.
Es posible que deba desconectar temporalmente su servidor original para asegurarse de no perder ningún dato. Alternativamente, para tener un tiempo de inactividad cero, puede activar el segundo en vivo, apuntar el dns al nuevo servidor y luego actualizar cualquier entrada de dns manualmente en el nuevo servidor, para que efectivamente haya un tiempo de inactividad cero. Sin embargo, esto es más complicado que unos pocos minutos de tiempo de inactividad para hacer una copia de seguridad del sql y restaurarlo en el nuevo servidor, pero puede ser necesario para cero tiempo de inactividad.
Por supuesto, este es solo un ejemplo de caso de uso, y dependiendo de su configuración y varias variables, es posible que necesite crear su propia estrategia para la migración en función de su caso específico.
El otro problema está relacionado con la configuración del hardware del servidor. ¿El nuevo servidor es 100% idéntico en hardware al antiguo servidor? Si es así, entonces la configuración es más fácil. Sin embargo, si, por otro lado, es una configuración de hardware totalmente diferente, entonces es posible que deba implementar una estrategia diferente, que es simplemente configurar el segundo servidor con anticipación y luego hacer una copia de seguridad de todos sus datos y bases de datos sql en el primer servidor y migrarlos manualmente, cambiando la configuración según lo desee.
La migración del servidor no es en absoluto trivial, y para tener un movimiento exitoso, debe tener un conocimiento profundo de los servidores, o del personal disponible que tenga el mismo. En cualquier caso, se recomienda encarecidamente que realice una copia de seguridad completa y la almacene en una tercera fuente, incluso en su computadora local, de modo que si ocurre el peor de los casos (ambos servidores se bloquean y mueren irreparablemente), todavía tiene otro copia de sus datos para reconstruir sus servidores.
Espero que esto ayude, ¡y buena suerte con tu servidor!