Bash + rclone · OneDrive ↔ Google Drive · מדריך תפעול בקוד פתוח

העברת ענן להעתקה בלבד ב-Bash באמצעות rclone

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

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

התשובה הקצרה

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

למה לעטוף את rclone במקום לבנות מחדש לקוח לכל ספק

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

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

הסקריפט לעולם אינו מפעיל במפורש את rclone move, sync, delete, purge או rmdirs. הוא משתמש ב-lsf וב-about לגילוי, ב-copy לכל מקטע וב-check --download לאימות מלא של כל הבתים. ההסרה היחידה היא של קובץ מאומת מתיקיית הביניים המקומית.

הורדת גרסת Bash ורישיון MIT

הורדת תוכנית ההעברה ב-Bash וב-rclone
מעטפת להעתקה בלבד, עם מגבלות אצווה, עתודות מקומיות וביעד, אימות מלא של כל הבתים, נקודות ביקורת, בקרות לניסיונות חוזרים והדגמה שאינה זקוקה לרשת.
fileark-cloud-transfer.sh · Bash 4+ · rclone · jq · רישיון MIT

הורידו את רישיון MIT
הודעת הרשאה החלה על שני הסקריפטים של FileArk להעברה ידנית.
LICENSE-fileark-cloud-transfer.txt · MIT · טקסט פשוט

הריצו את הדגמת המפעיל ללא חיבור לרשת

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

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

בדקו את ההורדה ובצעו בדיקת תקינות ראשונית
chmod +x fileark-cloud-transfer.sh
bash -n fileark-cloud-transfer.sh
./fileark-cloud-transfer.sh --demo
./fileark-cloud-transfer.sh --help

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

התקינו גרסה עדכנית של rclone לפי ההוראות הרשמיות שלו, והתקינו את jq באמצעות מנהל החבילות של מערכת ההפעלה. נדרש Bash 4 ומעלה, משום שסקריפט המעטפת משתמש בטיפול מחמיר בשגיאות ובביטויים מותנים מודרניים.

הריצו rclone config וצרו שני שירותים מרוחקים בעלי שמות נפרדים, לדוגמה onedrive: ו-gdrive:. הזינו מזהה לקוח וסוד משלכם עבור הספק כאשר המדיניות או מגבלות הקצב מחייבות יישומי OAuth ייעודיים. rclone שומר אסימוני OAuth בקובץ ההגדרות שלו; הגנו על הקובץ באמצעות הרשאות מצומצמות ולעולם אל תצרפו אותו לסקריפט.

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

הגדרה ובדיקה של שני השירותים המרוחקים
rclone version
rclone config
rclone lsd onedrive:
rclone lsd gdrive:
rclone about onedrive: --json | jq
rclone about gdrive: --json | jq

הקפאת מצאי דטרמיניסטי לפני העברת הבתים

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

גרסת Bash דוחה שמות קבצים המכילים טאבים, החזרות גרר או ירידות שורה, מפני שרשימות --files-from-raw המופרדות בירידות שורה אינן יכולות לייצג אותם ללא עמימות. כאשר קיימים שמות כאלה, השתמשו בגרסת Python או בפורמט מצאי ייעודי.

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

פקודת המצאי הבסיסית שבה משתמשת המעטפת
rclone lsf "$SOURCE" \
  --recursive \
  --files-only \
  --format "sp" \
  --separator 
    
  

\t' > "$inventory"

עצרו בכשל לפני שאצווה צורכת את הרזרבה

מספר הבתים הפנויים באופן מקומי מתקבל מ-df במערכת הקבצים של אזור הביניים. מספר הבתים הפנויים ביעד מתקבל מ-rclone about --json: הסקריפט משתמש בערך free כאשר הוא מסופק, ואחרת מחשב את total פחות used. הוא בודק את סך הבתים הממתינים לפני תחילת העבודה, ובודק שוב את הקיבולת המקומית וביעד לפני כל אצווה.

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

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

אמתו כל צד של גבול אחסון הביניים המקומי

כל אצווה עוברת בשני מקטעים עצמאיים. תחילה rclone מעתיק את נתיבי המקור שנבחרו אל אזור הביניים המקומי באמצעות --ignore-existing, ואז check --download קורא את שני הצדדים ומשווה את התוכן בפועל. לאחר מכן rclone מעתיק את הנתיבים מאזור הביניים אל היעד וחוזר על אותה בדיקה מלאה של כל הבתים.

האפשרות --ignore-existing מונעת מהרצות שנקטעו לגרום נזק: פריט קיים אינו נדרס. עם זאת, האימות עדיין חייב להצליח לפני שאפשר להוסיף את הנתיב לנקודת הביקורת. אם הפריט הקיים ביעד שונה, rclone check נכשל וטיפול השגיאות המחמיר של Bash עוצר את ההרצה.

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

שני מקטעי ההעתקה והאימות
rclone copy "$SOURCE" "$STAGING_DIR" \
  --files-from-raw "$batch_list" \
  --ignore-existing --retries 6 --low-level-retries 20

rclone check "$SOURCE" "$STAGING_DIR" \
  --files-from-raw "$batch_list" --one-way --download

rclone copy "$STAGING_DIR" "$DESTINATION_ROOT" \
  --files-from-raw "$batch_list" \
  --ignore-existing --retries 6 --low-level-retries 20

rclone check "$STAGING_DIR" "$DESTINATION_ROOT" \
  --files-from-raw "$batch_list" --one-way --download

העבירו מ-OneDrive אל Google Drive עם אחסון ביניים מוגבל

הדוגמה משאירה 15 GiB בכונן המקומי ללא שימוש, שומרת 10 GiB פנויים ב-Google Drive, מגבילה אצווה רגילה ל-8 GiB או ל-200 קבצים ומשתמשת בארבע העברות במקביל. התוכן ביעד נכתב תחת תיקייה חדשה ששמה כולל תאריך.

השתמשו תחילה ב---dry-run. האפשרות מבצעת מיפוי של המקור ובדיקת מכסה מקדימה ביעד, ללא הורדה או העלאה. סקריפט המעטפת מציג את המספר הכולל של הבתים הממתינים, ויש להתאים אותו להיקף ההעברה לפני האצווה האמיתית הראשונה.

בצעו בדיקה מקדימה ולאחר מכן הפעילו את אותו היקף
./fileark-cloud-transfer.sh \
  --source onedrive: \
  --destination gdrive: \
  --destination-folder "OneDrive archive 2026-07-25" \
  --staging-dir /srv/fileark-staging \
  --state-file ./onedrive-to-google-verified.txt \
  --batch-gib 8 \
  --batch-files 200 \
  --local-reserve-gib 15 \
  --destination-reserve-gib 10 \
  --transfers 4 \
  --checkers 8 \
  --dry-run

# Remove only --dry-run after reviewing the preflight.

הפכו את כיוון ההעברה בלי להשתמש שוב בנתוני המצב

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

Docs, Sheets, Slides ופורמטים וירטואליים אחרים שמקורם ב-Google דורשים הגדרת ייצוא ב-rclone ובדיקה קפדנית. אשרו את סיומות הקבצים המיוצאים ואת אופן ההמרה באמצעות ערכת בדיקה. העתקה באמצעות מעטפת פקודה אינה משמרת את היסטוריית שיתוף הפעולה של Google, קיצורי דרך, הרשאות או מטא-נתונים ייחודיים ל-Microsoft.

מ-Google Drive ל-OneDrive
./fileark-cloud-transfer.sh \
  --source gdrive: \
  --destination onedrive: \
  --destination-folder "Google archive 2026-07-25" \
  --staging-dir /srv/google-staging \
  --state-file ./google-to-onedrive-verified.txt \
  --batch-gib 8 \
  --local-reserve-gib 15

יצירת נקודת ביקורת רק לאחר אימות היעד

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

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

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

התייחסו לכל יציאה בקוד שאינו אפס כאל אצווה שלא נפתרה

  • מצב מחמיר מפסיק את ההרצה כאשר פקודה או צינור עיבוד נכשלים, או כאשר נעשה שימוש במשתנה שלא הוגדר; תיקיית המצאי הזמנית מוסרת אוטומטית.
  • rclone מנסה מחדש העברות שנכשלו זמנית, אך שגיאות מתמשכות בהרשאות, במכסה, ברשת, בהתנגשויות או בשלמות הנתונים עוצרות את האצווה.
  • קבצים באזור הביניים שלא נוספו לנקודת הביקורת נשארים זמינים לבדיקה, והרצה חוזרת זהה משתמשת ב--ignore-existing לפני בדיקת הבתים שלהם.
  • קובץ שונה ביעד לעולם אינו נדרס. פתרו את ההתנגשות או בחרו תיקיית שורש נקייה ביעד.
  • אל תהפכו העתקה שנכשלה ל-rclone sync או move. לפקודות האלה יש כללי מחיקה שונים.
  • שמרו את היומנים ואת נקודת הביקורת עד להשלמת האישור הידני של היעד.

אבטחו את המארח שהופך למישור הנתונים

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

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

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

סיום ההעברה על סמך ראיות, לא רק פקודה ירוקה

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

שאלות נפוצות

מדוע סקריפט ה-Bash משתמש ב-rclone copy במקום ב-sync?

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

האם rclone check --download משנה משהו באחד משירותי הענן?

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

מה קורה כאשר כבר קיים קובץ ביעד?

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

האם הסקריפט יכול לטפל בקבצים שגדולים מאצווה אחת?

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

האם התהליך מעביר הרשאות, גרסאות או נתוני שיתוף פעולה שמקורם בענן?

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

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

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