rsync por VPN: que lado é a fonte da verdade?

Dous servidores, unha VPN, un directorio que debe existir nos dous lugares e un comando fácil de executar e difícil de desfacer. Antes de escribilo, decida que copia é autoritativa, porque cada pregunta posterior sobre rsync depende desa resposta. Unha réplica unidireccional, un cartafol de traballo compartido e un arquivo con versións necesitan regras diferentes para edicións e eliminacións. O túnel achega o camiño e non ten opinión sobre ningunha delas.

Decida que copia manda antes de escribir un comando

Escriba a dirección nunha frase, incluídos o nome de host e o camiño de cada lado, e consígaa aprobada por quen é dono dos datos. Neste percorrido a orixe é /srv/publish/ e o destino é unha conta en fileserver.example que só pode escribir en /srv/mirror/.

Confirme os feitos de transporte antes da copia: a chave de host SSH está verificada, a conta de destino pode escribir na área de réplica e en nada máis, e ambos os hosts teñen versións de rsync compatibles. Estas condicións previas impiden que un pequeno erro de planificación se converta nun incidente de permisos. Tamén lle din que conta aparecerá nos rexistros do destino cando algo vaia mal.

Previsualice a copia e lea a lista detallada

Executa primeiro a copia coa opción de previsualización e conserva a saída. Os cambios detallados dinlle que pasaría con cada camiño, o que é moito máis útil que un resumo de finalización posterior. Garda a saída no rexistro de cambios para que a seguinte execución teña con que compararse.

rsync -rt --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

A barra final importa. Na orixe significa o contido dese directorio, mentres que omitila engade un nivel de directorio co nome da orixe. O manual de rsync documenta ambas as formas xunto coas opcións de preservación, e o conxunto de opcións que precisa depende dos datos e non do costume.

Lea cada liña pensando no destino que pretendía. Quitar a opción de previsualización executa a copia e pode sobrescribir ficheiros, e sen unha opción de eliminación os ficheiros sobrantes que xa están no destino simplemente quedan onde están. Iso só é o valor seguro por defecto se de verdade decidiu que deixar ficheiros obsoletos atrás é aceptable. Se a resposta é non, a decisión de eliminación de máis abaixo é a que hai que tomar, non unha opción extra que espallar neste comando.

Despois decida se as eliminacións viaxan

Converter o destino nun espello é unha segunda decisión, non un refinamento da primeira. Previsualízea por separado, coa opción de eliminación engadida e nada máis cambiado, para que a diferenza na lista pertenza por completo a esa decisión.

rsync -rt --delete --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

As eliminacións retiran ficheiros sobrantes do lado receptor dentro do ámbito sincronizado, e por iso un camiño de orixe equivocado, un directorio sen montar ou un filtro que exclúe máis do previsto poden facer que unha execución destrutiva pareza un espello limpo. A lista de previsualización é o único lugar onde esa diferenza se fai visible antes de ser cara. Manteña unha copia de recuperación independente onde os datos o xustifiquen, e lembre que un espello reproduce fielmente unha eliminación accidental en lugar de conservar o historial.

Unha previsualización tampouco bloquea nada. A xente edita ficheiros entre a proba e a execución real, e os sistemas de ficheiros teñen as súas propias opinións, así que a execución que aproba e a que se executa non son a mesma operación agás que ambas as árbores estean quietas.

Dous traballos unidireccionais non fan unha sincronización bidireccional

Executar o mesmo comando nos dous sentidos é a forma máis común de perder datos neste escenario. Cada dirección trata o outro lado como destino e sobrescribe alegremente contido máis recente, e as eliminacións reflíctense na orde en que se dispara a planificación.

Se os usuarios deben editar ambas as copias, esa é outra decisión de produto: xestión de conflitos, seguimento de eliminacións e unha ferramenta deseñada para ese modelo. Aproximalo coa orde da planificación é como un cartafol compartido acaba con dúas versións de cada documento que ninguén pode reconciliar. Decídao explicitamente en lugar de aproximarlo con dúas entradas de cron e esperanza.

Automatice só despois de escribir a política

Un traballo planificado debe levar a dirección, os camiños, a política de metadatos e a decisión de eliminación aprobada. Poña eses cinco feitos no propio ficheiro do traballo, non nunha páxina wiki que o próximo administrador pode que nunca lea. Evite execucións solapadas, porque dúas copias escribindo a mesma árbore á vez producen un estado que ningunha das dúas pretendía.

Cando a orixe é unha base de datos activa ou outro conxunto de datos con varios ficheiros, faga primeiro unha exportación coherente coa aplicación ou unha instantánea coordinada. Un percorrido recursivo de ficheiros non é unha transacción, e unha copia dun conxunto de datos que cambia non é coherente.

Rexistre finalizacións e fallos, e comprobe o conxunto de datos no destino en lugar de só o código de saída. Restaurar a VPN tras unha caída restaura a conectividade; non di nada sobre se a última copia rematou ou sobre se as edicións en conflito chegaron a resolverse.