Transfer rapid de fișiere mari între două servere folosind comanda rsync prin SSH

Comanda rsync prin SSH este una dintre cele mai practice metode Linux utilizate pentru a muta rapid, sigur și fără întreruperi fișiere mari între două servere. În special, atunci când se mută fișiere de site-uri web de sute de GB, arhive de backup, foldere media sau date de aplicație, rsync oferă un avantaj semnificativ de viteză în comparație cu metodele clasice de copiere, deoarece transferă doar blocurile care s-au schimbat. Principiul de bază al utilizării este următorul: fișierele de pe serverul sursă sunt sincronizate în mod criptat pe serverul țintă printr-un tunel SSH; dacă conexiunea se întrerupe, procesul poate fi reluat de unde a rămas.

Atunci când se mută servere, se face upgrade la hosting, se schimbă centrul de date sau se execută operațiuni de backup, atât viteza, cât și integritatea datelor sunt importante. Descărcarea și reîncărcarea unui arhiv mare ca un singur fișier consumă mult timp și poate duce la necesitatea de a începe din nou în caz de erori de conexiune. Aici intervine rsync, care poate păstra amprentele temporale ale fișierelor, permisiile, informațiile despre proprietate și structura folderului. Din acest motiv, este frecvent utilizat de administratori de sisteme Linux, echipe DevOps și experți în hosting pentru operațiuni zilnice.

În acest ghid, vom aborda pas cu pas procesul de mutare a fișierelor mari între două servere Linux prin SSH folosind rsync, cu exemple reale de comenzi. De asemenea, vom împărtăși parametrii de îmbunătățire a performanței, controalele de securitate, scenariile de eroare, metodele de testare a transferului și aspectele de care trebuie să țineți cont înainte de a trece în mediul de producție. Dacă plănuiți o tranziție către un VPS sau un mediu de hosting nou, asigurați-vă că aveți suficient spațiu pe disc, acces SSH și permisiuni corecte pe serverele sursă și țintă înainte de a aplica acest ghid. Puteți consulta paginile Solutii de server VPS Hostragons și Pachete de hosting Linux pentru alegerea infrastructurii relevante.

Ce este rsync și de ce este preferat pentru mutarea fișierelor mari?

rsync este un instrument puternic de linie de comandă utilizat pentru a sincroniza fișiere și directoare între sistemul local sau servere îndepărtate. Cea mai importantă caracteristică a sa este algoritmul de transfer delta. Acest algoritm trimite doar părțile modificate ale fișierului, în loc să trimită întregul fișier de fiecare dată. De exemplu, dacă într-un fișier de backup de 80 GB există doar 2 GB de modificări, în condiții adecvate, este posibil să se transfere doar blocurile modificate în loc de întregul fișier.

SSH face transferul criptat. Astfel, comanda rsync nu trimite conținutul fișierelor ca text simplu pe rețea. Această caracteristică este esențială în special pentru datele clienților, înregistrările comenzii de comerț electronic, arhivele media, backup-urile bazelor de date și fișierele aplicațiilor private. În lumea hosting-ului, securitatea datelor nu se limitează doar la certificatul SSL; canalul de transfer între servere trebuie să fie de asemenea sigur. Atunci când utilizați certificat SSL pentru traficul site-ului web, criptarea SSH ar trebui să fie preferată și pentru transferul de fișiere între servere.

rsync este mai flexibil în comparație cu FTP sau metodele manuale de descărcare-încărcare. Acesta poate păstra permisiile, poate transporta link-uri simbolice, poate șterge fișierele șterse și poate limita lățimea de bandă, precum și poate verifica ce trebuie să facă înainte de transfer. Acest nivel de control oferă avantaje semnificative în operațiunile riscante de mutare a fișierelor mari.

Când ar trebui să utilizați comanda rsync prin SSH?

Comanda rsync prin SSH este ideală în special pentru mutarea fișierelor mari, numeroase sau care se schimbă frecvent. Pentru un simplu folder media, SFTP manual poate fi suficient; însă, atunci când este vorba de mii de fișiere, permisiuni diferite și arhive mari, rsync devine o opțiune mult mai fiabilă.

• Dacă mutați un site web de pe un server vechi pe un VPS nou.
• Dacă transferați directoare care conțin mii de fișiere media, cum ar fi folderul uploads de WordPress.
• Dacă copiați backup-uri zilnice, săptămânale sau lunare pe un alt server.
• Dacă schimbați centrul de date sau furnizorul de hosting.
• Dacă sincronizați fișierele aplicației între medii de producție și backup.
• Dacă planificați transferuri pe termen lung cu risc de întrerupere a conexiunii.

De exemplu, descărcarea unui folder media de 250 GB pe computerul dvs. desktop și apoi încărcarea acestuia pe un nou server înseamnă două transferuri separate. Acest lucru atât prelungește timpul total, cât și poate face conexiunea dvs. de internet de acasă sau de birou să devină un punct de congestie. Cu rsync, puteți elimina acest pas intermediar prin transferul direct de pe serverul sursă pe serverul țintă.

Ce trebuie să verificați înainte de a începe?

Pentru o operațiune rsync de succes, a cunoaște comanda nu este suficient. Verificarea condițiilor de pe serverele sursă și țintă reduce riscul de pierdere de date sau transferuri incomplete în timpul procesului. Următoarele verificări trebuie făcute cu siguranță în medii de producție.

1. Verificați accesul SSH

Trebuie să se poată stabili o conexiune SSH de la serverul sursă la serverul țintă. Conexiunea standard este testată astfel: ssh utilizator@ip-server-tinta. Dacă SSH funcționează pe un port diferit, conexiunea este testată astfel: ssh -p 2222 utilizator@ip-server-tinta. Dacă acest test nu reușește, rsync nu va funcționa nici el. Trebuie verificate firewall-ul, Fail2ban, portul SSH, permisiile utilizatorului și validarea parolei sau a cheii.

2. Verificați dacă pachetul rsync este instalat

Majoritatea distribuțiilor Linux vin cu rsync preinstalat; cu toate acestea, este bine să verificați. În sistemele bazate pe Debian și Ubuntu, se poate folosi comanda rsync --version. Dacă nu este instalat, poate fi descărcat cu apt install rsync. În distribuțiile AlmaLinux, Rocky Linux sau CentOS, se preferă comenzile dnf install rsync sau yum install rsync. Dacă utilizați un VPS bazat pe Linux pe Hostragons, instalarea durează de obicei câteva secunde.

3. Calculați spațiul pe disc

Dacă nu există suficient spațiu liber pe serverul țintă, transferul se va opri. Se poate folosi logica du -sh /cale/catre/director pentru a vedea dimensiunea directorului sursă. Pe serverul țintă, se verifică starea discului cu comanda df -h. În practică, nu trebuie să lăsați doar spațiul necesar pentru dimensiunea fișierului, ci să faceți loc și pentru fișiere temporare și loguri. De exemplu, dacă transportați 500 GB de date, este mai sănătos să planificați un spațiu disponibil de cel puțin 550-600 GB pe serverul țintă.

4. Planificați serviciile critice și fișierele care se schimbă

Fișierele de pe site-urile web active se pot schimba în timpul transferului. În special, încărcările utilizatorilor, folderele cache și fișierele jurnal sunt actualizate constant. În cazul mutărilor mari, datele principale sunt transferate mai întâi, apoi se activează modul de întreținere și se rulează o ultimă comandă rsync. Astfel, timpul de întrerupere poate fi redus la câteva minute. Pentru site-uri WordPress, puteți completa planul de procesare cu conținuturi de suport precum Ghid pentru transferul hostingului WordPress.

Comanda rsync de bază: Mutarea fișierelor între două servere

Structura de bază cea mai frecvent utilizată este următoarea: rsync -avz /cale/catre/director/ utilizator@ip-tinta:/cale/catre/director/. Aici, -a este modul de arhivare și încearcă să păstreze informațiile precum permisiile, amprentele temporale și linkurile simbolice. -v oferă o ieșire detaliată. -z aplică comprimarea în timpul transferului. Slash-ul de la sfârșitul directorului este un detaliu important. Dacă scrieți /cale/catre/director/, conținutul directorului este copiat pe țintă; dacă scrieți /cale/catre/director, directorul în sine va fi creat în destinația respectivă.

Să luăm un scenariu exemplu: doriți să mutați fișierele web de 180 GB din folderul /var/www/site/public_html/ de pe serverul vechi în directorul /var/www/site/public_html/ de pe noul server. Comanda funcționează astfel: rsync -avz /var/www/site/public_html/ root@203.0.113.20:/var/www/site/public_html/. Această operațiune transferă fișierele de pe serverul sursă pe serverul țintă prin SSH.

Dacă nu doriți să utilizați root, este mai sigur să creați un utilizator special cu permisiuni de scriere în directorul respectiv pe serverul țintă. De exemplu, puteți folosi utilizatorul deploy și să ajustați proprietatea folderului în consecință. Deși utilizarea root în medii de producție este practică, este recomandat să se folosească un utilizator cu permisiuni limitate din motive de securitate.

Parametrii rsync recomandați pentru securitate și reziliență

În transferurile mari de fișiere, a se limita doar la comanda de bază nu este întotdeauna corect. Este nevoie de parametrii suplimentari pentru întreruperi de conexiune, fișiere incomplete, ștergeri greșite sau rețele lente. Comanda de mai jos este un punct de plecare solid pentru multe scenarii reale de transfer:

rsync -aHAXv --numeric-ids --partial --progress --append-verify -e ssh /cale/catre/director/ utilizator@ip-tinta:/cale/catre/director/

În această comandă, -a păstrează modul de arhivare, -H păstrează informațiile despre linkurile hard, -A păstrează permisiile ACL, iar -X păstrează valorile atributelor extinse. --numeric-ids se bazează pe ID-uri în loc de numele de utilizator și grup; acest lucru poate fi util atunci când numele utilizatorilor diferă pe servere diferite. --partial lasă fișierele incomplete fără a le șterge. --progress arată starea transferului. --append-verify ajută în special la validarea porțiunii adăugate în timpul continuării transferului pentru fișiere mari.

Fiecare parametru poate să nu fie necesar în fiecare sistem. De exemplu, în cazul mutării unui simplu site web, utilizarea -aHAX poate fi suficientă, în timp ce în cazul unei aplicații care folosește permisiuni de fișiere personalizate, păstrarea informațiilor ACL și a atributelor extinse devine critică. De aceea, este important să efectuați mai întâi un transfer de test.

Ce se întâmplă dacă folosiți un port SSH diferit?

Pentru securitate, portul SSH ar putea să nu fie 22, ci un alt port. În acest caz, parametrul SSH este specificat în rsync. Exemplu: rsync -avz -e ssh -p 2222 /cale/catre/director/ utilizator@ip-tinta:/cale/catre/director/. Cu toate acestea, valoarea parametrului -e trebuie să fie utilizată împreună în linia de comandă. Principiul de utilizare corect este: rsync -avz -e 'ssh -p 2222' /cale/catre/director/ utilizator@ip-tinta:/cale/catre/director/.

În JSON și în anumite panouri, utilizarea ghilimelelor simple poate comporta diferit, așa că asigurați-vă că ghilimelele sunt corecte atunci când le scrieți direct în terminal. Dacă vă conectați cu cheia SSH, poate fi adăugat și parametrul -i: rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /cale/catre/director/ utilizator@ip-tinta:/cale/catre/director/. Această metodă este frecvent utilizată în sarcini automate și în procese de backup bazate pe cron.

Test de transfer înainte: utilizarea --dry-run

Unul dintre cele mai profesionale pași pe care trebuie să îi faceți înainte de a muta date mari este să folosiți --dry-run. Acest parametru nu copiază efectiv fișierele; arată doar care fișiere vor fi transferate. Astfel, se poate observa o cale greșită, un director țintă incorect sau ștergeri neașteptate înainte de a începe transferul.

Exemplu de comandă de test: rsync -avz --dry-run /var/www/site/ utilizator@ip-tinta:/var/www/site/. În ieșire veți vedea fișierele care vor fi transferate, directoarele care vor fi create și un rezumat al procesului. Dacă veți utiliza parametrul --delete, dry-run devine și mai critic, deoarece --delete poate șterge fișierele care nu există pe sursă de pe țintă. Utilizat corect, acesta face ca destinația să fie o oglindă identică; utilizat greșit, poate duce la pierderi semnificative de date.

Ordinea profesională de aplicare este de obicei următoarea: mai întâi se testează SSH, apoi se verifică spațiul pe disc, urmat de rularea rsync --dry-run, se realizează un test real cu un director mic, apoi se inițiază transferul principal. Această abordare poate adăuga câteva minute în plus, dar previne transferurile greșite care ar putea dura ore.

Setări de comprimare, lățime de bandă și criptare pentru performanță

Performanța rsync nu depinde doar de dimensiunea fișierului. Puterea CPU a serverelor, tipul de disc, latența rețelei, lățimea de bandă și numărul de fișiere sunt de asemenea importante. Un număr mare de fișiere mici poate fi transferat mai lent decât un singur fișier mare; deoarece se efectuează operațiuni de metadate pentru fiecare fișier în parte. În medii VPS cu disc NVMe, performanța de scanare și scriere a fișierelor poate fi semnificativ mai bună. Prin urmare, dacă planificați un transfer intens, este logic să evaluați opțiunile server VPS NVMe.

Parametrul -z de comprimare aduce beneficii în cazul fișierelor text, logurilor și anumitor tipuri de backup. Totuși, pentru fișiere deja comprimate, cum ar fi zip, tar.gz, jpg, mp4 sau gzip, utilizarea acestuia poate consuma CPU fără a aduce câștiguri semnificative. Dacă transferați fișiere media mari între două servere puternice cu o conexiune de 1 Gbps, puteți obține o performanță mai bună fără a utiliza -z. Pe de altă parte, în cazul lățimii de bandă reduse și a fișierelor bazate pe text, -z poate oferi economii considerabile.

Pentru a limita lățimea de bandă, se poate utiliza --bwlimit. De exemplu, --bwlimit=50000 limitează la aproximativ 50 MB/s. Acest lucru este important pentru a nu suprasolicita traficul de rețea al unui site web activ. Efectuarea unui transfer la viteză maximă în orele de vârf pe serverul de producție poate afecta negativ experiența vizitatorilor. Este o practică bună să planificați transferul pentru orele de noapte, să impuneți o limită de lățime de bandă și să monitorizați valorile medii de încărcare în timpul procesului.

Compararea rsync, scp, SFTP și FTP

Există mai multe metode de mutare a fișierelor; totuși, fiecare metodă are punctele sale forte și slabe. Tabelul de mai jos rezumă care instrument este cel mai potrivit pentru scenariile de transfer de fișiere mari și de server.

După cum se poate observa în tabel, rsync este deosebit de eficient în sincronizările repetate și în mutarea datelor mari. scp este simplu și util, dar nu este la fel de puternic ca rsync în detectarea fișierelor modificate. FTP, atunci când este utilizat fără criptare, nu este potrivit pentru standardele moderne de securitate. Accesul FTP în panourile de hosting poate fi practic; totuși, pentru transferurile critice între servere, metodele bazate pe SSH ar trebui să fie preferate.

Flux de lucru exemplu pentru mutarea unui site web activ

Când mutați un site web de pe un server vechi pe unul nou, scopul nu este doar de a copia fișierele. DNS, baza de date, versiunea PHP, permisiile fișierelor și configurația e-mailului trebuie, de asemenea, verificate. Mai jos se află un flux de lucru exemplu cu întreruperi minime pentru un site cu fișiere mari.

• Configurați serverul web, PHP, baza de date și modulele necesare pe noul server.
• Reduceți valoarea TTL DNS a domeniului la o valoare scăzută de 300 de secunde înainte de mutare. Puteți evalua pagina Verificare domeniu și administrare domeniu pentru gestionarea domeniului.
• Inițiați prima comandă rsync în timp ce site-ul este activ. Această etapă va muta cea mai mare parte a datelor.
• Faceți un backup al bazei de date și transferați-l pe noul server.
• Puneți site-ul în modul de întreținere pentru o perioadă scurtă.
• Rulați a doua comandă rsync pentru a sincroniza ultimele fișiere modificate.
• Actualizați din nou baza de date sau utilizați o strategie incrementală.
• Verificați permisiile fișierelor, deschiderea site-ului și logurile pe noul server.
• Instalați sau reînoiți certificatul SSL. Informațiile din instalarea certificatului SSL pot fi utile în acest sens.
• Redirecționați înregistrările DNS către noua adresă IP.

În această metodă, cea mai lungă durată de timp este transferul principal de fișiere, care se efectuează în timp ce site-ul este activ. Întreținerea apare doar în timpul ultimei sincronizări și a tranziției DNS. Această abordare poate reduce timpul de întrerupere de la câteva ore la câteva minute pentru site-urile WordPress cu arhive mari de media.

Verificarea integrității datelor

Odată ce transferul este complet, nu este suficient doar să se finalizeze comanda. Numărul de fișiere, dimensiunile și fișierele critice trebuie verificate. Pentru o verificare simplă, dimensiunile directoarelor sursă și țintă pot fi comparate folosind comanda du -sh. Cu toate acestea, din cauza diferențelor de blocuri ale sistemului de fișiere, valorile pot să nu apară identice. Pentru o verificare mai detaliată, rsync poate fi rulat din nou cu aceleași parametri. Dacă nu mai există fișiere noi de transferat, ieșirea va fi minimă.

Pentru validarea checksum, se poate utiliza rsync -avc --dry-run /cale/catre/director/ utilizator@ip-tinta:/cale/catre/director/. Aici, parametrul -c compară fișierele nu doar prin amprente temporale și dimensiuni, ci și prin checksum. Fiindcă poate genera o încărcare pe CPU și pe disc în cazul datelor mari, trebuie utilizat cu atenție. Această validare suplimentară oferă siguranță pentru arhivele critice, fișierele dump ale bazelor de date sau documentele clienților.

Dacă ați mutat un site web, verificați și la nivel de aplicație. Trebuie inspectate pagina principală, panoul de administrare, încărcarea imaginilor, pagina de plată, formularul de contact și logurile de erori. Pe site-urile de comerț electronic, mutarea fișierelor nu este suficientă; integrarea plăților și sarcinile cron trebuie, de asemenea, testate pe noul server.

Eroare frecventă și soluțiile acestora

Eroarea Permission denied

Această eroare apare de obicei din cauza permisiunilor utilizatorului SSH, permisiunilor de scriere în directorul țintă sau a validării cheii. Încercați mai întâi să stabiliți o conexiune SSH normală cu același utilizator. Dacă conexiunea reușește, efectuați un test de creare a fișierelor în directorul țintă. Dacă este necesar, schimbați proprietatea folderului țintă cu chown pentru utilizatorul relevant sau planificați o strategie bazată pe sudo.

Eroarea No space left on device

Când nu mai există suficient spațiu pe discul țintă, transferul se oprește. Verificați partițiile discului cu df -h. Uneori, discul principal nu este plin, dar /tmp sau punctul de montare țintă pot fi pline. În cazul mutărilor mari, fișierele de loguri, backup-urile vechi și folderele cache pot fi curățate. Pentru o soluție permanentă, ar putea fi necesară extinderea discului sau trecerea la un plan VPS cu o capacitate mai mare.

Eroarea Connection reset sau Broken pipe

În transferurile prelungite, pot apărea întreruperi de rețea. Dacă utilizați --partial și --append-verify, puteți rula din nou comanda pentru a continua de unde ați rămas. De asemenea, setările keepalive SSH pot fi utile. Pe partea clientului, setarea ServerAliveInterval 60 poate reduce riscul de deconectare a conexiunii în repaus.

Transfer foarte lent

Încetinirea poate fi cauzată de numărul de fișiere, limitele I/O ale discului, sarcina de comprimare sau capacitatea rețelei. Dacă aveți un număr mare de fișiere mici, crearea unui arhiv tar înainte de transfer poate fi mai rapidă în anumite situații; totuși, în acest caz, avantajul modificării bazate pe fișiere al rsync scade. Testați eliminând parametrul -z pentru fișiere mari și deja comprimate. De asemenea, utilizați instrumente precum iotop, htop și iftop pentru a determina unde se află blocajul, fie pe CPU, disc sau rețea.

Cele mai bune practici pentru securitate

În timpul transferului de fișiere între servere, securitatea nu trebuie neglijată. În special, accesul root, cheile SSH și fișierele de backup trebuie considerate sensibile. Este recomandat să folosiți chei SSH în loc de autentificare prin parolă. Permisiile fișierelor de chei trebuie menținute stricte, cheile private nu trebuie partajate și, dacă este posibil, acestea trebuie protejate cu o frază de acces.

Crearea unui utilizator temporar pentru transfer și oferirea de acces doar la directoarele necesare este o metodă bună. După finalizarea procesului, permisiunile acestui utilizator pot fi revocate sau contul dezactivat. Limitarea accesului SSH la anumite adrese IP reduce, de asemenea, suprafața de atac. Regulile firewall-ului, Fail2ban și utilizarea versiunii actualizate a OpenSSH sunt printre controalele de bază necesare.

Dacă se transferă fișiere dump ale bazelor de date, documente ale clienților sau arhive care conțin date personale, fișierele temporare inutile trebuie curățate de pe sursă și țintă după transfer. De asemenea, lăsarea fișierelor de backup cum ar fi .sql, .zip sau .tar în directorul rădăcină al web-ului reprezintă un risc serios de securitate. Aceste fișiere trebuie, dacă este posibil, păstrate într-un director care nu este accesibil web-ului sau șterse după finalizarea procesului.

Utilizarea rsync pentru backup automat

rsync nu este util doar pentru transferuri unice, ci și pentru backup-uri regulate. De exemplu, se poate defini o sarcină cron pentru a trimite un anumit folder pe un server de backup în fiecare noapte. În acest scenariu, se stabilește o conexiune sigură, fără parolă, cu cheia SSH, rsync transferă doar fișierele modificate și se poate aplica o limită de lățime de bandă.

Logica exemplară: rsync -a --delete --bwlimit=30000 /var/www/site/ backup@ip-backup:/backup/site/. Această comandă poate sincroniza directorul țintă cu sursa. Totuși, din cauza parametrului --delete, trebuie utilizată cu atenție. Un fișier șters accidental din sursă va fi șters și în destinație. Prin urmare, în strategiile critice de backup, ar trebui preferate soluții care suportă snapshoturi, foldere zilnice sau versioning.

În operațiunile de hosting, regula 3-2-1 pentru backup este un bun reper: trebuie să existe cel puțin 3 copii ale datelor, în 2 medii diferite, iar 1 copie să fie într-o locație diferită. rsync facilitează partea de copiere între servere a acestei strategii. Pentru o infrastructură mai cuprinzătoare, puteți consolida planul dvs. cu informații despre Soluții de backup și servicii de hosting corporate.

Lista de verificare finală

Înainte de a iniția procesul de mutare a fișierelor mari, aplicarea următoarei liste scurte reduce riscul de erori. Această listă ar trebui să devină o procedură standard, în special în medii de producție.

• rsync este instalat pe serverele sursă și țintă?
• Conexiunea SSH a fost testată cu utilizatorul și portul corect?
• Există suficient spațiu pe disc pe serverul țintă?
• Prima operațiune a fost verificată cu --dry-run?
• Modul de întreținere și ultima sincronizare au fost planificate pentru site-ul activ?
• A fost confirmată destinația corectă dacă se va utiliza --delete?
• Vor fi verificate dimensiunile fișierelor, permisiile și testele aplicației după transfer?
• Fișierele temporare de backup și dump-uri vor fi curățate în siguranță?

Aceste verificări par simple, dar în practică cele mai frecvente probleme derivă adesea dintr-un director țintă greșit, permisiuni lipsă, insuficient spațiu pe disc și tranziții DNS neplanificate. Un proces rsync planificat poate reduce atât timpul de transfer, cât și probabilitatea de erori de revenire.

Întrebări frecvente

Dacă conexiunea se întrerupe în timpul comenzii rsync prin SSH, transferul începe din nou?

Nu, dacă sunt utilizate parametrii corecți, acesta nu va începe din nou. Opțiunile --partial și --append-verify ajută la protejarea fișierelor mari incomplete și permit continuarea transferului de unde a rămas atunci când se reia comanda. Cu toate acestea, în cazul transferurilor critice, este bine să verificați spațiul pe disc țintă și starea fișierelor incomplete înainte de a relua comanda.

Se poate transfera direct baza de date cu rsync?

rsync transferă fișiere; copierea directă a fișierelor bazei de date active nu este sănătoasă. Pentru MySQL sau MariaDB, ar trebui utilizate mysqldump sau instrumente de backup fizic, iar fișierul de backup rezultat ar trebui transferat pe serverul țintă cu rsync. În sistemele active, trebuie planificate strategii de modul de întreținere sau replicare pentru a asigura coerența datelor.

Este necesar să existe acces root pe ambele servere pentru a utiliza rsync?

Accesul root nu este obligatoriu. Un utilizator cu permisiuni de scriere în directorul țintă este suficient. Cu toate acestea, dacă trebuie păstrate proprietățile fișierelor, directoarele sistemului, ACL-urile sau permisiunile speciale, este posibil să fie necesare permisiuni mai ridicate. Din punct de vedere al securității, este recomandat să se utilizeze un utilizator cu permisiuni limitate, atunci când este posibil.

Este sigur parametrul --delete?

--delete este foarte util pentru a sincroniza destinația cu sursa, dar poate duce la pierderi de fișiere dacă este utilizat în directorul greșit. Prin urmare, comenzile care includ --delete trebuie testate întotdeauna mai întâi cu --dry-run, iar căile sursă și țintă trebuie verificate cu atenție.

Care este mai bun pentru transferul de fișiere mari, rsync sau scp?

Pentru copieri unice mici, scp poate fi suficient; dar pentru fișiere mari, un număr mare de fișiere și sincronizări repetate, rsync este de obicei mai bun. Deoarece poate detecta datele modificate, poate continua transferurile incomplete, poate limita lățimea de bandă și oferă un mod de testare.

Rezumat și pași următori

Transferul de fișiere mari între două servere folosind comanda rsync prin SSH este o metodă rapidă, sigură și gestionabilă. Cu parametrii corecți, devine rezistent la deconectări, economisind timp prin transferul doar al fișierelor modificate și reducând întreruperile în procesele de mutare a site-urilor active. Pentru cele mai bune rezultate, începeți prin a efectua verificări SSH și de disc, testați cu --dry-run, iar apoi planificați transferul principal.

Dacă plănuiți o tranziție către un nou server, stocare de capacitate mare sau o infrastructură de hosting mai performantă, puteți explora soluțiile Hostragons; cu opțiuni de VPS, hosting, domenii și SSL, puteți face procesul de mutare mai sigur. Începeți cu teste mici, măsurați și planificați sincronizarea finală cu atenție.