Як хутка і бяспечна пераносіць вялікія файлы паміж двума серверамі праз SSH і rsync

Перанос вялікіх файлаў паміж серверамі — частая задача для сістэмных адміністратараў, DevOps-спецыялістаў і вэб-хостынг каманд. Праз SSH і rsync можна зрабіць гэты працэс хуткім, бяспечным і надзейным, асабліва калі гаворка ідзе пра сотні гігабайт: бэкапы сайтаў, медыя-архівы, дадзеныя праграм і г.д. rsync перадае толькі змененыя блокі, а не ўвесь файл, таму ён значна пераўзыходзіць звычайныя метады капіравання па хуткасці. Асноўны прынцып: файлы з крынічнага сервера сінхранізуюцца ў шыфраваным выглядзе праз SSH на мэтавы сервер; калі злучэнне абрываецца, перанос можна аднавіць з таго месца, дзе ён спыніўся.

Пры міграцыі сайтаў, абнаўленні хостынгу, змене датацэнтра ці бэкапе важныя не толькі хуткасць, але і цэласнасць дадзеных. Спроба спампаваць вялікі архіў цалкам і загрузіць яго нанова займае шмат часу і пры перапынках патрабуе пачаць зноў. rsync захоўвае таймстампы файлаў, правы доступу, уласнасць і структуру каталогаў, таму яго выбіраюць амаль усе спецыялісты ў Linux-hosting. У гэтым гайдзе мы разглядзім этапы пераносу вялікіх файлаў паміж серверамі праз SSH і rsync, дадзім рэальныя каманды, парады па аптымізацыі, бяспецы, сітуацыях з памылкамі, тэставых пераносах і крытычныя моманты перад запускам у прадукцыйнай рэальнасці. Перад пачаткам пераканайцеся, што на абодвух серверах ёсць дастаткова месца, SSH-доступ і правільныя правы карыстальніка. Для выбару VPS і хостынгу глядзіце Hostragons рашэнні для VPS сервера і Пакеты Linux Хостынгу.

Што такое rsync і чаму ён лепшы для пераносу вялікіх файлаў?

rsync — магутны інструмент для сінхранізацыі каталогаў і файлаў паміж лакальнымі і аддаленымі серверамі. Яго галоўная моц — алгарытм дэльта-перадачы: перадаюцца толькі змененыя часткі файла. Напрыклад, калі ў 80 GB бэкапе змянілася толькі 2 GB, rsync перашле толькі гэтыя блокі.

SSH забяспечвае шыфраванне перадачы. Вашы файлы не ідуць па сетцы як адкрыты тэкст — гэта крытычна для канфідэнцыйных дадзеных: кліенцкіх архіваў, заказаў, медыя і бэкапу баз дадзеных. У хостынг-сферы SSL-сертыфікат абараняе сайт, а SSH — канал паміж серверамі. Для файлаў паміж серверамі выкарыстоўвайце шыфраванне праз SSH, як і для сайтаў — Сертыфікат SSL.

rsync значна гібчэйшы за FTP ці ручную загрузку: захоўвае правы, пераносіць сімвалічныя спасылкі, можа выдаляць файлы, абмяжоўваць хуткасць, тэставаць перанос. Гэта дае кантроль і бяспеку, асабліва калі працуюць вялікія архівы.

Калі выкарыстоўваць rsync праз SSH?

rsync праз SSH ідэальны для вялікіх, часта зменяемых або масіўных файлаў. Для маленькіх каталогаў SFTP можа быць дастаткова, але калі тысячы файлаў, розныя правы і вялікія архівы — rsync гарантуе надзейнасць.

• Перанос сайта з старога сервера на новы VPS.
• Медыятэка WordPress: тысячы файлаў у uploads.
• Бэкапы (штодзённыя, тыднёвыя, месячныя) на іншы сервер.
• Пераезд у новы датацэнтр або хостынг-правайдэр.
• Сінхранізацыя файлаў паміж прадукцыйнай і бэкап-сістэмай.
• Працяглы перанос з рызыкай абрыву злучэння.

Напрыклад, перанос 250 GB медыя-каталога праз ваш камп’ютар — гэта два этапы, што падоўжыць працэс і перагрузіць ваш інтэрнэт. rsync дазваляе пераносіць файлы напрамую паміж серверамі, не стварыўшы unnecessary bottlenecks.

Што трэба праверыць перад пачаткам

Для паспяховага rsync пераносу аднаго ведання каманды мала. Праверце параметры сервераў, каб зменшыць рызыку страты дадзеных або няпоўнага пераносу. Вось што неабходна зрабіць:

1. Праверка SSH-доступу

Злучэнне з мэтавым серверам праз SSH павінна працаваць: ssh user@target-ip. Калі порт нестандартны, ssh -p 2222 user@target-ip. Калі не працуе, rsync таксама не зможа падключыцца. Праверце firewall, Fail2ban, порт SSH, правы карыстальніка і аўтэнтыфікацыю.

2. rsync павінен быць усталяваны

У большасці Linux-дыстрыбуцый rsync ёсць па змаўчанні, але праверце rsync --version. Калі няма — apt install rsync (Debian/Ubuntu), dnf install rsync або yum install rsync (CentOS/Rocky/AlmaLinux). На VPS ад Hostragons з Linux гэта займае некалькі секунд.

3. Дастаткова месца на дыску

Недахоп месца спыняе перанос. Праверце du -sh /source/dir на крыніцы, df -h на мэтавым серверы. Дадайце запас для часовых файлаў і логаў — калі пераносіце 500 GB, плануйце мінімум 550-600 GB.

4. Планаваць змены на жывы сайт

Пры пераносе жывых сайтаў файлы могуць змяняцца падчас працэсу — uploads, cache, логаў. Спачатку перанесіце асноўныя дадзеныя, потым перавядзіце сайт у рэжым абслугоўвання і зрабіце фінальны rsync. Так downtime будзе мінімальным. Для WordPress глядзіце Кіраўніцтва па пераносу WordPress хостынга.

Базавая каманда rsync: як пераносіць файлы паміж серверамі

Асноўная каманда: rsync -avz /source/dir/ user@target-ip:/target/dir/. -a — архіўны рэжым (захоўвае правы, таймстампы, сімв. спасылкі), -v — падрабязны вывад, -z — сціск пры перадачы. Звярніце ўвагу на слэш у канцы: /source/dir/ пераносіць змесціва каталога, /source/dir — сам каталог.

Прыклад: перанос /var/www/site/public_html/ (180 GB) з старога на новы сервер: rsync -avz /var/www/site/public_html/ root@203.0.113.20:/var/www/site/public_html/. Каманда пераносіць файлы праз SSH.

Для бяспекі лепш стварыць асобнага карыстальніка (напрыклад, deploy), які мае права запісу ў мэтавы каталог. root дае прастату, але абмежаваны карыстальнік — лепшая практыка.

Рэкамендаваныя параметры для бяспечнага і надзейнага rsync

Пры вялікіх пераносах базавая каманда — гэта не ўсё. Для абароны ад абрыву злучэння, частковых файлаў, выпадковых выдаленняў і павольных сетак дадавайце параметры:

rsync -aHAXv --numeric-ids --partial --progress --append-verify -e ssh /source/dir/ user@target-ip:/target/dir/

-a — архіў, -H — hard link, -A — ACL, -X — extended attributes. --numeric-ids — ідэнтыфікатары карыстальнікаў/груп, --partial — не выдаляе частковыя файлы, --progress — паказвае ход пераносу, --append-verify — правярае даданыя часткі пры працягненні.

Не ўсе параметры патрэбны ў кожным выпадку. Для простых сайтаў -aHAX дастаткова, для складаных прыкладанняў з ACL і extended attributes — важна. Заўсёды рабіце тэставы перанос.

rsync з нестандартным SSH-портам

Калі SSH працуе не на 22-м порце, выкарыстоўвайце -e: rsync -avz -e 'ssh -p 2222' /source/dir/ user@target-ip:/target/dir/. Для SSH-ключа дадайце -i: rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /source/dir/ user@target-ip:/target/dir/. Гэта вельмі карысна для аўтаматызацыі і cron-бэкапаў.

У некаторых панелях і JSON-скрыптах кавычкі могуць працаваць інакш, таму ў тэрмінале ўважліва ўводзьце каманду.

Тэставы перанос: --dry-run

Самы прафесійны крок перад вялікім пераносам — запусціць rsync з --dry-run. Файлы не пераносяцца, але паказваецца, што будзе зроблена: якія файлы, якія каталоги, якія выдаленні. Гэта дазваляе заўчасна выправіць памылкі і няправільныя шляхі.

Прыклад: rsync -avz --dry-run /var/www/site/ user@target-ip:/var/www/site/. З --delete dry-run крытычны, бо гэты параметр выдаляе файлы на мэтавым серверы, якіх няма на крыніцы. Правільна — мэтавая папка стане люстрай крыніцы, памылкова — можна страціць дадзеныя.

Прафесійны workflow: спачатку SSH-тэст, потым праверка дыска, dry-run, рэальны перанос маленькага каталога, і толькі потым асноўны перанос. Гэта некалькі хвілін, але эканоміць гадзіны і дні на выпраўленне памылак.

Аптымізацыя: сціск, прапускная здольнасць, шыфраванне

Хуткасць rsync залежыць не толькі ад аб’ёму файлаў, але і ад CPU, дыска, сеткі, колькасці файлаў. Мноства маленькіх файлаў пераносіцца павольней, бо для кожнага — метаданыя. На VPS з NVMe дыскамі перанос ідзе хутчэй, таму для масавых пераносаў глядзіце Сервер NVMe VPS.

-z (сціск) — карысны для тэкставых файлаў, логаў, бэкапаў. Але для ўжо сціснутых файлаў (zip, tar.gz, jpg, mp4) можа толькі павялічыць нагрузку на CPU без выйгрышу ў хуткасці. Пры пераносах медыя — лепш без -z, пры тэкставых — з -z.

Бандытная здольнасць: --bwlimit=50000 (50 MB/s). Гэта абараняе жывы сайт ад перагрузкі сеткі. Перанос лепш планаваць на ноч, дадаваць bwlimit і маніторыць нагрузку.

Параўнанне rsync, scp, SFTP, FTP

Існуе некалькі метадаў пераносу файлаў, але ў кожнага свае плюсы і мінусы. Табліца паказвае, калі і што лепш выкарыстоўваць:

rsync лідыруе, калі трэба сінхранізаваць вялікі аб’ём дадзеных або часта паўтараць перанос. scp просты, але не дае гнуткасці rsync. FTP без шыфравання — не для сучасных задач. Для крытычных пераносаў выбірайце SSH-метады.

Прыклад workflow для пераносу сайта з мінімальным downtime

Перанос сайта — гэта не толькі файлы, але і DNS, база дадзеных, SSL, PHP, правы, email. Вось workflow для вялікіх сайтаў:

• На новым серверы падрыхтуйце web server, PHP, базу, модулі.
• Перад пераносам зменіце DNS TTL на 300 сек. Для кіравання даменам глядзіце Праверка дамена і кіраванне даменамі.
• Запусціце першы rsync, калі сайт працуе. Гэта пераносіць асноўны аб’ём.
• Зрабіце бэкап базы і перанясіце яе.
• Перавядзіце сайт у рэжым абслугоўвання.
• Запусціце другі rsync для змененых файлаў.
• Абнавіце базу або выкарыстоўвайце incremental перанос.
• Праверце правы, запуск сайта і логаў.
• Усталюйце/абнавіце SSL-сертыфікат (Устаноўка сертыфіката SSL).
• Абнавіце DNS-запісы для новага IP.

Асноўны перанос адбываецца, калі сайт працуе. Downtime — толькі пры фінальнай сінхранізацыі і DNS-пераходзе. Для WordPress з вялікімі медыя архівамі гэта скарачае перапынкі з гадзін да хвілін.

Праверка цэласнасці дадзеных

Пасля пераносу праверце не толькі завяршэнне каманды, але і колькасць файлаў, памер, важныя файлы. du -sh на крыніцы і мэтавым серверы параўноўвае аб’ём, але могуць быць розніцы ў filesystem. Для дакладнай праверкі запусціце rsync з тымі ж параметрамі: калі нічога не пераносіцца — усё добра.

Для checksum: rsync -avc --dry-run /source/dir/ user@target-ip:/target/dir/. -c параўноўвае файлы па checksum. Гэта дадае нагрузку, таму выкарыстоўвайце для крытычных архіваў, dump-файлаў, кліенцкіх дакументаў.

Пасля пераносу сайта праверце яго на ўзроўні прыкладання: homepage, admin, загрузка малюнкаў, аплата, формы, логаў. Для e-commerce — праверце інтэграцыю плацяжоў і cron-заданні.

Тыповыя памылкі і рашэнні

Permission denied

Праблема з правамі SSH, доступам да мэтавага каталога, праверкай ключа. Заўсёды спачатку праверце SSH-логін з тым жа карыстальнікам. Калі працуе — паспрабуйце стварыць файл у мэтавай папцы. Калі не — змяніце ўласнасць (chown) або выкарыстоўвайце sudo.

No space left on device

На дыску няма месца. df -h паказвае аб’ём, але часам перапоўнены /tmp або mount-point. Чысціце логаў, старыя бэкапы, cache. Калі пастаянная праблема — пашырайце дыск ці абірайце VPS з большым месцам.

Connection reset або Broken pipe

Пры доўгіх пераносах бывае абрыў сеткі. З параметрамі --partial і --append-verify вы можаце працягнуць з месца спынення. Дадайце ServerAliveInterval 60 у SSH, каб злучэнне не абрывалася без дзейнасці.

Павольны перанос

Павольнасць можа быць з-за колькасці файлаў, абмежавання I/O, нагрузкі на CPU, прапускной здольнасці. Калі шмат маленькіх файлаў — можна спачатку стварыць tar-архіў, але rsync тады страціць перавагі. Для ўжо сціснутых файлаў — выдаліце -z. Маніторыце iotop, htop, iftop для выявы bottleneck-а.

Бяспека: лепшыя практыкі

Не забывайце пра бяспеку: root-доступ, SSH-ключы, бэкапы — ўсё важна. Аддавайце перавагу SSH-ключам з passphrase, не перадавайце приватныя ключы, усталюйце строгія правы на файлы.

Стварыце асобнага карыстальніка для пераносу, дайце доступ толькі да патрэбных каталогаў. Пасля пераносу выдаліце або адключыце карыстальніка. Абмежуйце SSH па IP, настройце firewall, Fail2ban і выкарыстоўвайце апошнюю версію OpenSSH.

Пасля пераносу выдаліце часовыя файлы і бэкапы з web-root (.sql, .zip, .tar) — яны могуць стаць шэрагам для атакаў. Захоўвайце іх у закрытых каталогаў або выдаляйце адразу пасля пераносу.

rsync для аўтаматычных бэкапаў

rsync — не толькі для аднаразовых пераносаў, але і для рэгулярных бэкапаў. Заплануйце cron-задачу для пераносу каталогаў на бэкап-сервер. Падключэнне праз SSH-ключ (без пароля) бяспечна, rsync пераносіць толькі змены, можна абмежаваць прапускную здольнасць.

Прыклад: rsync -a --delete --bwlimit=30000 /var/www/site/ backup@backup-ip:/backup/site/. Каманда сінхранізуе мэтавы каталог з крыніцай. --delete — небяспечны, бо выдаляе файлы на backup, якіх няма на крыніцы. Для важных бэкапаў выкарыстоўвайце snapshot, версіраванне, або штодзённыя папкі.

У хостынг-практыцы дзейнічае правіла 3-2-1: 3 копіі, 2 розныя носьбіты, 1 копія на іншай локацыі. rsync робіць міжсерверную копію простай. Для складаных задач глядзіце Рашэнні для рэзервовага капіявання і паслугі карпаратыўнага хостынгу.

Канчатковы чэк-ліст

Перад пераносам вялікіх файлаў праверце:

• rsync усталяваны на абодвух серверах?
• SSH працуе з правільным карыстальнікам і портам?
• На мэтавым серверы дастаткова месца?
• Перанос тэставаны з --dry-run?
• План уключае рэжым абслугоўвання і фінальную сінхранізацыю?
• --delete правільна настроены для мэтавага каталога?
• Праверка памеру, правоў і тэст прыкладання пасля пераносу?
• Часовыя файлы бэкапа будуць выдалены?

Нават простыя пункты чэк-ліста дапамагаюць пазбегнуць частых праблем: няправільны каталог, недастатковыя правы, недахоп месца, неапрацаваны DNS. Планаваны rsync-працэс скарачае час, забяспечвае надзейнасць і магчымасць адката.

Частыя пытанні

Пры абрыве злучэння rsync пачне перанос спачатку?

Не, калі выкарыстоўваць --partial і --append-verify, перанос працягнецца з месца абрыву. Але перад паўторным запускам праверце месца на дыску і частковыя файлы.

Ці можна rsync пераносіць базу дадзеных?

rsync пераносіць файлы, але не рэкамендуецца выкарыстоўваць яго для жывых файлаў базы дадзеных. Для MySQL/MariaDB лепш зрабіць dump праз mysqldump і перанесці файл rsync-ам. Для цэласнасці дадзеных выкарыстоўвайце рэжым абслугоўвання або рэплікацыю.

Ці патрэбны root-доступ для rsync?

Не — дастаткова карыстальніка з правамі на мэтавы каталог. Але для захавання уласнасці, ACL, сістэмных каталогаў патрэбны больш высокія правы. Для бяспекі працуйце з абмежаваным карыстальнікам.

--delete бяспечны?

Калі ўсё настроена дакладна — так, ён сінхранізуе мэтавы каталог з крыніцай. Але калі выкарыстоўваць няправільны каталог — можна страціць дадзеныя. Заўсёды тэстуйце з --dry-run.

Для вялікіх файлаў rsync ці scp?

Для малых файлаў — scp, для вялікіх, масавых, часта зменяемых — rsync. Ён лепш апрацоўвае змены, абрывы злучэння, абмежаванне прапускной здольнасці і тэставы рэжым.

Рэзюмэ і наступныя крокі

Перанос вялікіх файлаў паміж серверамі праз SSH і rsync — хуткі, бяспечны і кіраваны спосаб. Правільныя параметры забяспечваюць надзейнасць пры абрывах злучэння, пераносяць толькі змены, мінімізуюць downtime. Лепшыя практыкі: праверка SSH і дыска, тэставы dry-run, планаваны запуск асноўнага пераносу.

Калі вы плануеце міграцыю на новы сервер, больш ёмісты сховішча або прадукцыйны хостынг, азнаёмцеся з Hostragons: VPS, хостынг, дамен, SSL — усё для бяспечнага пераносу. Пачынайце з малых тэстаў, вымярайце вынік і праводзьце фінальную сінхранізацыю ў планаваны час.