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

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

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

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

תקציר מנהלים SEIM + SOC + IRT + FORENSIC

המונחים האלו מתארים שרות חיצוני של "חברת שמירה" שמקבלת אליה התראות סייבר של הלקוח. זה דומה לעולם חברות השמירה שאתם מכירים מהשמירה על המשרדים והבתים: מערכות ההגנה שמנטרות ומזעיקות את חברת השמירה: (בעולם הפיזי זה גלאי נפח, מצלמות וכו', ותוכנות הבקרה והפקוח בחברת השמירה), בעולם הסייבר זה ה SEIM – security information and event management שזה אוסף התוכנות, […]

לפרטים

תוכנות שיתוף קבצים

לכל משתמשי קזה, מסנג'ר ושאר התוכנות השיתופיות לא אחת עובדינו נתקלים בהתקנות של תוכנות אלו אצל לקוחותינו השונים, בהתאם להנחייתנו עובדינו מנסים "בעדינות" לשכנע את הלקוח להסיר את התוכנות אבל לצערי לא תמיד מקבלים אישור לכך. מעבר לעומס המזעזע (!) שהתוכנות הללו יוצרות ברשת הפנימית וביציאה לאינטרנט (עומס שקשה מאוד לעמוד על סיבתו – בבואנו […]

לפרטים

חבילת אבטחת הנתונים ה"נכונה" ללקוחות הקטנים/בינוניים

עם שוך (יותר נכון: כנראה הפוגה בלבד) מתקפת הוירוסים האחרונה – שהוגדרה בעולם כמתקפה ההקשה ביותר אי פעם אני מתפנה להיענות לבקשת חלק ממכם ולהגדיר את חבילת האבטחה האופטימאלית ללקוחותינו, ההדגש במכתב לעיל הוא על נושא האנטי וירוס ועל מגזר הלקוחות הקטן/בינוני בלבד: 1. חברות ה ISP (ספקיות אינטרנט) משווקות שרות אנטי וירוס המפשיט את […]

לפרטים

זהירות – אחיזת עיניים!

אני מבקש לידע אתכם ב"עליית מדרגה" בתחכום מעשי הרמאות הנעשים בכלי האינטרנט. המדובר בדבר דואר המתחזה בצורה מושלמת להיות דואר של חברת פיננסים/ממשלתית/ביטוחית וכו' – ידועה. כתובת השולח נראית אותנטית, מבנה הדואר שמתקבל הוא בפורמט הרגיל המתקבל מאותו גוף, לעיתים הדואר הוא בפורמט של HTML וזהה מבחינה העיצוב והגרפיקה לדפי האתר האמיתיים. הדואר מספר סיפור […]

לפרטים

האם אתם מוציאים דואר שעלול להראות כדואר זבל

שלום לכולם, כידוע לכם עבר בארה"ב חוק המחייב פורמט ודרכי הפצה מאוד קשוחים של דואר לרשימות תפוצה. לכאורה הדבר אינו נוגע לנו כמפיצים פוטנציאליים, אלא דווקא משמח אותנו כ"נפגעי" דואר כנ"ל, אבל ……. ההגדרה של דואר זבל היא "נזילה" וכך – למשל – שליחת דואר (ואפילו ברכת חג שמח עם לוגו החברה…) לרשימת לקוחות ובינהם […]

לפרטים

שיחזור מגיבויים – שווה את הטרחה?

לא אחת אנו מתבקשים ע"י לקוחותינו לבצע שיחזור מדגמי מהטייפ וזאת כדי לוודא את תקינות הגיבויים. ברשותכם, כמה מילים על נושא זה: מטודולוגיית הגיבוי שלנו מכתיבה: 1. בעת התקנת הטייפ ו/או התוכנה לראשונה המתקין מבצע גיבוי ושיחזור ניסיוני. 2. אנו מגדירים ביצוע אוטומתי – בסוף כל גיבוי – של פעולת verify, דהינו: בסוף כל (!) […]

לפרטים

הגיבוי עובד, אבל השחזור?

שלום לכולם, בהמשך למאמר קודם שכתבתי על חשיבות הגיבויים ועל ההכרח לבדוק שאכן כל החומר החשוב מגובה, אני הפעם מבקש למקד את תשומת הלב בפן השני של הגיבוי השחזור. אנו נדרשים לשחזור חומר מגיבוי בתרחישים שונים, אבל המטרה העיקרית של הגיבוי זה להיות מסוגלים לשחזר את השרת במהירות ובאמינות – למצבו קודם לאסון. את המילה […]

לפרטים

תל אביב והמרכז

  • טלפון: 03-5610001
  • פקס: 03-5610055
  • בארי 51 תל אביב

חיפה והצפון

  • טלפון: 04-8643344
  • פקס: 04-8643343

כתובת לדואר

  • צור קשר info@schieber.net
  • תמיכה support@schieber.net
  • דרושים jobs@schieber.net
עיצוב וניהול אתר - בייטק תקשורת בע"מ

צור קשר