Rsync vs SCP: Perintah Salin Linux Mana yang Dipakai

Gunakan rsync untuk apa pun yang lebih besar dari salinan sekali jalan, dan scp saat Anda hanya ingin sebuah berkas pindah ke mesin lain sekarang juga. Beda intinya: scp mengalirkan seluruh berkas lagi setiap saat dan tak ingat koneksi yang putus, sedangkan rsync membandingkan sumber dan tujuan, mengirim hanya blok yang berubah, dan melanjutkan salinan yang terputus dari titik berhentinya. Untuk backup besar lewat koneksi rewel, itu bedanya dua menit dengan mulai dari nol. Keduanya ikut OpenSSH di hampir semua distro Linux, jadi ini pilihan kebiasaan, bukan pilihan instalasi — dan kebiasaan itu semestinya bawaan ke rsync. Di bawah: tabel perbandingan lugas, selisih kecepatan nyata, trik lanjut yang tak dimiliki scp, dan kasus saat scp tetap jawaban yang tepat.

Apa bedanya rsync dan scp?

scp melakukan satu hal: membuka kanal SSH, mengalirkan byte, menutup. Ia tak punya ingatan antar eksekusi, jadi jika transfer mati di 90%, Anda mulai dari nol.

rsync adalah alat sinkronisasi yang kebetulan memakai SSH sebagai transportnya. Sebelum mengirim, ia membangun daftar checksum berkas tujuan (algoritma delta rolling-checksum) dan hanya mengirim blok yang berbeda. Jalankan perintah yang sama dua kali dan putaran kedua hampir tak memindahkan apa-apa. Itu juga menjadikan rsync alat yang wajar untuk menjaga dua direktori tetap sinkron — jadwalkan, dan tiap eksekusi hanya menyalin delta.

Konsekuensi praktisnya:

• Interupsi: rsync melanjutkan; scp mengulang berkas dari awal.
• Salinan kedua: rsync hanya mengirim perubahan; scp mengirim ulang semuanya.
• Penghapusan: rsync bisa mencerminkan penghapusan dengan --delete; scp tidak bisa.
• Penyaringan: rsync punya pola --exclude; scp menyalin semua yang Anda tunjuk.
• Dry run: rsync menunjukkan yang akan dilakukan dengan --dry-run; scp tak menawarkan apa pun.

Apakah rsync lebih cepat dari scp?

Untuk salinan pertama satu berkas besar lewat koneksi cepat, keduanya berdekatan — sama-sama menyaturasi SSH, dan proses checksum hanya menambah overhead kecil. Jaraknya terbuka di tiga tempat:

1. Berkas kecil dalam jumlah banyak. rsync memipeline penelusuran direktori dan bisa memakai ulang satu koneksi; setup scp lama memunculkan pekerjaan per berkas. Ribuan berkas kecil (sebuah node_modules, instalasi WordPress) selesai jauh lebih cepat dengan rsync.
2. Eksekusi ulang. Salin berkas 4 GB yang berubah 50 MB dan rsync memindahkan sekitar 50 MB; scp memindahkan 4 GB lagi.
3. Kompresi. -z mengompres di perjalanan, membantu di tautan WAN lambat.

Anda bisa mengukurnya sendiri — bentuk perintahnya identik:

# berkas sama, server sama, keduanya lewat SSH
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

# jalankan ulang keduanya: scp menyalin ulang, rsync memverifikasi dan mengirim ~nihil
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

Jika hari Anda habis di server, kecepatan transfer termasuk hal yang layak diukur sekali — sama seperti ss mengalahkan netstat di host sibuk (lihat ss vs netstat: perintah port Linux mana yang dipakai).

Bisakah scp melanjutkan transfer yang terputus?

Tidak. scp tak punya resume; jika koneksi putus di 900 MB dari 1 GB, Anda mulai lagi. Inilah alasan yang paling sering dikutip dalam setiap debat rsync-vs-scp, dan alasan itu nyata.

Desain rsync memang mengasumsikan transfer kadang terputus. Mantra lanjut yang kanonik:

rsync -avh --partial --append-verify --progress bigfile.tar.gz user@server:/srv/backup/

• --partial menyimpan berkas setengah jadi alih-alih menghapusnya.
• --append-verify melanjutkan dengan menambahkan, lalu memverifikasi checksum wilayah yang ditambahkan — aman dari berkas parsial yang korup, tak seperti --append polos yang lama.
• --progress menunjukkan dari mana ia melanjutkan.

Dibalut loop coba lagi, ini menjadi backup pasang-lalu-lupakan bahkan di koneksi yang buruk:

until rsync -avh --partial --append-verify --progress 
    ./bigfile.tar.gz user@server:/srv/backup/; do
  sleep 5
done

Kapan sebaiknya Anda memakai scp alih-alih rsync?

scp tetap alat yang tepat dalam segelintir kasus:

• Satu berkas kecil, sekali. Mengetik scp app.conf user@host:/etc/myapp/ lebih pendek daripada invokasi rsync apa pun, dan tak ada yang perlu dilanjutkan.
• rsync tak ada di ujung sana. rsync butuh binernya di kedua sisi. Banyak container dan appliance minimal menyertakan server SFTP milik scp tapi bukan rsync.
• Anda tak ingin server rsync terekspos. Jarang, tapi ada lingkungan yang mengunci daemon rsync secara spesifik.

Satu subtleti yang layak diketahui: proyek OpenSSH telah memensiunkan protokol asli scp bertahun-tahun lalu, dan scp modern sebenarnya berbicara SFTP di bawahnya. Itu memperbaiki keanehan path-escaping, tapi tak mengubah dua keterbatasan yang penting di sini — tak ada resume, tak ada transfer delta. Perubahan protokol tak membuat scp menjadi rsync.

Terkait juga: jika pertanyaan Anda sebenarnya “rsync vs cp”, jawabannya mencerminkan yang ini — cp adalah padanan lokal scp (tanpa resume, tanpa delta, tanpa atribut kecuali Anda menambah flag), dan rsync bekerja untuk lokal maupun remote. Untuk sekali jalan lokal, cp sudah cukup.

Flag rsync mana yang paling penting?

Kebanyakan orang hanya perlu satu baris:

rsync -avh --partial --progress src/ user@server:/srv/dest/

Flag	Yang dilakukannya
-a (archive)	Rekursif + mempertahankan permission, waktu, grup, symlink, device
-v (verbose)	Menampilkan apa yang ditransfer
-h (human)	Ukuran yang mudah dibaca manusia
--partial	Menyimpan berkas yang tertransfer sebagian, agar eksekusi ulang melanjutkan
--progress	Progres per berkas — yang tak pernah dimiliki scp
-z	Kompres di perjalanan (CPU lambat di LAN cepat: lewati)
--delete	Mencerminkan penghapusan juga — berbahaya, selalu pasangkan dengan dry run
--dry-run (-n)	Menunjukkan apa yang akan terjadi, tanpa mengubah apa pun

Dua kebiasaan yang layak diadopsi. Pertama, dry-run apa pun yang memakai --delete:

rsync -avh --delete --dry-run src/ user@server:/srv/dest/   # tinjau dulu
rsync -avh --delete src/ user@server:/srv/dest/             # baru eksekusi

Kedua, awasi garis miring di akhir — /srv/src menyalin direktorinya sendiri ke dalam tujuan, sedangkan /srv/src/ menyalin isinya. Ini sekali pernah menjebak semua orang; rsync bahkan memperingatkan “no bytes transferred” saat yang Anda maksud bentuk yang lain.

Untuk sinkronisasi harian atau mingguan, masukkan rsync ke systemd timer dan biarkan ia hanya menyalin delta — sisi journalctl dari penjadwalan dibahas di journalctl cheat sheet.

Rsync vs scp: vonisnya

	scp	rsync
Ikut OpenSSH	Ya	Ya (kedua ujung diperlukan)
Melanjutkan transfer terputus	Tidak	Ya (--partial)
Transfer delta saat eksekusi ulang	Tidak	Ya
Mempertahankan permission/symlink	Sebagian	Penuh (-a)
Pola exclude	Tidak	--exclude
Dry run	Tidak	--dry-run
Mencerminkan penghapusan	Tidak	--delete
Paling cocok untuk	Salinan sekali jalan yang cepat	Backup, sinkronisasi, pohon berkas besar

Jadikan rsync bawaan untuk backup, pohon besar, apa pun lewat koneksi yang bisa putus, dan apa pun yang akan Anda jalankan lebih dari sekali. Pakai scp saat perintahnya lebih pendek daripada pikirannya. Jika satu flag boleh dibawa pulang, ambil --partial — ia mengubah setiap koneksi putus di masa depan dari mulai ulang menjadi sekadar jeda.