Paano Maglipat ng Malalaking File sa Dalawang Server Gamit ang rsync sa SSH: Mabilis, Ligtas, at Walang Sagabal

Ang SSH gamit ang rsync command ay isa sa pinaka-praktikal na paraan sa Linux para maglipat ng malalaking file sa pagitan ng dalawang server nang mabilis, ligtas, at hindi madaling maputol. Kapag kailangan mong mag-migrate ng daan-daang GB na website files, backup archive, media folder o application data, mas mabilis ang rsync dahil kaya nitong i-transfer ang nagbago lang na bahagi ng files. Ang pangunahing prinsipyo: ang files sa source server ay sine-synchronize sa destination server sa pamamagitan ng SSH tunnel; kung maputol ang connection, puwedeng magpatuloy ang proseso kung saan ito tumigil.

Sa paglipat ng server, pag-upgrade ng hosting, palit ng data center o backup operations, mahalaga ang bilis at integrity ng data. Ang pag-download at upload ng malalaking archive sa isang buo ay matagal at kapag nagka-problema sa connection, kailangan mong magsimula uli. Dito pumapasok ang rsync—kaya nitong panatilihin ang file timestamps, permissions, ownership at folder structure. Kaya madalas itong gamitin ng Linux admins, DevOps teams, at web hosting experts sa pang-araw-araw na operations.

Sa gabay na ito, tatalakayin natin ang step-by-step na paglipat ng malalaking files sa pagitan ng dalawang Linux server gamit ang rsync sa SSH, may totoong command example. Ituturo rin namin ang mga performance tweaks, security tips, error scenarios, test migration methods, at mga bagay na dapat tandaan bago mag-production. Kung nagpaplano kang lumipat sa bagong VPS o hosting, tiyakin muna na may sapat na disk space, SSH access at tamang user permissions ang source at destination server mo. Para sa tamang server setup, bisitahin ang Hostragons Mga Solusyon sa VPS Server at Mga Pakete ng Linux Hosting.

Ano ang rsync at Bakit Ito ang Pinakamagandang Tool sa Malalaking File Transfer?

Ang rsync ay isang powerful command-line tool para mag-sync ng files at directories sa local o remote server. Ang pinaka-importanteng feature nito ay ang delta transfer algorithm: imbes na i-transfer ang buong file bawat time, nagbabago lang ang inilipat kapag may update. Halimbawa, kung may 80 GB backup file at 2 GB lang ang nagbago, pwedeng mag-transfer ng 2 GB lang imbes na buong file.

Ang SSH naman ay nag-eencrypt ng transfer. Hindi plain text ang files na lumalakad sa network. Lalo itong mahalaga sa customer data, e-commerce order logs, media archive, database backup, at special app files. Sa web hosting, hindi sapat ang SSL certificate sa site traffic; dapat secure din ang transfer sa pagitan ng servers. Gamitin ang sertipiko ng SSL para sa website, at SSH encryption para sa server-to-server file transfer.

Mas flexible ang rsync kaysa FTP o manual download-upload. Pinapanatili nito ang permissions, symbolic links, puwedeng mag-delete ng files sa destination na wala na sa source, limit ang bandwidth, at mag-test kung ano ang gagawin bago mag-transfer. Sa risky operations tulad ng malalaking file transfer, mas kontrolado at mas mabilis ito.

Kailan Dapat Gamitin ang rsync sa SSH?

Ideal ang rsync sa SSH kapag malalaki, maraming, o madalas magbago ang files na nililipat. Sa simpleng image folder, sapat na ang manual SFTP. Pero kung libo-libong files, iba-ibang permissions, at malalaking archive, mas reliable ang rsync.

• Kung naglilipat ng website mula old server papunta sa bagong VPS.
• Kung nililipat ang WordPress uploads folder na maraming media files.
• Kung nagco-copy ng daily, weekly, o monthly backups sa ibang server.
• Kung nagpapalit ng data center o hosting provider.
• Kung nagse-sync ng application files sa production at backup environment.
• Kung may long transfers na puwedeng maputol ang connection.

Halimbawa, kung may 250 GB media folder, ang pag-download sa local PC at upload sa bagong server ay dalawang transfer—mas matagal at bottleneck pa ang home/office internet. Mas mainam ang rsync dahil direct transfer ito mula source server papunta sa destination server.

Mga Dapat Ihanda Bago Mag-Transfer

Hindi sapat ang alam sa command para maging successful ang rsync operation. Dapat i-check ang kondisyon ng source at destination server para maiwasan ang data loss o incomplete transfer. Narito ang mga dapat gawin lalo na sa production.

1. Siguraduhin ang SSH Access

Dapat makakonekta ang source server sa destination server sa SSH. Test: ssh user@destination-ip. Kung ibang port ang gamit, test: ssh -p 2222 user@destination-ip. Kung hindi mag-connect, hindi gagana ang rsync. I-check ang firewall, Fail2ban, SSH port, user privileges, at password o key authentication.

2. I-check kung Installed ang rsync Package

Karaniwang installed na ang rsync sa Linux, pero dapat i-check. Sa Debian/Ubuntu: rsync --version. Kung wala pa, install gamit apt install rsync. Sa AlmaLinux, Rocky Linux, CentOS: dnf install rsync o yum install rsync. Sa Hostragons Linux VPS, mabilis lang ang install nito.

3. Suriin ang Disk Space

Kung kulang ang disk space sa destination, mapuputol ang transfer. Para malaman ang folder size: du -sh /source/folder. Sa destination, df -h para i-check ang disk status. Maglaan ng extra space para sa temporary files at logs. Kung 500 GB ang itatransfer, magplano ng 550–600 GB free space sa destination.

4. Planuhin ang Critical Services at Changing Files

Sa live website, puwedeng magbago ang files habang nagta-transfer. Lalo na sa user uploads, cache, at logs. Sa malalaking transfer, unahin ang main data, tapos mag-maintenance mode at mag-final rsync. Mas mababa ang downtime. Para sa WordPress, basahin ang Gabayan sa paglilipat ng WordPress hosting para mas planado ang process.

Pangunahing rsync Command: Paglipat ng Files sa Dalawang Server

Pinakamadalas gamitin: rsync -avz /source/folder/ user@destination-ip:/destination/folder/. Ang -a ay archive mode (pinapanatili ang permissions, timestamps, symbolic links), -v para verbose output, -z para compression. Mahalaga ang slash sa dulo ng folder—/source/folder/ ay laman ng folder lang, /source/folder ay buong folder itself.

Halimbawa: Gusto mong ilipat ang 180 GB web files mula /var/www/site/public_html/ sa old server papunta sa /var/www/site/public_html/ sa bagong server. Ang command: rsync -avz /var/www/site/public_html/ root@203.0.113.20:/var/www/site/public_html/. Galing ang files sa source server, diretso sa destination sa SSH.

Kung ayaw mong gumamit ng root, mag-create ng user na may write access sa destination folder. Halimbawa, deploy user at i-set ang folder ownership. Mas secure ang limited user kaysa direct root access.

Recommended rsync Parameters para sa Secure & Resilient Transfer

Sa malalaking file transfer, hindi sapat ang basic command. Para sa connection drops, partial files, mistaken deletes, o slow network, kailangan ng extra parameters. Sample command para sa matibay na transfer:

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

Ang -a archive mode, -H hard link info, -A ACL permissions, -X extended attributes. --numeric-ids para sa user/group IDs (kapag iba user names sa servers). --partial hindi dine-delete ang incomplete files. --progress makikita ang transfer status. --append-verify para mag-verify kapag nag-resume ng transfer.

Hindi laging kailangan ang lahat ng parameters. Sa simple site transfer, -aHAX lang ay sapat. Pero kung may special file permissions, mahalaga ang ACL at extended attributes. Kaya dapat mag-test transfer muna.

Paano Kung Iba ang SSH Port?

Kung hindi 22 ang SSH port, dapat isama sa rsync command. Halimbawa: rsync -avz -e ssh -p 2222 /source/folder/ user@destination-ip:/destination/folder/. Pero dapat ganito ang syntax: rsync -avz -e 'ssh -p 2222' /source/folder/ user@destination-ip:/destination/folder/.

Siguraduhin ang tamang quotation marks lalo na sa terminal. Kung SSH key ang gamit, idagdag ang -i: rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /source/folder/ user@destination-ip:/destination/folder/. Madalas gamitin ito sa automated o cron-based backup.

Testing ang Transfer: --dry-run Usage

Isa sa pinaka-pro tip bago mag-transfer ng malaking data ay ang --dry-run. Hindi ito nagko-copy, pero pinapakita kung anong files ang ililipat. Dito mo makikita kung tama ang path, destination o kung may file na made-delete.

Sample test: rsync -avz --dry-run /var/www/site/ user@destination-ip:/var/www/site/. Makikita mo sa output ang files, folders, at summary ng operation. Kung gagamit ng --delete, mas kritikal ang dry-run dahil puwedeng madelete ang files sa destination na wala sa source.

Ang tamang sequence: SSH test, disk check, rsync --dry-run, maliit na test folder, saka mag-large transfer. Mas maganda maglaan ng ilang minuto sa testing kesa magsayang ng oras sa failed transfer.

Performance Tips: Compression, Bandwidth, Encryption Settings

Hindi lang file size ang basehan ng rsync performance. Kasama ang CPU power, disk type, network latency, bandwidth, at file count. Mas mabagal ang maraming maliit na files kaysa isang malaking file dahil sa metadata processing. Sa NVMe VPS, mas mabilis ang file scan at write. Kung laging magta-transfer ng malalaking files, tingnan ang NVMe VPS server options.

Ang -z compression ay malaki ang tulong sa text files, logs, o backup. Pero sa files na compressed na tulad ng zip, tar.gz, jpg, mp4, o gzip, magpapalakas lang ng CPU pero walang dagdag speed. Kung 1 Gbps ang servers at malalaking media files, subukan ang transfer na walang -z. Sa mababang bandwidth at text-heavy files, malaki ang savings ng -z.

Puwedeng limitahan ang bandwidth gamit --bwlimit. Halimbawa, --bwlimit=50000 ay 50 MB/s. Sa live website, huwag mag-full speed transfer para hindi masikip ang network. Gawin ang transfer sa off-peak oras, mag-set ng bwlimit, at tingnan ang load average habang nagta-transfer.

Paghahambing ng rsync, scp, SFTP, at FTP

Maraming paraan para mag-transfer ng files, pero may kanya-kanyang advantages at limitations. Narito ang table para sa malalaking file at server migration scenarios:

Makikita sa table na rsync ang top choice sa paulit-ulit na sync at malalaking transfer. Ang scp ay simple pero hindi kasing smart ng rsync sa pagdetect ng changes. Ang FTP ay hindi encrypted kaya hindi bagay sa modern security standards. Sa hosting panels, madali ang FTP, pero kung critical ang file migration, SSH-based tools ang gamitin.

Sample Workflow para sa Live Website Migration

Sa paglipat ng website, hindi lang files ang dapat isipin—kasama ang DNS, database, SSL, PHP version, permissions, at email setup. Narito ang step-by-step na low-downtime workflow para sa malalaking site:

• I-set up ang web server, PHP, database at modules sa bagong server.
• I-adjust ang DNS TTL sa 300 seconds para mabilis ang switch. Para sa domain management, tingnan ang Pagsusuri ng domain at pamamahala ng domain.
• I-run ang unang rsync habang live pa ang site—dito naililipat ang bulk ng data.
• I-backup ang database, tapos i-transfer sa bagong server.
• Ilagay ang site sa maintenance mode.
• I-run ang pangalawang rsync para sa recent changes.
• I-update ang database o mag-incremental backup.
• I-check ang file permissions, site launch, at logs sa bagong server.
• I-install o i-update ang SSL certificate. May guide sa pag-install ng sertipiko ng SSL.
• I-update ang DNS records papunta sa bagong IP.

Sa ganitong paraan, ang pinakamahabang transfer ay nangyayari habang live pa ang site. Ang downtime ay sa last sync at DNS switch lang—sa malalaking WordPress sites, ang downtime ng ilang oras ay puwedeng maging ilang minuto.

Paano I-check ang Data Integrity

Hindi sapat na natapos ang command—dapat i-verify ang file count, sizes, at critical files. Sa simple check, du -sh sa source at destination para i-compare ang folder sizes. Pero hindi laging pareho dahil sa filesystem blocks. Para sa mas accurate, ulitin ang rsync gamit same parameters; kung walang bagong files na ililipat, minimal ang output.

Sa checksum validation, gamitin: rsync -avc --dry-run /source/folder/ user@destination-ip:/destination/folder/. Ang -c ay nag-compare ng checksum bukod sa timestamps at size. Sa napakalaking data, magpapalakas ito ng CPU at disk kaya maging maingat. Sa critical archives, database dumps, o sensitive files, maganda itong extra step.

Kung website migration, mag-test din sa application level: homepage, admin panel, image upload, payment page, contact form, error logs. Sa e-commerce, hindi lang files ang dapat ilipat—dapat testin ang payment integrations at cron jobs.

Karaniwang Errors at Solusyon

Permission denied Error

Karaniwan ito kapag kulang ang SSH user privileges, wala write access sa destination folder, o mali ang key authentication. Subukang mag-SSH gamit ang same user. Kung mag-success, mag-test mag-create ng file sa destination folder. Ayusin ang folder ownership gamit chown, o mag-set ng sudo strategy.

No space left on device Error

Kapag puno ang disk sa destination, tigil ang transfer. I-check ang df -h. Minsan, puno ang /tmp o mount point kahit hindi ang main disk. Linisin ang logs, old backups, at cache folders. Kung hindi sapat, mag-upgrade ng disk o pumili ng mas mataas na VPS plan.

Connection reset o Broken pipe Error

Sa matagal na transfer, puwedeng maputol ang connection. Kung gamit ang --partial at --append-verify, puwedeng mag-resume. Maaaring makatulong ang SSH keepalive settings—ServerAliveInterval 60 para hindi madaling maputol ang idle connection.

Napakabagal na Transfer

Maaaring dahil sa dami ng files, disk I/O limits, compression load, o network. Kung maraming maliit na files, pwede ring i-tar muna para mas mabilis. Sa compressed files, subukang walang -z. Gamitin ang iotop, htop, at iftop para malaman kung CPU, disk, o network ang bottleneck.

Security Best Practices sa Server-to-Server File Transfer

Huwag pabayaan ang security sa file transfer. Lalo na sa root access, SSH keys, at backup files. Mas mainam ang SSH key authentication kaysa password. Siguraduhin ang tamang permissions sa key files, huwag i-share ang private keys, at gumamit ng passphrase kung posible.

Mag-create ng temporary user na may access lang sa kailangan folders. Pagkatapos ng transfer, alisin ang permissions o disable ang user. Limitahan ang SSH access sa specific IP addresses para mas maliit ang attack surface. Dapat may firewall, Fail2ban, at updated OpenSSH.

Kung nagta-transfer ng database dumps, customer docs, o personal data, linisin ang temporary files sa source at destination. Huwag iwan ang .sql, .zip, o .tar backups sa web root—malaking security risk ito. Dapat sa private folder o i-delete agad pagkatapos ng transfer.

Paano Gamitin ang rsync para sa Automated Backup

Hindi lang one-time transfer ang gamit ng rsync—puwede itong regular backup. Halimbawa, mag-set ng cron job para mag-backup ng folder gabi-gabi. Gamit ang SSH key, walang password pero secure ang connection, at rsync lang ang nagbabago ang files. Pwedeng mag-set ng bandwidth limit.

Sample: rsync -a --delete --bwlimit=30000 /var/www/site/ backup@backup-ip:/backup/site/. Nag-equalize ito ng destination sa source. Pero ingat sa --delete—kapag nabura ang file sa source, mabubura rin sa backup. Sa critical data, mas mainam ang snapshot, daily folders, o versioned backups.

Sa hosting, sundin ang 3-2-1 backup rule: 3 copies ng data, 2 magkaibang storage, 1 copy sa ibang location. rsync ang practical tool para sa server-to-server backup. Para sa mas advanced solutions, basahin ang Mga Solusyon sa Backup at mga serbisyong korporatibong hosting.

Final Checklist bago Mag-Transfer ng Malalaking Files

Bago magsimula ng malaking file transfer, sundin ang checklist na ito para sa mas kaunting error. Gawin itong standard procedure lalo na sa production:

• Installed ba ang rsync sa source at destination?
• Nag-test ba ng SSH connection gamit tamang user at port?
• Sapat ba ang disk space sa destination?
• Nag-run ba ng --dry-run sa unang test?
• Naka-plan ba ang maintenance mode at final sync para sa live site?
• Kung gagamit ng --delete, confirmed ba ang tamang destination path?
• May plan ba para i-verify file sizes, permissions, application tests pagkatapos ng transfer?
• Sigurado bang malilinis ang temporary backup at dump files?

Simple lang ang mga ito pero sa totoong buhay, ang madalas na problema ay maling destination folder, kulang sa permission, walang disk space, o walang plano sa DNS switch. Ang well-planned rsync process ay mas mabilis, mas safe, at mas maganda ang fallback.

Mga Madalas Itanong

Paano kung maputol ang connection habang nagta-transfer gamit ang rsync sa SSH?

Hindi magsisimula uli kung tama ang parameters—gamitin ang --partial at --append-verify para puwedeng mag-resume ang transfer. Pero bago mag-resume, i-check ang disk space at partial files sa destination.

Puwede bang i-transfer ang database gamit ang rsync?

rsync ay pang-file transfer lang. Hindi recommended ang pag-copy ng running database files. Para sa MySQL o MariaDB, gamitin ang mysqldump o physical backup tools, tapos i-transfer ang backup file gamit rsync. Sa live system, mag-maintenance mode o gumamit ng replication.

Kailangan bang root access sa parehong server para mag-rsync?

Hindi required ang root—basta may write access sa destination folder ang user. Pero kung kailangan ang file ownership, system folders, ACL, o special permissions, maaaring kailangan ang higher privileges. Mas secure ang limited user kung puwede.

Safe ba ang --delete parameter?

Safe ito basta tama ang paggamit. --delete ay mag-sync ng destination sa source, pero kapag mali ang path, puwedeng madelete ang important files. Laging mag-test muna gamit --dry-run at double-check ang paths.

Mas okay ba ang rsync kaysa scp para sa malalaking file?

Para sa one-time, maliit na transfer, okay ang scp. Pero sa malalaking files, maraming files, at repeated sync, mas maganda ang rsync. Puwede itong i-resume, mag-limit ng bandwidth, mag-test, at mag-detect ng changes.

Summary at Susunod na Hakbang

Ang rsync command sa SSH ay napakabilis, secure, at madaling i-manage na paraan sa paglipat ng malalaking files sa pagitan ng dalawang server. Sa tamang parameters, kaya nitong mag-resume after connection drop, mag-transfer lang ng nagbago, at magpababa ng downtime sa live site migration. Mag-test muna ng SSH at disk space, run --dry-run, saka magplano ng actual transfer.

Kung naghahanap ka ng bagong server, mas malawak na storage, o upgraded hosting, tingnan ang Hostragons options—VPS, hosting, domain, at SSL para safe ang migration. Simulan sa maliit na test, sukatin ang performance, at planuhin ang final sync para walang aberya.