Cara Pindah Fail Gergasi antara Dua Server dengan rsync melalui SSH (Panduan Hosting)

Rsync melalui SSH adalah salah satu kaedah Linux paling efisien untuk memindahkan fail-fail bersaiz besar antara dua server, dengan pantas, selamat dan tahan gangguan sambungan. Terutama sekali apabila anda ingin memindahkan fail website beratus GB, folder media, backup arkib atau data aplikasi, rsync jauh lebih laju berbanding teknik salin biasa kerana ia hanya memindahkan blok yang berubah. Konsep asasnya: fail dari server sumber diselaraskan ke server destinasi melalui terowong SSH yang disulitkan; jika sambungan terputus, proses boleh disambung dari tempat berhenti.

Dalam operasi migrasi server, upgrade hosting, tukar pusat data atau backup, kelajuan dan integriti data sama penting. Memuat turun arkib besar sekali gus untuk dimuat naik semula bukan saja membazir masa, malah jika sambungan terganggu, anda perlu mula dari awal. Di sinilah rsync membantu: ia boleh kekalkan cap masa fail, izin, pemilik dan struktur direktori. Oleh itu, rsync sentiasa jadi pilihan utama pentadbir sistem Linux, DevOps dan pakar web hosting dalam rutin harian mereka.

Panduan ini akan membimbing anda langkah demi langkah cara pindah fail besar antara dua server Linux dengan rsync melalui SSH, lengkap dengan contoh arahan sebenar. Kami akan bincangkan juga parameter untuk tingkatkan prestasi, kawalan keselamatan, senario error, cara ujian transfer dan perkara perlu diberi perhatian sebelum produksi. Jika anda sedang merancang migrasi ke VPS atau hosting baru, pastikan server sumber dan destinasi cukup ruang cakera, akses SSH serta izin pengguna yang betul sebelum mula. Untuk pilihan infrastruktur, anda boleh rujuk Hostragons penyelesaian pelayan VPS dan Pakej Hosting Linux.

Apakah rsync dan Kenapa Ia Pilihan Terbaik untuk Pindah Data Besar?

rsync ialah alat baris arahan yang sangat power untuk selaraskan fail dan direktori antara sistem tempatan atau remote server. Keistimewaan utamanya adalah algoritma delta transfer: hanya bahagian fail yang berubah akan dipindahkan, bukan keseluruhan fail setiap kali. Contohnya, jika backup bersaiz 80GB tapi cuma 2GB berubah, rsync hanya transfer blok yang berubah jika syarat sesuai.

SSH menjadikan pemindahan ini selamat kerana data dihantar dalam bentuk terenkripsi, bukan plain text. Ini kritikal untuk data pelanggan, rekod order e-commerce, arkib media, backup database dan fail aplikasi sensitif. Dalam hosting, keselamatan data tak terhad kepada SSL sahaja; channel antara server mesti dienkripsi juga. Untuk trafik website, gunakan Sijil SSL, manakala transfer antara server pula, pilih SSH encryption.

rsync lebih fleksibel daripada FTP atau kaedah manual download-upload. Ia boleh kekalkan izin, pindahkan symbolic link, padam fail di destinasi jika sudah dipadam di sumber, hadkan bandwidth dan uji dahulu sebelum transfer. Untuk operasi risiko tinggi seperti pindahan fail besar, level kawalan ini sangat berguna.

Bila Patut Guna rsync melalui SSH?

rsync melalui SSH sangat ideal untuk pindahan fail besar, banyak, atau yang kerap berubah. Untuk folder gambar kecil, SFTP manual mungkin cukup; tapi jika melibatkan beribu fail dengan izin berbeza dan arkib besar, rsync jauh lebih boleh diharap.

• Pindah website dari server lama ke VPS baru.
• Pindah direktori media seperti WordPress uploads yang mengandungi ribuan fail.
• Backup harian, mingguan atau bulanan ke server lain.
• Tukar pusat data atau provider hosting.
• Selaraskan fail aplikasi antara environment produksi dan backup.
• Transfer panjang dengan risiko sambungan terputus.

Contohnya, memuat turun folder media 250GB ke komputer anda sebelum upload ke server baru akan memakan dua kali masa dan jadikan internet rumah/pejabat bottleneck. Dengan rsync, anda boleh transfer terus dari sumber ke destinasi tanpa langkah tengah.

Keperluan Sebelum Memulakan

Memahami arahan rsync sahaja tidak cukup untuk operasi berjaya. Pastikan keadaan server sumber dan destinasi, supaya risiko data hilang atau transfer separuh jalan dapat dikurangkan. Periksa perkara berikut sebelum produksi:

1. Semak Akses SSH

Server sumber mesti boleh sambung ke server destinasi dengan SSH. Uji dengan: ssh pengguna@ip-server-destinasi. Jika SSH guna port lain, cuba: ssh -p 2222 pengguna@ip-server-destinasi. Jika gagal, rsync juga tidak akan berjaya. Semak firewall, Fail2ban, port SSH, izin pengguna serta password/SSH key.

2. Pastikan rsync Sudah Dipasang

Kebanyakan Linux sudah ada rsync; untuk pasti, gunakan rsync --version. Jika belum, install dengan apt install rsync (Debian/Ubuntu), atau dnf/yum install rsync (CentOS, AlmaLinux, Rocky Linux). VPS Linux Hostragons biasanya boleh install dalam beberapa saat.

3. Sediakan Ruang Cakera Secukupnya

Jika ruang cakera destinasi tidak cukup, transfer akan terhenti. Untuk ukur saiz folder sumber, gunakan du -sh /direktori/sumber. Di destinasi, semak ruang dengan df -h. Selain saiz fail, sediakan sedikit ruang ekstra untuk fail sementara dan log. Untuk 500GB data, sebaiknya sediakan 550-600GB ruang.

4. Rancang Servis Kritikal dan Fail Berubah

Website aktif mungkin ada fail yang berubah semasa transfer, contohnya upload pengguna, cache dan log. Kaedah terbaik: transfer utama dahulu, kemudian aktifkan maintenance mode dan lakukan rsync terakhir. Ini boleh kurangkan downtime kepada beberapa minit. Untuk WordPress, rujuk Panduan pemindahan hosting WordPress.

Arahan Asas rsync: Transfer Fail antara Dua Server

Struktur asas yang kerap digunakan: rsync -avz /direktori/sumber/ pengguna@ip-destinasi:/direktori/destinasi/. -a untuk archive mode (kekalkan izin, cap masa, symbolic link), -v untuk verbose output, -z untuk compression semasa transfer. Slash di akhir direktori penting: /direktori/sumber/ bermaksud hanya kandungan, tanpa slash bermaksud direktori itu sendiri akan dicipta di destinasi.

Contoh: Anda mahu pindahkan /var/www/site/public_html/ dari server lama ke lokasi sama di server baru. Arahan: rsync -avz /var/www/site/public_html/ root@203.0.113.20:/var/www/site/public_html/. Ini akan transfer fail melalui SSH.

Jika tidak mahu guna root, cipta pengguna khusus dengan izin menulis ke direktori destinasi. Contohnya, guna deploy dan tukar pemilikan folder. Untuk produksi, pengguna dengan izin terhad lebih selamat berbanding root.

Parameter rsync Selamat & Tahan Gangguan (Disyorkan)

Arahan asas saja tidak cukup untuk transfer fail besar. Untuk sambungan terputus, fail separuh, padam tak sengaja atau network perlahan, tambahkan parameter tertentu. Berikut contoh arahan yang mantap untuk kebanyakan senario:

rsync -aHAXv --numeric-ids --partial --progress --append-verify -e ssh /direktori/sumber/ pengguna@ip-destinasi:/direktori/destinasi/

-a archive, -H kekalkan hard link, -A ACL, -X extended attributes. --numeric-ids guna ID pengguna/kumpulan, bukan nama; berguna jika nama berbeza antara server. --partial simpan fail separuh, --progress paparkan status transfer, --append-verify sambung dari tempat berhenti dan sahkan bahagian baru.

Tidak semua parameter perlu untuk semua sistem. Contohnya, untuk website biasa, -aHAX mungkin cukup. Untuk aplikasi guna izin khas, ACL dan extended attribute penting. Sentiasa lakukan ujian transfer dulu.

Cara rsync dengan SSH Port Tidak Standard

SSH mungkin dijalankan pada port selain 22. Dalam rsync, nyatakan parameter SSH. Contoh: rsync -avz -e ssh -p 2222 /direktori/sumber/ pengguna@ip-destinasi:/direktori/destinasi/. Pastikan -e digunakan dengan betul: rsync -avz -e 'ssh -p 2222' /direktori/sumber/ pengguna@ip-destinasi:/direktori/destinasi/.

Jika guna SSH key, tambahkan -i: rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /direktori/sumber/ pengguna@ip-destinasi:/direktori/destinasi/. Kaedah ini sangat sesuai untuk backup automatik atau cron job.

Ujian Transfer: Guna --dry-run

Langkah profesional sebelum pindah data besar ialah guna --dry-run. Parameter ini tidak memindahkan fail, cuma paparkan fail mana akan dipindah. Anda boleh semak direktori, destinasi dan risiko padam fail sebelum transfer sebenar.

Contoh: rsync -avz --dry-run /var/www/site/ pengguna@ip-destinasi:/var/www/site/. Output akan tunjuk fail, direktori dan ringkasan. Jika guna --delete, --dry-run sangat kritikal kerana --delete akan padam fail di destinasi yang tiada di sumber. Gunakan dengan hati-hati.

Urutan profesional: ujian SSH, semak ruang cakera, rsync --dry-run, ujian transfer folder kecil, kemudian transfer utama. Luangkan beberapa minit untuk ujian, elak kesilapan yang boleh makan berjam-jam.

Tingkatkan Prestasi: Compression, Bandwidth dan Enkripsi

Prestasi rsync tidak hanya bergantung pada saiz fail. CPU server, jenis cakera, latency network, bandwidth dan bilangan fail juga mempengaruhi. Banyak fail kecil selalunya lebih lambat dari satu fail besar kerana metadata. VPS dengan NVMe disk jauh lebih laju. Jika anda perlukan transfer intensif, pertimbangkan pelayan VPS NVMe.

-z (compression) berguna untuk fail teks, log dan backup tertentu. Tapi untuk fail yang sudah compressed (zip, tar.gz, jpg, mp4, gzip), ia cuma guna CPU tanpa banyak manfaat. Untuk dua server berkuasa dengan sambungan 1Gbps, transfer media besar tanpa -z mungkin lebih laju. Sebaliknya, pada bandwidth rendah dan fail teks, -z sangat membantu.

Untuk limit bandwidth, guna --bwlimit. Contoh: --bwlimit=50000 (50MB/s). Ini penting supaya transfer tidak menjejaskan trafik web. Jadualkan transfer waktu malam, guna limit dan pantau load average semasa proses.

Perbandingan rsync, scp, SFTP dan FTP

Terdapat banyak teknik transfer fail, setiap satu ada kelebihan dan kekurangan. Jadual berikut ringkaskan bila sesuai guna setiap kaedah untuk transfer fail besar antara server:

Jelas rsync paling unggul untuk sync berulang dan transfer data besar. scp mudah tapi kurang pintar dalam kes fail berubah. FTP tanpa enkripsi tidak sesuai untuk standard keselamatan moden. FTP mudah digunakan melalui panel, tapi untuk transfer kritikal antara server, pilih kaedah berasaskan SSH.

Contoh Workflow Migrasi Website Aktif

Memindahkan web bukan setakat salin fail. DNS, database, SSL, versi PHP, izin fail dan setup email perlu diperiksa. Berikut workflow migrasi website berdosa besar dengan downtime minimum:

• Siapkan server baru: web server, PHP, database dan modul perlu.
• Setkan DNS TTL ke nilai rendah seperti 300 saat sebelum migrasi. Untuk pengurusan domain, rujuk Semakan domain dan pengurusan domain.
• Lakukan rsync pertama semasa website masih aktif — ini pindahkan sebahagian besar data.
• Backup database dan transfer ke server baru.
• Aktifkan maintenance mode.
• Lakukan rsync kedua untuk sync fail terbaru.
• Backup database terkini atau guna incremental.
• Periksa izin fail, buka website dan semak log di server baru.
• Pasang atau renew SSL, rujuk Pemasangan sijil SSL.
• Kemaskini DNS ke IP baru.

Dengan cara ini, transfer utama berlaku semasa website live. Downtime hanya terjadi semasa sync terakhir dan pertukaran DNS. Untuk WordPress dengan media besar, downtime boleh dikurangkan dari berjam kepada beberapa minit.

Semak Integriti Data Selepas Transfer

Selesai transfer, jangan cuma bergantung pada output arahan. Semak bilangan fail dan saiz folder dengan du -sh di kedua server. Nilai mungkin berbeza sedikit kerana blok fail, jadi untuk detail, jalankan rsync dengan parameter sama sekali lagi; jika tiada fail dipindah, output sangat minima.

Untuk semakan checksum, guna rsync -avc --dry-run /direktori/sumber/ pengguna@ip-destinasi:/direktori/destinasi/. -c akan semak checksum selain cap masa dan saiz. Hati-hati gunakan pada data besar kerana ia guna CPU dan disk. Untuk fail penting seperti backup database atau dokumen pelanggan, semakan ini memberi ketenangan.

Jika pindah website, semak aplikasi: homepage, admin panel, upload gambar, pembayaran, contact form dan log error. Untuk e-commerce, jangan lupa test integrasi pembayaran dan cron job di server baru.

Masalah Biasa dan Cara Atasi

Permission denied Error

Biasanya disebabkan izin pengguna SSH, direktori destinasi atau pengesahan key. Cuba akses SSH dengan pengguna sama. Jika berjaya, cuba buat fail di direktori destinasi. Jika gagal, tukar pemilikan folder dengan chown atau rancang guna sudo.

No space left on device Error

Ruang cakera destinasi habis. Semak dengan df -h. Kadang-kadang /tmp atau mount point penuh walaupun disk utama masih ada ruang. Padam log lama, backup usang dan cache. Untuk kekal, naik taraf ke VPS dengan kapasiti lebih tinggi.

Connection reset atau Broken pipe Error

Pindahan panjang boleh terputus akibat network. Jika guna --partial dan --append-verify, ulang arahan untuk sambung transfer. Set ServerAliveInterval 60 pada SSH client untuk kurangkan sambungan idle terputus.

Transfer Sangat Perlahan

Boleh disebabkan jumlah fail, limit I/O disk, compression, atau bandwidth. Untuk fail kecil banyak, buat tar archive dulu (tapi rsync tak dapat sync fail individu). Untuk fail besar sudah compressed, cuba tanpa -z. Guna iotop, htop, iftop untuk kenal pasti bottleneck.

Amalan Terbaik Keselamatan

Jangan abaikan keselamatan semasa transfer. Jangan guna root tanpa sebab, pastikan SSH key digunakan, izin file key ketat dan ada passphrase. Jangan kongsi private key.

Buat pengguna sementara dengan izin ke folder perlu saja; deactivate selepas transfer. Hadkan akses SSH kepada IP tertentu. Firewall, Fail2ban dan OpenSSH versi terbaru wajib disemak.

Untuk data sensitif seperti dump database, dokumen pelanggan, selepas transfer padam fail sementara di kedua server. Jangan simpan fail backup seperti .sql, .zip, .tar di folder web yang boleh diakses awam. Simpan di folder tidak boleh diakses web atau padam selepas selesai.

rsync untuk Backup Automatik

rsync bukan sahaja untuk transfer sekali, tapi juga backup berkala. Contohnya, setup cron job untuk backup folder ke server backup setiap malam. Guna SSH key tanpa password untuk sambungan selamat, rsync hanya transfer fail berubah dan boleh limit bandwidth.

Contoh: rsync -a --delete --bwlimit=30000 /var/www/site/ backup@ip-backup:/backup/site/. --delete akan padam fail di destinasi yang sudah dipadam di sumber, jadi guna dengan caution. Untuk backup kritikal, guna snapshot, folder harian atau sistem versioning.

Dalam hosting, amalkan prinsip backup 3-2-1: sekurang-kurangnya 3 salinan, 2 media berbeza, 1 salinan di lokasi lain. rsync mudahkan bahagian salinan antara server. Untuk backup yang lebih kompleks, rujuk Penyelesaian Sandaran dan perkhidmatan hosting korporat.

Checklist Akhir Sebelum Transfer Fail Besar

Sebelum mula, ikut checklist berikut untuk kurangkan risiko error. Jadikan checklist ini SOP untuk produksi:

• rsync sudah dipasang di kedua server?
• SSH sambungan diuji dengan pengguna dan port yang betul?
• Ruang cakera destinasi cukup?
• Ujian transfer dengan --dry-run sudah dilakukan?
• Rancang maintenance mode & sync terakhir untuk website aktif?
• Jika guna --delete, sahkan destinasi betul?
• Selepas transfer, semak saiz fail, izin dan aplikasi?
• Padam backup sementara dan dump file dengan selamat?

Masalah nyata biasanya berpunca dari direktori salah, izin kurang, ruang cakera tidak cukup dan pertukaran DNS tanpa perancangan. Proses rsync yang terancang boleh pendekkan masa transfer dan mudahkan rollback jika perlu.

Soalan Lazim

Jika sambungan terputus semasa rsync melalui SSH, adakah transfer bermula semula?

Tidak, jika guna parameter betul seperti --partial dan --append-verify, fail besar separuh akan disimpan dan transfer boleh disambung. Sebelum sambung semula, semak ruang cakera dan status fail separuh di destinasi.

Boleh rsync transfer database terus?

rsync hanya transfer fail. Jangan transfer fail database aktif secara langsung. Untuk MySQL/MariaDB, guna mysqldump atau alat backup fizikal, kemudian transfer fail backup dengan rsync. Untuk integriti, aktifkan maintenance mode atau replikasi.

Perlu akses root di kedua server untuk guna rsync?

Tidak wajib. Pengguna dengan izin menulis ke folder destinasi sudah cukup. Untuk kekalkan pemilikan, izin khas atau ACL, mungkin perlu akses lebih tinggi. Untuk keselamatan, guna pengguna terhad jika boleh.

Adakah --delete selamat digunakan?

Jika digunakan dengan betul, --delete sangat berguna untuk sync destinasi sama seperti sumber. Tapi jika direktori salah, fail boleh terpadam. Sentiasa uji dengan --dry-run dan sahkan path sebelum transfer sebenar.

Untuk transfer fail besar, rsync atau scp lebih baik?

scp sesuai untuk transfer sekali fail kecil. Tapi untuk fail besar, banyak fail atau sync berulang, rsync lebih baik: ia boleh sambung dari tempat terputus, hadkan bandwidth, uji dahulu dan hanya transfer fail berubah.

Kesimpulan & Langkah Seterusnya

Rsync melalui SSH membolehkan anda pindah fail gergasi antara server dengan pantas, selamat dan boleh diurus. Dengan parameter yang betul, ia tahan sambungan terputus, hanya transfer fail berubah dan kurangkan downtime semasa migrasi website. Dapatkan hasil terbaik dengan ujian SSH, semak ruang cakera, lakukan --dry-run dan rancang transfer utama.

Jika anda ingin migrasi ke server baru, kapasiti storage tinggi atau infrastruktur hosting lebih laju, tinjau solusi Hostragons; VPS, hosting, domain dan SSL tersedia untuk jadikan transfer lebih selamat. Mulakan dengan ujian kecil, perhatikan output, dan rancang sync terakhir secara sistematik.