rsync per VPN: quina banda és la font de veritat?

Dos servidors, una VPN, un directori que ha d'existir en tots dos llocs i una ordre fàcil d'executar i difícil de desfer. Abans d'escriure-la, decideix quina còpia és autoritativa, perquè cada pregunta posterior sobre rsync depèn d'aquesta resposta. Una rèplica unidireccional, una carpeta de treball compartida i un arxiu amb versionat necessiten regles diferents per a edicions i eliminacions. El túnel aporta el camí i no té opinió sobre cap d'elles.

Decideix quina còpia mana abans d'escriure una ordre

Escriu la direcció en una frase, amb el nom d'amfitrió i el camí de cada banda, i aconsegueix que ho aprovi qui és propietari de les dades. En aquest recorregut l'origen és /srv/publish/ i la destinació és un compte a fileserver.example que només pot escriure a /srv/mirror/.

Confirma els fets de transport abans de la còpia: la clau d'amfitrió SSH està verificada, el compte de destinació pot escriure a l'àrea de rèplica i enlloc més, i tots dos amfitrions tenen versions d'rsync compatibles. Aquestes condicions prèvies eviten que un petit error de planificació es converteixi en un incident de permisos. També et diuen quin compte apareixerà als registres de la destinació quan alguna cosa vagi malament.

Previsualitza la còpia i llegeix la llista detallada

Executa primer la còpia amb l'opció de previsualització i conserva la sortida. Els canvis detallats et diuen què passaria amb cada camí, cosa que és molt més útil que un resum de finalització posterior. Desa la sortida al registre de canvis perquè la propera execució tingui amb què comparar-se.

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

La barra final importa. A l'origen significa el contingut d'aquell directori, mentre que ometre-la afegeix un nivell de directori amb el nom de l'origen. El manual d'rsync documenta totes dues formes juntament amb les opcions de preservació, i el conjunt d'opcions que necessites depèn de les dades i no del costum.

Llegeix cada línia pensant en la destinació que volies. Treure l'opció de previsualització executa la còpia i pot sobreescriure fitxers, i sense una opció d'eliminació els fitxers sobrants que ja són a la destinació simplement es queden on són. Això només és el valor segur per defecte si de debò has decidit que deixar fitxers obsolets enrere és acceptable. Si la resposta és no, la decisió d'eliminació d'aquí sota és la que cal prendre, no una opció extra a escampar en aquesta ordre.

Després decideix si les eliminacions viatgen

Convertir la destinació en un mirall és una segona decisió, no un refinament de la primera. Previsualitza-la per separat, amb l'opció d'eliminació afegida i res més canviat, perquè la diferència a la llista pertanyi del tot a aquesta decisió.

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

Les eliminacions treuen fitxers sobrants del costat receptor dins de l'abast sincronitzat, i per això un camí d'origen equivocat, un directori sense muntar o un filtre que exclou més del previst poden fer que una execució destructiva sembli un mirall net. La llista de previsualització és l'únic lloc on aquesta diferència es fa visible abans de ser car. Mantén una còpia de recuperació independent on les dades ho justifiquin, i recorda que un mirall reprodueix fidelment una eliminació accidental en lloc de conservar l'historial.

Una previsualització tampoc no bloqueja res. La gent edita fitxers entre la prova i l'execució real, i els sistemes de fitxers tenen les seves pròpies opinions, així que l'execució que aproves i la que s'executa no són la mateixa operació tret que tots dos arbres estiguin quiets.

Dues feines unidireccionals no fan una sincronització bidireccional

Executar la mateixa ordre en tots dos sentits és la manera més habitual de perdre dades en aquest escenari. Cada direcció tracta l'altra banda com a destinació i sobreescriu alegrement contingut més recent, i les eliminacions es reflecteixen en l'ordre en què es dispara la planificació.

Si els usuaris han d'editar totes dues còpies, això és una altra decisió de producte: gestió de conflictes, seguiment d'eliminacions i una eina dissenyada per a aquest model. Aproximar-ho amb l'ordre de la planificació és com una carpeta compartida acaba amb dues versions de cada document que ningú no pot reconciliar. Decideix-ho explícitament en lloc d'aproximar-ho amb dues entrades de cron i esperança.

Automatitza només després d'escriure la política

Una feina planificada ha de portar la direcció, els camins, la política de metadades i la decisió d'eliminació aprovada. Posa aquests cinc fets al mateix fitxer de la feina, no en una pàgina wiki que el proper administrador potser no llegirà mai. Evita execucions solapades, perquè dues còpies escrivint el mateix arbre alhora produeixen un estat que cap de les dues pretenia.

Quan l'origen és una base de dades activa o un altre conjunt de dades amb diversos fitxers, fes primer una exportació coherent amb l'aplicació o una instantània coordinada. Un recorregut recursiu de fitxers no és una transacció, i una còpia d'un conjunt de dades que canvia no és coherent.

Registra les finalitzacions i els errors, i comprova el conjunt de dades a la destinació en lloc de només el codi de sortida. Restaurar la VPN després d'una caiguda restaura la connectivitat; no diu res sobre si l'última còpia va acabar ni sobre si les edicions en conflicte es van arribar a resoldre.