Large migrations · Verification · Bằng chứng đằng sau thanh tiến trình

Di chuyển hàng trăm GB giữa các đám mây: Làm sao bạn biết mọi tệp đã đến?

Ở mức 500 GB, “quá trình tải lên đã hoàn tất” không phải là bằng chứng. Quá trình di chuyển đáng tin cậy cần có kho dữ liệu lâu bền, quá trình chuyển đổi trạng thái cho mọi đối tượng, quá trình khôi phục có thể lặp lại sau khi bị gián đoạn và bằng chứng từ chính đích đến.

Cập nhật ; 16 phút đọc.

Câu trả lời ngắn gọn

FileArk chia thư viện thành các bản ghi trên mỗi tệp và các thông báo xếp hàng lâu dài. Một nhân viên sao chép một lần phân phối, lưu trữ ID đích được trả về, xác thực kích thước, đọc lại đối tượng chính xác đó và so sánh SHA-256 với tải trọng nguồn. Bản ghi sẽ được xác minh—và thông báo được xác nhận—chỉ sau khi những lần kiểm tra đó và cập nhật cơ sở dữ liệu thành công.

Tại sao quy mô lại thay đổi ý nghĩa của “đã hoạt động”

Mười tập tin rất dễ kiểm tra. Mười nghìn tập tin thì không. Một thư viện cá nhân lớn có thể kết hợp các tài liệu nhỏ, video nhiều gigabyte, tệp trống, thư mục lồng nhau, tên Unicode, dự án lưu trữ và định dạng gốc trên nền tảng đám mây. Một thất bại có thể ẩn giấu bên trong một tỷ lệ phần trăm ấn tượng.

Tổng số là hữu ích nhưng không đầy đủ. Hai thư viện có thể hiển thị cùng một kích thước rõ ràng trong khi một thư viện thiếu một đối tượng hoặc chứa một đối tượng bị cắt bớt được cân bằng bởi một số tệp không liên quan. Số lượng tệp cũng có thể khác nhau sau khi xuất tài liệu gốc hoặc đối tượng nhà cung cấp bị loại trừ.

Đơn vị hữu ích của sự thật là tác vụ tệp: đối tượng nguồn nào đã được đọc, đối tượng đích nào đã được tạo, byte nào được so sánh, thời điểm xác minh hoàn tất và liệu mọi nỗ lực có còn chưa được giải quyết hay không.

Vòng đời đầy đủ của FileArk, có chú thích

Vòng đời được chú thích hiển thị cơ sở dữ liệu quét thiết lập trình duyệt FileArk, trình xử lý hàng đợi bền vững và xác minh SHA-256
Trình duyệt bắt đầu luồng điều khiển; máy quét, hàng đợi liên tục, cơ sở dữ liệu và nhân viên thực hiện quá trình di chuyển kéo dài.

Khi Bắt đầu được chấp nhận, trước tiên API sẽ ghi lệnh quét vào MongoDB, sau đó xuất bản thông báo quét liên tục lên hàng đợi RabbitMQ bền vững đã bật xác nhận của nhà xuất bản. Nếu xuất bản không thành công, công việc sẽ được đánh dấu là Không thành công và API báo cáo rằng công việc đó không thể xếp hàng quét một cách an toàn.

Máy quét xác thực cả hai nhà cung cấp, kiểm kê nguồn đã chọn, kiểm tra hạn ngạch đích hữu hạn đối với các byte được phát hiện và nâng cấp bản ghi cơ sở dữ liệu cho mỗi tệp nguồn. Nó xuất bản các thông báo di chuyển liên tục và chỉ đánh dấu quá trình quét hoàn tất sau khi những lần xuất bản đó thành công.

Nhân viên di chuyển sử dụng xác nhận thủ công và số lần tìm nạp trước là một. Việc gửi vẫn không được xác nhận trong khi nội dung được đọc, tải lên, đọc lại, xác minh và lưu giữ. Do đó, một kết nối hoặc quá trình bị dừng có thể trả lại công việc chưa hoàn thành cho hàng đợi.

Hàng cơ sở dữ liệu là một mục trong danh sách kiểm tra, không phải là sổ sách kế toán dùng một lần

Mọi bản ghi tệp bắt đầu Đang chờ xử lý, chuyển sang InProgress trong khi thử và chỉ đạt đến Đã tải lên sau khi xác minh. Số lần thử, thời gian thử lần cuối, chi tiết lỗi, ID đối tượng đích, cả thông báo SHA-256, phương pháp xác minh và VerifyAt vẫn được đính kèm vào bản ghi.

Các hồ sơ đã hoàn thành sẽ nằm trong cơ sở dữ liệu dưới dạng tiến trình và quá trình kiểm tra. “Xóa một tập tin” có nghĩa là thay đổi trạng thái được kiểm soát, không xóa bằng chứng. Việc gửi hàng đợi trùng lặp sẽ kiểm tra trạng thái đó và ngay lập tức xác nhận bản ghi đã được đánh dấu Đã tải lên bằng Đã xác minh.

Sau ba lần thử không thành công, một sự cố dai dẳng sẽ trở thành Thất bại kèm theo dấu thời gian hoàn thành cho chu kỳ thử. Điều này làm cho các ngoại lệ hiển thị và ngăn thông báo độc hại quay mãi trong khi bảng thông tin bị kẹt.

Cổng hoàn thành cho một tập tin
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

Tại sao một tệp có thể được gửi nhiều lần

Hàng đợi đáng tin cậy thường cung cấp khả năng phân phối ít nhất một lần, không phải là lời hứa kỳ diệu chính xác một lần trên API đám mây, nhà môi giới tin nhắn và cơ sở dữ liệu. Sự cố có thể xảy ra sau khi OneDrive hoặc Google Drive chấp nhận tải lên nhưng trước khi nhân viên viết xong.

FileArk xử lý sự không chắc chắn đó bằng các bản ghi bình thường và khôi phục đích. Đầu tiên, nhân viên kiểm tra xem hồ sơ đã được xác minh chưa. Nếu không, nó có thể sử dụng ID đích được lưu trữ hoặc tìm kiếm đường dẫn đích dự kiến ​​và kích thước chính xác cho kết quả bị gián đoạn trước khi quyết định tải lên lại.

Các ứng cử viên khôi phục sau đó phải chịu sự xác minh băm đối tượng chính xác tương tự. Tìm một tên tập tin quen thuộc là chưa đủ. Mục đích là biến nỗ lực bị gián đoạn trở lại thành bằng chứng chứ không phải thành công lạc quan.

Năng lực được kiểm tra tại nơi đến và trên người lao động

Trước khi công việc trên mỗi tệp được xuất bản, máy quét sẽ tính tổng kích thước siêu dữ liệu nguồn không âm và so sánh yêu cầu với dung lượng lưu trữ còn lại được báo cáo của đích bất cứ khi nào nhà cung cấp cung cấp hạn ngạch hữu hạn. Một đích đến có kích thước nhỏ không thể quét được thay vì đưa công việc vào ngõ cụt đã biết.

Con số này chỉ là ước tính trước, không phải là sự đảm bảo: hoạt động của tài khoản có thể tiêu tốn dung lượng trong quá trình chạy, báo cáo hạn ngạch của nhà cung cấp có thể bị trễ và các tệp gốc trên nền tảng đám mây được xuất có thể không có kích thước nguồn thông thường. Việc thực thi của nhà cung cấp và xử lý lỗi trên mỗi tệp vẫn hoạt động.

Đĩa máy tính của bạn không được sử dụng để dàn dựng. Trên trình di chuyển, các tệp trên ngưỡng bộ nhớ chỉ được đặt trong một thư mục tạm thời biệt lập sau khi ổ đĩa có đủ chỗ cho đối tượng dự kiến ​​cộng với mức dự trữ hai gigabyte. Nội dung tạm thời sẽ bị xóa trong quá trình dọn dẹp cho dù nỗ lực thành công hay thất bại.

Tại sao ID đích cộng với SHA-256 lại quan trọng

Tên tập tin không phải là một danh tính duy nhất. Đích có thể đã chứa hai tệp có cùng tên hiển thị hoặc danh sách siêu dữ liệu có thể mất thời gian để giải quyết. Phản hồi tải lên cung cấp ID đối tượng nhà cung cấp và FileArk lưu trữ ID đó trước giai đoạn xác minh cuối cùng.

Nhân viên tính toán SHA-256 trên luồng tải trọng nguồn, tải nó lên, sau đó mở đối tượng đích chính xác theo ID đó và tính toán lại SHA-256. Kích thước bằng nhau bắt được sự cắt cụt rõ ràng; thông báo mật mã bằng nhau là kiểm tra mức byte mạnh hơn.

Chỉ có đại diện tập tin được chuyển được bảo hiểm. Thông báo không thể xác thực các quy tắc chia sẻ, nhận xét, phiên bản, nhãn, lối tắt, cài đặt lưu giữ hoặc cách tài liệu Google đã xuất hiển thị cho người dùng. Những nhiệm vụ đó vẫn được chấp nhận.

Việc xóa nguồn là cố ý nằm ngoài con đường thành công thông thường

Mặc định an toàn nhất là chỉ sao chép và tùy chọn xóa của FileArk sẽ tắt trừ khi bạn bật nó. Khi tính năng xóa bị vô hiệu hóa, việc xác minh không thành công sẽ không thể xóa bản gốc vì việc xóa không bao giờ được yêu cầu.

Nếu bạn cố tình bật tính năng xóa sau khi di chuyển, nhân viên vẫn chờ ID đích, kích thước và xác thực SHA-256 trước khi gọi thao tác xóa của nhà cung cấp nguồn. Lựa chọn vận hành mạnh mẽ hơn đối với các thư viện không thể thay thế hoặc thư viện rất lớn vẫn là tắt tùy chọn này và sử dụng khoảng thời gian chồng chéo được con người phê duyệt.

Câu trả lời di chuyển “bản sao đã được xác minh có đến không?” Câu trả lời duy trì “khi nào bản cũ có thể bị xóa?” Hãy coi chúng như những quyết định riêng biệt với bằng chứng riêng biệt.

Mô hình điều khiển giống nhau hoạt động theo cả hai hướng

Đối với OneDrive to Google Drive, tải trọng nguồn được đọc từ Microsoft Graph và đối tượng đích được xác minh thông qua Google Drive bằng ID được trả về. Đối với Google Drive sang OneDrive, nguồn được tải xuống hoặc xuất thông qua Google Drive và mục OneDrive mới được đọc lại thông qua Microsoft Graph.

Hàng đợi, trạng thái cơ sở dữ liệu, số lần thử bị giới hạn, ánh sáng trước dung lượng, thông báo nguồn, ID đích, thông báo đích và thứ tự xác nhận là trung lập về hướng. Bộ điều hợp nhà cung cấp xử lý các API tải lên, thư mục và nội dung khác nhau.

Sự bất đối xứng là ngữ nghĩa nội dung. Các tài liệu gốc của Google cần xuất và cả hai nền tảng đều có hành vi phiên bản và chia sẻ dành riêng cho từng dịch vụ. Nội dung tệp đã được xác minh theo byte không được tiếp thị dưới dạng bản sao hoàn chỉnh của mọi tính năng cộng tác.

Sử dụng kế hoạch chấp nhận gồm bốn phần

  1. Đối chiếu hồ sơ hệ thống

    Xem xét số lượng đã hoàn thành, đang chờ xử lý, đang tiến hành và không thành công. Không có mục nào bị lỗi nên bị loại bỏ vì tỷ lệ phần trăm tổng thể cao.

  2. Lấy mẫu theo rủi ro

    Mở các tệp có thể bị mất nhiều nhất, cùng với phương tiện lớn, kho lưu trữ, tài liệu cũ, tên không phải tiếng Anh, đường dẫn lồng nhau và tệp gốc được chuyển đổi trên đám mây.

  3. Xác thực hành vi đích

    Kiểm tra quyền truy cập từ các thiết bị và người dùng thực. Xây dựng lại yêu cầu chia sẻ và xác nhận rằng các tệp Office hoặc Google đã xuất sẽ mở như mong đợi.

  4. Giữ một khoảng thời gian chồng chéo

    Giữ nguồn có sẵn và ổn định trong khi sử dụng bình thường sẽ thực hiện được đích. Đưa ra bất kỳ quyết định hủy hoặc xóa nào sau đó.

Câu hỏi thường gặp

FileArk có sử dụng hàng đợi cho mọi tệp không?

Vâng. Máy quét tạo hoặc sử dụng lại bản ghi cơ sở dữ liệu cho mỗi tệp nguồn và xuất bản thông báo di chuyển liên tục. Công nhân lấy những tin nhắn đó với sự xác nhận thủ công.

Khi nào một tin nhắn hàng đợi được xác nhận?

Sau khi ID, kích thước và SHA-256 của đối tượng đích đã được xác minh, đồng thời trạng thái Đã tải lên và Đã xác minh vẫn được duy trì. Những đơn hàng chưa hoàn thành có thể được giao lại.

Các bản ghi tệp đã hoàn thành có bị xóa khỏi cơ sở dữ liệu không?

Không. Hoàn thành là sự chuyển đổi trạng thái trên bản ghi lâu dài. Hàng này lưu giữ thông tin nhận dạng điểm đến, bằng chứng xác minh, thời gian và nỗ lực cho tiến trình và kiểm tra.

SHA-256 có thể chứng minh quyền và phiên bản đã được di chuyển không?

Không. Nó chứng minh byte của tệp đích khớp với tải trọng nguồn được truyền. Chia sẻ, quyền, phiên bản, nhận xét, nhãn, lối tắt và hành vi gốc của nhà cung cấp cần xác thực riêng.

OneDrive to Google Drive có được xác minh theo cách tương tự như ngược lại không?

Quy tắc cốt lõi giống nhau theo cả hai hướng: thông báo tải trọng nguồn, nhận dạng đối tượng đích, kích thước đích, thông báo tải lại đối tượng chính xác, xác minh liên tục, sau đó xác nhận hàng đợi.

Các tài nguyên chính thức được sử dụng cho hướng dẫn này

Đọc hướng dẫn