การสำรองข้อมูลบนคลาวด์ช้าผ่าน VPN: หาเฟสที่แท้จริง
การสำรองข้อมูลที่ช้าอาจกำลังสแกน แฮช หรือลองใหม่แทนการถ่ายโอน เปรียบเทียบเฟส ชนิดปลายทาง และการกู้คืนก่อนเปลี่ยนเส้นทาง
การสำรองข้อมูลที่คลานผ่าน VPN ชวนให้ทำการทดลองที่เห็นได้ชัดคือตัดอุโมงค์แล้ววัดใหม่ การทดลองนั้นมักตอบคำถามอีกข้อ เพราะงานอาจกำลังแฮชไฟล์หรือรอการลองใหม่แทนที่จะย้ายไบต์ แยกเฟสก่อน แล้วข้อร้องเรียนจะกลายเป็นการทดสอบเฉพาะที่มีผลลัพธ์คาดหวังเฉพาะ เส้นทางจะกลายเป็นตัวเลือกก็ต่อเมื่อเฟสการถ่ายโอนคือเฟสที่ช้าจริง ๆ
งานอยู่เฟสไหนเมื่อรู้สึกช้า
เครื่องมือสำรองข้อมูลผ่านเฟสต่าง ๆ ได้แก่ การค้นหาไฟล์ การอ่านและแฮชไฟล์ การบีบอัด การเข้ารหัส การอัปโหลด แล้วจึงตรวจสอบ แต่ละเฟสมีคอขวดของตัวเอง และมีเพียงบางเฟสเท่านั้นที่แตะเครือข่าย เครื่องมือที่ยังไม่รายงานเฟสใด ๆ กำลังบอกคุณว่ายังสแกนไม่เสร็จ
งานที่ใช้เวลายี่สิบนาทีเตรียมไฟล์เล็กหนึ่งล้านไฟล์จะไม่เร็วขึ้นเมื่ออุโมงค์เร็วขึ้น งานที่อิ่มตัวลิงก์อัปโหลดคือปัญหาความจุที่มีวิธีแก้ต่างกัน อ่านเอาต์พุตความคืบหน้าขณะเกิดความล่าช้า บันทึกเฟสและเวลาไว้ เพราะเฟส ณ เวลาที่ร้องเรียนคือเฟสเดียวที่สำคัญ ไฟล์เล็กยังทำงานต่างจากวัตถุขนาดใหญ่หนึ่งชิ้น เพราะการไปกลับต่อไฟล์เป็นตัวหลักและการถ่ายโอนไม่เคยถึงอัตราที่คงที่ เปรียบเทียบสิ่งที่เทียบกันได้ก่อนสรุปเกี่ยวกับอุโมงค์
ปลายทางสาธารณะและ NAS ส่วนตัวล้มเหลวต่างกัน
บริการสำรองข้อมูลสาธารณะมีการเชื่อมต่อแอปพลิเคชันที่ผ่านการรับรองของตัวเอง และอุโมงค์เป็นเพียงหนึ่งช่วงบนเส้นทางที่ยาวกว่า NAS ส่วนตัวมักพึ่งพาอุโมงค์นั้นเพื่อการเข้าถึงเครือข่ายของคุณ ความแตกต่างนี้ตัดสินว่าการตัดการเชื่อมต่อเป็นเส้นฐานที่ใช้ได้หรือเป็นการทดสอบที่ไม่มีความหมาย
ในกรณีสาธารณะ งานเดียวกันผ่านเส้นทางอื่นอาจเป็นการเปรียบเทียบที่ยุติธรรมเมื่อนโยบายอนุญาต ในกรณีส่วนตัว การถอดอุโมงค์ออกไม่เหลือเส้นทางไปยังเซิร์ฟเวอร์เลย ผลลัพธ์จึงอธิบายเส้นทางที่คุณลบไป ไม่ใช่เส้นทางที่คุณใช้
| Destination | What the tunnel provides | Valid baseline |
|---|---|---|
| Public backup service | One hop among several | The same job over another route |
| Private NAS | The only path to the server | None that removes the tunnel |
| Self-hosted gateway | Path plus split-DNS policy | Only if the policy is unchanged |
การหยุดชะงักเป็นความล้มเหลวคนละแบบกับการถ่ายโอนที่ช้า
คอลัมน์ที่สามของตารางนั้นตัดสินว่าการทดสอบความเสถียรทำได้หรือไม่ เพราะเส้นฐานที่ถอดอุโมงค์ออกมีความหมายเฉพาะที่ที่มีเส้นทางอื่นอยู่ ด้วยเส้นฐานที่ใช้งานได้ ให้ดูรูปร่างของความล้มเหลวไม่ใช่อัตราเฉลี่ย การอัปโหลดต่ำแต่สม่ำเสมอชี้ไปที่ความจุ ขณะที่งานที่หยุดแล้วเริ่มใหม่ชี้ไปที่การขัดจังหวะ การรับรองความถูกต้อง หรือไฟล์ที่มีปัญหาหนึ่งไฟล์ สองอย่างนี้สร้างข้อร้องเรียนเกือบเหมือนกันและการซ่อมที่ต่างกันโดยสิ้นเชิง
การลองใหม่บิดเบือนการวัดทุกครั้ง เพราะไบต์บนสายอาจมากกว่าปริมาณที่เปลี่ยนจริง อ่านพฤติกรรมการดำเนินต่อก่อนจะขัดจังหวะงานอีกครั้งเพื่อดูว่าเกิดอะไรขึ้น เพราะการอัปโหลดแบบแบ่งส่วนที่ดำเนินต่อได้ฟื้นตัวได้ถูกกว่า และการเริ่มไฟล์ทั้งหมดใหม่ไม่เป็นเช่นนั้น อุโมงค์ที่เชื่อมต่อใหม่ทุกไม่กี่นาทีก็ดูเหมือนปัญหาแบนด์วิดท์เมื่อจริง ๆ เป็นปัญหาความเสถียร MTU ของเส้นทางยิ่งทำให้หนักขึ้น เพราะอุโมงค์ที่ลดเพย์โหลดที่ใช้ได้จะหยุดเซกเมนต์ขนาดใหญ่ในขณะที่ขนาดเล็กผ่านไป
journalctl -u wg-quick@wg0 -n 50 --no-pager
ss -tin dst :443
ping -M do -s 1400 -c 3 backup.example.comการอัปโหลดครั้งเดียวสามารถทำให้ทุกโฟลว์อื่นอดอาหาร
การอัปโหลดที่เติมลิงก์อัปโหลดทำให้การโทรและการท่องเว็บไม่ตอบสนอง และการสำรองข้อมูลไม่ค่อยเป็นสิ่งเดียวที่แย่งชิงมัน ไคลเอนต์ซิงก์ตัวที่สองสร้างอาการเดียวกันได้เอง ก่อนตำหนิอุโมงค์ ให้ดูว่ามีอะไรอัปโหลดอยู่อีก
ใช้ตารางเวลาหรือขีดจำกัดแบนด์วิดท์ที่เครื่องมือบันทึกไว้แทนการต่อสู้เพื่อทรูพุตสูงสุด การเหลือที่ว่างสำหรับงานโต้ตอบมักมีค่ามากกว่าสองสามเปอร์เซ็นต์สุดท้าย จากนั้นตรวจสอบว่าขีดจำกัดใช้กับอะไรจริง ๆ เพราะเครื่องมือบางตัวจำกัดต่อไฟล์ บางตัวจำกัดทั้งรอบการทำงาน และบางตัวเพิกเฉยต่อค่าใช้จ่ายของไฟล์เล็กโดยสิ้นเชิง ขีดจำกัดที่ไม่ตรงกับภาระงานไม่เปลี่ยนอะไร การแยกอุโมงค์ก็ควรถูกสงสัยตรงนี้ด้วย เพราะการยกเว้นตัวเรียกใช้ออกจากอุโมงค์ไม่ได้ยกเว้นบริการช่วยเหลือที่ทำการอัปโหลด ตัวอย่างเช่น Rclone เผยแพร่ทั้งขีดจำกัดการถ่ายโอนและพฤติกรรมการลองใหม่ในเอกสารของตน ซึ่งทำให้เป็นแหล่งอ้างอิงที่มีประโยชน์ว่าขีดจำกัดควรควบคุมอะไร
จบด้วยการกู้คืน ไม่ใช่การทดสอบความเร็ว
การอัปโหลดที่เสร็จสิ้นยังไม่ใช่การสำรองข้อมูลจนกว่าจะมีอะไรกู้คืนจากมันได้ ยืนยันว่ามีเวอร์ชันที่คาดหวังอยู่ แล้วกู้คืนไฟล์ตัวแทนด้วยขั้นตอนที่เครื่องมือบันทึกไว้ เก็บข้อมูลการกู้คืนไว้อีกที่หนึ่งแทนที่จะเก็บไว้ในเครื่องหรือโปรไฟล์ที่คุณอาจสูญเสีย และอย่าทิ้งการสำรองข้อมูลที่ใช้งานได้เพียงเพื่อให้การทดลองเรียบร้อย
restic snapshots --latest 3
restic restore latest --target /tmp/restore-check --include /etc/hostsทำซ้ำทั้งการถ่ายโอนและการกู้คืนหลังการเปลี่ยนแปลงเครือข่าย เพื่อให้เห็นว่าการปรับปรุงนั้นรับใช้การสำรองข้อมูล ไม่ใช่แค่ย้ายข้อมูลเร็วขึ้น การรันครั้งที่สองคือสิ่งที่ปิดตั๋ว การถ่ายโอนที่เร็วขึ้นพร้อมการกู้คืนที่ยังไม่ทดสอบคือวิธีที่ช้ากว่าในการไม่มีการป้องกัน