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

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

אפשר גם להציג ולשנות את הגדרות המדיניות של אפליקציות ספציפיות, על ידי הצגת החלונית של שינוי הגדרות המדיניות מהדף Manage Backup Plan של האפליקציה.

כדי להציג את דף הגדרות המדיניות, פועלים לפי ההוראות הבאות.

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

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

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

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

    כדי לטעון קובץ snapshot של Windows Compute Engine כמכונה וירטואלית חדשה או קיימת שצולמה באמצעות האפשרות Application consistent, צריך לשנות את הדיסק ממצב קריאה בלבד למצב קריאה וכתיבה. כדי לעשות את זה, פועלים לפי ההוראות בקטע אופציונלי: סימון הדיסק כזמין לקריאה ולכתיבה.
  • ‫Take crash consistent backup on last try: האפשרות הזו מבצעת בהתחלה גיבויים כוללי ריקון מידע, אבל אם גיבוי כולל ריקון מידע נכשל מסיבה כלשהי, היא מבצעת גיבוי ללא ריקון מידע.
    •
    מיקום קובץ ה-snapshot
    (רלוונטי רק למכונות של Compute Engine ו-SAP HANA)    		 בוחרים את האזור שבו רוצים לאחסן את קובצי ה-snapshot של Persistent Disk. כברירת מחדל, נבחרת האפשרות "מספר אזורים" (על סמך המיקום של דיסק המקור). אפשר גם לשנות את מיקום האחסון של קובץ snapshot לאזור אחר מזה של דיסק המקור. כששומרים קובצי snapshot במיקום שונה מהמיקום של דיסק המקור, הנתונים עוברים ברשת בין המיקומים האלה, ויכול להיות שתחויבו בעמלות רשת. העמלות על קובצי Snapshot זהות לעמלות על העברת נתונים ב-Cloud Storage. למידע נוסף על תמונת מצב של Persistent Disk. למידע נוסף על המחירים, קראו את המאמר תמחור דיסקים.
    סוג תמונת המצב      
    (רלוונטי רק למכונות של Compute Engine ו-SAP HANA)    		בוחרים את סוג קובץ ה-snapshot של Persistent Disk שבו רוצים להשתמש לגיבויים של מכונות Compute Engine. תמונות מצב מגבות נתונים באופן מצטבר מדיסקים לאחסון מתמיד. במהלך הגיבויים, נוצרת תמונת מצב חדשה כדי לתעד את המצב הנוכחי של Persistent Disk, ואפשר להשתמש בה מאוחר יותר כדי ליצור דיסק חדש לטעינה או לשחזור. כדי להבטיח את תקינות הנתונים, Compute Engine שומר כמה עותקים של כל קובץ snapshot בכמה מיקומים, עם סיכומי ביקורת (checksum) אוטומטיים. מידע נוסף על קובץ snapshot של Persistent Disk למידע נוסף על המחירים, קראו את המאמר תמחור דיסקים.
  • רגיל: כברירת מחדל, נבחר סוג תמונת המצב הרגיל. מומלץ להשתמש בסוג הסטנדרטי אם רוצים לשמור את הגיבויים למשך פחות מ-90 יום.
  • ‫Archive: בחרו בסוג Archive אם אתם רוצים לשמור את הגיבויים למשך זמן רב. חשוב לזכור שתקופת החיוב המינימלית של קובץ snapshot של ארכיון היא 90 יום, בלי קשר לתקופת השמירה שמוגדרת במדיניות. בנוסף, אם משתמשים בסוג Archive בפעולת טעינה או שחזור, יש חיוב נוסף על אחזור.
    •       
    הקצאת יתר של דיסק ה-Staging
    (באחוזים)    		 מציינים את המקום הנוסף שמוקצה לדיסק ה-staging (מעבר למה שבאמת נדרש) כדי להתאים לצמיחה של האפליקציה. ההגדרה הזו היא בין אפס ל-1,000 אחוזים.
    נתיבי גיזום גלובליים לא לגבות את הספריות האלה (צריך לציין את הנתיב המלא). כדאי לעיין גם בערכים של Global Prune Paths ברמת המדיניות.
    דחיסת Streamsnap Replication כברירת מחדל, הדחיסה של רפליקציית streamsnap מופעלת. הדחיסה מגבירה את היעילות של שכפול ה-streamsnap למכשיר הגיבוי/השחזור המרוחק כשמעבירים נתונים ברשת, למשל כשמשכפלים גיבויים וסרטונים. כשהדחיסה מופעלת, כל החבילות נדחסות. מכשיר הגיבוי/השחזור של היעד מבטל את הדחיסה של החבילות לפני הכתיבה לדיסק ה-staging. אם לא צריך דחיסה בשביל רפליקציית streamsnap למכשיר הגיבוי/השחזור השני, משנים את ההגדרה המתקדמת של דחיסת רפליקציית streamsnap ל-Don't compress ולוחצים על Save Changes.
    הערה: אפשר להשתמש ברפליקציה של Streamsnap רק במכשירי גיבוי/שחזור שפרוסים ברשת אחת.
    לא לבטל את המיפוי ההגדרה הזו קובעת אם דיסקים זמניים של אזור ביניים שממופים למארח ומשמשים להעברת נתונים לצורך גיבוי, יישארו ממופים למארח. מספרי ה-LUN ממופים במהלך המשימה הראשונה, ובכל המשימות הבאות נעשה שימוש חוזר באותו LUN ממופה. בוחרים באחת מהאפשרויות הבאות:
  • שמירה על מיפוי הדיסקים של שלבי הביניים בין המשימות. צריך לבחור באפשרות הזו אם רוצים שהדיסקים הזמניים של ה-staging, שממופים למארח ומשמשים במהלך העברת הנתונים, יישארו ממופים למארח. מספרי ה-LUN ממופים במהלך המשימה הראשונה, ובכל המשימות הבאות נעשה שימוש חוזר באותו LUN ממופה. האפשרות הזו מסומנת כברירת מחדל.
    הערה: באפליקציות שמנוהלות באמצעות סוכן Backup and DR (כמו מסד נתונים של SQL), שבהן האפליקציה נמצאת במערכת הפעלה שפועלת בתוך מכונה וירטואלית של VMware, המערכת מתעלמת מהאפשרות הזו. המיפוי של דיסק ה-staging תמיד מבוטל מה-VM אחרי כל משימה.
    •
  • ביטול המיפוי של דיסקים זמניים אחרי כל משימה. האפשרות הזו גם מבטלת את הטעינה של דיסק ה-staging ממערכת ההפעלה בסיום כל משימה (הסרת נקודות טעינה או אותיות כונן), וגם מבטלת את המיפוי שלו מהמארח לחלוטין. כדי להשתמש באפשרות הזו, המארח צריך לבצע סריקה של מספרי LUN של SCSI בתחילת המשימה הבאה, כי צריך לגלות מחדש את הדיסקים הזמניים שמופו מחדש לפני שאפשר יהיה לטעון אותם מחדש.
    •
    Truncate (Purge) Log After Backup מציינים אם לקטוע (למחוק) את יומני מסד הנתונים אחרי כל גיבוי. כשהאפשרות Truncate Log After Backup מופעלת, היומנים שקשורים לאפליקציה נחתכים עד לגיבוי האחרון או הנוכחי. אם אתם מקצרים את היומנים, אתם צריכים גם לגבות את יומן העסקאות כדי לאפשר שחזור של roll forward.
    האפשרויות הן:
  • לא לחתוך או לנקות את היומן אחרי הגיבוי
    •
  • קיצור או מחיקה של היומן אחרי הגיבוי
    •
    דילוג על אפליקציות אופליין
    (לניהול קבוצת אפליקציות עקביות בלבד)    		 הגדרת התעלמות מאפליקציות לא זמינות שהן חלק מקבוצת אפליקציות עקביות. אתם יוצרים קבוצת אפליקציות עקביות כדי לגבות את הנתונים של כל האפליקציות שחברות בקבוצה ביחד, וכך לשמור על עקביות הנתונים בכל האפליקציות שחברות בקבוצה. קבוצות אפליקציות עקביות הן אוספים של אפליקציות שזוהו מאותו מארח.
    האפשרויות הן:
  • הגיבוי נכשל כשנמצאות אפליקציות אופליין
    •
  • דילוג על אפליקציות אופליין במהלך הגיבוי
    •
    מיפוי דיסקים זמניים לכל הצמתים באשכול של אפליקציה אם הצמתים נמצאים באשכול של אפליקציה, אפשר להשתמש באפשרות הזו כדי לוודא שהצמתים באשכול של האפליקציה מוגנים במקרה של יתירות כשל במהלך הגיבוי.
  • אל תמפו את דיסק ה-staging לכל הצמתים של אשכול האפליקציה.
    •
  • מיפוי דיסק ה-staging לכל הצמתים של אשכול האפליקציה
    במקרה של כשל באשכול האפליקציה, האפשרות הזו מגינה על עותקי יתירות הכשל.
    •
    מיפוי דיסק ה-Staging לכל מארחי ה-ESX באשכול
    (למכונות וירטואליות של VMware בלבד)     		אם שרתי ה-ESX נמצאים במכשיר, אפשר להשתמש בהגדרה הזו כדי לוודא שהמכונות הווירטואליות מנוהלות במקרה של יתירות כשל במהלך הגיבוי. במקרה של כשל במארח ESX, האפשרות הזו מנהלת עותקים של יתירות כשל של מכונות וירטואליות של VMware. ‫(Oracle, מערכות קבצים מקומיות, SMB, ‏ NFS, ‏ SQL Server):
  • מיפוי דיסק ה-staging למארח ESX ל-VM בלבד
    •
  • מיפוי דיסק ה-staging לכל מארחי ה-ESX באשכול
    •
  • מיפוי דיסק ה-staging לשני מארחי ESX באשכול
    •
    גיבוי פרטי הכניסה של משתמשי SQL Server מתעד את פרטי הכניסה למסד הנתונים של SQL Server. כשמסד הנתונים נטען כאפליקציה וירטואלית (טעינה עם מודעות לאפליקציה), מסד הנתונים הווירטואלי כולל את כל פרטי הכניסה שמשמשים את המקור. האפשרויות הן כן או לא.
    הפעלת גיבוי של יומן מסד הנתונים האפשרות Enable Database Log Backup מאפשרת למדיניות של תוכנית הגיבוי לגבות מסד נתונים ואת כל קובצי יומן הטרנזקציות שמשויכים אליו. היומנים מגובים כשמשימת תמונת המצב של היומן פועלת. האפשרויות הן "כן" או "לא". אם בוחרים באפשרות כן, האפשרויות הקשורות מופעלות.
    הערה: לפרטים על הגנה על יומנים, קראו את המאמר הגנה על יומני מסד נתונים במדיניות של תוכנית גיבוי.
    RPO כשהאפשרות Enable Database Log Backup מוגדרת ל-Yes, ה-RPO מגדיר את התדירות של גיבוי יומן מסד הנתונים. התדירות מוגדרת בדקות, והיא לא יכולה להיות גדולה יותר ממרווח הזמן של גיבוי מסד הנתונים. הערך הקטן ביותר שאפשר להגדיר (בדקות) הוא 15.
    תקופת השמירה של גיבוי היומן
    (בימים)    		 כשהאפשרות Enable Database Log Backup מוגדרת ל-Yes, שמירת היומן מוגדרת בנפרד משמירת מדיניות תמונת המצב. תקופת שמירה נפרדת מאפשרת להשתמש ביומנים בשילוב עם עותקים של מסד הנתונים שמאוחסנים במאגר תמונות המצב. תקופת השמירה של היומן היא הגדרת חובה.
    שכפול יומנים
    (באמצעות טכנולוגיית Streamsnap)    		 כשההגדרה Enable Database Log Backup מוגדרת ל-Enable, ההגדרה המתקדמת Replicate Logs מאפשרת לשכפל את יומני מסד הנתונים למכשיר מרוחק. כדי להריץ משימה של שכפול יומנים, התבנית צריכה לכלול מדיניות שכפול של streamsnap ופרופיל משאבים שמציין מכשיר מרוחק, וצריך להשלים לפחות שכפול אחד של מסד הנתונים. לאחר מכן, תוכלו להשתמש ביומנים באתר המרוחק לכל גיבוי של מסד נתונים בטווח השמירה של היומנים המשוכפלים. הפונקציה הזו מופעלת כברירת מחדל.
    שכפול היומנים משתמש בטכנולוגיית streamsnap כדי לבצע את השכפול בין המכשירים המקומיים והמרוחקים. שכפול היומנים עובר ישירות ממאגר קובצי ה-snapshot המקומי למאגר קובצי ה-snapshot במכשיר המרוחק.
    הערה: שכפול היומן לא מתרחש עד שמסד הנתונים מוגן והגיבוי משוכפל למכשיר המרוחק.
    שליחת יומנים למאגר OnVault אם מגדירים Yes, היומנים משוכפלים למאגר אחסון אחד או יותר של OnVault, וכך אפשר לבצע שחזור מנקודה מסוימת בזמן (PITR) מ-OnVault באתר אחר.
    הערה: אם בוחרים באפשרות הזו, Backup and DR שולח יומנים לכל מאגר OnVault שמוגדר בפרופיל של האפליקציה הזו. אם יש שני מאגרים בפרופיל, במסך יוצגו משימות OnVault (יומן) לכל גיבוי של יומן, אחת לכל מאגר. רק מאגרי OnVault שנמצאים בפרופיל של ה-SLA הזה יקבלו את היומנים.
    • שמירת היומנים שמשוכפלים ל-OnVault דומה לשמירת היומנים של תמונות המצב.
    • שכפול של יומני מסד נתונים לקטגוריית OnVault שונה מגיבוי של מסד נתונים. אם בוחרים באפשרות Send logs to OnVault Pool, Backup and DR ישכפל באופן רציף את היומנים לקטגוריות OnVault, בדומה לגיבויים של קובצי snapshot של יומנים. לדוגמה, אם גיבוי של יומן מתבצע כל 15 דקות, היומנים ישוכפלו ל-OnVault כל 15 דקות כדי להבטיח שכל קובצי ה-snapshot של היומנים ישוכפלו למאגרים של OnVault.
    • מזהה המדיניות שמוצג במסוף הניהול של המכשיר הוא מזהה המדיניות של תמונת המצב, כי השכפול הזה של היומנים לקטגוריות של OnVault קשור למדיניות של תמונת המצב.
    הערה: כללי המדיניות של OnVault לגיבוי יומי, שבועי, חודשי ושנתי מיועדים רק לגיבויים של מסדי נתונים, ולא חלים על גיבויים של יומנים.
    Log Staging Disk Growth Size (In Percent) כשההגדרה Enable Database Log Backup מוגדרת לערך Yes, ההגדרה Log Staging Disk Growth Size קובעת את גודל ההרחבה האוטומטית של דיסק ה-Staging שבו נמצאים היומנים. ההגדרה הזו היא בין 5% ל-100%.
    שיעור השינוי המשוער כשהאפשרות Enable Database Log Backup מוגדרת כ-Yes, ההגדרה הזו קובעת את השינוי היומי (באחוזים), שמאפשר למכשיר לחשב טוב יותר את גודל דיסק ה-staging שנדרש כדי להכיל את היומנים. ההגדרה הזו היא בין אפס ל-100.
    דחיסת הגיבוי של יומן מסד הנתונים כשהאפשרות Enable Database Log Backup מוגדרת כ-Yes, ההגדרה הזו מורה למסד הנתונים של המקור לדחוס את היומנים שלו לפני שהם נלכדים על ידי מסוף הניהול של המכשיר. שרת מסד הנתונים מבצע דחיסת יומנים במהלך גיבוי היומנים. האפשרויות הן Yes או No. כשמגדירים את האפשרות Yes, האפשרות Compress Database Log Backup מופעלת.
    שמירה כפויה מאפשר למשתמש להגדיר את תקופת חוסר השינוי בין אפס ל-36,525 ימים. כברירת מחדל, הערך מוגדר כאפס בכל כללי המדיניות הקיימים.
    אפשר לשנות מדיניות שכבר משמשת להגנה על אפליקציה, על ידי הגדרת תקופת שמירה ארוכה יותר לאכיפה. עם זאת, אי אפשר לקצר את תקופת השמירה שנאכפת.
    אי אפשר להגדיר שמירת נתונים באכיפה למדיניות של streamsnap ששמירת הנתונים שלה היא "שמירה רק של התמונה המרוחקת האחרונה".
    הערה: אי אפשר לשנות את ההגדרה אכיפת שמירה לכל אפליקציה בנפרד. האפשרות לא מופיעה בדף שינוי ברירת המחדל של המדיניות.
    הערה: הגדרת המדיניות המתקדמת Enforced Retention לא תואמת להגנה על אפליקציות שמפנה לכספת גיבוי. כשכספת גיבוי היא יעד האחסון, כספת הגיבוי קובעת את תקופת השמירה שנאכפת.
    התנהגות המשימה כשהמכונה הווירטואלית המטורגטת צריכה איחוד של קובצי Snapshot בוחרים פעולה אם המכונה הווירטואלית דורשת איחוד:
  • העבודה נכשלת אם צריך לאחד את ה-VM: עבודות נקודתיות נכשלות.
    •
  • הפעלת המשימה בלי לבצע איחוד: כל המשימות פועלות כרגיל גם אם האיחוד בהמתנה.
    •
  • ביצוע איחוד בתחילת המשימה: במשימות נקודתיות, המערכת מנסה לבצע איחוד בתחילת המשימה. אם האיחוד נכשל, המשימה נכשלת ומוצגת הודעת שגיאה.
    •
    Fail On Missing Start Path אם מציינים נתיב התחלה אחד או יותר, ואחד מהם לא קיים, המשימה נכשלת ומוצגת ההודעה "UDSAgent: Specified start path doesn't exist". אם לא צוינו נתיבי התחלה, לאפשרות הזו אין השפעה. האפשרויות הן Yes או No.
    הערה: מצב ברירת המחדל של האפשרות הזו הוא No (מושבת), וזו אותה התנהגות כמו בגרסאות הקודמות של סוכן Backup and DR. המשימה לא נכשלת אם נתיב ההתחלה לא קיים.
    הפעלת מצב צילום מופחת מצב תיעוד מופחת מתעד נתונים מצטברים כששירות Change Block Tracking‏ (CBT) לא זמין. יכול להיות שתיעוד הנתונים יימשך יותר זמן. האפשרויות הן כן או לא.
    זמן קצוב לתפוגה של סקריפט
    (רלוונטי רק לגיבויים מבוססי-סוכנים)    		 סוכן Backup and DR מאפשר ליצור סקריפטים מצד המארח שפועלים במארח של האפליקציה לפני או אחרי הפעלת המדיניות. ארבעת פסקי הזמן שמופיעים בתבנית המדיניות ממופים ישירות לארבעת השלבים של סקריפט מצד המארח.
    הערה: כברירת מחדל, ערכי הזמן הקצוב לתפוגה של הסקריפט הם לפי הערכים הבאים. אם לא צוין זמן קצוב לתפוגה של סקריפט, הערך ריק ונעשה שימוש בברירת המחדל.
  • זמן קצוב לתפוגה של אתחול הסקריפט: משך הזמן שהמשימה צריכה להמתין לסקריפט שמופעל במארח לפני שהמשימה מבצעת פעולה כלשהי. אם הסקריפט לא מסתיים במסגרת הזמן הקצוב לתפוגה, המשימה נכשלת. ערך ברירת המחדל הוא 60 שניות. הטווח המותר הוא בין שנייה אחת ל-86,400 שניות.
    •
  • ‫Script Freeze Timeout: משך הזמן שהמדיניות צריכה להמתין לסקריפט שמופעל כדי להקפיא אפליקציה, לפני שנוצרת תמונת מצב. אם הסקריפט לא מסתיים בפרק הזמן הזה, המשימה נכשלת. ערך ברירת המחדל הוא 60 שניות. הטווח המותר הוא בין שנייה אחת ל-86,400 שניות.
  • Script Unfreeze Timeout: משך הזמן שהמדיניות צריכה להמתין לסקריפט שמופעל כדי להקפיא אפליקציה, אחרי שנוצרת תמונת מצב. אם הסקריפט לא מסתיים במסגרת הזמן הקצוב לתפוגה, המשימה נכשלת. ערך ברירת המחדל הוא 60 שניות. הטווח המותר הוא בין שנייה אחת ל-86,400 שניות.
  • ‫Script Finish Timeout: מגדירה כמה זמן המדיניות צריכה להמתין לסקריפט שמופעל בסוף המשימה. אם הסקריפט לא מסתיים במסגרת הזמן הקצוב לתפוגה, המשימה נכשלת. ערך ברירת המחדל הוא 60 שניות. הטווח המותר הוא בין שנייה אחת ל-86,400 שניות.
    		•

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