Large migrations · Verification · ההוכחה מאחורי סרגל ההתקדמות

העברת מאות GB בין עננים: איך אתה יודע שכל קובץ הגיע?

ב-500 GB, "ההעלאה נראתה גמורה" אינה ראיה. הגירה מהימנה זקוקה למלאי עמיד, מעבר מצב לכל אובייקט, התאוששות חוזרת לאחר הפרעות והוכחה מהיעד עצמו.

עודכן ; 16 דקות קריאה.

התשובה הקצרה

FileArk מפרק את הספרייה לרשומות לכל קובץ והודעות עמידות בתור. עובד מעתיק משלוח אחד, מאחסן את מזהה היעד המוחזר, מאמת את הגודל, קורא את האובייקט המדויק בחזרה ומשווה את SHA-256 למטען המקור. הרשומה מאומתת - וההודעה מקבלת אישור - רק לאחר שהבדיקות הללו ועדכון מסד הנתונים מצליחים.

מדוע קנה המידה משנה את המשמעות של "עבד"

קל לבדוק עשרה קבצים. עשרת אלפים קבצים לא. ספרייה אישית גדולה יכולה לשלב מסמכים זעירים, סרטוני וידאו מרובי ג'יגה-בייט, קבצים ריקים, תיקיות מקוננות, שמות Unicode, פרויקטים בארכיון ופורמטים מקוריים בענן. כישלון אחד יכול להסתתר בתוך אחוז מרשים למראה.

הסכומים שימושיים אך לא שלמים. שתי ספריות יכולות להראות את אותו גודל לכאורה כאשר אחת חסר אובייקט או מכילה אובייקט קטוע מאוזן על ידי קובץ לא קשור כלשהו. ספירת הקבצים יכולה להיות שונה גם לאחר ייצוא מסמכים מקוריים או אובייקטי ספק שלא נכללו.

יחידת האמת השימושית היא עבודת הקובץ: איזה אובייקט מקור נקרא, איזה אובייקט יעד נוצר, אילו בתים הושוו, מתי האימות הושלם, והאם ניסיון כלשהו נשאר ללא פתרון.

מחזור החיים המלא של FileArk, מובא

מחזור חיים מוער המציג את מסד הנתונים של סורק הגדרת הדפדפן של FileArk עמיד בתור עובד ואימות SHA-256
הדפדפן מתחיל את זרימת הבקרה; הסורק, התור המתמשך, מסד הנתונים והעובד נושאים את ההגירה ארוכת השנים.

כאשר Start מתקבל, ה-API כותב תחילה עבודת סריקה ל-MongoDB ולאחר מכן מפרסם הודעת סריקה מתמשכת לתור RabbitMQ עמיד עם אישור מפרסם מופעל. אם הפרסום נכשל, העבודה מסומנת ככשלה והממשק ה-API מדווח כי הוא לא הצליח לעמוד בבטחה בתור הסריקה.

הסורק מאמת את שני הספקים, רושם מלאי של המקור שנבחר, בודק את מכסת היעד הסופית מול בתים שהתגלו, ומעביר רשומת מסד נתונים עבור כל קובץ מקור. הוא מפרסם הודעות הגירה מתמשכות ומסמן את הסריקה כשלמה רק לאחר שהפרסומים הללו מצליחים.

עובד ההגירה משתמש באישורים ידניים ובספירת אחזור מראש של אחד. מסירה נשארת ללא אישור בזמן שתוכן נקרא, מועלה, קריאה חוזרת, מאומת ומתמשך. לכן חיבור או תהליך שהופסק יכול להחזיר עבודה לא גמורה לתור.

שורת מסד נתונים היא פריט רשימת תיוג, לא הנהלת חשבונות חד פעמית

כל רשומת קובץ מתחילה בהמתנה, עוברת ל-InProgress במהלך ניסיון, ומגיעה להעלאה רק לאחר אימות. ספירת ניסיונות, זמן ניסיון אחרון, פרטי שגיאה, מזהה אובייקט יעד, שני תקצירי SHA-256, שיטת אימות ו-VerifiedAt נשארים צמודים לרשומה.

רשומות שהושלמו נשארות במסד הנתונים בתור ההתקדמות ומסלול הביקורת. "חציית קובץ" פירושה שינוי מצב מבוקר, לא מחיקת הראיות. משלוחים כפולים בתור בודקים את המצב הזה ומאשרים מיד רשומה שכבר מסומנת שהועלה עם VerifiedAt.

לאחר שלושה ניסיונות לא מוצלחים, בעיה מתמשכת הופכת ל-Failed עם חותמת זמן של השלמה עבור מחזור הניסיון. זה הופך חריגים לנראים ומונעים מהודעת רעל להסתובב לנצח בזמן שלוח המחוונים נראה תקוע.

שער ההשלמה לקובץ אחד
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

מדוע קובץ עשוי להימסר יותר מפעם אחת

תורים אמינים בדרך כלל מספקים מסירה של פעם אחת לפחות, לא הבטחה קסומה של פעם אחת בדיוק על פני ממשק API של ענן, מתווך הודעות ומסד נתונים. קריסה יכולה להתרחש לאחר ש-OneDrive או Google Drive מקבלים העלאה אך לפני שהעובד כותב השלמה.

FileArk מטפל בחוסר הוודאות הזה עם רשומות חסרות יכולת ושחזור יעד. העובד בודק תחילה אם הרשומה כבר מאומתת. אם לא, הוא יכול להשתמש במזהה היעד המאוחסן או לחפש בנתיב היעד הצפוי ובגודל המדויק עבור התוצאה שנקטעה לפני שתחליט להעלות שוב.

לאחר מכן מועמדים לשחזור נתונים לאותו אימות גיבוב מדויק של אובייקט. מציאת שם קובץ מוכר אינו מספיק. העניין הוא להמיר ניסיון שנקטע בחזרה לראיות, לא להצלחה אופטימית.

קיבולת נבדקת ביעד ועל העובד

לפני פרסום משימות לכל קובץ, הסורק כולל גדלי מטא נתונים של מקור שאינם שליליים ומשווה את הדרישה לאחסון שנותר של היעד המדווח בכל פעם שהספק מספק מכסה סופית. יעד בגודל נמוך נכשל בסריקה במקום להזין עבודה למבוי סתום ידוע.

הנתון הוא בדיקה מוקדמת, לא ערובה: פעילות החשבון עלולה לצרוך מקום במהלך ריצה, דוחות מכסת ספקים יכולים להשתהות, וייתכן שלקבצים מיוצאים מקוריים בענן אין גודל מקור קונבנציונלי. אכיפת ספק וטיפול בשגיאות לכל קובץ נשארים פעילים.

הדיסק של המחשב שלך אינו משמש לסטייג'ינג. ב- Migration Worker, קבצים מעל סף הזיכרון ממוקמים בספרייה זמנית מבודדת רק לאחר שבאמצעי האחסון יש מקום לאובייקט הצפוי בתוספת רזרבה של שני גיגה-בייט. תוכן זמני מוסר בניקוי בין אם הניסיון מצליח ובין אם זורק.

מדוע מזהה יעד בתוספת SHA-256 חשוב

שם קובץ אינו זהות ייחודית. ייתכן שהיעד כבר מכיל שני קבצים עם אותו שם גלוי, או שרשומה של מטא נתונים עשויה להימשך זמן להתיישב. תגובת ההעלאה מספקת מזהה אובייקט של ספק, ו-FileArk מאחסן את המזהה הזה לפני שלב האימות הסופי.

העובד מחשב את SHA-256 על פני זרם מטען המקור, מעלה אותו, ואז פותח את אובייקט היעד המדויק על ידי מזהה זה ומחשב שוב את SHA-256. גודל שווה תופס חיתוך ברור; תקציר קריפטוגרפי שווה הוא הבדיקה החזקה יותר ברמת הבתים.

רק ייצוג הקובץ המועבר מכוסה. תקציר אינו יכול לאמת כללי שיתוף, הערות, גרסאות, תוויות, קיצורי דרך, הגדרות שמירה או אופן עיבוד של מסמך Google מיוצא עבור משתמש. אלו נותרו משימות קבלה.

מחיקת המקור היא בכוונה מחוץ לנתיב ההצלחה הרגיל

ברירת המחדל הבטוחה ביותר היא העתקה בלבד, ואפשרות המחיקה של FileArk כבויה אלא אם תפעיל אותה. כשהמחיקה מושבתת, כישלון אימות אינו יכול להסיר את המקור, מכיוון שמעולם לא מתבקש המחיקה.

אם תפעיל בכוונה מחיקה-אחר-העברה, העובד עדיין ממתין למזהה יעד, גודל ואימות SHA-256 לפני שיתקשר לפעולת המחיקה של ספק המקור. הבחירה התפעולית החזקה יותר עבור ספריות שאין להן תחליף או גדולות מאוד היא עדיין להשאיר את האפשרות כבויה ולהשתמש בתקופת חפיפה שאושרה על ידי אדם.

הגירה עונה "האם הגיע עותק מאומת?" שימור עונה "מתי ניתן להסיר את העותק הישן?" התייחס אליהם כהחלטות נפרדות עם ראיות נפרדות.

אותו מודל בקרה פועל בשני הכיוונים

עבור OneDrive ל-Google Drive, מטען המקור נקרא מ-Microsoft Graph ואובייקט היעד מאומת באמצעות Google Drive על ידי המזהה המוחזר שלו. עבור Google Drive ל-OneDrive, המקור מוריד או מיוצא דרך Google Drive והפריט החדש של OneDrive נקרא בחזרה דרך Microsoft Graph.

התור, מצבי מסד הנתונים, ניסיונות מוגבלים, בדיקת קיבולת מוקדמת, תקציר מקור, מזהה יעד, תקציר יעד וסדר אישור הם ניטרליים לכיוון. מתאמי ספקים מטפלים בממשקי API שונים של העלאה, תיקיות ותוכן.

האסימטריה היא סמנטיקה של תוכן. מסמכים מקוריים של Google זקוקים לייצוא, ולשתי הפלטפורמות יש שיתוף ספציפי לשירות והתנהגות גרסאות. אין לשווק תוכן קובץ מאומת בתים כשיבוט מלא של כל תכונת שיתוף פעולה.

השתמש בתוכנית קבלה בת ארבעה חלקים

  1. התאם את רשומת המערכת

    סקירה הושלמה, בהמתנה, בעיצומה ונכשלה. אין להרחיק שום פריט שנכשל מכיוון שהאחוז הכולל גבוה.

  2. דגימה לפי סיכון

    פתח את הקבצים שהכי יכאב להם לאבד, בתוספת מדיה גדולה, ארכיונים, מסמכים ישנים, שמות שאינם באנגלית, נתיבים מקוננים וקבצים מקוריים בענן שהומרו.

  3. אמת את התנהגות היעד

    בדוק גישה ממכשירים ומשתמשים אמיתיים. בנה מחדש את השיתוף הנדרש ואשר שקובצי Office או מיוצאים של Google פתוחים כצפוי.

  4. החזק תקופת חפיפה

    שמור על המקור זמין ויציב בזמן ששימוש רגיל מפעיל את היעד. קבל כל החלטת ביטול או מחיקה מאוחר יותר.

שאלות נפוצות

האם FileArk משתמש בתור עבור כל קובץ?

כן. הסורק יוצר או עושה שימוש חוזר ברשומת מסד נתונים לכל קובץ מקור ומפרסם הודעת העברה מתמשכת. עובדים מושכים את ההודעות האלה עם אישור ידני.

מתי מקבלים הודעת תור?

לאחר שמזהה אובייקט היעד, הגודל וה-SHA-256 אומתו והמצב Uploaded and VerifiedAt נמשך. ניתן לשלוח מחדש משלוחים לא גמורים.

האם רשומות קבצים שהושלמו נמחקות ממסד הנתונים?

לא. השלמה היא מעבר מצב על הרשומה העמידה. השורה שומרת את זהות היעד, ראיות אימות, תזמון ומידע על ניסיון להתקדמות ולביקורת.

האם SHA-256 יכול להוכיח הרשאות וגרסאות שהועברו?

לא. זה מוכיח שהבתים של קובץ היעד תואמים את מטען המקור המועבר. שיתוף, הרשאות, גרסאות, הערות, תוויות, קיצורי דרך והתנהגות מקורית של ספק זקוקים לאימות נפרד.

האם OneDrive ל-Google Drive מאומת באותו אופן כמו ההיפך?

כלל הליבה זהה בשני הכיוונים: תקציר מטען מקור, זהות אובייקט יעד, גודל יעד, תקציר הורדה חוזרת של אובייקט מדויק, אימות מתמשך ואז אישור תור.

מקורות רשמיים ששימשו להכנת המדריך

לקריאת המדריך