วิธีใช้คำสั่ง rsync ผ่าน SSH เพื่อย้ายไฟล์ขนาดใหญ่ระหว่างเซิร์ฟเวอร์สองเครื่องอย่างรวดเร็วและปลอดภัย

คำสั่ง rsync ผ่าน SSH เป็นวิธีที่สะดวกและมีประสิทธิภาพสูงสำหรับการย้ายไฟล์ขนาดใหญ่ระหว่างเซิร์ฟเวอร์ Linux สองเครื่อง ด้วยความสามารถในการส่งเฉพาะส่วนที่เปลี่ยนแปลงของไฟล์เท่านั้น ทำให้เร็วกว่าการคัดลอกแบบธรรมดาอย่างมาก เหมาะกับการโอนย้ายไฟล์เว็บไซต์ขนาดหลายร้อยกิกะไบต์, แฟ้มสำรองข้อมูล, โฟลเดอร์สื่อ หรือข้อมูลแอปพลิเคชัน โดยไฟล์จะถูกเข้ารหัสผ่านช่องทาง SSH ช่วยให้มั่นใจในความปลอดภัย และหากการเชื่อมต่อขาดไปก็สามารถกลับมาต่อได้จากจุดที่ค้างไว้โดยไม่ต้องเริ่มใหม่

ในการย้ายเซิร์ฟเวอร์, อัปเกรดโฮสติ้ง, ย้ายศูนย์ข้อมูล หรือทำงานแบ็กอัปนั้น นอกจากความเร็วแล้ว ความสมบูรณ์ของข้อมูลก็เป็นสิ่งสำคัญ การดาวน์โหลดไฟล์ขนาดใหญ่ทั้งหมดลงมาในเครื่องแล้วอัปโหลดขึ้นใหม่อาจใช้เวลานานและเสี่ยงต่อการขาดการเชื่อมต่อจนต้องเริ่มต้นใหม่ rsync จึงช่วยเก็บรักษาเวลาประทับ (timestamp), สิทธิ์การเข้าถึง, เจ้าของไฟล์ และโครงสร้างโฟลเดอร์ได้อย่างครบถ้วน ทำให้เป็นเครื่องมือยอดนิยมสำหรับผู้ดูแลระบบ Linux, ทีม DevOps และผู้เชี่ยวชาญเว็บโฮสติ้งในงานประจำวัน

บทความนี้จะสอนการใช้งาน rsync ผ่าน SSH เพื่อย้ายไฟล์ขนาดใหญ่ระหว่างเซิร์ฟเวอร์ Linux สองเครื่อง พร้อมตัวอย่างคำสั่งจริงทีละขั้นตอน รวมถึงคำแนะนำการเพิ่มประสิทธิภาพ, การตรวจสอบความปลอดภัย, การจัดการข้อผิดพลาด, วิธีทดสอบการถ่ายโอน และข้อควรระวังก่อนนำไปใช้งานจริง หากคุณวางแผนย้าย VPS หรือสภาพแวดล้อมโฮสติ้งใหม่ กรุณาตรวจสอบว่าทั้งเซิร์ฟเวอร์ต้นทางและปลายทางมีพื้นที่ว่างพอ, สามารถเข้าถึง SSH ได้ และตั้งสิทธิ์ผู้ใช้อย่างเหมาะสมแล้ว สำหรับข้อมูลเพิ่มเติมเกี่ยวกับโครงสร้างพื้นฐานที่เหมาะสมสามารถดูได้ที่ โซลูชันเซิร์ฟเวอร์ VPS Hostragons และ แพ็กเกจโฮสติ้งลินุกซ์

rsync คืออะไร และทำไมจึงเหมาะกับการย้ายไฟล์ใหญ่?

rsync คือเครื่องมือบรรทัดคำสั่งที่ใช้ซิงค์ไฟล์และโฟลเดอร์ระหว่างระบบในเครื่องเดียวกันหรือระยะไกล จุดเด่นอยู่ที่อัลกอริทึม delta transfer ซึ่งจะส่งเฉพาะส่วนที่เปลี่ยนแปลงของไฟล์แทนที่จะส่งทั้งไฟล์ใหม่ทั้งหมด เช่น ถ้าไฟล์สำรองข้อมูลขนาด 80 GB มีข้อมูลเปลี่ยนแค่ 2 GB ก็จะส่งแค่ส่วนที่เปลี่ยน ทำให้ประหยัดเวลาและแบนด์วิดท์

ส่วน SSH จะช่วยเข้ารหัสการส่งข้อมูล ทำให้เนื้อหาไฟล์ไม่ถูกส่งเป็นข้อความธรรมดา ซึ่งสำคัญมากสำหรับข้อมูลลูกค้า, รายการสั่งซื้ออีคอมเมิร์ซ, แฟ้มสื่อ, แบ็กอัพฐานข้อมูล หรือไฟล์แอปพลิเคชันพิเศษ ในวงการโฮสติ้ง ความปลอดภัยของข้อมูลไม่ได้จำกัดแค่ SSL เท่านั้น แต่ช่องทางส่งข้อมูลระหว่างเซิร์ฟเวอร์ก็ควรปลอดภัยเช่นกัน หากใช้ ใบรับรอง SSL เพื่อเข้ารหัสเว็บไซด์ ก็ควรใช้ SSH สำหรับโอนย้ายไฟล์ระหว่างเซิร์ฟเวอร์ด้วยเช่นกัน

rsync มีความยืดหยุ่นกว่า FTP หรือการดาวน์โหลด-อัปโหลดด้วยมือ สามารถรักษาสิทธิ์ไฟล์, รองรับ symbolic link, ลบไฟล์ที่ถูกลบในต้นทางออกจากปลายทาง, จำกัดแบนด์วิดท์ และทดสอบก่อนส่งจริงได้ ทั้งหมดนี้ช่วยลดความเสี่ยงเมื่อถ่ายโอนไฟล์ใหญ่

เมื่อไรควรใช้ rsync ผ่าน SSH?

rsync ผ่าน SSH เหมาะกับการย้ายไฟล์ขนาดใหญ่, จำนวนมาก หรือที่เปลี่ยนแปลงบ่อย ในกรณีที่เพียงแค่โฟลเดอร์ภาพเล็ก ๆ อาจใช้ SFTP ธรรมดาได้ แต่ถ้าต้องจัดการไฟล์นับพัน, สิทธิ์แตกต่างกัน หรือแฟ้มขนาดใหญ่ การใช้ rsync จะน่าเชื่อถือกว่า

• ย้ายเว็บไซต์จากเซิร์ฟเวอร์เก่าไปยัง VPS ใหม่
• ย้ายโฟลเดอร์สื่อที่มีไฟล์นับพัน เช่น โฟลเดอร์ WordPress uploads
• สำรองข้อมูลรายวัน รายสัปดาห์ หรือรายเดือนไปยังเซิร์ฟเวอร์อื่น
• เปลี่ยนศูนย์ข้อมูลหรือผู้ให้บริการโฮสติ้ง
• ซิงค์ไฟล์แอปพลิเคชันระหว่างสภาพแวดล้อมการใช้งานจริงและสำรอง
• วางแผนถ่ายโอนข้อมูลระยะยาวที่เสี่ยงต่อการขาดการเชื่อมต่อ

เช่น หากต้องดาวน์โหลดโฟลเดอร์สื่อขนาด 250 GB ลงเครื่องคอมพิวเตอร์ก่อน แล้วจึงอัปโหลดไปยังเซิร์ฟเวอร์ใหม่ จะต้องทำสองขั้นตอน ซึ่งใช้เวลานานและทำให้เน็ตบ้านหรือเน็ตที่ทำงานอืดได้ แต่ถ้าใช้ rsync โอนไฟล์จากเซิร์ฟเวอร์ต้นทางไปยังปลายทางโดยตรง ก็จะตัดขั้นตอนนี้ออกไป

สิ่งที่ต้องเตรียมก่อนเริ่ม

การใช้ rsync ให้สำเร็จไม่ใช่แค่รู้คำสั่งเท่านั้น แต่ต้องตรวจสอบสภาพแวดล้อมทั้งต้นทางและปลายทางด้วย เพื่อป้องกันข้อมูลเสียหายหรือการโอนไม่สมบูรณ์ โดยมีขั้นตอนตรวจสอบหลัก ๆ ดังนี้

1. ตรวจสอบการเข้าถึง SSH

ต้องสามารถเชื่อมต่อ SSH จากเซิร์ฟเวอร์ต้นทางไปยังปลายทางได้ ทดสอบด้วยคำสั่ง ssh user@ip-address หาก SSH ใช้พอร์ตอื่นให้ลอง ssh -p 2222 user@ip-address หากทดสอบไม่ผ่าน rsync จะไม่ทำงาน ต้องตรวจสอบ firewall, Fail2ban, พอร์ต SSH, สิทธิ์ผู้ใช้ และการยืนยันตัวตนด้วยรหัสผ่านหรือคีย์

2. ตรวจสอบว่ามี rsync ติดตั้งแล้ว

โดยทั่วไป rsync จะถูกติดตั้งมาพร้อมกับลินุกซ์ แต่ควรเช็คก่อนด้วยคำสั่ง rsync --version บน Debian/Ubuntu หากไม่มีให้ติดตั้งด้วย apt install rsync บน AlmaLinux, Rocky Linux หรือ CentOS ใช้ dnf install rsync หรือ yum install rsync หากใช้ VPS บน Hostragons การติดตั้งมักใช้เวลาไม่กี่วินาที

3. ตรวจสอบพื้นที่ดิสก์

พื้นที่ว่างบนเซิร์ฟเวอร์ปลายทางต้องเพียงพอ หากไม่พอกระบวนการจะหยุดกลางคัน ใช้ du -sh /path/to/source ดูขนาดโฟลเดอร์ต้นทาง และ df -h ตรวจสอบพื้นที่ดิสก์ปลายทาง ควรเผื่อพื้นที่สำหรับไฟล์ชั่วคราวและล็อกไฟล์ด้วย เช่น ถ้าจะย้ายข้อมูล 500 GB ควรวางแผนพื้นที่ว่างอย่างน้อย 550-600 GB

4. วางแผนจัดการไฟล์ที่เปลี่ยนแปลงและบริการสำคัญ

ในเว็บไซต์ที่ใช้งานจริง ไฟล์อาจถูกเปลี่ยนระหว่างการถ่ายโอน เช่น ไฟล์ที่ผู้ใช้โหลดขึ้น, โฟลเดอร์ cache หรือไฟล์ล็อก ในการย้ายข้อมูลขนาดใหญ่ ควรถ่ายโอนข้อมูลหลักก่อน แล้วสั่งให้เว็บไซต์เข้าสู่โหมดบำรุงรักษา (maintenance mode) จากนั้นรัน rsync อีกครั้งเพื่อนำไฟล์ที่เปลี่ยนแปลงล่าสุดไปด้วย วิธีนี้ช่วยลดเวลาที่เว็บไซต์ไม่สามารถใช้งานได้ให้น้อยที่สุด สำหรับ WordPress สามารถดูคำแนะนำได้ที่ คู่มือการย้าย WordPress hosting

คำสั่ง rsync พื้นฐานสำหรับการย้ายไฟล์ระหว่างเซิร์ฟเวอร์

คำสั่งพื้นฐานที่นิยมใช้คือ rsync -avz /path/to/source/ user@target-ip:/path/to/destination/ โดย -a คือโหมดเก็บรักษา (archive) ซึ่งจะรักษาสิทธิ์, timestamp, symbolic link และข้อมูลอื่น ๆ -v แสดงรายละเอียดระหว่างทำงาน -z เปิดการบีบอัดข้อมูลขณะส่ง ซึ่งช่วยลดปริมาณข้อมูลได้ แต่ไม่เหมาะกับไฟล์ที่ถูกบีบอัดอยู่แล้ว เช่น .zip, .jpg, .mp4 ที่ท้าย path ถ้ามี / หมายถึงส่งเฉพาะเนื้อหาในโฟลเดอร์ ถ้าไม่มี / หมายถึงส่งทั้งโฟลเดอร์ไปยังปลายทาง

ตัวอย่างเช่น ต้องการย้ายโฟลเดอร์เว็บขนาด 180 GB จาก /var/www/site/public_html/ บนเซิร์ฟเวอร์เก่าไปยังตำแหน่งเดียวกันบนเซิร์ฟเวอร์ใหม่ที่ IP 203.0.113.20 คำสั่งคือ: rsync -avz /var/www/site/public_html/ root@203.0.113.20:/var/www/site/public_html/ ซึ่งจะส่งไฟล์ผ่าน SSH

ถ้าไม่อยากใช้ root ควรสร้างผู้ใช้ที่มีสิทธิ์เขียนในโฟลเดอร์เป้าหมาย เช่น deploy และตั้งสิทธิ์ของโฟลเดอร์ให้เหมาะสม ถึงแม้การใช้ root จะสะดวก แต่เพื่อความปลอดภัยควรใช้ผู้ใช้ที่จำกัดสิทธิ์แทน

พารามิเตอร์ rsync ที่แนะนำสำหรับความปลอดภัยและความทนทาน

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

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

โดย -H รักษา hard link, -A รักษา ACL, -X รักษา extended attributes, --numeric-ids ใช้ ID แทนชื่อผู้ใช้และกลุ่มเพื่อแก้ปัญหาชื่อไม่ตรงกัน, --partial เก็บไฟล์ที่ส่งไม่ครบไว้เพื่อให้กลับมาต่อได้, --progress แสดงความคืบหน้า, และ --append-verify ช่วยตรวจสอบส่วนที่เพิ่มเข้ามาขณะต่อเนื่อง

ไม่จำเป็นต้องใช้ทุกพารามิเตอร์ในทุกกรณี เช่น เว็บไซต์ธรรมดาใช้แค่ -aHAX ก็เพียงพอ แต่แอปที่ต้องรักษาสิทธิ์พิเศษควรใช้ ACL และ extended attributes ซึ่งควรทดสอบก่อนใช้งานจริง

ถ้า SSH ใช้พอร์ตอื่นควรใส่คำสั่งอย่างไร?

ถ้า SSH ไม่ใช้พอร์ต 22 แต่เปลี่ยนเป็นพอร์ตอื่น เช่น 2222 ต้องระบุพารามิเตอร์ SSH ในคำสั่ง rsync แบบนี้:

rsync -avz -e 'ssh -p 2222' /path/to/source/ user@target-ip:/path/to/destination/

หากใช้คีย์ SSH ก็เพิ่ม -i ตามนี้:

rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /path/to/source/ user@target-ip:/path/to/destination/

ข้อควรระวังคือ การใช้ single quote (' ') กับ double quote (" ") ต้องเหมาะสมกับ shell และสคริปต์ที่ใช้ด้วย

ทดสอบการถ่ายโอนด้วย --dry-run ก่อน

การทดสอบด้วย --dry-run เป็นขั้นตอนสำคัญก่อนย้ายข้อมูลใหญ่ เพราะจะไม่ส่งไฟล์จริง แต่แสดงรายการไฟล์ที่จะถูกส่ง ช่วยตรวจสอบว่าคำสั่งถูกต้อง ไม่เกิดการลบไฟล์ผิดพลาด

ตัวอย่างคำสั่งทดสอบ:

rsync -avz --dry-run /var/www/site/ user@target-ip:/var/www/site/

ผลลัพธ์จะแสดงไฟล์ที่จะถูกย้ายและสรุปการทำงาน หากใช้ --delete ด้วย ควรยิ่งต้องทดสอบอย่างละเอียด เพราะคำสั่งนี้จะลบไฟล์ที่ไม่มีในต้นทางออกจากปลายทาง เพื่อให้เหมือนกันเป๊ะ ๆ แต่ถ้าผิดพลาดอาจทำให้ข้อมูลสูญหายได้

ลำดับการทำงานแนะนำคือ ทดสอบ SSH, ตรวจสอบพื้นที่ดิสก์, รัน rsync --dry-run, ทดสอบจริงกับโฟลเดอร์เล็ก ๆ แล้วจึงเริ่มการย้ายข้อมูลหลัก ขั้นตอนนี้เพิ่มเวลาไม่กี่นาทีแต่ป้องกันปัญหาที่อาจจะแก้ไขยากหลายชั่วโมงได้

การปรับแต่งเพื่อประสิทธิภาพ เช่น การบีบอัด, จำกัดแบนด์วิดท์ และการเข้ารหัส

ประสิทธิภาพของ rsync ขึ้นกับหลายปัจจัย ไม่ใช่แค่ขนาดไฟล์ เช่น CPU ของเซิร์ฟเวอร์, ชนิดของดิสก์, ความหน่วงของเครือข่าย, แบนด์วิดท์ และจำนวนไฟล์ ไฟล์เล็กจำนวนมากอาจช้ากว่าไฟล์ใหญ่เพราะต้องจัดการ metadata ของแต่ละไฟล์ได้

ถ้าใช้ VPS ที่มี NVMe disk จะช่วยให้การอ่านเขียนเร็วขึ้นมาก หากวางแผนถ่ายโอนข้อมูลเยอะควรพิจารณา เซิร์ฟเวอร์ VPS NVMe

พารามิเตอร์ -z ช่วยบีบอัดข้อมูลเหมาะกับไฟล์ข้อความ, log, หรือบางประเภทแบ็กอัป แต่ไฟล์ที่ถูกบีบอัดแล้วเช่น zip, tar.gz, jpg, mp4 อาจทำให้ CPU ทำงานหนักโดยไม่คุ้มค่า ถ้ามีการเชื่อมต่อ 1 Gbps ระหว่างเซิร์ฟเวอร์ที่แรงมาก อาจปิด -z เพื่อเพิ่มความเร็ว ในทางกลับกันถ้าแบนด์วิดท์จำกัดและไฟล์เป็นข้อความเยอะ -z จะช่วยประหยัดได้มาก

ถ้าต้องการจำกัดแบนด์วิดท์เพื่อไม่ให้รบกวนการใช้งานอื่น สามารถใช้ --bwlimit เช่น --bwlimit=50000 เพื่อจำกัดที่ประมาณ 50 MB/s การทำถ่ายโอนในช่วงเวลาที่คนใช้น้อย เช่น กลางคืน และติดตามค่า load average ขณะทำงาน เป็นวิธีปฏิบัติที่ดี

เปรียบเทียบ rsync, scp, SFTP และ FTP

มีหลายวิธีในการย้ายไฟล์ แต่แต่ละวิธีมีข้อดีข้อเสียต่างกัน ตารางด้านล่างสรุปความเหมาะสมในงานถ่ายโอนข้อมูลขนาดใหญ่และการย้ายเซิร์ฟเวอร์

จากตารางจะเห็นว่า rsync เหมาะกับงานซิงค์ไฟล์ซ้ำ ๆ และไฟล์ใหญ่ scp ใช้งานง่ายแต่ไม่ฉลาดเท่า rsync ในการส่งเฉพาะส่วนที่เปลี่ยน FTP ไม่มีการเข้ารหัสจึงไม่เหมาะกับข้อมูลสำคัญ แม้ FTP จะสะดวกบนแผงควบคุมโฮสติ้ง แต่ถ้าเป็นงานย้ายเซิร์ฟเวอร์ที่ต้องการความปลอดภัย ควรใช้วิธีที่มี SSH

ตัวอย่างขั้นตอนการย้ายเว็บไซต์ที่กำลังใช้งานอยู่

เมื่อย้ายเว็บไซต์จากเซิร์ฟเวอร์เก่าไปยังใหม่ ไม่ใช่แค่การคัดลอกไฟล์เท่านั้น ต้องตรวจสอบ DNS, ฐานข้อมูล, SSL, เวอร์ชัน PHP, สิทธิ์ไฟล์ และการตั้งค่าอีเมลด้วย ด้านล่างเป็นตัวอย่างขั้นตอนที่ช่วยลดเวลาหยุดทำงานสำหรับเว็บไซต์ที่มีไฟล์จำนวนมาก

• ติดตั้งเว็บเซิร์ฟเวอร์, PHP, ฐานข้อมูล และโมดูลที่จำเป็นบนเซิร์ฟเวอร์ใหม่
• ลดค่า DNS TTL ของโดเมนเป็น 300 วินาทีล่วงหน้าก่อนย้าย ดูข้อมูลเพิ่มเติมได้ที่ การตรวจสอบโดเมนและการจัดการโดเมน
• เริ่มการถ่ายโอนไฟล์ครั้งแรกด้วย rsync ขณะที่เว็บไซต์ยังเปิดใช้งานอยู่ เพื่อย้ายข้อมูลส่วนใหญ่
• สำรองฐานข้อมูลและโอนย้ายไปยังเซิร์ฟเวอร์ใหม่
• ปิดเว็บไซต์เข้าสู่โหมดบำรุงรักษาชั่วคราว
• รัน rsync อีกครั้งเพื่อซิงค์ไฟล์ที่เปลี่ยนแปลงล่าสุด
• อัปเดตฐานข้อมูลอีกครั้ง หรือใช้กลยุทธ์ incremental
• ตรวจสอบสิทธิ์ไฟล์, ทดสอบเปิดเว็บไซต์ และดูล็อกต่าง ๆ บนเซิร์ฟเวอร์ใหม่
• ติดตั้งหรืออัปเดต SSL โดยอ้างอิงจาก การติดตั้งใบรับรอง SSL
• เปลี่ยน DNS ให้ชี้ไปยัง IP ใหม่

ขั้นตอนนี้จะใช้เวลานานที่สุดในช่วงถ่ายโอนไฟล์ครั้งแรกขณะที่เว็บไซต์ยังใช้งานได้ และมี downtime แค่ช่วงซิงค์ไฟล์รอบสองและเปลี่ยน DNS วิธีนี้ช่วยลดเวลาหยุดทำงานจากหลายชั่วโมงเหลือเพียงไม่กี่นาที โดยเฉพาะกับเว็บไซต์ WordPress ที่มีไฟล์สื่อจำนวนมาก

ตรวจสอบความสมบูรณ์ของข้อมูลหลังย้าย

หลังจากการถ่ายโอนเสร็จสิ้น ไม่ควรพึ่งแค่คำสั่งจบอย่างเดียว ต้องตรวจสอบจำนวนไฟล์, ขนาด, และไฟล์สำคัญว่าถูกต้องครบถ้วนหรือไม่ ใช้คำสั่ง du -sh เปรียบเทียบขนาดโฟลเดอร์ต้นทางและปลายทาง แม้ว่าค่าจะไม่เท่ากันเป๊ะเนื่องจากระบบไฟล์อาจแตกต่างกัน

สามารถรัน rsync ซ้ำด้วยพารามิเตอร์เดิม หากไม่มีไฟล์ใหม่จะแสดงผลน้อยมาก

สำหรับความแม่นยำขั้นสูง ใช้คำสั่ง rsync -avc --dry-run /path/to/source/ user@target-ip:/path/to/destination/ ซึ่ง -c จะเปรียบเทียบด้วย checksum นอกจาก timestamp และขนาดไฟล์ แต่ต้องระวังว่าใช้ CPU และดิสก์สูง อาจไม่เหมาะกับข้อมูลใหญ่เกินไป

ถ้าย้ายเว็บไซต์ควรทดสอบในระดับแอปพลิเคชัน เช่น หน้าแรก, แผงควบคุม, การอัปโหลดรูป, หน้าชำระเงิน, ฟอร์มติดต่อ และตรวจสอบล็อกข้อผิดพลาด สำหรับเว็บไซต์อีคอมเมิร์ซ ไม่ใช่แค่ย้ายไฟล์ได้เท่านั้น ต้องทดสอบระบบชำระเงินและงาน cron บนเซิร์ฟเวอร์ใหม่ด้วย

ปัญหาที่พบบ่อยและวิธีแก้ไข

Permission denied

ข้อผิดพลาดนี้เกิดจากสิทธิ์ผู้ใช้ SSH, สิทธิ์เขียนโฟลเดอร์เป้าหมาย หรือการยืนยันตัวตนด้วยคีย์ผิด ลองเชื่อมต่อ SSH ด้วยผู้ใช้เดียวกันก่อน ถ้าได้ให้ทดสอบสร้างไฟล์ในโฟลเดอร์ปลายทาง หากไม่ได้ให้แก้ไขสิทธิ์ด้วย chown หรือวางแผนใช้ sudo

No space left on device

พื้นที่ดิสก์ปลายทางเต็ม ทำให้การโอนหยุด ตรวจสอบด้วย df -h และดูพื้นที่ใน mount point หรือ /tmp บางครั้งดิสก์หลักอาจยังว่าง แต่โฟลเดอร์ชั่วคราวเต็ม ในกรณีนี้ควรลบไฟล์เก่า ๆ เช่นล็อก, แฟ้มสำรองเก่า หรือเพิ่มขนาดดิสก์หรือเปลี่ยนเป็น VPS ที่มีสเปคสูงกว่า

Connection reset หรือ Broken pipe

การเชื่อมต่อขาดในระหว่างส่งข้อมูลยาว ๆ หากใช้ --partial และ --append-verify จะช่วยให้กลับมาต่อได้อีกครั้ง นอกจากนี้สามารถปรับตั้งค่า SSH keepalive เช่น ServerAliveInterval 60 เพื่อลดโอกาสเชื่อมต่อหลุด

การโอนช้ามาก

ปัญหานี้มักมาจากจำนวนไฟล์มาก, การจำกัด I/O ของดิสก์, การบีบอัดที่เพิ่มภาระ CPU หรือแบนด์วิดท์ไม่พอ ถ้าไฟล์จำนวนมากอาจสร้าง tar archive ก่อนแล้วค่อยส่งเพื่อให้เร็วขึ้น แต่จะเสียข้อได้เปรียบการส่งเฉพาะส่วนที่เปลี่ยนของ rsync ถ้าไฟล์ใหญ่และบีบอัดแล้ว ลองปิด -z ดู และใช้เครื่องมืออย่าง iotop, htop, iftop เพื่อตรวจสอบว่าแออัดที่ CPU, ดิสก์ หรือเครือข่าย

แนวทางปฏิบัติด้านความปลอดภัย

การส่งไฟล์ระหว่างเซิร์ฟเวอร์ต้องไม่ละเลยความปลอดภัย โดยเฉพาะการใช้สิทธิ์ root, คีย์ SSH และไฟล์แบ็กอัปที่เป็นความลับ แนะนำให้ใช้คีย์ SSH แทนรหัสผ่านและตั้งสิทธิ์ไฟล์คีย์ให้เข้มงวด ไม่แชร์คีย์ และตั้งรหัสผ่านคีย์ (passphrase) หากเป็นไปได้

ควรสร้างผู้ใช้เฉพาะสำหรับการย้ายไฟล์ โดยให้สิทธิ์เข้าถึงเฉพาะโฟลเดอร์ที่จำเป็น และลบหรือระงับสิทธิ์หลังเสร็จงาน นอกจากนี้ควรจำกัดการเข้าถึง SSH เฉพาะ IP ที่เชื่อถือได้ ใช้ firewall, Fail2ban และอัปเดต OpenSSH เป็นเวอร์ชันล่าสุด

ถ้าย้ายไฟล์ที่มีข้อมูลส่วนบุคคล, ฐานข้อมูล หรือเอกสารลูกค้า ควรลบไฟล์ชั่วคราวที่ไม่จำเป็นออกหลังส่งเสร็จ และอย่าทิ้งไฟล์สำรอง เช่น .sql, .zip, .tar ไว้ในโฟลเดอร์ที่เว็บเข้าถึงได้ เพราะเสี่ยงถูกโจมตี ไฟล์เหล่านี้ควรเก็บในโฟลเดอร์ที่ไม่ถูกเปิดเผย หรือถ้าไม่จำเป็นให้ลบทิ้ง

การใช้ rsync เพื่อแบ็กอัปอัตโนมัติ

rsync ไม่ได้ใช้แค่ในครั้งเดียว แต่สามารถตั้งค่าให้แบ็กอัปไฟล์เป็นประจำ เช่น ตั้ง cron job ให้ส่งโฟลเดอร์สำคัญไปยังเซิร์ฟเวอร์แบ็กอัปทุกคืน โดยใช้ SSH คีย์เพื่อเข้าสู่ระบบแบบไม่มีรหัสผ่านแต่ปลอดภัย และส่งเฉพาะไฟล์ที่เปลี่ยนแปลง พร้อมกำหนดแบนด์วิดท์จำกัดได้

ตัวอย่างคำสั่งแบ็กอัป:

rsync -a --delete --bwlimit=30000 /var/www/site/ backup@backup-ip:/backup/site/

ต้องระวังเมื่อใช้ --delete เพราะถ้าไฟล์ต้นทางถูกลบ ไฟล์ในปลายทางก็จะถูกลบตาม การตั้งค่าระบบแบ็กอัปที่ดีควรรวม snapshot, แยกโฟลเดอร์รายวัน หรือระบบ versioning เพื่อป้องกันการสูญหายของข้อมูล

สำหรับการจัดการแบ็กอัปในโครงสร้างโฮสติ้ง แนะนำตามกฎ 3-2-1 คือเก็บข้อมูลอย่างน้อย 3 ชุดใน 2 สื่อที่แตกต่างกัน และ 1 ชุดอยู่นอกสถานที่ rsync ช่วยให้การคัดลอกระหว่างเซิร์ฟเวอร์สะดวกขึ้น สำหรับคำแนะนำเพิ่มเติมดูได้ที่ โซลูชันการสำรองข้อมูล และ บริการโฮสติ้งธุรกิจ

รายการตรวจสอบก่อนเริ่มย้ายไฟล์

ก่อนเริ่มย้ายไฟล์ขนาดใหญ่ ควรเช็คตามรายการต่อไปนี้เพื่อลดความเสี่ยงข้อผิดพลาด โดยเฉพาะในสภาพแวดล้อมจริง

• ติดตั้ง rsync บนเซิร์ฟเวอร์ต้นทางและปลายทางหรือไม่?
• ทดสอบเชื่อมต่อ SSH ด้วยผู้ใช้และพอร์ตที่ถูกต้องแล้วหรือยัง?
• มีพื้นที่ว่างเพียงพอบนเซิร์ฟเวอร์ปลายทางหรือไม่?
• รันคำสั่ง rsync ด้วย --dry-run เพื่อตรวจสอบก่อนหรือยัง?
• วางแผนโหมดบำรุงรักษาและซิงค์ไฟล์รอบสุดท้ายสำหรับเว็บไซต์ที่เปิดใช้งานอยู่หรือยัง?
• ถ้าใช้ --delete ตรวจสอบเส้นทางปลายทางอย่างละเอียดหรือยัง?
• วางแผนตรวจสอบขนาดไฟล์, สิทธิ์ และทดสอบแอปพลิเคชันหลังย้ายหรือยัง?
• เตรียมลบไฟล์แบ็กอัปชั่วคราวและไฟล์ dump อย่างปลอดภัยหรือยัง?

รายการนี้ดูง่ายแต่ช่วยป้องกันปัญหายอดนิยม เช่น กำหนดเส้นทางผิด, สิทธิ์ไม่ครบ, พื้นที่ไม่พอ และการเปลี่ยน DNS แบบไม่รัดกุม การวางแผนดีช่วยลดเวลาย้ายและเพิ่มโอกาสกลับสถานะเดิมได้หากเกิดปัญหา

คำถามที่พบบ่อย

ถ้าเชื่อมต่อ SSH ระหว่าง rsync ขาดกลางทาง จะต้องเริ่มส่งใหม่ทั้งหมดไหม?

ไม่จำเป็น หากใช้พารามิเตอร์ --partial และ --append-verify จะช่วยเก็บไฟล์ที่ส่งไม่เสร็จและยืนยันความถูกต้องตอนต่อเนื่อง ทำให้ rsync ทำงานต่อจากจุดที่ค้างได้ แต่อย่างไรก็ตาม ควรตรวจสอบพื้นที่ดิสก์และสถานะไฟล์ก่อนเริ่มใหม่ โดยเฉพาะในงานย้ายข้อมูลสำคัญ

rsync สามารถย้ายฐานข้อมูลโดยตรงได้ไหม?

rsync ส่งไฟล์เท่านั้น ไม่แนะนำให้คัดลอกไฟล์ฐานข้อมูลที่กำลังทำงานอยู่โดยตรง ควรใช้ mysqldump หรือเครื่องมือแบ็กอัปฐานข้อมูลอื่นเพื่อสร้างไฟล์สำรอง จากนั้นจึงใช้ rsync ส่งไฟล์เหล่านั้นไปยังเซิร์ฟเวอร์ปลายทาง ในกรณีระบบใช้งานจริง ควรวางแผนโหมดบำรุงรักษาหรือใช้ระบบ replication เพื่อความสมบูรณ์ของข้อมูล

ต้องมีสิทธิ์ root ทั้งสองเซิร์ฟเวอร์ไหมถึงจะใช้ rsync ได้?

ไม่จำเป็น ต้องมีสิทธิ์เขียนในโฟลเดอร์เป้าหมายก็พอแล้ว แต่ถ้าต้องการรักษาเจ้าของไฟล์, ระบบ ACL หรือสิทธิ์พิเศษอื่น ๆ อาจต้องสิทธิ์สูงกว่านั้น แนะนำให้ใช้ผู้ใช้ที่มีสิทธิ์จำกัดเพื่อความปลอดภัย

พารามิเตอร์ --delete ปลอดภัยไหม?

ถ้าใช้ถูกต้อง --delete จะลบไฟล์ที่ไม่มีในต้นทางออกจากปลายทาง ทำให้สองฝั่งเหมือนกันเป๊ะ แต่ถ้าระบุผิดพาธอาจลบไฟล์สำคัญได้ ดังนั้นควรทดสอบด้วย --dry-run ก่อนทุกครั้ง และตรวจสอบเส้นทางให้ชัดเจน

ถ่ายโอนไฟล์ใหญ่ ควรใช้ rsync หรือ scp ดีกว่า?

ถ้าคัดลอกครั้งเดียวไฟล์จำนวนน้อย scp อาจเพียงพอ แต่ถ้าเป็นไฟล์ใหญ่ ไฟล์จำนวนมาก หรือทำซ้ำหลายครั้ง rsync จะดีกว่า เพราะส่งเฉพาะส่วนที่เปลี่ยน, รองรับการต่อเนื่อง และจำกัดแบนด์วิดท์ได้ รวมถึงโหมดทดสอบ

สรุปและขั้นตอนถัดไป

การใช้ rsync ผ่าน SSH เพื่อย้ายไฟล์ขนาดใหญ่ออกจากเซิร์ฟเวอร์สองเครื่อง เป็นวิธีที่รวดเร็ว, ปลอดภัย และควบคุมง่าย ช่วยเพิ่มความทนทานต่อการขาดการเชื่อมต่อ ส่งเฉพาะไฟล์ที่เปลี่ยนแปลง ลดเวลาการหยุดทำงานของเว็บไซต์ แนะนำให้ตรวจสอบ SSH และพื้นที่ดิสก์ก่อน, ทดสอบด้วย --dry-run และวางแผนถ่ายโอนอย่างรัดกุม

หากคุณกำลังวางแผนเปลี่ยนเซิร์ฟเวอร์, ใช้พื้นที่เก็บข้อมูลขนาดใหญ่ หรือระบบโฮสติ้งที่มีประสิทธิภาพสูงขึ้น สามารถศึกษาผลิตภัณฑ์ของ Hostragons พร้อมบริการ VPS, โฮสติ้ง, โดเมน และ SSL เพื่อความปลอดภัยในการย้ายข้อมูล เริ่มจากทดสอบเล็ก ๆ วัดผล แล้วจึงซิงค์ไฟล์รอบสุดท้ายอย่างมีแผนเพื่อความราบรื่นของระบบ