Minha empresa precisa configurar um servidor de desenvolvimento e já temos dois servidores RHEL 6 de produção trabalhando sob um switch L4.
Uma das soluções para configurar o servidor dev foi copiar todos os arquivos de um dos servidores de produção e ajustá-lo um pouco.
Eu nunca fiz isso antes, mas soa semelhante à imagem fantasma ... pode ser feito? É recomendado? Seria propenso a erros?
Copiar todos os arquivos pode funcionar. Vai depender do sistema operacional e do tipo de método de cópia.
Um problema geral é tentar copiar o sistema enquanto ele está sendo executado. Normalmente, pelo menos alguns dos arquivos serão bloqueados e, portanto, não serão copiados corretamente. Usar algum tipo de software de imagem enquanto o sistema está desligado é geralmente mais seguro (você mencionou o Ghost, que é um exemplo)
Por que não converter os sistemas em execução em máquinas virtuais? A maioria dos hipervisores, como o VMware ou o Hyper-V, tem uma ferramenta para converter um sistema em execução em uma máquina virtual com facilidade.
Você pode trabalhar com um sistema que não seja de produção como deseja antes de fazer qualquer coisa em um servidor de produção.
Graças a @WernerCD
Pode ser feito?
Definitivamente sim. Eu copiei um servidor Linux inteiro simplesmente empacotando os arquivos com tar e os extraí novamente no servidor de destino. A única ressalva de que me lembro foi ter que lembrar de usar --numeric-owner ao extrair. Eu não posso falar por outro sistema operacional e outras ferramentas, mas imagino que seja possível com todos os principais sistemas operacionais.
Deve ser feito?
Esta questão é um pouco mais complicada de responder. Não recomendarei simplesmente clonar um sistema de produção para fins de desenvolvimento. Pode muito bem conter muitos dados do usuário, bem como material chave, que você não deseja ter nos sistemas de desenvolvimento.
Mas a clonagem do seu sistema de produção pode ser uma boa ideia para outros fins.
A abordagem que eu recomendaria para criar um clone do sistema de produção é restaurar a partir do backup. Você pode evitar o impacto no desempenho do sistema de produção, restaurando a partir de um backup, e você pode testar seu procedimento de restauração, o que é uma coisa boa.
É importante manter o clone que você restaurou do backup isolado do resto do mundo. Como ele foi restaurado a partir de um backup de um sistema de produção, ele pode conter trabalhos automatizados, que se comunicarão com outros sistemas de produção e terão as credenciais para isso.
Você poderia causar muitos danos se o clone tivesse que se comunicar com sistemas de produção reais.
Mas, se você mantê-lo isolado, ele terá a oportunidade de testar se o sistema restaurado funciona como esperado. Além disso, esse sistema restaurado pode ser um ambiente útil para o último teste de novo código antes de ser implementado na produção. Esta pode ser sua única oportunidade de testar o código em dados reais do usuário, antes que ele realmente esteja em posição de quebrar o sistema de produção.
Claro, é possível, porque não é difícil "instalar" o Linux usando meios não convencionais. Você poderia, por exemplo, replicar o servidor usando o rsync via SSH.
/target . /proc , /sys , swap). /target/etc/fstab , especialmente se as partições forem referenciadas pelo UUID. A etapa 3 pode consistir em vários passos de rsync, possivelmente auxiliados por snapshots do LVM na máquina de origem, a última passada com todos os serviços na máquina de origem parados para garantir a consistência dos dados.
Só porque você pode não significa que deveria. Eu recomendei o processo acima como uma maneira de fazer uma migração do data center. No entanto, seu caso de uso é bem diferente. Recorrer à clonagem destaca algumas deficiências:
Se você clonar cegamente o servidor de produção, perderá uma oportunidade valiosa para esclarecer exatamente o que está sendo executado nele.