Eu tenho um servidor muito antigo lento (ubuntu 9.04) que tem um monte de outras coisas rodando nele junto com SubVersion.
Eu agora pretendo mover o subversion para um servidor melhor e mais rápido, mas é claro que não quero perder nenhum dado ou histórico. Muitas pessoas têm acesso ao SVN e eu não quero nenhuma alteração no final (também vou mover o domínio para o novo servidor).
Qual é a melhor maneira de fazer isso? Enquanto me movo, eu também quero atualizar o antigo svn versão 1.5.4 para a última versão estável 1.7.0
Existe algum problema que eu deva saber antes de fazer isso? Qualquer guia que possa me ajudar aqui
Obrigado
para cada repo no servidor de origem
Eu recomendaria primeiro instalar uma instância do SVN 1.7.0 no novo servidor. Então, você pode começar a copiar todas as informações armazenadas em seu antigo repositório SVN para o novo.
Como David Spillet explica isso nesta resposta , rsync deve estar perfeitamente bem para fazer backup / copiar um repositório svn, contanto que você não esteja fazendo o backup de um repositório que esteja atualmente ativo. Eu suspeito que você está tentando fazer backup de um repositório ativo que é problemático.
Eu estou supondo que os problemas relatados estão relacionados à falta de arquivos (eles estavam presentes durante a varredura inicial, mas foram movidos / renomeados / apagados antes que o backup fosse concluído), sendo bloqueados ou aparentemente alterados enquanto o rsync os estava lendo. . Você verá erros similares (ou muito pior: problemas relacionados, mas não reportados) com a maioria das técnicas de backup se estiver fazendo backup de um serviço svn ativo e você não parar completamente o serviço svn antes de iniciar o backup.
Parar todo o acesso ao repositório durante a execução do backup pode não estar disponível para você, mesmo que seja feito na madrugada (como você pode ter desenvolvedores remotos que trabalham em horários diferentes). Se este for o caso, existem algumas opções, incluindo:
Use hot-backup.py para fazer um backup completo do repositório enquanto ele estiver ativo como descrito nesta seção do Controle de Versão com Subversão disponível gratuitamente, que é geralmente considerado leitura recomendada. Isso não será adequado diretamente para o backup remoto, pois o repo completo será enviado pela linha toda vez, mas você poderá fazer o backup em uma área local temporária e executar o backup rsync (ou qualquer outra coisa). sobre isso, em vez do repositório ao vivo.
Se você estiver executando no Linux e usar o LVM para particionar a unidade, poderá usar o recurso de instantâneo do LVM para executar um feito semelhante ao descrito na opção 1. Consulte aqui e aqui, por exemplo, a documentação da técnica. Isso significa interromper o acesso ao serviço SNV por um curto período de tempo, pelo período de tempo que o instantâneo leva a ser criado, mas isso é quase instantâneo, muito menos provável de ser um problema do que precisar interrompê-lo para toda a operação de backup. .
Use backups incrementais do repositório ativo, também mencionado no livro SVN acima.
A técnica LVM será mais rápida do que hot-backup.py -then-sync, mas não estará disponível para você sem um trabalho extra e aprendizado, a menos que você já esteja familiarizado com o LVM. Suas vantagens são que ele será quase certamente mais rápido e usará menos espaço em disco (embora o espaço em disco seja bastante barato atualmente). As capturas instantâneas do LVM afetam o desempenho da gravação enquanto estão presentes, mas é improvável que a diferença seja perceptível, a menos que o repositório esteja muito ocupado e o desempenho volte ao normal de qualquer maneira no final da execução do backup.
O método hot-backup.py tem a vantagem de fornecer um backup local também se você ainda não tiver um - se você armazenar a versão "hot copy" em outra máquina, poderá restaurá-la com muito mais rapidez do que restaurar a cópia remota se a máquina principal morrer em um evento que não afete a outra (uma falha do controlador de unidade, por exemplo). Também é provável que seja mais simples de implementar, a menos que você já use o LVM e esteja familiarizado com ele.
Backups incrementais serão mais rápidos que essas duas técnicas, mas menos simples que hotcopy-then-sync e restauração após um desastre completo são potencialmente mais complexos, a menos que você use os backups incrementais para construir uma cópia completa do repo na outra extremidade ( em vez de apenas armazenar as informações incrementais). No entanto, recomenda-se a recompilação do repositório na outra extremidade, pois é uma forma de testar se o backup é realmente válido - mesmo com as outras técnicas, você deve testar seus backups regularmente (mantra: um backup não é um bom backup, a menos que foi testado).
Em resumo, rsync deve estar perfeitamente bem para fazer backup ou copiar um repositório svn contanto que você não esteja fazendo o backup de um repositório que esteja atualmente ativo - você precisa parar o serviço ou backup de alguma forma de captura instantânea.
Lembre-se sempre de testar se tudo está ok, por comparar as informações é ambos os repositórios SVN, usando opções de realocação, verificar arquivos de log, etc.
Tags svn