rsync ผ่าน VPN: ฝั่งไหนคือแหล่งความจริง?

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

ตัดสินใจว่าสำเนาใดชนะก่อนพิมพ์คำสั่ง

เขียนทิศทางเป็นประโยคเดียว รวมชื่อโฮสต์และพาธในแต่ละฝั่ง และให้เจ้าของข้อมูลอนุมัติ ในคำแนะนำนี้ต้นทางคือ /srv/publish/ และปลายทางคือบัญชีบน fileserver.example ที่ได้รับอนุญาตให้เขียนได้เฉพาะใน /srv/mirror/

ยืนยันข้อเท็จจริงของการรับส่งก่อนคัดลอก: คีย์โฮสต์ SSH ได้รับการตรวจสอบแล้ว บัญชีปลายทางเขียนได้ในพื้นที่สำเนาและที่อื่นไม่ได้ และทั้งสองโฮสต์มี rsync เวอร์ชันที่เข้ากันได้ เงื่อนไขเบื้องต้นเหล่านี้ป้องกันไม่ให้ข้อผิดพลาดในการวางแผนเล็กน้อยกลายเป็นเหตุการณ์ด้านสิทธิ์ และยังบอกด้วยว่าบัญชีใดจะปรากฏในบันทึกของปลายทางเมื่อมีสิ่งผิดพลาด

ดูตัวอย่างการคัดลอกและอ่านรายการโดยละเอียด

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

rsync -rt --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

เครื่องหมายทับท้ายสำคัญ ฝั่งต้นทางหมายถึงเนื้อหาของไดเรกทอรีนั้น ส่วนการละไว้จะเพิ่มระดับไดเรกทอรีอีกชั้นตามชื่อต้นทาง คู่มือ rsync อธิบายทั้งสองรูปแบบพร้อมธงการเก็บรักษาเมทาดาทา และชุดตัวเลือกที่คุณต้องการขึ้นอยู่กับข้อมูลไม่ใช่ความเคยชิน

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

จากนั้นตัดสินใจว่าการลบจะเดินทางหรือไม่

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

rsync -rt --delete --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

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

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

งานทางเดียวสองงานไม่ได้ทำให้เกิดการซิงก์สองทาง

การรันคำสั่งเดียวกันทั้งสองทิศทางเป็นวิธีที่พบบ่อยที่สุดในการทำข้อมูลหายในสถานการณ์นี้ แต่ละทิศทางถืออีกฝั่งเป็นปลายทางและเขียนทับเนื้อหาใหม่กว่าอย่างมีความสุข และการลบจะถูกสะท้อนตามลำดับที่ตารางเวลาทำงาน

หากผู้ใช้ต้องแก้ไขทั้งสองสำเนา นั่นคือการตัดสินใจเชิงผลิตภัณฑ์อีกเรื่อง: การจัดการความขัดแย้ง การติดตามการลบ และเครื่องมือที่ออกแบบสำหรับโมเดลนั้น การประมาณด้วยลำดับตารางเวลาเป็นวิธีที่โฟลเดอร์ร่วมลงเอยด้วยเอกสารแต่ละฉบับสองเวอร์ชันที่ไม่มีใครกระทบยอดได้ ควรตัดสินใจอย่างชัดเจนแทนการประมาณด้วยรายการ cron สองรายการและความหวัง

ทำระบบอัตโนมัติหลังจากเขียนนโยบายแล้วเท่านั้น

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

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

บันทึกการเสร็จสิ้นและความล้มเหลว และตรวจสอบชุดข้อมูลที่ปลายทางไม่ใช่แค่รหัสออก การกู้คืน VPN หลังเหตุขัดข้องกู้คืนการเชื่อมต่อ แต่ไม่ได้บอกว่าสำเนาสุดท้ายเสร็จหรือไม่ หรือการแก้ไขที่ขัดแย้งกันได้รับการแก้ไขหรือไม่