העברת נתונים מ-Vault באמצעות העברת דומיין

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

לפני שמתחילים

  • שימוש ב-Vault API – כדי להעביר עניינים והשעיות ב-Vault, צריך להשתמש ב-Vault API. אי אפשר לבצע את השלבים האלה דרך ממשק המשתמש של Vault. פרטים על ה-API זמינים במאמר בנושא Google Vault API.

    טיפ: אפשר להשתמש ב-Google Apps Manager‏ (GAM), כלי שורת פקודה של צד שלישי, כדי לקבל עזרה ב-Vault API. הכלי זמין ב-GitHub.

  • בדיקה של מה שמועבר ומה שלא מועבר – פרטים נוספים זמינים במאמר בנושא אפליקציות ליבה של Google.

שלב 1: הורדת עניינים והשעיות

כדי לבצע את המשימה הזו, אתם צריכים להיות סופר-אדמינים ב-Google Workspace או אדמינים ב-Vault.

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

הורדת מסמכים
ה-Method ב-API

matters.list

רשימה של עניינים שלמשתמש יש גישה אליהם. מידע נוסף

פרמטרים view: FULL

מציין אילו חלקים מהעניין יוחזרו בתשובה.

state: OPEN

הצגת עניינים פתוחים בלבד.

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

הורדה של השעיות
ה-Method ב-API

matters.holds.list

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

פרמטרים view: FULL_HOLD

מציין אילו חלקים של ההשעיה יוחזרו.

שלב 2: ניקוי של עניינים והשעיות שהורדו

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

  1. אם ההקפאות נקבעו ברמת היחידה הארגונית, צריך למפות את כל היחידות הארגוניות ליחידה הארגונית להעברה המתאימה בסביבת היעד באמצעות Orgunits API. מידע נוסף

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

  2. (אופציונלי) מסירים עניינים והשעיות ריקים.

אם אתם מתכננים ליצור תיקים עם בעלים שונים, צריך להמיר את כל ההרשאות מסוג OWNER להרשאות מסוג COLLABORATOR בשדה matterPermissions[]. מידע נוסף

שלב 3: אחרי ההעברה, מעלים את העניינים וההשעיות

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

צריך גם להגדיר את מדיניות השמירה המתאימה ב-Vault. מידע נוסף

עניינים

ה-Method ב-API matters.create

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

עוד דברים שכדאי לזכור:

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

החזקות

ה-Method ב-API matters.holds.create

יצירת החזקה בעניין שצוין. מידע נוסף

עוד דברים שכדאי לזכור:

  • השמות הייחודיים של ההקפאות נאכפים במסגרת הטיפול בתיק, כך שלא צריך לדאוג לגבי העלאת כפילויות.
  • חשוב לרשום את מזהה ההחזקה לצורך משפטי שנוצר. הוא מאפשר לכם לשמור על מיפוי בין מזהה ההשעיה בסביבת המקור לבין מזהה ההשעיה בסביבת היעד.
  • אם מספר החשבונות בהקפאה עולה על מגבלת החשבונות שאפשר להוסיף בזמן היצירה, אפשר להוסיף עוד חשבונות בנפרד להקפאה אחרי שהיא נוצרה. אפשר להשתמש ב-method‏ matters.holds.accounts.create של ה-API. מידע נוסף

שלב 4: ממתינים 24 שעות

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


Google‏, Google Workspace וסימנים וסמלי לוגו קשורים הם סימנים מסחריים של Google LLC. כל שמות החברות והמוצרים האחרים הם סימנים מסחריים של החברות שאליהן הם משויכים.