rsync printr-un VPN: care parte este sursa adevărului?

Două servere, un VPN, un director care trebuie să existe în ambele locuri și o comandă ușor de rulat și greu de anulat. Înainte să o scrii, decide care copie este autoritativă, pentru că fiecare întrebare rsync care urmează depinde de acel răspuns. O replică unidirecțională, un dosar de lucru partajat și o arhivă cu versionare au nevoie de reguli diferite pentru modificări și ștergeri. Tunelul furnizează calea și nu are nicio părere despre niciuna dintre ele.

Decide care copie câștigă înainte de a tasta o comandă

Scrie direcția într-o propoziție, inclusiv numele de gazdă și calea de fiecare parte, și obține acordul celui care deține datele. În acest parcurs sursa este /srv/publish/, iar destinația este un cont pe fileserver.example care poate scrie doar în /srv/mirror/.

Confirmă faptele de transport înainte de copiere: cheia de gazdă SSH este verificată, contul de destinație poate scrie în zona de replică și în nimic altceva, iar ambele gazde au versiuni rsync compatibile. Aceste condiții prealabile împiedică o mică eroare de planificare să devină un incident de permisiuni. Îți spun și ce cont va apărea în jurnalele destinației când ceva merge prost.

Previzualizează copia și citește lista detaliată

Rulează mai întâi copia cu opțiunea de previzualizare și păstrează ieșirea. Modificările detaliate îți spun ce s-ar întâmpla cu fiecare cale, ceea ce este mult mai util decât un rezumat de finalizare ulterior. Păstrează ieșirea în registrul de modificări, ca următoarea rulare să aibă cu ce se compara.

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

Bara finală contează. La sursă înseamnă conținutul acelui director, iar omiterea ei adaugă un nivel de director cu numele sursei. Manualul rsync documentează ambele forme împreună cu opțiunile de păstrare, iar setul de opțiuni de care ai nevoie depinde de date, nu de obișnuință.

Citește fiecare linie raportând-o la destinația pe care o aveai în vedere. Eliminarea opțiunii de previzualizare execută copia și poate suprascrie fișiere, iar fără o opțiune de ștergere fișierele suplimentare deja aflate la destinație rămân pur și simplu acolo unde sunt. Acesta este valoarea implicită sigură doar dacă ai decis într-adevăr că fișierele învechite lăsate în urmă sunt acceptabile. Dacă răspunsul este nu, decizia de ștergere de mai jos este cea care trebuie luată, nu o opțiune în plus presărată în această comandă.

Apoi decide dacă ștergerile călătoresc

A face din destinație o oglindă este o a doua decizie, nu o rafinare a primeia. Previzualizeaz-o separat, cu opțiunea de ștergere adăugată și nimic altceva schimbat, astfel încât diferența din listă să aparțină în întregime acelei decizii.

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

Ștergerile elimină fișierele în plus de pe partea receptoare din cadrul sincronizat, motiv pentru care o cale de sursă greșită, un director nemontat sau un filtru care exclude mai mult decât s-a intenționat pot face o rulare distructivă să pară o oglindă curată. Lista de previzualizare este singurul loc unde această diferență devine vizibilă înainte de a deveni costisitoare. Păstrează o copie de recuperare independentă acolo unde datele o justifică și ține minte că o oglindă reproduce fidel o ștergere accidentală în loc să păstreze istoricul.

O previzualizare nu blochează nimic. Oamenii editează fișiere între probă și rularea reală, iar sistemele de fișiere au propriile păreri, așa că rularea pe care o aprobi și rularea care se execută nu sunt aceeași operație decât dacă ambele arbori sunt liniștiți.

Două lucrări unidirecționale nu fac o sincronizare bidirecțională

Rularea aceleiași comenzi în ambele direcții este cea mai obișnuită cale de a pierde date în acest scenariu. Fiecare direcție tratează cealaltă parte ca destinație și suprascrie voios conținut mai nou, iar ștergerile se oglindesc în ordinea în care se declanșează planificarea.

Dacă utilizatorii trebuie să editeze ambele copii, aceea este o altă decizie de produs: tratarea conflictelor, urmărirea ștergerilor și un instrument proiectat pentru acel model. A o aproxima prin ordinea planificării este modul în care un dosar partajat ajunge cu două versiuni ale fiecărui document pe care nimeni nu le poate reconcilia. Decide-o explicit în loc să o aproximezi cu două intrări cron și speranță.

Automatizează doar după ce politica este scrisă

O lucrare planificată ar trebui să poarte direcția, căile, politica de metadate și decizia de ștergere aprobată. Pune aceste cinci fapte în fișierul lucrării înseși, nu într-o pagină wiki pe care următorul administrator poate să nu o citească niciodată. Împiedică rulările suprapuse, pentru că două copii care scriu același arbore simultan produc o stare pe care niciuna nu o intenționa.

Când sursa este o bază de date activă sau un alt set de date cu mai multe fișiere, fă mai întâi un export consecvent cu aplicația sau un instantaneu coordonat. O parcurgere recursivă de fișiere nu este o tranzacție, iar o copie a unui set de date care se schimbă nu este consecventă.

Înregistrează finalizările și eșecurile și verifică setul de date la destinație, nu doar codul de ieșire. Restabilirea VPN după o pană restabilește conectivitatea; nu spune nimic despre dacă ultima copie s-a terminat sau dacă modificările conflictuale au fost vreodată rezolvate.