Пренос великих датотека између два сервера помоћу rsync команде преко SSH

rsync команда преко SSH је један од најпрактичнијих начина за брз, сигуран и отпоран пренос великих датотека између два сервера на Линукс систему. Посебно када се преносе веб фајлови величине стотина ГБ, резервне архиве, медијски фолдери или подаци апликација, rsync преноси само променљиве блокове, што значи да пружа значајну предност у брзини у поређењу са класичним методама копирања. Основна логика коришћења је следећа: датотеке са извора се синхронизују на циљни сервер преко шифрованог SSH тунела; ако дође до прекида везе, процес се може наставити са места где је стао.

Пренос сервера, надоградња хостинга, прелазак на нови дата центар или операције резервног копирања, поред брзине, захтевају и интегритет података. Преузимање и поновно учитавање велике архиве у једном делу може довести до губитка времена и потребе за поновним покретањем у случају прекида везе. Ту на сцени ступа rsync, који може да задржи временске ознаке, дозволе, информације о власнику и структуру фолдера. Због тога га систем администратори Линукса, DevOps тимови и стручњаци за хостинг често користе у свакодневним операцијама.

У овом водичу ћемо детаљно обрадити процес преноса великих датотека између два Линукс сервера помоћу rsync преко SSH, уз праве примере команди. Такође ћемо поделити параметре за повећање перформанси, безбедносне контроле, сценарије грешака, методе тест преноса и важне аспекте на које треба обратити пажњу пре него што пређете на производно окружење. Ако планирате прелазак на нови VPS или хостинг окружење, уверите се да на вашем изворном и циљном серверу имате довољно простора на диску, SSH приступ и исправне корисничке дозволе. За одговарајући избор инфраструктуре можете погледати Hostragons решења за VPS сервере и Пакети Линус Хостинга.

Шта је rsync и зашто се преферира за пренос великих датотека?

rsync је моћан алат за командну линију који се користи за синхронизацију датотека и директоријума на локалном систему или између удаљених сервера. Његова најважнија карактеристика је алгоритам делта трансфера. Овај алгоритам преноси само променљиве делове датотеке уместо да поново шаље целу датотеку сваки пут. На пример, ако у резервној копији од 80 ГБ постоји само 2 ГБ промена, у одговарајућим условима могуће је пренети само променљиве блокове уместо целокупне датотеке.

SSH, с друге стране, чини пренос шифрованим. На тај начин, rsync команда не преноси садржај датотеке у чистом тексту преко мреже. Ова карактеристика је посебно важна за податке о клијентима, е-трговинске поруџбине, медијске архиве, резервне копије база података и посебне апликационе датотеке. У свету хостинга, безбедност података није ограничена само на SSL сертификате; канал за пренос између сервера такође мора бити сигуран. Док користите SSL сертификат за саобраћај веб сајта, треба да се преферира SSH шифровање и за пренос датотека између сервера.

rsync је флексибилнији од FTP-а или ручних метода преузимања и учитавања. Може да задржи дозволе, преноси симболске везе, може да обрише уклоњене датотеке на циљу, ограничи пропусни опсег и пре преноса тестира шта ће да уради. Овај ниво контроле пружа значајне предности у ризичним операцијама као што је пренос великих датотека.

Kада треба да користите rsync команду преко SSH?

rsync команда преко SSH је идеална за пренос великих, бројних или често променљивих датотека. За једноставне визуелне фолдере, ручни SFTP може бити довољан; али када су у питању хиљаде датотека, различите дозволе и велике архиве, rsync постаје много поузданија опција.

• Ако преносите веб сајт са старог сервера на нови VPS сервер.
• Ако преносите директоријуме који садрже хиљаде медијских датотека, као што је WordPress uploads фолдер.
• Ако копирате дневне, недељне или месечне резервне копије на други сервер.
• Ако мењате дата центар или провајдера хостинга.
• Ако синхронизујете датотеке апликације између производног и резервног окружења.
• Ако планирате дуготрајне преносе са шансом за прекид везе.

На пример, преузимање медијског фолдера од 250 ГБ на ваш десктоп рачунар и затим учитавање на нови сервер значи да ћете морати да извршите два одвојена преноса. То не само да продужава укупно време већ и може да успори вашу интернет везу код куће или у канцеларији. Користећи rsync, можете избећи овај интермедијарни корак преносећи директно са извора на циљни сервер.

Шта је потребно пре него што почнете?

Знање команде rsync није довољно за успешну операцију. Контроверзије о условима извора и циља могу смањити ризик од губитка података или делимичног преноса током процеса. Испод су контроле које обавезно морају бити извршене у производним окружењима.

1. Потврдите SSH приступ

Потребно је да можете успоставити SSH везу из извора на циљни сервер. Стандардна веза се тестира на следећи начин: ssh корисник@циљ-сервер-ип. Ако SSH ради на другом порту, веза се може тестирати на следећи начин: ssh -p 2222 корисник@циљ-сервер-ип. Ако овај тест не успе, rsync такође неће радити. Морају се проверити заштитни зид, Fail2ban, SSH порт, корисничке дозволе и верификација лозинке или кључа.

2. Проверите да ли је rsync пакет инсталиран

У већини Линукс дистрибуција, rsync долази инсталиран, али је добро проверити. На системима базираним на Дебијану и Убунту можете користити rsync --version команду. Ако није инсталиран, можете га инсталирати помоћу apt install rsync. На дистрибуцијама као што су AlmaLinux, Rocky Linux или CentOS, можете користити dnf install rsync или yum install rsync команду. Ако користите Линукс базиран VPS на Hostragons, инсталација обично траје само неколико секунди.

3. Израчунате слободан простор на диску

Ако на циљном серверу нема довољно слободног простора, пренос ће бити прекинут. За преглед величине извора можете користити du -sh /извор/директоријум. На циљу, мора се проверити стање диска са df -h командом. У пракси, не само да је потребно планирати простор за величину датотека, већ и оставити простор за привремене датотеке и логове. На пример, ако преносите 500 ГБ података, планирајте најмање 550-600 ГБ слободног простора на циљу.

4. Планирајте критичне услуге и променљиве датотеке

Датотеке на активним веб страницама могу се мењати током преноса. Посебно корисничке уплате, кеш фолдери и лог датотеке стално се ажурирају. Код великих преноса, прво се преносе основни подаци, а затим се ставља у режим одржавања и изврши последњи rsync. На тај начин, време прекида може бити смањено на минуте. За WordPress сајтове можете завршити свој план операције уз помоћ подршке као што је Водич за пренос WordPress хостинга.

Основна rsync команда: Пренос датотека између два сервера

Најчешће коришћена основна конструкција је: rsync -avz /извор/директоријум/ корисник@циљ-ип:/циљ/директоријум/. Овде -a представља архивски мод и покушава да задржи информације као што су дозволе, временске ознаке и симболске везе. -v даје детаљан излаз. -z примењује компресију током преноса. Важно је напоменути да коса crta на крају директоријума има важну улогу. Ако напишете /извор/директоријум/, садржај директоријума ће бити копиран на циљ; ако напишете /извор/директоријум, сам директоријум ће бити створен на циљу.

Размотримо пример сценарија: желите да пренесете 180 ГБ веб датотека из /var/www/site/public_html/ директоријума на нови сервер у /var/www/site/public_html/. Команда ће радити на следећи начин: rsync -avz /var/www/site/public_html/ root@203.0.113.20:/var/www/site/public_html/. Ова операција преноси датотеке из извора на циљни сервер преко SSH.

Aко не желите да користите root, боље је да на циљном серверу креирате посебног корисника који има дозволу за писање у одговарајући директоријум. На пример, можете користити корисника deploy и поставити власништво директоријума према томе. У производним окружењима, обављање операција директно као root може бити практично, али се препоручује коришћење корисника са ограниченим правима из безбедносних разлога.

Препоручени сигурни и отпорни rsync параметри

При преносу великих датотека, ослањање само на основну команду није увек исправно. За прекиде везе, делимичне датотеке, погрешне операције брисања или спори мрежа потребни су додатни параметри. Следећа команда представља добру почетну тачку за многе реалне сценарије преноса:

rsync -aHAXv --numeric-ids --partial --progress --append-verify -e ssh /извор/директоријум/ корисник@циљ-ип:/циљ/директоријум/

У овој команди -a помаже у одржавању архивског режима, -H задржава информације о хард везама, -A задржава ACL дозволе, а -X задржава вредности проширених атрибута. --numeric-ids користи ID вредности уместо имена корисника и групе; то може бити корисно када се имена корисника разликују на различитим серверима. --partial оставља делимичне датотеке без брисања. --progress показује статус преноса. --append-verify посебно помаже да се потврди додатни део када се пренос наставља из тачке на којој је прекинут, посебно код великих датотека.

Сваки параметар можда неће бити потребан на сваком систему. На пример, за једноставан пренос веб сајта, коришћење -aHAX може бити довољно, док је у апликацијама које користе специјалне дозволе критично задржати ACL и информације о проширеним атрибутима. Због тога је важно прво извршити тестни пренос.

Како написати команду ако користите различити SSH порт?

Из безбедносних разлога, SSH порт може радити на другом порту уместо 22. У том случају, SSH параметар се наводи у rsync. Пример: rsync -avz -e ssh -p 2222 /извор/директоријум/ корисник@циљ-ип:/циљ/директоријум/. Међутим, вредност параметра -e мора бити коришћена заједно у командној линији. Исправна логика коришћења је: rsync -avz -e 'ssh -p 2222' /извор/директоријум/ корисник@циљ-ип:/циљ/директоријум/.

Због различитог понашања једноставних наводника у JSON-у и неким панелима, уверите се да су наводници исправни када их директно пишете у терминалу. Ако се повезујете помоћу SSH кључа, можете додати и -i параметар: rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /извор/директоријум/ корисник@циљ-ип:/циљ/директоријум/. Овај метод се често користи у аутоматизацији и задачама резервних копија базираним на cron-у.

Тест пре преноса: коришћење --dry-run

Један од најпрофесионалнијих корака пре преноса великих података је коришћење --dry-run. Овај параметар не копира датотеке; само показује које датотеке ће бити пренете. На тај начин можете рано уочити погрешан директоријум, погрешан циљ или неочекиване операције брисања.

Пример тест команде: rsync -avz --dry-run /var/www/site/ корисник@циљ-ип:/var/www/site/. У излазу ћете видети које ће датотеке бити пренете, који ће директоријуми бити створени и резиме операције. Ако планирате да користите --delete параметар, --dry-run постаје још критичнији. јер --delete може обрисати датотеке које нису присутне на извору на циљу. Када се правилно користи, чини циљ идентичним извору; али ако се користи у погрешном директорију, може довести до значајног губитка података.

Професионални редослед примене обично је следећи: прво се врши тест SSH, затим се проверава простор на диску, потом се покреће rsync --dry-run, затим се ради прави тест са малим директоријумом, а на крају се покреће главни пренос. Овај приступ може захтевати неколико додатних минута, али спречава преносе који могу трајати сате.

Подешавања компресије, пропусности и шифровања за перформансе

Перформансе rsync-а не зависе само од величине датотека. Потребна је и CPU снага сервера, тип диска, мрежна латенција, пропусни опсег и број датотека. Велики број малих датотека може се преносити спорије него једна велика датотека; јер за сваку датотеку морају бити извршене операције метаподатака. У VPS окружењима са NVMe дисковима, перформансе скенирања и писања датотека могу бити знатно боље. Због тога, ако планирате интензиван пренос, разумно је размотрити NVMe VPS сервер опције.

-z параметар компресије пружа користи за текстуалне датотеке, логове и неке врсте резервних копија. Међутим, компримоване zip, tar.gz, jpg, mp4 или gzip датотеке могу потрошити CPU без значајне добити. Када преносите велике медијске датотеке између два моћна сервера са 1 Gbps везом, можете добити боље перформансе без -z. С друге стране, код ниског пропусног опсега и текстуално оптерећених датотека, -z може значајно уштедети.

За ограничење пропусног опсега може се користити --bwlimit. На пример, --bwlimit=50000 поставља границу на приближно 50 MB/s. Ово је важно да не блокирате мрежни саобраћај активног веб сајта. Извођење преноса на производном серверу у активно време може негативно утицати на искуство посетилаца. Планирање преноса у вечерњим сатима, постављање границе пропусног опсега и праћење вредности load average током процеса је добра пракса.

Поређење rsync, scp, SFTP и FTP

Постоји више метода за пренос датотека; али свакој методи недостају снаге и слабе стране. Долња табела резимира који алат је најпогоднији за велике датотеке и сценарије преноса сервера.

Како се види из табеле, rsync се посебно истиче у поновљеним синхронизацијама и преносу великих података. scp је једноставан и користан, али није толико моћан као rsync у паметном детектовању променљивих датотека. FTP, када се користи без шифровања, није прикладан за савремене безбедносне стандарде. FTP доступност у хостинг панелима може бити практична; али за критичне преносе између сервера, требало би да се преферирају методе базиране на SSH.

Пример радног токa за пренос активног веб сајта

Када преносите веб сајт из старог сервера на нови, циљ није само копирање датотека. Такође треба проверити DNS, базу података, верзију PHP, дозволе датотека и конфигурацију е-поште. Испод је пример радног toka за веб сајт са великим датотекама са малим прекидима.

• Подесите веб сервер, PHP, базу података и потребне модуле на новом серверу.
• Смањите DNS TTL вредност домена на ниску вредност, као што је 300 секунди, пре преноса. Можете размотрити страницу доменска претрага и управљање доменима за управљање доменом.
• Покрените прву rsync операцију док је сајт активан. Ова фаза преноси већину великих података.
• Направите резервну копију базе података и пренесите је на нови сервер.
• Ставите сајт у кратак режим одржавања.
• Покрените другу rsync команду за синхронизацију последњих променљивих датотека.
• Ажурирајте базу података или користите инкременталну стратегију.
• Проверите дозволе датотека, стартовање сајта и логове на новом серверу.
• Инсталирајте или обновите SSL сертификат. За ово би могао бити користан садржај Инсталација SSL сертификата.
• Преусмерите DNS записе на нову IP адресу.

У овој методи, најдужи пренос главних датотека се изводи док је сајт активан. Прекиди се јављају само током последње синхронизације и преласка на DNS. Овај приступ може смањити време прекида на неколико минута, посебно код WordPress сајтова са великим медијским архивима.

Контрола интегритета података

Када се пренос заврши, само завршетак команде није довољан. Морају се проверити број датотека, величине и критичне датотеке. За једноставну контролу, можете упоредити величине директоријума на извору и циљу помоћу du -sh команде. Међутим, због разлика у блоковима датотечног система, вредности можда неће изгледати идентично. За детаљнију контролу, rsync се може поново покренути са истим параметрима. Ако нема нових датотека за пренос, излаз ће бити минималан.

За проверу контролних сумова, можете користити rsync -avc --dry-run /извор/директоријум/ корисник@циљ-ип:/циљ/директоријум/. Овде параметар -c упоређује датотеке не само по временској ознаци и величини, већ и по контролним сумовима. Због великог оптерећења CPU-а и диска, пажљиво користите овај параметар. Ова додатна верификација пружа сигурност за критичне архиве, резервне копије база података или документацију клијената.

Ако сте преносили веб сајт, такође проверите на нивоу апликације. Морају се испитати почетна страница, административни панел, визуелно учитавање, страница за плаћање, контакт форма и логови грешака. У е-трговинским сајтовима, само пренос датотека није довољан; интеграције плаћања и cron задатке такође треба тестирати на новом серверу.

Чести проблеми и решења

Грешка Permission denied

Ова грешка обично настаје због корисничких права SSH, права за писање у циљном директоријуму или верификације кључа. Прво покушајте да успоставите нормалну SSH везу са истим корисником. Ако веза прође, тестирајте креирање датотеке у циљном директоријуму. Ако је потребно, промените власништво циљне фасцикле коришћењем chown за одговарајућег корисника или планирајте стратегију засновану на sudo.

Грешка No space left on device

Када на циљном диску не остане довољно простора, пренос се прекида. Проверите партиције диска помоћу df -h. Понекад главни диск није пун, али /tmp или циљна монт точка може бити пуна. Код великих преноса, лог датотеке, старе резервне копије и кеш фолдери могу бити очишћени. За трајно решење може бити потребно повећање диска или прелазак на VPS планове са већим капацитетом.

Грешка Connection reset или Broken pipe

Током дугих преноса могу се јавити мрежни прекиди. Ако користите --partial и --append-verify, можете поново покренути команду да наставите од места на коме сте стали. Такође, SSH keepalive подешавања могу бити од помоћи. На страни клијента, подешавање ServerAliveInterval 60 може смањити шансе за прекид везе због неактивности.

Веома спор пренос

Спора преноса може бити узрокована бројем датотека, I/O лимитом диска, оптерећењем компресијом или мрежним капацитетом. Ако имате велики број малих датотека, прво креирање tar архива може бити брже у неким ситуацијама; али у таквом случају, предност rsync-а у праћењу промена у датотекама се смањује. Тестирајте и са -z параметром уклоњеним у великим и већ стиснутим датотекама. Такође, користите алате као што су iotop, htop и iftop да бисте утврдили где је уско грло: на страни CPU-а, диска или мреже.

Најбоље праксе за безбедност

Током преноса датотека између сервера, безбедност не треба занемарити. Посебно root приступ, SSH кључеви и резервне копије треба сматрати осетљивим. Препоручује се коришћење SSH кључа уместо лозинке. Дозволе за кључне датотеке морају бити строгe, приватни кључеви се не смеју делити и, ако је могуће, заштитити passphrase-ом.

Креирање привременог корисника за пренос и давање приступа само неопходним директоријумима је добар метод. Након завршетка операције, права овом кориснику могу бити уклоњена или налог деактивиран. Ограничење SSH приступа на одређене IP адресе такође смањује површину напада. Правила за заштитни зид, Fail2ban и ажурна верзија OpenSSH требало би да буду основне контроле.

Ако се преносе резервне копије база података, документа клијената или архиве које садрже личне податке, непотребне привремене датотеке треба очистити на извору и циљу након преноса. Осим тога, остављање резервних датотека попут .sql, .zip или .tar у коренском директоријуму веба представља озбиљан безбедносни ризик. Ове датотеке треба чувати у директоријуму који је затворен за веб приступ, или их обрисати након завршетка процеса.

Користите rsync за аутоматске резервне копије

rsync се може користити не само за једнократни пренос, већ и за редовне резервне копије. На пример, можете дефинисати cron задатак да сваке ноћи пошаље одређени директоријум на резервни сервер. У овој ситуацији, успоставља се сигурна веза без лозинке помоћу SSH кључа, rsync преноси само променљиве датотеке и може се применити ограничење пропусног опсега.

Пример логике: rsync -a --delete --bwlimit=30000 /var/www/site/ backup@резервни-ип:/backup/site/. Ова команда може ускладити циљни директоријум са извором. Међутим, због --delete параметра, треба бити опрезан. Ако је датотека случајно обрисана на извору, она ће бити обрисана и на циљу. Због тога, у критичним стратегијама резервних копија, требало би да се преферирају решења подршке за snapshot, дневне директоријуме или верзионисање.

У хостинг операцијама, 3-2-1 правило резервних копија је добар референтни модел: најмање 3 копије података, у 2 различите средине, а 1 копија на различитој локацији. rsync чини део овог стратегије о копији између сервера практичним. За свеобухватнију инфраструктуру можете ојачати свој план са Решења за резервисање и услуге корпоративног хостинга садржајем.

Листа за последњу проверу

Пре него што започнете пренос великих датотека, следећа кратка листа може смањити ризик од грешке. Ова листа треба да постане стандардна процедура, посебно у производним окружењима.

• Да ли је rsync инсталиран на изворном и циљном серверу?
• Да ли је SSH веза тестирана са исправним корисником и портом?
• Да ли постоји довољно слободног простора на циљном серверу?
• Да ли је прва операција контролисана помоћу --dry-run?
• Да ли је режим одржавања и последња синхронизација планирана за активан сајт?
• Ако ће се користити --delete, да ли је циљна путања потврђена?
• Да ли ће се након преноса извршити тестови величине датотека, дозвола и апликације?
• Да ли ће се привремене резервне копије и dump датотеке безбедно очистити?

Ове контроле изгледају једноставно, али у стварности, најчешћи проблеми потичу од погрешних циљних директоријума, недостајућих дозвола, недовољног простора на диску и непланираног преласка на DNS. Планирани rsync процес смањује време преноса и повећава шансу за повратак.

Често постављана питања

Да ли пренос почиње изнова ако се веза преко SSH прекине?

Не, ако се користе исправни параметри, неће почети изнова. Опције --partial и --append-verify помажу у чувању делимичних великих датотека и омогућавају да пренос настави од места на коме је прекинут. Ипак, код критичних преноса, корисно је проверити простор на диску и статус делимичних датотека пре поновног покретања команде.

Да ли се базу података може директно преносити помоћу rsync?

rsync преноси датотеке; директно копирање активних датотека базе података није здраво. За MySQL или MariaDB требало би користити mysqldump или алате за физичко резервно копирање, а произведена резервна копија се преноси на циљни сервер помоћу rsync. У активним системима, за очување интегритета података, требало би планирати режим одржавања или стратегију репликације.

Да ли је потребан root приступ на оба сервера за коришћење rsync?

Root приступ није обавезан. Достатно је да постоји корисник са правима за писање у циљном директоријуму. Међутим, ако је потребно очувати власништво над датотекама, системске директорије, ACL или специјалне дозволе, може бити потребан виши ниво права. Из безбедносних разлога, боље је обављати операције са корисником са ограниченим правима, где год је то могуће.

Да ли је --delete параметар безбедан?

Када се правилно користи, --delete је веома користан за синхронизацију циљног директоријума са извором; али ако се користи у погрешном циљном директоријуму, може довести до губитка података. Због тога, команде које садрже --delete морају бити тестиране прво са --dry-run, а путеви извора и циља морају бити пажљиво проверени.

Шта је боље за пренос великих датотека, rsync или scp?

За једнократне мале копије scp може бити довољан; али за велике датотеке, велики број датотека и поновљене синхронизације, rsync је обично бољи. Зато што може да детектује променљиве податке, настави делимичне преносе, ограничи пропусни опсег и понуди тест режим.

Резиме и следећи корак

Пренос великих датотека између два сервера помоћу rsync команде преко SSH представља брз, сигуран и управљив метод. Уз исправне параметре, постаје отпоран на прекиде везе, преноси само променљиве датотеке, што штеди време, и смањује прекиде током преноса активног сајта. За најбоље резултате прво проверьте SSH и дисковни простор, тестирајте помоћу --dry-run, а затим планирано започните главни пренос.

Ако планирате прелазак на нови сервер, високо капацитетно складиште или перформансији хостинг инфраструктуру, можете погледати решења од Hostragons и учинити свој процес преноса безбеднијим уз опције VPS, хостинга, домена и SSL. Започните са малим тестовима, мерите и планирајте последњу синхронизацију без проблема.