יצירת גיבויים

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

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

גיבויים אוטומטיים של מופעים שמתארחים ב-Looker

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

הגיבויים נשמרים למשך 30 יום. כדי לגשת לגיבוי ולשחזר אותו, צריך לפנות לתמיכה.

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

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

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

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

מבנה הספרייה

בקטע הזה מתוארות ספריות המשנה הסטנדרטיות בספריית הבית של משתמש Looker (בדרך כלל ‎/home/looker).

  • home
    • looker
    • .ssh
    • looker
      • ‫ .cache
      • ‎ .db
      • ‫ ‎ .ssl
      • ‎ .tmp
      • deploy_keys
      • יומן
      • דגמים
      • models-user-1
ספרייה נדרש גיבוי שינוי התדירות תיאור
‎.ssh כן נדיר מפתחות SSH שמשמשים לאימות ב-Git עבור פרויקטים של LookML שנוצרו ב-Looker 4.6 או בגרסאות קודמות
looker/.cache לא אנשי קשר תדירים קבצים זמניים במטמון
looker/.db כן, אלא אם מסד הנתונים בקצה העורפי הועבר ל-MySQL אנשי קשר תדירים מסד נתונים פנימי של Looker
looker/.snapshots לא בעדכון עותק גיבוי של קובץ ה-jar של Looker והספרייה ‎ .db נשמרים כאן במהלך עדכונים
looker/.ssl אולי נדיר אישורי SSL בחתימה עצמית (ראו הערה)
looker/.tmp לא אנשי קשר תדירים קבצים זמניים
looker/deploy_keys כן נדיר מפתחות SSH שמשמשים לאימות ב-Git עבור פרויקטים של LookML שנוצרו באמצעות Looker 4.8 או גרסה חדשה יותר
looker/log אולי אנשי קשר תדירים קבצי יומן; נדרש רק אם יש דרישה לכך במדיניות השמירה שלכם
looker/models לא משתנה מודלים של ייצור שהועתקו ממאגר המקור (בדרך כלל GitHub)
looker/models-user-* כן משתנה מודלים של פיתוח של כל משתמש מאוחסנים בספריות נפרדות עם מספר המזהה של המשתמש

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

קבצים מחוץ לספריית הבית של Looker שצריך להוסיף לגיבוי כוללים את הקבצים הבאים:

ספרייה נדרש גיבוי שינוי התדירות תיאור
/etc/init.d/looker כן נדיר סקריפט לטעינה בזמן ההפעלה של Looker
אישורי SSL כן נדיר אם אתם משתמשים באישורי SSL, ודאו שכל הקבצים הנדרשים כלולים

למרות שבדרך כלל זה לא גורם לבעיות, חלק מהלקוחות דיווחו על בעיות אם הם כוללים את הקובץ looker/.db/looker.lck בגיבויים שלהם. במקרה הצורך, אפשר להחריג את הקובץ הזה.

יצירת גיבוי

אתם יכולים ליצור גיבוי של מופע Looker באמצעות כל אפליקציית גיבוי רגילה, וגם באמצעות כלי שורת פקודה כמו rsync.

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

סביבות באשכולות

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

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

אם יש לכם התקנה באירוח בצד הלקוח והועברה להצפנת AES-256 GCM ולא נעשה בה שימוש ב-AWS KMS, תוכלו להשתמש בהליך הזה כדי ליצור גיבוי של מופע Looker שלא תלוי במפתח המאסטר המקומי של הלקוח (CMK). התהליך הזה מספק שיטה לביצוע מיגרציה של מכונה באירוח בצד הלקוח למכונה באירוח Looker, בלי לספק CMK, או להעברת מכונה באירוח בצד הלקוח למארח חדש שאין לו גישה לאותו מאגר מפתחות מקומי.

כדי ליצור גיבוי שלא תלוי בחנות המפתחות:

  1. מפסיקים את Looker:

    cd looker
./looker stop

    אם מופע Looker שלכם הוא מקובץ, צריך להפסיק כל צומת לפני שממשיכים.

  2. מוודאים שלמכונת Looker יש גישה למפתח ה-CMK. אם ה-CMK שלכם מאוחסן בקובץ, אתם יכולים להשתמש במשתנה הסביבה LKR_MASTER_KEY_FILE כדי להפנות לנתיב של קובץ ה-CMK:

    export LKR_MASTER_KEY_FILE=<path_to_CMK_file>

    לחלופין, כדי לספק את מפתח ה-CMK ישירות במשתנה סביבה, אפשר להשתמש במשתנה הסביבה LKR_MASTER_KEY_ENV:

    export LKR_MASTER_KEY_ENV=<CMK_value>

  3. יוצרים קובץ מפתח חדש שישמש להצפנה מחדש של המפתח להצפנת מפתחות הצפנה (KEK):

    ./looker generate_keyfile_for_backup <key_file_name>

    כאשר <key_file_name> הוא השם שרוצים להשתמש בו עבור הקובץ ש-Looker ייצור ואז ישתמש בו כדי לכתוב את המפתח החדש.

    התוכן של קובץ המפתח החדש ייראה כך:

    {"dbmk":"vr1LUwO3q6weY8iS3JykVljSjiD4m6eGk227Cs7Qu9Q=\n","backup_uid":"XCXvRa38mNeqT6+HRBCo2Q=="}

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

  4. משתמשים בקובץ המפתח החדש כדי ליצור רשומת מפתח חדשה במסד הנתונים הפנימי של Looker:

    ./looker keystore_independent_recrypt <key_file_name>

    כאשר <key_file_name> הוא קובץ המפתח שנוצר קודם.

    הפעולה הזו מבטלת את ההצפנה של מפתח ה-KEK במסד הנתונים הפנימי באמצעות מפתח ה-CMK, ואז מצפינה מחדש את מפתח ה-KEK באמצעות המפתח החדש ושומרת את הערך המוצפן במסד הנתונים.

  5. יוצרים גיבוי של מופע Looker באמצעות שיטת הגיבוי הרגילה.

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

שחזור גיבויים

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

השלבים הבאים

אחרי שמגדירים גיבויים, אפשר לוודא שלמכונה של Looker יש גישה לשירותים הדרושים.