Бързо прехвърляне на големи файлове между два сървъра с командата rsync през SSH

Командата rsync през SSH е един от най-практичните методи за бързо, сигурно и устойчиво прехвърляне на големи файлове между два сървъра в Linux. Особено при прехвърляне на файлове от уебсайтове с размери стотици GB, архиви за резервно копие, медийни папки или данни от приложения, rsync предлага съществено предимство в скоростта, тъй като предава само променените блокове, а не целите файлове, в сравнение с класическите методи за копиране. Основната логика на използването е следната: файловете на източния сървър се синхронизират криптирано с целевия сървър чрез SSH тунел; ако връзката бъде прекъсната, процесът може да продължи от мястото, на което е спрял.

При преместване на сървъри, обновяване на хостинг, смяна на дата център или операции за резервно копие както скоростта, така и целостта на данните са важни. Изтеглянето на голям архив в един файл и след това повторното му качване може да е времеемко и да наложи ново начало при проблеми с връзката. Тук rsync влиза в действие, като запазва времевите печати на файловете, разрешенията, информацията за собственост и структурата на папките. Поради това Linux системните администратори, DevOps екипите и специалистите по уеб хостинг често го използват в ежедневната си работа.

В това ръководство ще разгледаме процеса на прехвърляне на големи файлове между два Linux сървъра с rsync през SSH, стъпка по стъпка, с реални примери за команди. Освен това ще споделим параметри за повишаване на производителността, проверки за сигурност, сценарии за грешки, методи за тестова прехвърляне и важни точки, на които да обърнете внимание, преди да преминете към продукционна среда. Ако планирате преход към нов VPS или хостинг среда, уверете се, че имате достатъчно дисково пространство, SSH достъп и правилни потребителски разрешения на източния и целевия сървър, преди да приложите това ръководство. За свързани инфраструктурни решения можете да разгледате страниците с Hostragons решения за VPS сървър и Пакети за Линукс хостинг.

Какво е rsync и защо се предпочита при прехвърляне на големи файлове?

Rsync е мощен инструмент за команден ред, предназначен за синхронизиране на файлове и директории между локални системи или отдалечени сървъри. Най-важната му характеристика е алгоритъмът за делта прехвърляне, който предава само променените части на файла, вместо да изпраща целия файл всеки път. Например, ако имате резервен файл с размер 80 GB и само 2 GB от него е променено, вместо да прехвърляте целия файл отново, е възможно да прехвърлите само променените блокове.

SSH криптира прехвърлянето, осигурявайки, че съдържанието на файла не се предава в обикновен текст по мрежата. Тази функция е особено важна за клиентски данни, записи на електронна търговия, медийни архиви, резервни копия на бази данни и специализирани файлове на приложения. В света на хостинга сигурността на данните не се ограничава само до SSL сертификати; каналът за прехвърляне между сървъри също трябва да бъде защитен. Докато за уеб трафика се използва SSL сертификат, е препоръчително и за прехвърляне на файлове между сървъри да се предпочита SSH криптиране.

Rsync предлага повече гъвкавост в сравнение с методи като FTP или ръчно изтегляне и качване. Може да запази разрешения, да прехвърля символични линкове, да изтрива изтрити файлове и на целевия сървър, да ограничава честотната лента и да тества какво ще се случи преди прехвърлянето. Тази степен на контрол е сериозно предимство при рискови операции като прехвърляне на големи файлове.

Кога да използвате командата rsync през SSH?

Командата rsync през SSH е идеална особено за прехвърляне на големи, множество или често променящи се файлове. За прост визуален файлов каталог ръчното SFTP може да е достатъчно; но когато става дума за хиляди файлове, различни разрешения и големи архиви, rsync става много по-надеждно решение.

• Когато прехвърляте уебсайт от стар сървър на нов VPS сървър.
• Когато прехвърляте директории с хиляди медийни файлове, като папката uploads на WordPress.
• Когато копирате дневни, седмични или месечни резерви на различен сървър.
• Когато извършвате смяна на дата център или хостинг доставчик.
• Когато синхронизирате файлове на приложения между продукционна и резервна среда.
• Когато планирате дълготрайни прехвърляния с риск от прекъсване на връзката.

Например, ако искате да изтеглите папка с медии с размер 250 GB на вашия настолен компютър и след това да я качите на новия сървър, това означава, че трябва да направите две отделни прехвърляния. Това не само ще удължи общото време, но и ще превърне вашата домашна или офис интернет връзка в бутало. С rsync можете да избегнете тази междинна стъпка, като направите директно прехвърляне от източния сървър към целевия сървър.

Необходими условия преди започване

За успешна операция с rsync знанието за командата не е достатъчно. Проверка на условията на източния и целевия сървър ще намали риска от загуба на данни или непълно прехвърляне. Следващите проверки трябва да се извършат в продукционни среди.

1. Потвърдете SSH достъпа

Трябва да е възможно да установите SSH връзка от източния сървър към целевия сървър. Стандартната връзка се тества по следния начин: ssh потребител@целеви-сървър-ip. Ако SSH работи на различен порт, връзката се тества по следния начин: ssh -p 2222 потребител@целеви-сървър-ip. Ако този тест е неуспешен, rsync също няма да работи. Трябва да се проверят защитната стена, Fail2ban, SSH порт, потребителски права и парола или удостоверяване на ключ.

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

Повечето дистрибуции на Linux идват с инсталиран rsync; все пак е необходимо да се провери. В системи, базирани на Debian и Ubuntu, може да се използва командата rsync --version. Ако не е инсталиран, може да се инсталира с apt install rsync. В дистрибуции на AlmaLinux, Rocky Linux или CentOS, предпочитаните команди са dnf install rsync или yum install rsync. Ако използвате Linux-базиран VPS на Hostragons, инсталацията обикновено отнема само няколко секунди.

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

Ако на целевия сървър няма достатъчно свободно пространство, прехвърлянето ще бъде прекратено. За да видите размера на източната директория, може да се използва командата du -sh /източна/директория. Състоянието на диска на целевия сървър трябва да се провери с df -h. На практика, не само размерът на файловете, но и временното пространство и логовете също трябва да бъдат взети предвид. Например, ако прехвърляте 500 GB данни, е по-добре да планирате поне 550-600 GB свободно пространство на целевия сървър.

4. Планирайте критичните услуги и променящите се файлове

Файловете на активни уебсайтове могат да се променят по време на прехвърлянето. Особено потребителските качвания, кеш директориите и лог файловете постоянно се обновяват. При големи прехвърляния първо се прехвърля основните данни, след което се активира режим на поддръжка и се изпълнява последен rsync. Така времето на прекъсване може да се намали до минути. Можете да завършите плана си за действие с помощта на поддържащи материали, като Ръководство за прехвърляне на WordPress хостинг.

Основна команда rsync: Прехвърляне на файлове между два сървъра

Най-често използваната основна структура е: rsync -avz /източна/директория/ потребител@целеви-ip:/целева/директория/. Тук -a е архивен режим и се опитва да запази информация като разрешения, времеви печати и символични линкове. -v дава подробен изход. -z прилага компресия по време на прехвърляне. Важен детайл е наклонената черта в края на директорията. Ако напишете /източна/директория/, съдържанието на директорията ще бъде копирано на целевия сървър; ако напишете /източна/директория, самата директория ще бъде създадена под целевата директория.

Нека разгледаме примерен сценарий: искате да прехвърлите уеб файловете с размер 180 GB от директорията /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.

Ако не искате да използвате root, по-сигурно е да създадете специален потребител с разрешение за запис в съответната директория на целевия сървър. Можете да използвате потребителя deploy и да настроите собствеността на необходимите папки в зависимост от това. В продукционните среди е практично да се работи с ограничени права на потребителя вместо директно с root, от гледна точка на сигурността.

Препоръчителни сигурни и устойчиви параметри на rsync

При големи трансфери на файлове, разчитането само на основната команда не винаги е правилно. Нужни са допълнителни параметри за случаи на прекъсване на връзката, частични файлове, неправилно изтриване или бавни мрежи. Следната команда е надеждна отправна точка за много реални сценарии на прехвърляне:

rsync -aHAXv --numeric-ids --partial --progress --append-verify -e ssh /източна/директория/ потребител@целеви-ip:/целева/директория/

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

Всеки параметър не е задължителен за всяка система. Например, за прехвърляне на прост уебсайт може да е достатъчно да се използват -aHAX, докато при приложения, които използват специални разрешения на файлове, запазването на информация за ACL и разширени атрибути става критично. Поради това е важно първо да се направи тестово прехвърляне.

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

За сигурност SSH портът може да работи на различен порт, а не на 22. В този случай в rsync се посочва параметър за SSH. Пример: rsync -avz -e ssh -p 2222 /източна/директория/ потребител@целеви-ip:/целева/директория/. Важно е да се използва параметър -e в командния ред. Правилната логика е: rsync -avz -e 'ssh -p 2222' /източна/директория/ потребител@целеви-ip:/целева/директория/.

В JSON и някои панели използването на единични кавички може да действа по различен начин, така че при писане в терминала се уверете, че кавичките са правилни. Ако се свързвате с SSH ключ, можете да добавите параметър -i: rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /източна/директория/ потребител@целеви-ip:/целева/директория/. Този метод често се използва в автоматизация и задачи за резервно копие на cron.

Тест преди прехвърляне: Използване на --dry-run

Една от най-професионалните стъпки преди прехвърляне на големи данни е използването на --dry-run. Този параметър не копира наистина файловете; само показва кои файлове ще бъдат прехвърлени. Така могат да се открият неправилни директории, грешни целеви пътища или неочаквани операции по изтриване предварително.

Примерен тестов команден ред: rsync -avz --dry-run /var/www/site/ потребител@целеви-ip:/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. Това е важно, за да не се блокира мрежовият трафик на активен уебсайт. Извършването на трансфери с пълна скорост по време на натоварени часове на продукционния сървър може да повлияе негативно на потребителското изживяване. Добра практика е да планирате прехвърлянето за нощните часове, да поставите ограничение на честотната лента и да наблюдавате стойностите на натоварването по време на операцията.

Сравнение на rsync, scp, SFTP и FTP

Има множество методи за прехвърляне на файлове, но всеки метод има своите силни и слаби страни. Следната таблица обобщава кой инструмент е по-подходящ за прехвърляне на големи файлове и сценарии на преместване на сървъри.

Както се вижда от таблицата, rsync се отк突ва особено в повтарящи се синхронизации и преместване на големи данни. scp е прост и удобен, но не е толкова мощен, когато става дума за интелигентно откриване на променящи се файлове, колкото rsync. FTP, когато се използва без криптиране, не е подходящ за съвременните стандарти за сигурност. FTP достъпът в хостинг панелите може да бъде практичен; но при критични прехвърляния между сървъри трябва да се предпочитат методи, базирани на SSH.

Примерен работен поток за прехвърляне на активен уебсайт

Когато прехвърляте уебсайт от стар сървър на нов, целта не е само да копирате файловете. DNS, база данни, версия на PHP, разрешения на файлове и конфигурация на имейли също трябва да бъдат проверени. По-долу е представен примерен работен поток с ниско прекъсване за уебсайт с големи файлове.

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

В този метод най-дългото време отнема основното прехвърляне на файловете, докато сайтът е активен. Прекъсване настъпва единствено по време на последната синхронизация и DNS прехвърляне. Тази стратегия може да намали продължителността на прекъсване от часове на няколко минути при уебсайтове на WordPress с големи медийни архиви.

Проверка на цялостността на данните

След като прехвърлянето е завършено, само завършването на командата не е достатъчно. Броят на файловете, размерите и критичните файлове трябва да бъдат проверени. За проста проверка размерите на директориите могат да бъдат сравнени с du -sh командата на източния и целевия сървър. Въпреки това, поради разлики в блоковете на файловата система, стойностите може да не изглеждат идентични. За по-подробна проверка rsync може да бъде стартиран отново със същите параметри. Ако няма нови файлове за прехвърляне, изходът ще бъде минимален.

За проверка на контролна сума може да се използва rsync -avc --dry-run /източна/директория/ потребител@целеви-ip:/целева/директория/. Тук параметърът -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 ключ вместо паролна защита. Правата на файловете на ключовите файлове трябва да бъдат стриктно контролирани, личните ключове не трябва да се споделят и, когато е възможно, да бъдат защитени с passphrase.

Създаването на временно потребителско име за прехвърлянето и даването на достъп само до необходимите директории е добър метод. След завършване на операцията правата на този потребител могат да бъдат отнети или акаунтът може да бъде деактивиран. Ограничаването на SSH достъпа до определени IP адреси също намалява атакуващата повърхност. Правила за защитна стена, Fail2ban и актуалната версия на OpenSSH трябва да бъдат част от основните проверки.

Ако прехвърляте резервни файлове, документи на клиенти или архиви, съдържащи лични данни, е необходимо да почистите ненужните временни файлове на източната и целевата страна след прехвърлянето. Освен това, оставянето на резервни файлове с разширения .sql, .zip или .tar в кореновата директория на уебсайта представлява сериозен риск за сигурността. Тези файлове трябва да се съхраняват в директория, недостъпна за уеб или да бъдат изтрити след операцията.

Използване на rsync за автоматични резервни копия

Rsync може да се използва не само за еднократни прехвърляния, но и за редовни резервни копия. Например, можете да зададете cron задача, за да изпращате определена директория на резервен сървър всяка нощ. В този сценарий се установява сигурна безпаролна SSH връзка, rsync прехвърля само променените файлове и може да се приложи ограничение на честотната лента.

Примерна логика: rsync -a --delete --bwlimit=30000 /var/www/site/ backup@резервен-ip:/backup/site/. Тази команда може да синхронизира целевата директория с източника. Въпреки това, заради параметъра --delete, трябва да се използва внимателно. Неправилно изтрит файл в източника ще бъде изтрит и в целевия. Затова в критични стратегии за резервно копие трябва да се предпочитат решения с поддръжка на snapshot, дневни папки или версиониране.

В хостинг операциите правилото 3-2-1 за резервни копия е добро ръководство: най-малко 3 копия на данните, на 2 различни места, 1 копие на различна локация. Rsync прави частта за копиране между сървъри в тази стратегия практична. За по-подробни инфраструктурни решения можете да използвате Решения за архивиране и услуги за корпоративен хостинг, за да укрепите плана си.

Последен контролен списък

Преди да започнете прехвърлянето на големи файлове, изпълнението на следния кратък списък намалява риска от грешки. Този списък трябва да стане стандартна процедура, особено в продукционни среди.

• Инсталиран ли е rsync на източния и целевия сървър?
• Тествахте ли SSH връзката с правилния потребител и порт?
• Има ли достатъчно дисково пространство на целевия сървър?
• Провери ли се първата операция с --dry-run?
• Планиран ли е режим на поддръжка и последна синхронизация за активния сайт?
• Ако ще използвате --delete, проверени ли са целевите пътища?
• Ще се извършат ли проверки на размера на файловете, разрешенията и тестовете на приложения след прехвърлянето?
• Ще бъдат ли безопасно почистени временни резервни файлове и dump файлове?

Тези проверки изглеждат прости, но в реалния свят най-често срещаните проблеми произтичат от неправилни целеви директории, липсващи разрешения, недостатъчно дисково пространство и непланирани DNS прехвърляния. Планираният процес на rsync не само съкращава времето за прехвърляне, но и увеличава вероятността за успешен обратен ход.

Често задавани въпроси

Ако връзката се прекъсне по време на прехвърляне с 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, а след това планирайте основното прехвърляне.