Rsync vs SCP: Aling Linux Copy Command ang Gagamitin

Gumamit ka ng rsync para sa kahit anong mas malaki sa mabilisang one-off copy, at scp kapag gusto mo lang may file sa ibang box ngayon na. Ang core na pagkakaiba: muli nitong pinapadausdos ang buong file ang scp tuwing beses at walang memorya ng naputol na connection, samantalang kinukumpara ng rsync ang source at destination, mga nagbagong blocks lang ang inililipat, at ipinagpapatuloy ang naputol na kopya sa natigilan nito. Sa malaking backup sa mahinang link, iyan ang pagitan ng dalawang minuto at pagsisimula ulit. Kasama ang pareho sa OpenSSH sa halos bawat Linux distribusyon, kaya habit ang pinag-uusapan dito, hindi install — at dapat default sa rsync ang habit. Sa ibaba: direktang comparison table, totoong speed differences, ang resume trick na hindi kaya ng scp, at ang mga kaso kung saan tama pa rin ang scp.

Ano ang pagkakaiba ng rsync at scp?

Isang bagay lang ang scp: buksan ang SSH channel, padaanin ang bytes, isara. Walang estado ito sa pagitan ng mga run, kaya kung mamatay ang transfer sa 90%, magsisimula ka muli sa zero.

Ang rsync ay synchronisation tool na nagkataong gumagamit ng SSH bilang transport nito. Bago magpadala, bumubuo ito ng checksum list ng destination file (ang rolling-checksum delta algorithm) at mga blocks lang na magkaiba ang ipinapadala. I-run ang same command nang dalawang beses at halos walang inilipat ang ikalawa. Kaya rin natural na tool ang rsync para panatilihing tugma ang dalawang directory — iiskedyul mo ito at mga delta lang ang kinokopya ng bawat run.

Ang mga praktikal na epekto:

• Mga pagkaantala: nagpapatuloy ang rsync; nagsisimula muli ang scp sa file.
• Pangalawang kopya: mga pagbabago lang ang ipinapadala ng rsync; lahat ay muling ipinapadala ng scp.
• Mga pagbura: kayang i-mirror ng rsync ang mga pagbura gamit ang --delete; hindi kaya ng scp.
• Filtering: may --exclude patterns ang rsync; lahat ng itinuro mo ay kinokopya ng scp.
• Dry runs: ipinapakita ng rsync ang gagawin nito gamit ang --dry-run; wala ang scp.

Mas mabilis ba ang rsync kaysa scp?

Para sa first-time na kopya ng isang malaking file sa mabilis na link, magkalapit sila — parehong sumasadsad sa SSH, at maliit lang ang dagdag na overhead ng checksum pass. Bubuksan ang pagitan sa tatlong lugar:

1. Maliliit na files sa maramihan. Nagma-pipeline ang rsync ng directory walks at pwedeng muling gumamit ng iisang connection; ang mga lumang scp setup ay naghahanda ng trabaho kada file. Libo-libong maliliit na files (isang node_modules, isang WordPress install) ay kapansin-pansing mas mabilis matapos sa rsync.
2. Mga muling run. Kopyahin ang 4 GB file kung saan 50 MB ang nagbago at mga 50 MB lang ang inilipat ng rsync; 4 GB ulit ang inilipat ng scp.
3. Compression. Kinokompress ng -z habang nasa ere, na nakakatulong sa mababang WAN links.

Pwedeng pansarili mong sukatin — same ang hugis ng command:

# same file, same server, both over SSH
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

# re-run both: scp re-copies, rsync verifies and sends ~nothing
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

Kung nasa mga server ka buong araw, isa sa mga bagay na worth sukatin nang isang beses ang transfer speed — pareho ng pagkapanalo ng ss sa netstat sa mga abalang host (tingnan ang ss vs netstat: kung aling Linux port command ang gagamitin).

Kayang ipagpatuloy ng scp ang naputol na transfer?

Hindi. Walang resume ang scp; kung natanggal ang connection sa 900 MB ng 1 GB, magsisimula ka ulit. Ito ang pinakamadalas banggitin sa bawat rsync-vs-scp debate, at totoo ito.

Ang buong disenyo ng rsync ay inaasahan na minsan maantala ang transfer. Ang canonical na resume incantation:

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

• Pinapanatili ng --partial ang kalahating naisulat na file sa halip na burahin ito.
• Nagre-resume ang --append-verify sa pamamagitan ng pag-append, tapos checksum-verify ang nai-appended na rehiyon — ligtas laban sa corrupt na partial file, hindi tulad ng lumang plain --append.
• Ipinapakita ng --progress kung saan ito kumabit.

Balot sa retry loop, set-and-forget na backup ito kahit sa kaaway na connection:

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

Kailan dapat gumamit ng scp sa halip na rsync?

Ilang kaso pa rin tama ang scp:

• Isang maliit na file, isang beses. Mas maikli itype ang scp app.conf user@host:/etc/myapp/ kaysa kahit anong rsync invocation, at walang dapat ipagpatuloy.
• Kulang ang rsync sa kabilang dulo. Kailangan ng rsync ng binary nito sa magkabilang panig. Maraming minimal containers at appliances ang may bitbit na SFTP server ng scp pero walang rsync.
• Ayaw mo ng nakabuyad na rsync server. Bihira, pero may mga environment na sadyang kumakanlong sa rsync daemon.

Isang subtlety na worth malaman: taon nang itinuring na deprecated ng OpenSSH project ang orihinal na protocol ng scp, at ang modernong scp ay talaga namang nagsasalita ng SFTP sa ilalim. Inayos nito ang isang path-escaping quirk, pero walang binago sa dalawang limitasyon na mahalaga dito — walang resume, walang delta transfer. Hindi ginagawang rsync ng scp ang pagbabago ng protocol.

Kaugali rin: kung ang totoong tanong mo ay “rsync vs cp”, kumikislap ang sagot sa ganito — ang cp ang local-only na katumbas ng scp (walang resume, walang delta, walang attributes maliban kung magdadagdag ka ng flags), at gumagana ang rsync pareho sa local at remote. Para sa local one-shots, ok lang ang cp.

Aling rsync flags ang pinakamahalaga?

Isang linya lang ang kailangan ng kalakhan:

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

Flag	Ginagawa nito
-a (archive)	Recursive + pinapanatili ang permissions, times, group, symlinks, devices
-v (verbose)	Inililista ang mga inililipat nito
-h (human)	Human-readable na sizes
--partial	Pinapanatili ang mga bahagyang na-transfer na files, para mag-resume ang muling run
--progress	Per-file na progress — ang bagay na hindi kailanman naging scp
-z	Kinokompress habang nasa ere (mababang CPUs sa mabilis na LANs: laktawan ito)
--delete	Ini-mirror din ang mga pagbura — delikado, laging paresan gamit ang dry run
--dry-run (-n)	Ipinapakita ang mangyayari, walang binabago

Dalawang habit na worth amponin. Una, i-dry-run ang kahit anong may --delete:

rsync -avh --delete --dry-run src/ user@server:/srv/dest/   # review
rsync -avh --delete src/ user@server:/srv/dest/             # then commit

Pangalawa, bantayan ang trailing slash — kinokopya ng /srv/src ang directory mismo papunta sa destination, samantalang nilalaman nito ang kinokopya ng /srv/src/. Nadadaganan ng isang beses ang lahat sa bagay na ito; nagbabala pa nga ang rsync ng “no bytes transferred” kapag ang kabila ang ibig mong sabihin.

Para sa araw-araw o lingguhang sync, ihulog mo ang rsync sa systemd timer at pabayaang mga delta lang ang kopyahin nito — ang journalctl side ng scheduling ay saklaw sa journalctl cheat sheet.

Rsync vs scp: ang pasya

	scp	rsync
Kasama sa OpenSSH	Oo	Oo (kailangan parehong dulo)
Ipagpatuloy ang naputol na transfer	Hindi	Oo (--partial)
Delta transfer sa mga muling run	Hindi	Oo
Panatilihin ang permissions/symlinks	Bahagya	Ganap (-a)
Exclude patterns	Hindi	--exclude
Dry run	Hindi	--dry-run
I-mirror ang mga pagbura	Hindi	--delete
Pinakamainam para sa	Mabilisang one-off copies	Backups, syncs, bulk trees

Default sa rsync para sa backups, malalaking trees, kahit anong dumadaan sa link na pwedeng mamatay, at kahit anong tatakbo mo nang higit sa isang beses. Gamitin ang scp kapag mas maikli ang command kaysa iniisip mo. Kung may isang flag kang dadalhin, --partial na — ginagawa nitong pause imbes na restart ang bawat susunod na naputol na connection.