Rsync vs SCP: คำสั่งคัดลอกของ Linux ควรใช้ตัวไหน

ใช้ rsync กับทุกงานที่ใหญ่กว่าการก๊อปครั้งเดียวจบ และใช้ scp เมื่อแค่อยากได้ไฟล์ไปอีกเครื่องเดี๋ยวนี้ ความต่างแก่น ๆ คือ: scp สตรีมไฟล์ทั้งไฟล์ใหม่ทุกครั้งและจำอะไรเรื่องการหลุดกลางคันไม่ได้ ขณะที่ rsync เทียบต้นทางกับปลายทาง โอนเฉพาะบล็อกที่เปลี่ยน และกลับมาโอนต่อจากจุดที่หยุด กับการสำรองข้อมูลใหญ่ผ่านเน็ตที่หลุดบ่อย นี่คือช่องว่างระหว่าง “สองนาทีจบ” กับ “เริ่มใหม่ตั้งแต่ศูนย์” ทั้งคู่มาพร้อม OpenSSH บน Linux เกือบทุก distro จึงเป็นเรื่องของนิสัย ไม่ใช่การติดตั้ง — และนิสัยที่ดีควรเริ่มจาก rsync เป็นค่าเริ่มต้น ด้านล่างมีตารางเทียบตรง ๆ ผลต่างความเร็วจริง เทคนิคกู้ต่อที่ scp ทำไม่ได้ และกรณีที่ scp ยังเป็นคำตอบที่ถูกต้อง

rsync กับ scp ต่างกันอย่างไร?

scp ทำสิ่งเดียว: เปิดช่อง SSH สตรีมไบต์ แล้วปิด มันไม่มีสถานะค้างระหว่างรัน การโอนจึงตายที่ 90% ก็เริ่มจากศูนย์ใหม่

rsync เป็นเครื่องมือซิงก์ที่บังเอิญใช้ SSH เป็นพาหะ ก่อนส่งมันจะสร้างรายการ checksum ของไฟล์ฝั่งปลายทาง (อัลกอริทึม delta แบบ rolling-checksum) แล้วส่งเฉพาะบล็อกที่ต่างกัน รันคำสั่งเดิมสองรอบ รอบที่สองแทบไม่เคลื่อนข้อมูลอะไรเลย นั่นยังทำให้ rsync เป็นเครื่องมือธรรมชาติของการคุมสองโฟลเดอร์ให้ตรงกัน — ตั้งตารางเวลาแล้วแต่รอบโอนแค่ส่วนต่าง

ผลที่ตามมาในทางปฏิบัติ:

• การหลุดกลางคัน: rsync โอนต่อได้ scp เริ่มไฟล์ใหม่
• การก๊อปซ้ำ: rsync ส่งเฉพาะสิ่งที่เปลี่ยน scp ส่งซ้ำทั้งหมด
• การลบ: rsync มิเรอร์การลบด้วย --delete ได้ scp ทำไม่ได้
• การกรอง: rsync มีรูปแบบ --exclude scp ก๊อปทุกอย่างที่ชี้ไป
• ทดลองก่อน: rsync โชว์ว่าจะทำอะไรด้วย --dry-run scp ไม่มีอะไรให้เลย

rsync เร็วกว่า scp หรือไม่?

สำหรับการก๊อปครั้งแรกของไฟล์ใหญ่ผ่านเน็ตเร็ว พวกเขาใกล้เคียงกัน — ทั้งคู่ใช้ SSH จนเต็มสาย และรอบเช็ก checksum แทบไม่กินเวลา ช่องว่างเปิดออกในสามจุด:

1. ไฟล์เล็กจำนวนมาก rsync จัดคิวการเดินโฟลเดอร์เป็นสายพานและใช้ connection เดียวซ้ำได้ รุ่นเก่าของ scp สร้างงานใหม่ต่อไฟล์ ไฟล์เล็กพันกว่าตัว (a node_modules หรืออินสตอล WordPress) จบเร็วขึ้นชัดเจนด้วย rsync
2. การรันซ้ำ ก๊อปไฟล์ 4 GB ที่เปลี่ยนไป 50 MB แล้ว rsync เคลื่อนราว ๆ 50 MB ส่วน scp โยก 4 GB ใหม่อีกรอบ
3. การบีบอัด -z บีบระหว่างทาง ช่วยกับลิงก์ WAN ช้า

จับเวลาเองได้เลย — รูปคำสั่งเหมือนกัน:

# ไฟล์เดียวกัน เซิร์ฟเวอร์เดียวกัน ผ่าน SSH ทั้งคู่
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

# รันซ้ำทั้งคู่: scp ก๊อปใหม่ rsync เช็กแล้วส่งเกือบไม่มีอะไร
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

ถ้าคุณใช้ชีวิตอยู่กับเซิร์ฟเวอร์ ความเร็วการโอนเป็นเรื่องที่ควรวัดสักครั้ง — เหมือนที่ ss ชนะ netstat บนเครื่องงานแน่น (ดู ss vs netstat)

scp กู้การโอนที่หลุดกลางคันได้ไหม?

ไม่ได้ scp ไม่มี resume ถ้าการเชื่อมต่อหลุดที่ 900 MB จาก 1 GB ก็เริ่มใหม่ นี่คือเหตุผลที่ถูกยกมากที่สุดในทุกกระดานโต้วาที rsync-vs-scp และมันเป็นความจริง

ดีไซน์ทั้งหมดของ rsync ออกแบบมาโดยสมมติว่าการโอนจะหลุดเป็นครั้งคราว คาถากู้คืนมาตรฐาน:

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

• --partial เก็บไฟล์เขียนครึ่งหนึ่งไว้แทนการลบทิ้ง
• --append-verify โอนต่อแบบเติมท้ายแล้วเช็ก checksum ยืนยันส่วนที่เติม — ปลอดภัยกับไฟล์ครึ่ง ๆ กลาง ๆ ที่เสีย ต่างจาก --append เปล่า ๆ รุ่นเก่า
• --progress โชว์ว่ามันคว้างานต่อจากตรงไหน

ห่อด้วยลูป retry ก็ได้ backup แบบตั้งแล้วลืม แม้ผ่านเน็ตสุดโหด:

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

เมื่อไรที่ควรใช้ scp แทน rsync?

scp ยังเป็นเครื่องมือที่ถูกต้องในไม่กี่กรณี:

• ไฟล์เล็กหนึ่งไฟล์ ครั้งเดียว พิมพ์ scp app.conf user@host:/etc/myapp/ สั้นกว่าการเรียก rsync ทุกแบบ และไม่มีอะไรต้องกู้ต่อ
• rsync ไม่มีอยู่ฝั่งปลายทาง rsync ต้องมีไฟล์โปรแกรมทั้งสองฝั่ง คอนเทนเนอร์มินิมอลและเครื่องไซส์เล็กจำนวนมากมาพร้อม SFTP server ของ scp แต่ไม่มี rsync
• ไม่อยากเปิด rsync daemon พบน้อย แต่บางสภาพแวดล้อมล็อก daemon ของ rsync เป็นการเฉพาะ

เกร็ดที่ควรรู้: โปรเจกต์ OpenSSH เลิกสนับสนุนโปรโตคอลดั้งเดิมของ scp ไปหลายปี และ scp รุ่นใหม่จริง ๆ พูดภาษา SFTP อยู่ข้างใต้ มันแก้บั๊กการหลุดจากพาธ แต่ไม่ได้แก้อะไรกับข้อจำกัดสองข้อที่สำคัญตรงนี้ — ไม่มี resume ไม่มี delta transfer การเปลี่ยนโปรโตคอลไม่ได้ทำให้ scp กลายเป็น rsync

เรื่องใกล้เคียงกัน: ถ้าคำถามจริง ๆ คือ “rsync vs cp” คำตอบสะท้อนเรื่องนี้ — cp คือฉบับ local ของ scp (ไม่มี resume ไม่มี delta ไม่มี attribute ถ้าไม่ใส่ flag) และ rsync ใช้ได้ทั้ง local และ remote ก๊อปในเครื่องครั้งเดียว cp ก็พอ

flag ของ rsync ตัวไหนสำคัญที่สุด?

คนส่วนใหญ่ใช้จริงแค่หนึ่งบรรทัด:

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

Flag	ทำอะไร
-a (archive)	แบบ recursive + คง permissions, เวลา, กลุ่ม, symlink, device
-v (verbose)	แสดงรายการที่โอน
-h (human)	ขนาดแบบอ่านง่าย
--partial	เก็บไฟล์ที่โอนไม่จบ รอบหน้าโอนต่อได้
--progress	ความคืบหน้ารายไฟล์ — ของที่ scp ไม่เคยมี
-z	บีบอัดระหว่างทาง (CPU ช้าบน LAN เร็ว: ข้ามได้)
--delete	มิเรอร์การลบด้วย — อันตราย ต้องคู่กับ dry run เสมอ
--dry-run (-n)	โชว์ว่าจะเกิดอะไร ไม่แตะอะไรเลย

สองนิสัยที่ควรทำ หนึ่ง ทำ dry run กับทุกคำสั่งที่มี --delete:

rsync -avh --delete --dry-run src/ user@server:/srv/dest/   # ทบทวนก่อน
rsync -avh --delete src/ user@server:/srv/dest/             # แล้วค่อยลงมือ

สอง ระวังเครื่องหมายทับท้ายทาง — /srv/src ก๊อปโฟลเดอร์ตัวมันเองไปไว้ที่ปลายทาง ขณะที่ /srv/src/ ก๊อป เนื้อหาข้างใน ทุกคนสะดุดจุดนี้ครั้งหนึ่งเป็นธรรม rsync ยังเตือน “no bytes transferred” เมื่อคุณตั้งใจแบบอีกฝั่ง

สำหรับซิงก์รายวันหรือรายสัปดาห์ โยน rsync ลง systemd timer แล้วให้มันก๊อปเฉพาะส่วนต่าง — เรื่อง journalctl ของการจัดตารางอยู่ใน สรุปคำสั่ง journalctl

Rsync vs scp: คำตัดสิน

	scp	rsync
มาพร้อม OpenSSH	มี	มี (ต้องมีทั้งสองฝั่ง)
กู้การโอนที่หลุดกลางคัน	ไม่	มี (--partial)
Delta transfer ตอนรันซ้ำ	ไม่	มี
คง permissions/symlink	บางส่วน	ครบ (-a)
รูปแบบ exclude	ไม่มี	--exclude
Dry run	ไม่มี	--dry-run
มิเรอร์การลบ	ไม่ได้	--delete
เหมาะกับ	ก๊อปครั้งเดียวจบ	สำรองข้อมูล ซิงก์ ต้นไม้ไฟล์ใหญ่

เริ่มจาก rsync สำหรับ backup ต้นไม้ไฟล์ใหญ่ ทุกอย่างผ่านลิงก์ที่หลุดได้ และทุกอย่างที่จะรันมากกว่าหนึ่งครั้ง ใช้ scp เมื่อคำสั่งสั้นกว่าความคิด ถ้าจะจำ flag เดียวจากบทความนี้ ขอให้เป็น --partial — มันเปลี่ยนการเชื่อมต่อที่หลุดทุกครั้งข้างหน้าจากการเริ่มใหม่ให้เป็นแค่การพัก