rsync por VPN: qual lado é a fonte da verdade?
Um túnel dá-lhe um caminho, não uma política de fusão. Escolha a cópia autoritativa, pré-visualize a cópia unidirecional e depois decida em separado se as eliminações viajam.
Dois servidores, uma VPN, um diretório que tem de existir nos dois locais e um comando fácil de executar e difícil de desfazer. Antes de o escrever, decida qual cópia é autoritativa, porque cada pergunta de rsync que se segue depende dessa resposta. Uma réplica unidirecional, uma pasta de trabalho partilhada e um arquivo com versionamento precisam de regras diferentes para edições e eliminações. O túnel fornece o caminho e não tem opinião sobre nenhuma delas.
Decida qual cópia ganha antes de escrever um comando
Escreva a direção numa frase, incluindo o nome do anfitrião e o caminho de cada lado, e obtenha o acordo de quem é dono dos dados. Neste percurso a origem é /srv/publish/ e o destino é uma conta em fileserver.example que só pode escrever em /srv/mirror/.
Confirme os factos de transporte antes da cópia: a chave de anfitrião SSH está verificada, a conta de destino pode escrever na área de réplica e em mais nada, e ambos os anfitriões têm versões de rsync compatíveis. Estes pré-requisitos impedem que um pequeno erro de planeamento se torne um incidente de permissões. Também lhe dizem que conta aparecerá nos registos do destino quando algo correr mal.
Pré-visualize a cópia e leia a lista detalhada
Execute primeiro a cópia com a opção de pré-visualização e guarde a saída. As alterações detalhadas dizem-lhe o que aconteceria a cada caminho, o que é muito mais útil do que um resumo de conclusão depois do facto. Guarde a saída no registo de alterações para que a execução seguinte tenha algo com que ser comparada.
rsync -rt --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/
A barra final importa. Na origem significa o conteúdo desse diretório, enquanto omiti-la acrescenta um nível de diretório com o nome da origem. O manual do rsync documenta ambas as formas juntamente com as opções de preservação, e o conjunto de opções de que precisa depende dos dados e não do hábito.
Leia cada linha em função do destino que pretendia. Remover a opção de pré-visualização executa a cópia e pode substituir ficheiros, e sem uma opção de eliminação os ficheiros extra já presentes no destino ficam simplesmente onde estão. Esse é o padrão seguro apenas se tiver mesmo decidido que ficheiros obsoletos deixados para trás são aceitáveis. Se a resposta for não, é a decisão de eliminação abaixo que deve ser tomada, e não uma opção extra a salpicar neste comando.
Depois decida se as eliminações viajam
Tornar o destino um espelho é uma segunda decisão, não um refinamento da primeira. Pré-visualize-a em separado, com a opção de eliminação acrescentada e nada mais alterado, para que a diferença na lista pertença inteiramente a essa decisão.
rsync -rt --delete --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/
As eliminações removem ficheiros supérfluos do lado recetor dentro do âmbito sincronizado, e é por isso que um caminho de origem errado, um diretório não montado ou um filtro que exclui mais do que o previsto podem fazer uma execução destrutiva parecer um espelho limpo. A lista de pré-visualização é o único lugar onde essa diferença se torna visível antes de ficar cara. Mantenha uma cópia de recuperação independente onde os dados o justifiquem, e lembre-se de que um espelho reproduz fielmente uma eliminação acidental em vez de preservar o histórico.
Uma pré-visualização também não bloqueia nada. As pessoas editam ficheiros entre o ensaio e a execução real, e os sistemas de ficheiros têm opiniões próprias, pelo que a execução que aprova e a execução que corre não são a mesma operação a menos que ambas as árvores estejam quietas.
Dois trabalhos unidirecionais não fazem uma sincronização bidirecional
Executar o mesmo comando nas duas direções é a forma mais comum de perder dados neste cenário. Cada direção trata o outro lado como destino e substitui alegremente conteúdo mais recente, e as eliminações espelham-se na ordem em que o agendamento dispara.
Se os utilizadores têm de editar as duas cópias, essa é outra decisão de produto: tratamento de conflitos, rastreio de eliminações e uma ferramenta concebida para esse modelo. Aproximá-la com a ordem do agendamento é como uma pasta partilhada ganha duas versões de cada documento que ninguém consegue reconciliar. Decida isso explicitamente em vez de o aproximar com duas entradas de cron e esperança.
Automatize só depois de a política estar escrita
Um trabalho agendado deve transportar a direção, os caminhos, a política de metadados e a decisão de eliminação aprovada. Coloque esses cinco factos no próprio ficheiro do trabalho, não numa página de wiki que o próximo administrador pode nunca ler. Evite execuções sobrepostas, porque duas cópias a escrever a mesma árvore ao mesmo tempo produzem um estado que nenhuma delas pretendia.
Quando a origem é uma base de dados ativa ou outro conjunto de dados com vários ficheiros, faça primeiro uma exportação consistente com a aplicação ou um instantâneo coordenado. Uma travessia recursiva de ficheiros não é uma transação, e uma cópia de um conjunto de dados em mudança não é consistente.
Registe conclusões e falhas, e verifique o conjunto de dados no destino em vez de apenas o código de saída. Restaurar a VPN após uma falha restaura a conectividade; não diz nada sobre se a última cópia terminou ou se edições em conflito chegaram a ser resolvidas.