הגדרה של הגדרות מדיניות מתקדמות במסוף הניהול של הציוד

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

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

כדי להציג את דף הגדרות המדיניות:

  1. במסוף הניהול של ה-appliance, לוחצים על הכרטיסייה Backup Plans (תוכניות גיבוי) ובוחרים באפשרות Templates (תבניות) מהתפריט הנפתח.
  2. בוחרים את התבנית שרוצים לנהל ולוחצים על עריכה בתפריט הנפתח בפינה השמאלית התחתונה של הדף.
  3. בדף התבנית, בצד שמאל, לוחצים על החץ הלבן לצד המדיניות שרוצים לנהל. בחלק התחתון של האפשרויות, לוחצים על עריכת המדיניות.
  4. בתחתית הקטע Create/Edit Policy (יצירה או עריכה של מדיניות), לוחצים על Advanced Policy Settings (הגדרות מתקדמות של מדיניות). ייפתחו הגדרות מדיניות מתקדמות שמפורטות בטבלה הבאה.

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

בטבלה הבאה מפורטות הגדרות המדיניות המתקדמות.

               
הגדרה מתקדמת תיאור
עקביות ברמת האפליקציה
(רלוונטי רק למכונות וירטואליות ב-Google Cloud VMware Engine ולמכונות וירטואליות ב-Compute Engine)		 בוחרים אחת מהאפשרויות הבאות:
  • גיבוי עקבי במקרה של קריסה: גיבוי עקבי במקרה של קריסה הוא גיבוי מהיר של נתוני האפליקציה באחסון, כאילו הייתה הפסקת חשמל באותו רגע. היא לא משהה את קלט/פלט הנתונים של האפליקציה. כל הנתונים בדיסק נשמרים, והנתונים בזיכרון אובדים. יכול להיות שייקח יותר זמן לשחזר גיבוי עקבי במקרה של קריסה, וייתכן שיוצגו חריגים. יכול להיות שיהיה צורך לבצע כמה שלבים נוספים של שחזור ידני במהלך השחזור, בהתאם למערכת ההפעלה של האורח, למערכות הקבצים ולאפליקציות. בוחרים באפשרות 'עקביות במקרה של קריסה' אם התהליך של עקביות האפליקציה גורם לבעיות באפליקציות או בעומסי העבודה שלכם בגלל תהליך ההשבתה. יכול להיות שגיבוי עקבי במקרה של קריסה יוביל ל-RTO ארוך יותר, כי מערכת הקבצים או האפליקציה יצטרכו לבצע שחזור מהתמונה הלא עקבית, ובמקרים קיצוניים יכול להיות שהתמונה לא תהיה ניתנת לשחזור.
  • יצירת גיבוי עקבי של האפליקציה: גיבוי עקבי של האפליקציה מתבסס על תמונות מצב במצב השהיה, שמשתמשות בכלי VMware או בסביבת אורח של Google Cloud כדי להשהות את מערכת הקבצים של המכונה הווירטואלית. פעולת השהיה מסתמכת על יכולות מובנות של מערכת ההפעלה Windows להשהיית מערכות קבצים ואפליקציות שתומכות ב-VSS. הוא גם משתמש בכל סקריפט הקפאה או ביטול הקפאה שסופק על ידי הלקוח (בכל הפלטפורמות) כדי להשיג עקביות ברמה גבוהה יותר של האפליקציה. התוצאה היא רמת סמך גבוהה יותר לגבי האפשרות לשחזר את הגיבוי, וגם זמני שחזור קצרים יותר ברוב המקרים. גיבויים עקביים של אפליקציות יכולים לפעמים לגרום להשהיה קצרה של קלט/פלט, ולמרות שזה לא נפוץ, יכול להיות שחלק מהאפליקציות העמוסות יותר ידווחו על שגיאות קלט/פלט בזמן הגיבוי. לפעמים, גיבויים עקביים של אפליקציות נכשלים אם VMware לא מצליח להשבית את ה-VM בתוך פסק זמן מוגדר מראש במהלך פעולת ה-snapshot. כדאי להשתמש בגיבויים עקביים של האפליקציה כשחשיבות השחזור היא הגבוהה ביותר, והאפליקציות במכונה הווירטואלית לא רגישות להשהיה הקצרה של קלט/פלט.
    מידע נוסף זמין בקטע יצירת snapshot עקבי של דיסק אחסון מתמיד של אפליקציית Linux.

    כדי לטעון תמונת מצב של Windows Compute Engine כמכונה וירטואלית חדשה או קיימת שצולמה באמצעות האפשרות Application consistent, צריך לשנות את הדיסק ממצב קריאה בלבד למצב קריאה וכתיבה. כדי לעשות את זה, פועלים לפי ההוראות שבקטע אופציונלי: סימון הדיסק כזמין לקריאה ולכתיבה.
  • יצירת גיבוי עקבי במקרה של קריסה בניסיון האחרון: האפשרות הזו יוצרת בהתחלה גיבויים עקביים של האפליקציה, אבל אם גיבוי עקבי של האפליקציה נכשל מסיבה כלשהי, היא יוצרת גיבוי עקבי במקרה של קריסה.
    •
    מיקום קובץ ה-Snapshot
    (רלוונטי רק למכונות של Compute Engine ולמכונות של SAP HANA)    		 בוחרים את האזור שבו יישמרו תמונות המצב של הדיסק הקשיח הקבוע. כברירת מחדל, נבחרת האפשרות 'מספר אזורים' (בהתאם למיקום של דיסק המקור). אפשר גם לשנות את מיקום האחסון של התמונה לאזור אחר, שונה מהאזור של דיסק המקור. כשמאחסנים תמונות מצב במיקום ששונה מהמיקום של דיסק המקור, הנתונים עוברים ברשת בין המיקומים האלה, ויכול להיות שיהיו חיובים על השימוש ברשת. התשלום על תמונות מצב זהה לתשלום על העברת נתונים ב-Cloud Storage. מידע נוסף על תמונת מצב של דיסק קבוע מחירון הדיסקים
    סוג תמונת המצב      
    (רלוונטי רק למכונות Compute Engine ולמכונות SAP HANA)    		בוחרים את סוג התמונה של הדיסק הקשיח שרוצים להשתמש בו לגיבויים של מכונות Compute Engine. תמונות מצב מגבות נתונים באופן מצטבר מדיסקים לאחסון מתמיד. במהלך הגיבויים, נוצרת תמונת מצב חדשה כדי לתעד את המצב הנוכחי של הדיסק הקשיח, ואפשר להשתמש בה מאוחר יותר כדי ליצור דיסק חדש להרכבה או לשחזור. ‫Compute Engine מאחסן כמה עותקים של כל תמונת מצב בכמה מיקומים, עם סכומי ביקורת אוטומטיים כדי לוודא את שלמות הנתונים. מידע נוסף על תמונת מצב של דיסק קבוע מחירון הדיסקים
  • רגיל: כברירת מחדל, נבחר סוג תמונת המצב 'רגיל'. מומלץ להשתמש בסוג הגיבוי הרגיל אם רוצים לשמור את הגיבויים למשך פחות מ-90 יום.
  • ארכיון: בוחרים באפשרות הזו אם רוצים לשמור את הגיבויים לטווח ארוך. שימו לב: תקופת החיוב המינימלית עבור קובץ snapshot של ארכיון היא 90 ימים, ללא קשר לתקופת השמירה שהוגדרה במדיניות. בנוסף, אם משתמשים בסוג ארכיון במשימת שחזור או במשימת הרכבה, יחול חיוב נוסף על אחזור.
    •       
    הקצאת יתר של דיסק זמני
    (באחוזים)    		 מציינים את הנפח הנוסף שמוקצה לדיסק של סביבת הבדיקה (בנוסף למה שנדרש בפועל) כדי להתאים את עצמו לצמיחה של האפליקציה. ההגדרה הזו היא בין אפס ל-1,000 אחוזים.
    Global Prune Paths אל תגבו את הספריות האלה (צריך לציין את הנתיב המלא). אפשר גם לראות את הערכים של Global Prune Paths ברמת המדיניות.
    Compress Streamsnap Replication כברירת מחדל, הדחיסה מופעלת לרפליקציה של Streamsnap. דחיסה מגדילה את היעילות של השכפול של streamsnap למכשיר הגיבוי או השחזור המרוחק כשמעבירים נתונים ברשת, למשל כשמשכפלים גיבויים וסרטונים. כשדחיסה מופעלת, כל החבילות נדחסות. מכשיר הגיבוי או השחזור של היעד מבצע דקומפרסיה של החבילות לפני הכתיבה לדיסק הזמני. אם אין צורך בדחיסה לשכפול של streamsnap במכשיר השני לגיבוי או לשחזור, משנים את ההגדרה המתקדמת של שכפול streamsnap לדחיסה לללא דחיסה ואז לוחצים על שמירת שינויים.
    הערה: שכפול Streamsnap נתמך רק במכשירי גיבוי ושחזור שנפרסו ברשת אחת.
    אל תבטלו את המיפוי המדיניות קובעת אם אתם רוצים שדיסקים זמניים של אזור אחסון זמני ימופו למארח וישמשו במהלך העברת נתונים לגיבוי, כדי שהם יישארו ממופים למארח. מיפוי ה-LUN מתבצע במהלך העבודה הראשונה, וכל העבודות הבאות משתמשות באותו LUN ממופה. בוחרים באחת מהאפשרויות הבאות:
  • שומרים את המיפוי של דיסקים זמניים בין משימות. בוחרים באפשרות הזו אם רוצים שהמיפוי של דיסקים זמניים לאחסון ביניים למארח יישאר גם אחרי העברת הנתונים. מיפוי ה-LUN מתבצע במהלך העבודה הראשונה, וכל העבודות הבאות משתמשות באותו LUN ממופה. האפשרות הזו מסומנת כברירת מחדל.
    הערה: המערכת מתעלמת מהאפשרות הזו באפליקציות שמנוהלות באמצעות סוכן Backup and DR (כמו מסד נתונים של SQL) כשהאפליקציה נמצאת במערכת הפעלה שפועלת בתוך מכונה וירטואלית של VMware. המיפוי של דיסק הביניים ל-VM תמיד מבוטל אחרי כל משימה.
    •
  • ביטול המיפוי של דיסקים של סביבת פיתוח אחרי כל משימה. האפשרות הזו גם מבטלת את הקישור של דיסק האחסון הזמני ממערכת ההפעלה בסיום כל עבודה (הסרת נקודות הקישור או אותיות הכונן), וגם מבטלת את המיפוי שלו מהמארח לגמרי. כדי להשתמש באפשרות הזו, המארח צריך לבצע סריקה של יחידות LUN של SCSI בתחילת העבודה הבאה, כי צריך לגלות מחדש את דיסקי הביניים שמופו מחדש לפני שאפשר להרכיב אותם מחדש.
    •
    חיתוך (ניקוי) של היומן אחרי הגיבוי מציינים אם לחתוך (למחוק) את יומני מסד הנתונים אחרי כל גיבוי. כשהאפשרות Truncate Log After Backup מופעלת, יומני רישום שקשורים לאפליקציה נחתכים עד לגיבוי האחרון או הנוכחי. אם חותכים את היומנים, צריך גם לגבות את יומן העסקאות כדי לאפשר שחזור קדימה.
    האפשרויות הן:
  • לא לחתוך או למחוק את היומן אחרי הגיבוי
    •
  • חיתוך או מחיקה של יומן אחרי גיבוי
    •
    Skip Offline Applications
    (לניהול קבוצת עקביות בלבד)    		 מציינים אם להתעלם מאפליקציות לא זמינות ששייכות לקבוצת אפליקציות עקביות. אתם יוצרים קבוצת עקביות כדי לגבות את הנתונים של כל האפליקציות החברות יחד, וכך לשמור על עקביות הנתונים בכל האפליקציות החברות. קבוצות עקביות הן אוספים של אפליקציות שזוהו מאותו מארח.
    האפשרויות הן:
  • הגיבוי ייכשל אם יימצאו אפליקציות אופליין
    •
  • דילוג על אפליקציות אופליין במהלך הגיבוי
    •
    מיפוי דיסקים של אזור ההמתנה לכל הצמתים באשכול אפליקציות אם הצמתים נמצאים באשכול אפליקציות, אפשר להשתמש באפשרות הזו כדי לוודא שהצמתים של אשכול האפליקציות מוגנים במקרה של יתירות כשל במהלך הגיבוי.
  • לא ממפים את דיסק הביניים לכל הצמתים של אשכול האפליקציה.
    •
  • מיפוי דיסק ההכנה לכל הצמתים של אשכול האפליקציות
    במקרה של כשל באשכול האפליקציות, האפשרות הזו מגנה על עותקי הגיבוי למעבר לגיבוי.
    •
    מיפוי של דיסק ההעברה לכל המארחים של ESX באשכול
    (למכונות וירטואליות של VMware בלבד)     		אם שרתי ה-ESX שלכם נמצאים במכשיר, אתם יכולים להשתמש בהגדרה הזו כדי לוודא שמכונות ה-VM מנוהלות במקרה של יתירות כשל במהלך הגיבוי. במקרה של כשל במארח ESX, האפשרות הזו מנהלת עותקי מעבר לגיבוי במקרה כשל של מכונות וירטואליות של VMware. ‫(Oracle, מערכות קבצים מקומיות, SMB, ‏ NFS, ‏ SQL Server):
  • מיפוי דיסק ההעברה למארח ESX רק עבור מכונה וירטואלית
    •
  • מיפוי של דיסק האחסון הזמני לכל מארחי ESX באשכול
    •
  • מיפוי של דיסק ביניים לשני מארחי ESX באשכול
    •
    גיבוי של התחברויות משתמשים ל-SQL Server משיג את פרטי הכניסה למסד הנתונים של SQL Server. כשמסד הנתונים מותקן כאפליקציה וירטואלית (התקנה מודעת לאפליקציה), למסד הנתונים הווירטואלי יש את כל פרטי הכניסה שמשמשים את המקור. האפשרויות הן כן או לא.
    הפעלת גיבוי של יומן מסד הנתונים האפשרות Enable Database Log Backup (הפעלת גיבוי של יומן מסד הנתונים) מאפשרת למדיניות של תוכנית הגיבוי לגבות מסד נתונים ואת כל קובצי יומן העסקאות שמשויכים אליו. הגיבוי של היומנים מתבצע כשמופעלת פעולת צילום המצב של היומן. האפשרויות הן 'כן' או 'לא'. אם בוחרים באפשרות כן, האפשרויות הקשורות מופעלות.
    הערה: פרטים על הגנה על יומנים זמינים במאמר בנושא הגנה על יומני מסדי נתונים במדיניות של תוכנית גיבוי.
    RPO כשהאפשרות Enable Database Log Backup מוגדרת לערך Yes, ‏ RPO מגדיר את התדירות של גיבוי יומן מסד הנתונים. התדירות מוגדרת בדקות ולא יכולה לחרוג ממרווח הגיבוי של מסד הנתונים. הערך הקטן ביותר שאפשר להגדיר (בדקות) הוא 15.
    תקופת השמירה של גיבוי היומן
    (בימים)    		 אם האפשרות Enable Database Log Backup (הפעלת גיבוי של יומן מסד הנתונים) מוגדרת ל-Yes (כן), שמירת היומן מוגדרת בנפרד משמירת תמונת המצב של מדיניות השמירה. תקופת שמירה נפרדת מאפשרת לכם להשתמש ביומנים בשילוב עם עותקים של מסד הנתונים שמאוחסנים במאגר תמונות המצב. הגדרת תקופת השמירה של היומנים היא חובה.
    ‫Replicate Logs
    (משתמש בטכנולוגיית Streamsnap)    		 אם ההגדרה Enable Database Log Backup (הפעלת גיבוי של יומן מסד הנתונים) מוגדרת לערך Enable (הפעלה), ההגדרה המתקדמת Replicate Logs (שכפול יומנים) מאפשרת לשכפל יומנים של מסד נתונים למכשיר מרוחק. כדי להפעיל שכפול של יומן, צריך לכלול בתבנית מדיניות שכפול של streamsnap, יחד עם פרופיל משאב שמציין מכשיר מרוחק. בנוסף, צריך להשלים קודם לפחות שכפול אחד מוצלח של מסד הנתונים. אחר כך תוכלו להשתמש ביומנים באתר המרוחק לכל גיבוי של מסד נתונים בטווח השמירה של היומנים המשוכפלים. הפונקציה הזו מופעלת כברירת מחדל.
    שכפול יומנים משתמש בטכנולוגיית streamsnap כדי לבצע את השכפול בין מכשירי ה-appliance המקומיים והמרוחקים. שכפול היומנים מתבצע ישירות ממאגר תמונות המצב המקומי אל מאגר תמונות המצב במכשיר ה-appliance המרוחק.
    הערה: שכפול היומן מתבצע רק אחרי שהמסד נתונים מוגן והגיבוי משוכפל למכשיר המרוחק.
    שליחת יומנים אל OnVault Pool אם בוחרים באפשרות כן, היומנים משוכפלים למאגרי אחסון של OnVault, וכך ניתן לבצע שחזורים מנקודת זמן מסוימת מ-OnVault באתר אחר.
    הערה: אם בוחרים באפשרות הזו, Backup and DR שולח יומנים לכל מאגר OnVault שמוגדר בפרופיל של האפליקציה. אם יש שני מאגרי נתונים בפרופיל, במסך יופיעו משימות OnVault (log) לכל גיבוי של יומן, אחת לכל מאגר. היומנים יתקבלו רק במאגרי OnVault שנכללים בפרופיל של הסכם ה-SLA הזה.
    • שמירת היומנים שמשוכפלים ל-OnVault דומה לשמירת יומני תמונות מצב.
    • שכפול יומני מאגר נתונים לקטגוריית OnVault שונה מגיבוי של מאגר נתונים. אם בוחרים באפשרות Send logs to OnVault Pool (שליחת יומנים למאגר OnVault),‏ Backup and DR ישכפל את היומנים באופן רציף לדליים של OnVault, בדומה לגיבויים של תמונות מצב של יומנים. לדוגמה, אם מתבצע גיבוי של יומן כל 15 דקות, היומנים ישוכפלו ל-OnVault כל 15 דקות כדי להבטיח שכל תמונות המצב של היומנים ישוכפלו למאגרי OnVault.
    • מזהה המדיניות שמוצג במסוף הניהול של ה-appliance הוא מזהה המדיניות של התמונה, כי השכפול הזה של היומנים לדליים ב-OnVault קשור למדיניות של התמונה.
    הערה: מדיניות OnVault שמוגדרת לגיבוי יומי, שבועי, חודשי ושנתי רלוונטית רק לגיבויים של מסדי נתונים, ולא לגיבויים של יומנים.
    הגידול בגודל של דיסק ההמתנה של היומן (באחוזים) כשההגדרה Enable Database Log Backup (הפעלת גיבוי של יומן מסד הנתונים) מוגדרת לערך Yes (כן), ההגדרה Log Staging Disk Growth Size (גודל הגידול של דיסק האחסון הזמני של היומן) מגדירה את הגידול שייעשה כשדיסק האחסון הזמני שבו נמצאים היומנים יגדל באופן אוטומטי. ההגדרה הזו היא בין 5 ל-100 אחוזים.
    שיעור השינוי המשוער אם ההגדרה Enable Database Log Backup (הפעלת גיבוי של יומן מסד הנתונים) מוגדרת לערך Yes (כן), ההגדרה הזו מגדירה את השינוי היומי (באחוזים), ומאפשרת למכשיר לחשב בצורה טובה יותר את הגודל של דיסק האחסון הזמני שנדרש לאחסון היומנים. ההגדרה הזו היא בין 0 ל-100.
    Compress Database Log Backup כשההגדרה Enable Database Log Backup (הפעלת גיבוי של יומן מסד הנתונים) מוגדרת לערך Yes (כן), ההגדרה הזו מורה למסד הנתונים של המקור לדחוס את היומנים שלו לפני שהם נלכדים על ידי מסוף הניהול של ה-appliance. שרת מסד הנתונים מבצע דחיסה של היומן במהלך גיבוי היומן. האפשרויות הן Yes או No. אם בוחרים באפשרות Yes, האפשרות Compress Database Log Backup מופעלת.
    שימור נאכף המשתמש יכול להגדיר את תקופת אי-השינוי בין אפס ל-36,525 ימים. כברירת מחדל, הערך שמוגדר הוא אפס לכל המדיניות הקיימת.
    אפשר לשנות מדיניות שכבר נמצאת בשימוש להגנה על אפליקציה על ידי הגדרת תקופת שמירה ארוכה יותר. עם זאת, אי אפשר לקצר את תקופת השמירה שנאכפת.
    אי אפשר להגדיר שמירה מאולצת למדיניות של תמונת מצב של זרם שהשמירה שלה היא 'שמירת התמונה המרוחקת העדכנית בלבד'.
    הערה: אי אפשר לבטל את האכיפה של מדיניות השמירה ברמת האפליקציה. האפשרות לא מופיעה בדף Policy Overrides.
    הערה: הגדרת המדיניות המתקדמת שמירת נתונים נאכפת לא תואמת להגנה על אפליקציות שמפנה לכספת גיבוי. כשכספת גיבוי היא יעד האחסון, כספת הגיבוי קובעת את תקופת השמירה שנאכפת.
    התנהגות של משימה כשצריך לאחד תמונות מצב של מכונת VM בוחרים פעולה אם המכונה הווירטואלית דורשת איחוד:
  • המשימה תיכשל אם צריך לאחד את מכונת ה-VM: משימות נקודתיות ייכשלו.
    •
  • הפעלת העבודה בלי לבצע איחוד: כל העבודות מופעלות כרגיל גם אם איחוד ממתין.
    •
  • ביצוע איחוד בתחילת העבודה: משימות של נקודת זמן מנסות לבצע איחוד בתחילת העבודה. אם האיחוד נכשל, המשימה נכשלת ומוצגת הודעת שגיאה.
    •
    Fail On Missing Start Path אם מציינים נתיב התחלה אחד או יותר, ואחד מנתיבי ההתחלה האלה לא קיים, המשימה נכשלת ומוצגת ההודעה UDSAgent: Specified start path doesn't exist. אם לא מציינים נתיבי התחלה, לא תהיה לאפשרות הזו השפעה. האפשרויות הן Yes או No.
    הערה: מצב ברירת המחדל של האפשרות הזו הוא No (מושבת), שזהה להתנהגות של הגרסאות הקודמות של הסוכן Backup and DR. העבודה לא נכשלת אם נתיב ההתחלה לא קיים.
    הפעלת מצב צילום באיכות נמוכה מצב לכידה מוגבל מאפשר לכידה של נתונים מצטברים כששירות המעקב אחר בלוקים שהשתנו (CBT) לא זמין. יכול להיות שייקח יותר זמן לתעד את הנתונים. האפשרויות הן כן או לא.
    ‫Script Timeout
    (applicable only for agent based backups)    		 הסוכן Backup and DR מאפשר ליצור סקריפטים בצד המארח שמופעלים במארח של אפליקציה לפני או אחרי הפעלה של מדיניות. ארבעת ערכי הזמן הקצוב לתפוגה שמופיעים בתבנית מדיניות ממופים ישירות לארבעת השלבים של תסריט בצד המארח.
    הערה: כברירת מחדל, ערכי הזמן הקצוב לתפוגה של הסקריפט הם הערכים הבאים. אם לא מציינים זמן קצוב לתפוגה של סקריפט, הערך ריק ומשתמשים בברירת המחדל.
  • Script Init Timeout: הגדרה שמגדירה כמה זמן עבודה צריכה לחכות לסקריפט שמופעל במארח לפני שהעבודה מבצעת פעולה כלשהי. אם הסקריפט לא יסתיים לפני שיפוג הזמן, העבודה תיכשל. ערך ברירת המחדל הוא 60 שניות. הטווח המותר הוא בין שנייה אחת ל-86,400 שניות.
    •
  • Script Freeze Timeout: מגדיר כמה זמן מדיניות צריכה לחכות לסקריפט שמופעל כדי להקפיא אפליקציה, לפני שנוצרת תמונת מצב. אם הסקריפט לא יושלם לפני שתפוג ההמתנה, העבודה תיכשל. ערך ברירת המחדל הוא 60 שניות. הטווח המותר הוא בין שנייה אחת ל-86,400 שניות.
  • Script Unfreeze Timeout: מגדיר כמה זמן מדיניות צריכה לחכות לסקריפט שמופעל כדי להקפיא אפליקציה, אחרי שנוצר צילום מצב. אם הסקריפט לא יסתיים לפני שיפוג הזמן, העבודה תיכשל. ערך ברירת המחדל הוא 60 שניות. הטווח המותר הוא בין שנייה אחת ל-86,400 שניות.
  • Script Finish Timeout: מגדיר כמה זמן מדיניות צריכה להמתין לסקריפט שמופעל בסוף התהליך. אם הסקריפט לא מסתיים לפני שתוקף הזמן הקצוב לתפוגה מסתיים, העבודה נכשלת. ערך ברירת המחדל הוא 60 שניות. הטווח המותר הוא בין שנייה אחת ל-86,400 שניות.
    		•

    המאמרים הבאים