Large migrations · Verification · หลักฐานเบื้องหลังแถบความคืบหน้า

การย้ายหลายร้อย GB ระหว่างคลาวด์: คุณจะรู้ได้อย่างไรว่าทุกไฟล์มาถึง?

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

อัปเดตเมื่อ ; 16 นาทีในการอ่าน.

คำตอบสั้น ๆ

FileArk แบ่งไลบรารีออกเป็นบันทึกต่อไฟล์และข้อความคิวที่คงทน พนักงานคัดลอกการจัดส่งหนึ่งครั้ง เก็บ ID ปลายทางที่ส่งคืน ตรวจสอบขนาด อ่านออบเจ็กต์นั้นกลับ และเปรียบเทียบ SHA-256 กับเพย์โหลดต้นทาง บันทึกจะได้รับการตรวจสอบและยอมรับข้อความหลังจากการตรวจสอบและการอัพเดตฐานข้อมูลสำเร็จเท่านั้น

เหตุใดมาตราส่วนจึงเปลี่ยนความหมายของคำว่า "ทำงาน"

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

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

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

วงจรการใช้งาน FileArk แบบเต็ม มีคำอธิบายประกอบ

วงจรการใช้งานที่มีคำอธิบายประกอบแสดงฐานข้อมูลสแกนเนอร์การตั้งค่าเบราว์เซอร์ FileArk ผู้ปฏิบัติงานคิวที่ทนทานและการตรวจสอบ SHA-256
เบราว์เซอร์เริ่มโฟลว์การควบคุม เครื่องสแกน คิวถาวร ฐานข้อมูล และผู้ปฏิบัติงานดำเนินการโอนย้ายระยะยาว

เมื่อยอมรับการเริ่ม API จะเขียนงานสแกนไปที่ MongoDB ก่อน จากนั้นจึงเผยแพร่ข้อความสแกนแบบถาวรไปยังคิว RabbitMQ ที่ทนทานโดยเปิดใช้งานการยืนยันจากผู้เผยแพร่ หากการเผยแพร่ล้มเหลว งานจะถูกทำเครื่องหมายว่าล้มเหลว และ API จะรายงานว่าไม่สามารถจัดคิวการสแกนได้อย่างปลอดภัย

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

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

แถวฐานข้อมูลเป็นรายการตรวจสอบ ไม่ใช่การทำบัญชีแบบใช้แล้วทิ้ง

ทุกบันทึกไฟล์เริ่มต้นที่รอดำเนินการ ย้ายไปที่ InProgress ในระหว่างที่พยายาม และจะอัปโหลดหลังจากการตรวจสอบแล้วเท่านั้น จำนวนความพยายาม เวลาพยายามครั้งล่าสุด รายละเอียดข้อผิดพลาด ID ออบเจ็กต์ปลายทาง ทั้งการแยกย่อย SHA-256 วิธีการตรวจสอบ และ VerifiedAt ยังคงแนบอยู่กับเรกคอร์ด

บันทึกที่เสร็จสมบูรณ์จะยังคงอยู่ในฐานข้อมูลตามความคืบหน้าและเส้นทางการตรวจสอบ “การขีดฆ่าไฟล์” หมายถึง การเปลี่ยนแปลงสถานะที่ได้รับการควบคุม ไม่ใช่การลบหลักฐาน การส่งมอบคิวที่ซ้ำกันจะตรวจสอบสถานะนั้นและรับทราบบันทึกที่ทำเครื่องหมายว่าอัปโหลดด้วย VerifiedAt แล้วทันที

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

ประตูเสร็จสิ้นสำหรับไฟล์เดียว
Pending
  → InProgress (attempt recorded)
  → destination ID stored
  → destination size matches
  → exact destination object re-downloaded
  → source SHA-256 == destination SHA-256
  → Uploaded + VerifiedAt persisted
  → queue message acknowledged

เหตุใดจึงมีการส่งไฟล์มากกว่าหนึ่งครั้ง

โดยทั่วไปแล้ว คิวที่เชื่อถือได้จะให้การส่งมอบอย่างน้อยหนึ่งครั้ง ไม่ใช่สัญญาที่มหัศจรรย์เพียงครั้งเดียวทั่วทั้ง Cloud API ตัวกลางรับข้อความ และฐานข้อมูล ข้อขัดข้องอาจเกิดขึ้นได้หลังจากที่ OneDrive หรือ Google Drive ยอมรับการอัปโหลด แต่ก่อนที่ผู้ปฏิบัติงานจะเขียนเสร็จ

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

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

มีการตรวจสอบกำลังการผลิตที่ปลายทางและบนผู้ปฏิบัติงาน

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

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

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

เหตุใด ID ปลายทางบวก SHA-256 จึงมีความสำคัญ

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

ผู้ปฏิบัติงานคำนวณ SHA-256 ข้ามเพย์โหลดสตรีมต้นทาง อัปโหลด จากนั้นเปิดออบเจ็กต์ปลายทางที่แน่นอนด้วย ID นั้น และคำนวณ SHA-256 อีกครั้ง ขนาดที่เท่ากันจะจับการตัดทอนที่เห็นได้ชัด การแยกย่อยการเข้ารหัสที่เท่ากันคือการตรวจสอบระดับไบต์ที่แข็งแกร่งยิ่งขึ้น

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

การลบแหล่งที่มามีเจตนานอกเส้นทางความสำเร็จปกติ

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

หากคุณจงใจเปิดใช้งานการลบหลังจากย้าย ผู้ปฏิบัติงานยังคงรอ ID ปลายทาง ขนาด และการตรวจสอบความถูกต้อง SHA-256 ก่อนที่จะเรียกการดำเนินการลบของผู้ให้บริการต้นทาง ตัวเลือกการดำเนินงานที่แข็งแกร่งกว่าสำหรับไลบรารีที่ไม่สามารถถูกแทนที่ได้หรือไลบรารีที่มีขนาดใหญ่มากยังคงเป็นการปิดตัวเลือกและใช้ช่วงเวลาที่ทับซ้อนกันซึ่งได้รับการอนุมัติโดยมนุษย์

คำตอบการย้ายถิ่นฐาน “มีสำเนาที่ยืนยันแล้วมาถึงหรือไม่” การเก็บรักษาตอบว่า “เมื่อใดที่สำเนาเก่าจะถูกลบออก” ถือเป็นการตัดสินใจแยกกันโดยมีหลักฐานแยกกัน

รูปแบบการควบคุมเดียวกันทำงานได้ทั้งสองทิศทาง

สำหรับ OneDrive ไปยัง Google Drive เพย์โหลดต้นทางจะถูกอ่านจาก Microsoft Graph และออบเจ็กต์ปลายทางได้รับการตรวจสอบผ่าน Google Drive ด้วย ID ที่ส่งคืน สำหรับ Google Drive ไปยัง OneDrive แหล่งที่มาจะถูกดาวน์โหลดหรือส่งออกผ่าน Google Drive และรายการ OneDrive ใหม่จะถูกอ่านกลับผ่าน Microsoft Graph

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

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

ใช้แผนการยอมรับสี่ส่วน

  1. กระทบยอดบันทึกของระบบ

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

  2. ตัวอย่างตามความเสี่ยง

    เปิดไฟล์ที่อาจสร้างความเสียหายให้กับการสูญเสียมากที่สุด รวมถึงสื่อขนาดใหญ่ ไฟล์เก็บถาวร เอกสารเก่า ชื่อที่ไม่ใช่ภาษาอังกฤษ เส้นทางที่ซ้อนกัน และไฟล์ที่แปลงบนระบบคลาวด์

  3. ตรวจสอบพฤติกรรมปลายทาง

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

  4. ถือระยะเวลาที่ทับซ้อนกัน

    รักษาแหล่งที่มาให้พร้อมใช้งานและมีเสถียรภาพในขณะที่การใช้งานปกติออกกำลังกายที่ปลายทาง ตัดสินใจยกเลิกหรือลบในภายหลัง

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

FileArk ใช้คิวสำหรับทุกไฟล์หรือไม่

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

ข้อความคิวจะได้รับการยอมรับเมื่อใด

หลังจาก ID ออบเจ็กต์ปลายทาง ขนาด และ SHA-256 ได้รับการยืนยันแล้ว และสถานะ Uploaded และ VerifiedAt ยังคงอยู่ การส่งมอบที่ยังไม่เสร็จสามารถจัดส่งใหม่ได้

บันทึกไฟล์ที่เสร็จสมบูรณ์ถูกลบออกจากฐานข้อมูลหรือไม่

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

SHA-256 สามารถพิสูจน์สิทธิ์และเวอร์ชันที่ย้ายได้หรือไม่

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

OneDrive ไปยัง Google Drive ได้รับการตรวจสอบในลักษณะเดียวกับย้อนกลับหรือไม่

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

แหล่งข้อมูลอย่างเป็นทางการที่ใช้จัดทำคู่มือนี้

อ่านคู่มือ