האומנם הכול מגובה?

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

להלן כמה תרחישים בהם מתקיים הכשל הזה:

1.בשרת אין תוכנת דואר (כגון exchange) והמשתמשים עובדים מול התיבות שלהם אצל ספק האינטרנט ומורידים (למשל ל outlook) את הדואר.
במצב זה כל הנתונים שב outlook אינם מגובים (מיילים, יומני פגישות, ספר טלפונים..) והם נשמרים בתחנה אצל כל אחד.
אז מה הפתרון?, אז זהו… שאין פתרון..
אפשר – תיאורטית – להגדיר ב outlook שקבציו ישמרו בשרת ולא בתחנה, אלא שבפועל זה לא עובד טוב ויציב.
אפשר "ללמד" את המשתמש להעתיק/לגבות את קבצי ה outlook לשרת לצורך גיבוי כל יום, אבל גם זה לא ממש עובד, הן בגלל שהעובד "מחפף" והן בגלל שלעיתים הקבצים "פתוחים" ולא ניתן לגבותם.
אפשר להשתמש בתוכנות גיבוי שיגבו מהתחנות לשרת, אבל מעבר לעלויות הרכישה והתחזוקה – גם כאן יהיו בעיות של קבצים פתוחים.
ישנם עוד רעיונות "יצירתיים" לפתרון, אבל בשורה התחתונה – אין פתרון אמין, יציב ולא תלוי אדם.

2.בשרת יש תוכנת דואר ויש תהליך גיבוי מסודר, אבל למשתמש הוגדר גם personal folder.
הגדרה כזאת אינה "טבעית" ואנו מוצאים אותה במקומות בהם המשתמש לא רוצה שמידע מסוים ישב בשרת, חשוב להבין ולהבהיר למשתמש כי חומר זה אינו מגובה (ולא ניתן לגיבוי אמין ומוסדר – ראה סעיף קודם) שכן הוא נשמר בתחנה.

3.טעויות הגדרה, כגון :
יש exchange אבל המשתמשים מוגדרים מולו ב pop3 (ולכן החומר נשמר בתחנה ולא בשרת).
יש exchange ותוכנת גיבוי, אבל אין לתוכנת הגיבוי agent for exchange.
יש exchange ותוכנת גיבוי עם agent for exchange , אבל לא הוגדר לגבות גם ברמת break level.
יום א' לא מגובה אף פעם – זה "קוריוז" שנובע מכך שתוכנות הגיבוי נוצרו אצל הגויים ושם לא עובדים בימי א'…., כמובן שניתן לתקן את ההגדרה.
ואלו רק חלק מהדוגמאות.

4.תוכנות "לווין" בארגון – תוכנות המותקנות בתחנה ולא בשרת ומשמשות את המשתמש בלבד (למשל "מכפל" להכנת משכורות), בד"כ הארגון מסתמך על נהלי הגיבוי שהגיעו עם התוכנה (בד"כ גיבוי לדיסקטים – למי שעוד זוכר מה זה דיסקטים…) ועל המשתמש – וזה רע….
הפתרון הוא פשוט: העברת הקבצים להיות ע"ג השרת (תוך הטמעת נהלי אבטחת נתונים – במידת הצורך), הגדרת התוכנה בהתאם והפעלת agent for open file בגיבוי.
כל פתרון אחר (גיבוי ל flash, צריבה וכו') שבד"כ מציעים אותו על רקע של אבטחת נתונים (חשש לשמור חומר רגיש בשרת) – הוא חד משמעית פחות טוב, שכן הוא נסמך על המשתמש – ויותר גרוע מזה לא יכול להיות …

5.מידע "רגיש" – נתונים שנוצרו בתוכנות "רגילות" (word, excel וכו') אבל יש רגישות לשמירתם על השרת (חשש לשמור חומר רגיש בשרת):
אני אצטט מה שכתבתי בסעיף למעלה:
כל פתרון אחר (גיבוי ל flash, צריבה וכו') שבד"כ מציעים אותו על רקע של אבטחת נתונים (חשש לשמור חומר רגיש בשרת) – הוא חד משמעית פחות טוב, שכן הוא נסמך על המשתמש – ויותר גרוע מזה לא יכול להיות …

6.תוכנות בסיסי נתונים כגון SQL – גם כאן דרוש לתוכנת הגיבוי agent for SQL (למשל) ובלעדיו בלתי אפשרי לשחזר את הנתונים.
(ניתן "לעקוף" את הצורך ב agent וזאת ע"י הפעלת האפשרות ב SQL לגבות את הנתונים לקובץ "בצד").

7.תוכנות עם נתונים בשרת שנשארות "פתוחות": בין עם מדובר בתוכנות המותקנות בשרת (למשל חשבשבת DOS) ובין עם בתוכנות המותקנות בתחנה אך שומרות את המידע בשרת (word, excel וכו') – במידה והמשתמשים לא סוגרים את הקובץ ואת התוכנה עצמה , הקובץ "פתוח" ולא יגובה.
כשזה קורה "פה ושם" אין מה להתייחס, אבל כשזה ע"ב קבוע ואותו משתמש תמיד שוכח לסגור את הקובץ, אני מציע לא לנסות "לחנך" את המשתמש ופשוט לקנות לתוכנת הגיבוי את מודול ה agent for open file.

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

ולסיום ובפעם האלף – לגבות לקלטות ולשים את הקלטות במגרה, מעיד עליכם שאתם אופטימיים חסרי תקנה ומאמינים ששרפות וגניבות קורים לאחרים ולא לכם…

עוד בנושא טיפים ומידע בנושא שירותי IT