שאלת Logים וגיבויים ב- Exchange

[sysnt]

שאלת Logים וגיבויים ב- Exchange

קראתי מס' שורות שמישהו כתב פה בפורום ויש לי שאלה: כתוב שכל פעולה שנעשית (מחיקת מייל שינוי יצירה ... ) נרשמת קודם כל בקובץ לוג (edb.log שזה הקובץ הפעיל), כאשר הקובץ מגיע ל- 5 מגה הוא נסגר ונפתח אחד חדש (לכל קובץ יש מספר סידורי) ה- exchange בזמנו הפנוי מבצע commit ללוגים (כלומר מבצע את הפעולה ב-DB). עקרונית ניתן למחוק את הקבצים הלא פעילים א ב ל !!!!! : בדרך כלל משתמשים בהם כשיש נפילה של שרת ה- EXCHANE דוגמא: השרת נפל (טפו טפו חמסה חמסה) ביום חמישי, ויש לנו גיבוי מיום שלישי אז: משחזרים את השרת ליום שלישי (ודיר בלקום להעלות את ה- services של ה- exchange) מסדרים את כל קבצי הלוג מיום שלישי מייד אתרי הגיבוי ועד התאריך הכי מאוחר שיש, ומעלים את ה- services של ה- exchange ואז מה שקורה ה- exchange מבצע את הפעולות שכתובות בלוג וחוזר ממש לרגע הנפילה, לא הבנתי אם אני אמור תחילה לשחזר את השרת ורק אחרי זה לסדר את קבצי הלוג (איך אני עושה זאת? ). תודה

 

[slave of the mind]

ההנחה היא שיש שני גיבויים

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

 

[sysnt]

אוקיי אז אם ככה...

כשאתה מתכוון לגיבויי רציף של השרת-האם אתה מתכוון לגיבויי של ה mailboxes (ז"א ברמה של Brick Level) או לגיבויי של ה- Information store ? תודה

 

[ezaton]

כל זאת דובר רק על גיבוי IS

גיבוי Brick Level עוקף את המנגנון הזה וניגש דרך MAPI לכל תיבת דואר. התוצאה, אגב, היא ששחזור מאגר שלם מתוכו יקח המון זמן, וינפח לך מאוד את ה- DB. הוא מאוד שימושי, כמובן, כאשר אתה רוצה לשחזר פריט בודד. אצלי, לאחר תקופה ארוכה, הגעתי למסכנה שהגדרת ריקון ה- DB (כלומר, בהכרח למחוק הודעת דואר ממש, פשוט שכחתי את השם הטכני של זה) ארוכה מספיק, ביחד עם גיבוי IS מסודר, חוסכת את הצורך לבצע גיבוי Brick Level, וחוסכת המון זמן גיבוי (בערך 4-5 שעות אצלי, E2K, נפח של בערך 8GB, כ- 30 משתמשים, על שרת Dell PE1800sc).

 

[antidot]

בינגו

היתרון היחיד של גיבוי brick level הוא מהירות השיחזור של פריט/תיבה בודדים. מה גם שהגדרת retention נכונה ברב המקרים יכולה לחסוך גם את הצורך בשיחזור brick level. באירגונים גדולים עם IS-ים גדולים נדיר להתקל במצב של גיבוי brick level של כל האירגון. בד"כ מבצעים גיבוי כזה לתיבות קריטיות (יש לקרוא "בעלי תפקידים").

 

[ezaton]

וואלה, הוספת לי רעיון נחמד

בהחלט מרחיב את היריעה. לא חשבתי על זה, אבל אכן יתכן ויתקיים צורך לגבות כמה תיבות. אפילו לא חשבתי לפרק את ה- brick level (חיחיחי - To brick-level the brick level) לטובת כמה תיבות רגישות יותר...