Memindahkan Ratusan GB Antar Awan: Bagaimana Anda Mengetahui Setiap File Tiba?

Jawaban singkat

FileArk memecah perpustakaan menjadi catatan per file dan pesan antrian yang tahan lama. Seorang pekerja menyalin satu pengiriman, menyimpan ID tujuan yang dikembalikan, memvalidasi ukuran, membaca kembali objek persis tersebut, dan membandingkan SHA-256 dengan payload sumber. Catatan menjadi terverifikasi—dan pesan diakui—hanya setelah pemeriksaan tersebut dan pembaruan database berhasil.

Mengapa skala mengubah arti “berhasil”

Sepuluh file mudah diperiksa. Sepuluh ribu file tidak. Perpustakaan pribadi yang besar dapat menggabungkan dokumen kecil, video multi-gigabyte, file kosong, folder bertumpuk, nama Unicode, proyek yang diarsipkan, dan format cloud-native. Satu kegagalan dapat bersembunyi di dalam persentase yang tampak mengesankan.

Total berguna tetapi tidak lengkap. Dua perpustakaan dapat menampilkan ukuran nyata yang sama sementara yang satu kehilangan objek atau berisi objek terpotong yang diseimbangkan dengan beberapa file yang tidak terkait. Jumlah file juga dapat berbeda setelah ekspor dokumen asli atau objek penyedia yang dikecualikan.

Unit kebenaran yang berguna adalah pekerjaan file: objek sumber mana yang dibaca, objek tujuan mana yang dibuat, byte apa yang dibandingkan, kapan verifikasi selesai, dan apakah ada upaya yang belum terselesaikan.

Siklus hidup FileArk lengkap, diberi anotasi

Ketika Mulai diterima, API terlebih dahulu menulis pekerjaan pemindaian ke MongoDB dan kemudian menerbitkan pesan pemindaian persisten ke antrean RabbitMQ yang tahan lama dengan konfirmasi penerbit diaktifkan. Jika penerbitan gagal, pekerjaan ditandai Gagal dan API melaporkan bahwa pekerjaan tersebut tidak dapat mengantri pemindaian dengan aman.

Pemindai mengautentikasi kedua penyedia, menginventarisasi sumber yang dipilih, memeriksa kuota tujuan terbatas terhadap byte yang ditemukan, dan memasukkan catatan database untuk setiap file sumber. Ini menerbitkan pesan migrasi terus-menerus dan menandai pemindaian selesai hanya setelah publikasi tersebut berhasil.

Pekerja migrasi menggunakan pengakuan manual dan hitungan prefetch sebanyak satu. Pengiriman tetap tidak diakui saat konten dibaca, diunggah, dibaca ulang, diverifikasi, dan disimpan. Oleh karena itu, koneksi atau proses yang dihentikan dapat mengembalikan pekerjaan yang belum selesai ke antrian.

Baris database adalah item daftar periksa, bukan pembukuan sekali pakai

Setiap rekaman file dimulai Tertunda, berpindah ke Sedang Berlangsung selama upaya, dan mencapai Diunggah hanya setelah verifikasi. Jumlah percobaan, waktu percobaan terakhir, detail kesalahan, ID objek tujuan, intisari SHA-256, metode verifikasi, dan VerifiedAt tetap dilampirkan pada catatan.

Catatan yang telah selesai disimpan dalam database sebagai kemajuan dan jejak audit. “Mencoret file” berarti perubahan keadaan terkendali, bukan menghapus bukti. Pengiriman antrean duplikat memeriksa status tersebut dan segera mengakui rekaman yang sudah ditandai Diunggah dengan VERVERAt.

Setelah tiga kali gagal, masalah yang terus-menerus menjadi Gagal dengan stempel waktu penyelesaian untuk siklus upaya tersebut. Hal ini membuat pengecualian terlihat dan mencegah pesan racun berputar selamanya saat dasbor tampak macet.

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

Mengapa file dapat dikirimkan lebih dari satu kali

Antrean yang andal umumnya menyediakan pengiriman setidaknya satu kali, bukan janji ajaib tepat satu kali di seluruh API cloud, perantara pesan, dan database. Kecelakaan bisa terjadi setelah OneDrive atau Google Drive menerima unggahan tetapi sebelum pekerja menulis penyelesaian.

FileArk menangani ketidakpastian tersebut dengan catatan idempoten dan pemulihan tujuan. Pekerja pertama-tama memeriksa apakah catatan sudah diverifikasi. Jika tidak, ia dapat menggunakan ID tujuan yang disimpan atau mencari jalur tujuan yang diharapkan dan ukuran pasti untuk hasil yang terputus sebelum memutuskan untuk mengunggah lagi.

Kandidat pemulihan kemudian dikenakan verifikasi hash objek yang sama persis. Menemukan nama file yang familier saja tidak cukup. Intinya adalah mengubah upaya yang terhenti menjadi bukti, bukan menjadi keberhasilan yang optimis.

Kapasitas diperiksa di tempat tujuan dan pada pekerja

Sebelum pekerjaan per file dipublikasikan, pemindai menjumlahkan ukuran metadata sumber non-negatif dan membandingkan persyaratan dengan sisa penyimpanan yang dilaporkan tujuan setiap kali penyedia menyediakan kuota terbatas. Tujuan yang berukuran terlalu kecil akan gagal dalam pemindaian dan bukannya membuat pekerjaan menemui jalan buntu.

Angka tersebut hanyalah angka pra-penerbangan, bukan jaminan: aktivitas akun dapat menghabiskan ruang saat dijalankan, laporan kuota penyedia dapat lambat, dan file cloud-native yang diekspor mungkin tidak memiliki ukuran sumber konvensional. Penegakan penyedia dan penanganan kesalahan per file tetap aktif.

Disk komputer Anda tidak digunakan untuk pementasan. Pada pekerja migrasi, file di atas ambang batas memori ditempatkan di direktori sementara yang terisolasi hanya setelah volume memiliki ruang untuk objek yang diharapkan ditambah cadangan dua gigabyte. Konten sementara dihapus dalam pembersihan baik upaya tersebut berhasil atau gagal.

Mengapa ID tujuan ditambah SHA-256 penting

Nama file bukanlah identitas unik. Tujuan mungkin sudah berisi dua file dengan nama yang terlihat sama, atau daftar metadata mungkin memerlukan waktu untuk diselesaikan. Respons unggahan memberikan ID objek penyedia, dan FileArk menyimpan ID tersebut sebelum tahap verifikasi akhir.

Pekerja menghitung SHA-256 di seluruh aliran payload sumber, mengunggahnya, lalu membuka objek tujuan yang tepat berdasarkan ID tersebut dan menghitung SHA-256 lagi. Ukuran yang sama menghasilkan pemotongan yang jelas; intisari kriptografi yang sama adalah pemeriksaan tingkat byte yang lebih kuat.

Hanya representasi file yang ditransfer yang tercakup. Intisari tidak dapat memvalidasi aturan berbagi, komentar, versi, label, pintasan, setelan penyimpanan, atau cara dokumen Google yang diekspor dirender untuk pengguna. Itu tetap merupakan tugas penerimaan.

Penghapusan sumber sengaja dilakukan di luar jalur sukses normal

Default yang paling aman adalah hanya salin, dan opsi penghapusan FileArk tidak aktif kecuali Anda mengaktifkannya. Jika penghapusan dinonaktifkan, kegagalan verifikasi tidak dapat menghapus dokumen asli karena penghapusan tidak pernah diminta.

Jika Anda sengaja mengaktifkan hapus setelah pemindahan, pekerja masih menunggu ID tujuan, ukuran, dan validasi SHA-256 sebelum memanggil operasi penghapusan penyedia sumber. Pilihan operasional yang lebih kuat untuk perpustakaan yang tidak tergantikan atau berukuran sangat besar adalah tetap tidak menggunakan opsi tersebut dan menggunakan periode tumpang tindih yang disetujui manusia.

Migrasi menjawab “apakah salinan terverifikasi telah tiba?” Jawaban retensi “kapan salinan lama boleh dihapus?” Perlakukan keputusan tersebut sebagai keputusan terpisah dengan bukti terpisah.

Model kendali yang sama bekerja dua arah

Untuk OneDrive ke Google Drive, payload sumber dibaca dari Microsoft Graph dan objek tujuan diverifikasi melalui Google Drive berdasarkan ID yang dikembalikan. Untuk Google Drive ke OneDrive, sumber diunduh atau diekspor melalui Google Drive dan item OneDrive baru dibaca kembali melalui Microsoft Graph.

Antrean, status basis data, upaya yang dibatasi, pra-penerbangan kapasitas, intisari sumber, ID tujuan, intisari tujuan, dan urutan pengakuan bersifat netral arah. Adaptor penyedia menangani API unggahan, folder, dan konten yang berbeda.

Asimetri adalah semantik konten. Dokumen asli Google perlu diekspor, dan kedua platform memiliki perilaku berbagi dan versi khusus layanan. Konten file yang diverifikasi byte tidak boleh dipasarkan sebagai tiruan lengkap dari setiap fitur kolaborasi.

Gunakan rencana penerimaan empat bagian

1. Rekonsiliasi catatan sistem

   Tinjauan selesai, tertunda, sedang berlangsung, dan jumlah gagal. Tidak ada item yang gagal yang harus diabaikan karena persentase keseluruhannya tinggi.

2. Sampel berdasarkan risiko

   Buka file yang paling sulit hilang, ditambah media berukuran besar, arsip, dokumen lama, nama non-Inggris, jalur bersarang, dan file cloud-native yang dikonversi.

3. Validasi perilaku tujuan

   Uji akses dari perangkat dan pengguna nyata. Bangun kembali berbagi yang diperlukan dan konfirmasikan bahwa Office atau file Google yang diekspor terbuka seperti yang diharapkan.

4. Tahan periode yang tumpang tindih

   Jaga agar sumber tetap tersedia dan stabil saat penggunaan normal mencapai tujuan. Buat keputusan pembatalan atau penghapusan apa pun nanti.

Pertanyaan umum

Apakah FileArk menggunakan antrian untuk setiap file?

Ya. Pemindai membuat atau menggunakan kembali catatan database per file sumber dan menerbitkan pesan migrasi persisten. Pekerja menarik pesan-pesan tersebut dengan pengakuan manual.

Kapan pesan antrian diakui?

Setelah ID objek tujuan, ukuran, dan SHA-256 telah diverifikasi dan status Diunggah dan Diverifikasi telah dipertahankan. Pengiriman yang belum selesai dapat dikirimkan kembali.

Apakah catatan file yang sudah selesai dihapus dari database?

Tidak. Penyelesaian adalah transisi keadaan pada catatan tahan lama. Baris tersebut menyimpan identitas tujuan, bukti verifikasi, waktu, dan informasi upaya untuk kemajuan dan audit.

Bisakah SHA-256 membuktikan izin dan versi dipindahkan?

Tidak. Ini membuktikan byte file tujuan cocok dengan payload sumber yang ditransfer. Berbagi, izin, versi, komentar, label, pintasan, dan perilaku asli penyedia memerlukan validasi terpisah.

Apakah OneDrive ke Google Drive diverifikasi dengan cara yang sama seperti sebaliknya?

Aturan intinya sama di kedua arah: intisari muatan sumber, identitas objek tujuan, ukuran tujuan, intisari pengunduhan ulang objek persis, verifikasi yang dipertahankan, lalu pengakuan antrean.

Sumber resmi yang digunakan untuk panduan ini

• Pusat Pembelajaran Google Workspace: beralih dari OneDrive ke Google Drive
• Bantuan Google Drive: penyimpanan dan perilaku file
• Dukungan Microsoft: mengunggah dan menyimpan file ke OneDrive
• RabbitMQ: pengakuan konsumen dan konfirmasi penerbit
• RabbitMQ: keamanan dan keandalan data
• Google Drive API: unggahan yang dapat dilanjutkan
• Microsoft Graph: membuat sesi unggah