שרשור תגובות: חברת Synology מחלקת לכם 10 מכשירי NAS

[nadav]

לפני סיפור השחזור שלי, צריך הקדמה קצת ורקע על גיבוי נכון של מסדי נתונים Big Data בארגון כך שאם תקראו עד הסוף תבינו כיצד תובנות אלו יכולות להציל אתכם מקטסטרופה נוראית, אז קצת תובנות שלמדתי במשך הזמן על גיבויי מסד נתונים Big Data, שכבר מזמן הפך לעדיפות עבור רוב הארגונים, לפחות אלו המודעים לתפקיד המרכזי שיכולים נתונים אלו למלא בהצלחת הארגון.

ישנן תפישות שגויות ונפוצות סביב גיבוי, כמה תפישות שגויות לדעתי:

• א. העתקים מרובים של נתונים מבטל את הצורך בכלי גיבוי נפרדים עבור ה-Big Data.

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

• ב. ניתן לבצע בנייה מחדש ובמהירות לנתונים מנתוני ה-RAW המקוריים.

זה למעשה עלול לעבוד, אבל בתנאי שיש לכם את כל ה-RAW DATA המקוריים לבנות מהם, אולם ברוב המקרים דווקא נתוני ה-RAW הם אלו שהולכים קפוט, או שנמחקו או שלא ניתן לגשת אליהם בקלות. אפילו אם כן, בניה שכזו לכמויות מידע בסדר גודל ארגוני יכולה לקחת שבועות אשר יגרמו לבזבוז משאבי IT והנדסה יקרים והנתונים בינתיים לא יהיו זמינים.

• ג. גיבוי של המון מידע לא שווה כלכלית ולא פרקטי (פטה בייט של מידע לפחות!)

גיבוי מלא תקופתי של פטה בייט של מידע, ידרוש שבועות ויחוייב בשקעה בתשתית של מעל לחצי מליון דולר, עם זאת, ישנם מספר דברים שניתן לעשות כדי להקל על גיבוי מסוג שכזה. ניתן לזהות קבוצות נתונים חשובות/קריטיות ולגבות רק נתונים אלו, להשתמש בטכנולוגיות גיבוי חדשות יותר, כפילויות (deduplication) כדי לאחסן את הגיבויים ביעילות, שימוש בשיטת incremental-forever בכדי להעביר רק את השינויים בנתונים, שימוש בשרתים בסיסיים כדי להוזיל עלויות (רק צריכים אחסון!) זאת ועוד...

• ד. העתקים של התאוששות מרוחקים (Remote disaster) יכולים לשמש כעותק לגיבוי.

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

• ה. כתיבת סקריפט לגיבוי / שחזור עבור נתונים זהו דבר פשוט.

סקריפטים טובים, אם יש לחברה משאבים הנדסיים לתחזק אותם או כמות קטנה של נתונים ופלטפורמת Big Data בודדה, לרוב זהו איננו המצב. ברוב הארגונים יש בין 10-100TB של Big-Data המתפרש על מספר פלטפורמות נתונים. זהו לא קל לכתוב, לבדוק ולתחזק סקריפטים לסוגי סביבות אלו. עבור כל סביבה יש לכתוב סקריפט ייעודי (למשל אחד עבור Cassandra, סקריפט נוסף עבור Hadoop וכו...). על הסקריפטים להבדק בכל שדרוג של גרסה של הפלטפורמה, במספר מקרים, הסקריפטים צריכים להיות מעודכנים גם בעדכון של Feature בפלטפורמה, ייתכן ויהיו APIים חדשים, מבנה נתונים עדכני וכיוצ"ב.
הרבה ארגונים לא מעריכים את העלויות הנסתרות הנוספות כאן והמומחיות הנדרשת לתחזוקת סקריפטים אלו. הליך השחזור איננו פשוט גם כן, צריך למצוא את עותק הגיבוי התואם, העתקה ל-Node המתאים וביצוע השחזור בהתאם לתנאי ונתוני הפלטפורמה הנוכחית ותנאיה לשחזור הנתונים בצורה המתאימה ביותר

• ו. עלויות גיבוי/שחזור נתוני Big Data הן מאוד קטנות.

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

• 1. עלויות כח אדם: אחריות להפעלת הסקריפטים, להבטיח גיבויים מוצלחים, ניפוי השגיאות במידת הצורך (Debuggin) ביצוע Recovery במידת הצורך וכו'..
• 2. עלויות אחסון – ההוצאות הנדרשות לאחסון גיבויים.
• 3. עלויות השבתה – במהלך הזמן שלוקח למנהל המערכת לאתר את עותקי הגיבוי ולהשיב את הנתונים הרצויים למצב הרצוי

עלויות אלו עלולות להסתכם בסכומים יפים ומכובדים ככל שסביבת הנתונים הולכת וגדלה.

• ז. Snapshoot הוא מנגנון גיבוי יעיל לנתונים גדולים.

Snapshots ("צילום" של נקודת זמן מסוימת של הנתונים) לעיתים משמשים כהעתק לגיבוי בכדי להגן מפני טעויות משתמש או פגמים ביישומים, אבל ישנם מספר שיקולים בעת השימוש בכאלו.
גיבויי "תמונה" כאלו יכולים לבצע תהליך גיבוי בצורה אוטומטית, אולם, כאשר משתמשים ב-Snapshot עבור אחסון, נדרשים צעדים ידניים הנדרשים על מנת לשמור על עקביות (Consistency) נתוני הגיבוי, יש להבין, Snapshots יעילים במיוחד כאשר הנתונים אינם משתנים בתדירות גבוהה. כאשר מדברים על Big Data השינויים תכופים מאוד ושיטות כמו דחיסה (Compaction) רק מוסיפות לגודל מסד הנתונים ויוצרות Overhead הזוי של עד כ-50%! על מנת לשמות מספר נקודות שחזור לנתונים.
הליך השחזור מ-Snapshot הוא ידני ומייגע, ה-DBA יצטרך לזהות את הגיבוי המתאים לתצורה הנוכחית ואת נקודות הזמן הנכונה למידע אותו יש לשחזר ולשחזר את המידע ל-Node המתאים. כל טעות בשחזור עלולה לגרום לנזק בלתי הפיך למידע.

אחרי סעיף ה-Snapshot שמתקשר ישירות לסיפור התקלה בגיבוי:

בניית מסד נתונים Big Data חדש:
היה זהו ארגון גדול, כל תרבות ה-Big Data נכנסה לשוק, ואנחנו בכיוון לבניית אפשרות להוספת מאגר נתונים שיתאים לאחסון כל כך הרבה מידע שעומד להצטבר, המון נתוני Big Data, ההתרגשות בשיאה, מציעים את השדרוג ללקוחות כמובן אחרי אין ספור ניסויים והשקעה וסוף סוף עליה ל-Production.
לקוח גדול מחליט להצטרף, יצרן משחות שיניים, בין היתר.
למרות המעבר לנתוני Big Data החליטו במשחות השיניים להמשיך ולגבות את הנתונים בתצורה הקיימת, Snapshotים (סעיף ז).
מי שקרא עד כה (סליחה על כמות המידע 😊), מבין שגיבוי כזה למידע המתחיל להצטבר ולגדול בצורה אקספוננציאלית בשל שינויי המידע התכופים, מצריך גם שינוי מהותי בנפחי האחסון.
מדובר לפני יותר מעשור ואחסון היה יקר מאוד ומסתבר שהחברה לא השקיעה כסף נוסף בשדרוג האחסון (תמיד תמיד על קמצנות ב-IT משלמים ביוקר).
הגיע הרגע המצער, ומספר עובדים בצעו שינויים נרחבים ב-Production אשר מחקו חלקים נרחבים במסד הנתונים, בשגגה כמובן.

סיפור השחזור:
מנהל ה-DB שם היה בהלם כשניסה לשחזר את נתוני ה-Big Data על הפלטפורמה, ופתאום גילה שאין לו שום Snapshot עדכני בנוסף מה שקיים לא יתאים לגרסה הנוכחית של הפלטפורמה ושכדי לשחזר צריך להתקין מספר גרסאות שלה אחורה! השחזור היה כרוך בהטסת צוות מקצועי של חבר'ה מהפלטפורמה וחבר'ה שלנו, תוך 48 שעות היינו On Site, טיסות מהרגע להרגע לגרמניה, שחזור שלקח נצח נצחים, התקנה אחורה ומחדש של הפלטפורמה, אין ספור נקניקיות גרמניות ופיצות למשרד, שהיה של 72 שעות רצופות כמעט במשרדי החברה, השבתה של מסד הנתונים לכמעט 12 שעות! ונזק של כמה מאות אלפי דולרים בסך הכל (תמיכה, שרות, אחסון וכו..)....
עכשיו רק כדי לא לבצע שינויים מרחיקי לכת בתצורות הגיבוי, הם רכשו שם אחסון שיכול להחזיק את ה-Snapshotים המטורפים האלו בקירוב של מאה אלף דולר בחודש!

הלקח:
להשתמש בסוג הגיבוי המתאים לסוג מסד הנתונים, ותמיד תמיד להיות עם היד על הדופק לגבי תדירות הנתונים ובסיפור הזה הכי חשוב, שיש מספיק מקום כדי לאחסן את מסדר הנתונים.



[img2=1300x866]https://previews.123rf.com/images/igord ... -chips.jpg[/img2]
*תמונות אילוסטרציה, אבל כן, היו שם המון נקניקיות....וסוף טוב.

[s235711]

הסיפור המשונה הזה הולך ככה, אבל קצת רקע קודם.
לאורך פחות או יותר שנתיים בסוף שנות ה90 וכמה עשרות מילוני ש"ח עבדנו על לקחת את כל הבימס הצה"לי מתצורת מיינפריים לקליינט סרבר שהיה מאד פופלרי אז. המהלך כלל התקנת סרבר בכל חור שהיה בו יותר מ-4 חיילים עם view משלהם, הצפנה ועדכונים הדדים ונעילות בלתי אפשריות על פני קווים שנחפרו במיוחד בשביל זה ו, כתיבה ואחסון של שרתי דואר יעודיים לזה והכל בקצב של תקשורת מודם 56.
אבל זה לא הסיפור.
אחרי שסיימנו להעביר הכל, או לפחות ככה חשבנו, וכאשר אנחנו מתגאים בדטבייס החדש שמתאים לשנות האלפיים, הכל התחיל איעשהו סוג של לעבוד. ישבתי בתורנות שישי ב28 במאי 1999, אני מקבל טלפון,"תשמע, מצאו את הצוללת דקר , אנחנו צריכים לשלוח מוניות לכל המשפחות. צריך את הכתובות, הנה רשימה של מספרים אישיים". מריצים אחד כלום, שתיים כלום. הידיעות משתלוללות ברדיו, ואנחנו בערך שני אנשים שיודעים שאין לנו מושג thl למצוא אותם אחרי 30 שנה. גם לא יודעים איך להשיג את קציני הנפגעים מחיל הים, כי אין את הפרטים במחשב של החיילים אז לא יודעים מ מטפל. מתקשרים לכל העולם, איפה הקבצים הללו, איך זה לא נגזר לדטבייס. אחרי שעה מישהו נזכר שהם אף פעם לא עלו לבימס, אבל מישהו גיבה אותם באיזה שנת 70 על סליליים מגנטיים. הם נמאים באיזה מרתף ברמת גן. שולחים מישהו לשם, מוצא, הבעיה: מאיפה מגרילים משהו שקורא את הדברים הללו. היה לי קסטות של קומודור 64, אבל זה היה הרבה יותר גדול. מוצאים איזה נגד שייתכן שנמצע שם מאז שנת 70 והוא מביא כזה, ומדפיסים את הרשימה על מדפסת סיכות של 150 ש"ח.

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

[SHAKEDLEVI]

לאחר השחרור מהצבא:o התחלתי לעבוד כמתקין אל פסק בחדרי שרתים באחת מהחברות הגדולות בשוק.

הייתי נכנס לחדרי שרתים, מתקין את האל פסק החדש מחתים את הלקוח וחוזר לרכב(Y), כך רוב היום.

באחד מן הימים נכנסתי עם בקבוק קולה(b), זה היה יום ממש חם ולחוץ:?, הנחתי את הבקבוק פתוח על אחד השרתים והתחלתי לעבוד.
[img2=73x73]https://mycustomtreats.com/wp-content/u ... -Front.jpg[/img2]
לקראת סיום העבודה אספתי את כל הכלים הכנסתי לתיק והתארגנתי ללכת, ואז.. בעודי קם מהריצפה התיק שעל גבי נגח בכלוב והקולה החלה נשפכת על השרתים !.

לא ידעתי את נפשי מרוב לחץ:oops:, החלו רעשים מוזרים וניצוצות, לא חלף זמן רב עד שהגיעו אנשים רבים לחדר:קיבינימט:.

הייתי מובך והרגשתי רע מאוד, החברה ניזוקה ואני.. איבדתי את עבודתי(U).

אין דבר חשוב יותר מגיבוי:!:.

גיבוי שומר לנו על העסקים, על הדברים הכי אישיים שלנו ולעיתים על דברים שלעולם לא נוכל לקבל בחזרה(U).

[OranCS]

אז ככה, הסיפור שלי מתחיל שכהייתי איש IT צעיר (מאוד) והיה לנו בארגון שרתים וירטואליים שאני מגובים למכונות NAS מקומית (של Synology במקרה)
בשבוע הראשון לאחר שפתחו לי את היוזר לחיבור ל-vmware של הארגון בטעות מחקתי את ה-DC הראשי של הארגון (זה שגם מחזיק את כל חוקי ה-FSMO). בזמן שאני מאדים ואז מחכיל ועובר את כל צבעי הקשת איך אני מתקן את מה שעשיתי (כבר עברו תרחישים שעד שהתחלתי בתחום הסיסטם עכשיו לחפש משרה חדשה..) נזכרתי שיש גיבוי של המכונות! הלכתי ל-NAS שמגבה כל שעה את המכונות הקריטיות והתחלתי תהליך שיחזור. פה קפצה התראה למנהל שלי שהבין את הצרה שעשיתי. אדום יותר ממני הוא קורא לי למשרד שלו להבין מה קרה, נשבתי מהר כמובן והודתי בטעות. לשמחתי הוא היה רגוע יותר ממה שחשבתי ואמר "כולם עושים טעויות בחודש הראשון, הכל בסדר - יש גיבוי" ועצר יש את השיחזור שעשיתי. בדיעבד מסתבר שרק עשיתי remove from inventory ולא ממש delete לכן לא היה צורך בשיחזור... אבל ככה הסתבר לא משמעות של גיבוי בארגון.. אחלה טבילת אש

[molvy]

הרחבת השימוש בשרת החברה והקמת START UP צבעוני

שוב נחזור חזרה לשנות השמונים המוקדמות ואני בארצות הברית נח על זירי הדפנה של הצלת האינפורמציה של מערך השירות, החלטתי ללמוד מעט יותר לעומק את נושא ה IT

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

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

היה בחור שהיה אחראי על מכלול הפעולות שעושים ונעשות על גבי המחשב הקריטי

לסרוור חובר NAS לגיבוי האינפורמציה של המשרד, אני חושב שסך הכול של הNAS היה 200 גיגה, לי על המחשב היו 2 דיסקים של 80 מגה כל אחד כך שהנפח של ה NAS היה סוג של OVERKILL עבור החברה שלנו

כפי שאמרתי התחלתי ללמוד את הנושא וצללתי לעומק של הגיבויים ושל הנפחים של ה NAS לעומת כלל הנפחים של המחשבים בחברה

כמנהל מערך השירות היו לי הרשאות די נרחבות והאינפורמציה שהייתי צריך היתה נגישה עבורי

לאחר כמה חודשים התחלתי לראות שהנפח התפוס של ה NAS מתחיל לגדול מעבר לסך הנפחים של מחשבי החברה וגודל באופן מתמיד

התחלתי לחקור את הגיבויים וראיתי שבאמת יש 2 גיבויים בשבוע כאשר יש שבועיים של גיבויים שמורים הכול נראה תקין פרט לעובדה שהנפח הפנוי ב NAS יורד באופן תמידי ודי קבוע

משהו היה ממש חשוד בעיני והייתי בטוח שהניהול של הגיבויים לא מוחק גיבויים ישנים שאין בהם צורך

לאט לאט הגעתי לתיקיות עם שמות מוזרים שלא היו חלק ממערך הנתונים של החברה

שניסיתי להכנס אליהן הוברר שאין לי הרשאה להכנס לתקיות אלו

החשד עכשיו השתנה לשימוש לא תקין ב NAS

התחלתי להריץ על התיקיות הללו תכנות פריצה וגילוי של ססמאות

לאחר זמן לא קצר הצלחתי לפרוץ לאחת התיקיות ומה רבה היתה הפתעתי לגלות בה חומר כחלחל עד כחול עמוק בכמות שלא היתה מביישת ספריית פורנו קשה

לא היה ספק מי האחראי לספריית הפורנו הקשה הזה

עכשיו הגיעה הדילמה מה לעשות עם האחראי לתפעול ה NAS, היה זה בחור מאוד חיובי עם תחביב מאוד גרפי

לחקתי אותו לשיחה עם הוכחות חודרות תרתי משמע

הוא התנצל ואמר שהחומר הזה לא פגע בתיפקודו של ה NAS ולא פגע בתפקודו שלו במה שהוא עשה בחברה

הפיתרון שלנו היה שהוא ימשיך לעשות את עבודתו נאמנה בתחום תפקוד ה NAS, ימחוק את החומר הכחול, ויקח על עצמו תפקיד נוסף בחברה ללא תוספת תשלום (אחראי על המלאים במחסן חלקי החילוף)

אציין שהוא הצטיין בשני התפקידים, חסך לנו חצי תקן והיה אסיר תודה שלא העפתי אותו מהחברה

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

והגיבויים המשיכו לעבוד כמו שצריך

לאחר זמן פגשתי את אותו בחור שוב והוא סיפר לי שהחומר שהיה ב NAS היה עובר לקלטות וידאו ונמכר בשוק האפור של הפורנו

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

אז אפשר לומר שהוא עשה אצלינו STARTUP מאוד מקורי

[boubi]

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

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

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

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

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

מתחילים בשדרוג:
ישנם שני nodes לאחסון, כך שמבצעים אחד אחד.
מתחילים עם הראשון, זה לוקח המון זמן...
מערכת לא עולה.אוקיי לפחות בודקים ויש שירות ללקוחות, הכל למעלה.
פותחים קריאה לחברה, הם מבקשים לבדוק כמה דברים, יחד עם הטכנאי מבקשים לשנות חיבורים.
עובר זמן מה ו... נחשו מה?

הצליחו להפיל את ה-node השני.
אין שירות, אין עבודה ללקוחות קצה ומפלס הלחץ עולה.

3 ימים של טירוף עם עבודה סביב השעון של נציגי חברת האחסון ושלנו, נסיונות רבים להציל את המידע עולים בתוהו ורק גיבוי מההעתק הציל את המצב.

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

כל טוב, נתראה בשמחות.
זז לישיבה.

[mp3lll]

אז הגעתי להיות עוזר IT בחברה עם עוד חמישה אנשים תותחים, צעיר אפשר לומר ילד בעיקר חושב שהוא יודע הכל, במהלך הזמן הביאו לי את הדברים המעצבנים, התקנות, גיבוי, שיחזורים, וכל פעם רציתי משהו רציני יותר, גיבוי לשרתים, הגדרות רציניות, גיבוי יומי , כלום לא הביאו לי.

יום אחד מנכל החברה ראה במקרה אותי ואמר "או הנה אתה אתה יכול לטפל לי במחשב נייד" אני לא אמור לטפל לו, אמרו לי עשרות פעמים לא לעשות מה שאני לא צריך, מי שמבקש לפנות אל מנהל הIT

אבל אני? חכם, אמרתי לו כן בטח אני בא אליך עכשיו, הגעתי אליו למשרד, מחשב עם חלונות 7 שלא עולה.
המנכל הדגיש לי שיש לו שם דברים חשובים מאוד, תמונות, מיילים (PST) שלא גובה המון זמן, זה מחשב מהבית שהוא משתמש בו.
מילה שאני לא אשכח "תגבה הכל ואז תתעסק"

סחבק חכם כבר אמרתי? מדליק את המחשב חלונות נתקע בעליה בכל פעם, מה לא ניסיתי לא עלה, בדיקות חומרה עברו.
חשבתי לעצמי מה עכשיו להוציא דיסק להתחיל לגבות, אלוהים יודע כמה חומר, לא בטוח שיש לי איפה, למה לא לעשות התקנה מחדש פשוט? חלונות על חלונות, יהיה windows חדש ויהיה גם את הישן.
לקחתי דיסק של חלונות Windows vista !! עשיתי התקנה על התקנה, בהתקנה לא שאל אותי להשאיר מהדורה פשוט התקין הכל מחדש ולא שמתי לב, בסיום ההתקנה כמעת עשיתי פיפי במכנסים, הכל נמחק, אין כלום, אין תקיה windows.old אין קבצים אין כלום.

כצעיר נלחצי מאוד, הייתי על סף בכי ולא ידעתי מה לעשות, לקחתי את המחשב הביתה וניסיתי לשחזר, לא הצלחתי לשחזר כלום, אחרי כמה ימים מנהל הIT שאל אותי "תגיד המנכל הביא לך מחשב נייד איפה הוא?" פה התחלתי לבכות ( לא בכי מטורף לחץ בעיקר) וסיפרתי לו מה קרה, למזלי הוא היה גם אדם חביב וגם מבין עניין, עשה לי מעט נו נו נו, אבל לקח את המחשב, התקין תוכנה שיחזור לא מתוך חלונות ולימד אותי איך לשחזר נכון, הצלחנו לשחזר את ה PST ורק חלק מהתמונות,

והמנכ"ל? מעולם לא ידע מזה כי לא באמת זכר מה היה לו ומה לא, ואני? למדתי בדרך הקשה לא להיות חכמולוג, ואם אני לא יודע משהו לשאול, זה היה שיעור קשה לחיים שלקחתי ממש קשה, גם הרגשתי חובבן, וגם מחקתי לאדם את כל החומר שלו בלי לדאוג לגיבוי.

שאני מספר את זה בא לי לבכות שוב

[sigamore]

"בפעם הבאה שאתה קופץ לביקור, מחכה לך הפתעה" ....
כך התחילה שיחת טלפון של בוקר עם מנהל הכספים של החברה בדרום אפריקה ....
הסיפור עצמו התרחש כשנה קודם לכן, כשבאותה התקופה עבדתי כמנמ"ר בסניף הישראלי של חברת פארמה בינלאומית ובין שאר המשימות נתבקשתי לנהל את מח' ה IT של הסניף ביוהנסבורג למשך מספר חודשים (עד שיגויס מנמ"ר מקומי).
רצה הגורל ובאותה שנה בדיוק תוכנן מעבר משרד מאזור אחד של העיר יוהנסבורג לאזור אחר.
מיותר לציין שהפרויקט דרש לא מעט שעות עבודה (אפיוני חדר מחשב, פרישת רשת, ושאר "זוטות") שהפכו למאתגרות כפליים בגלל העובדה שהכל נעשה ממרחק ~6000 ק"מ ...!
אחת הדרישות המעניינות יותר הייתה למערך מצלמות אבטחה שיכסו את כל שטח המשרד .
לאלו מביננו שאינם בקיאים בהלכות דרא"פ אספר שרמת הפשיעה הכללית במדינה וביוהנסבורג בפרט הרקיעה שחקים ! אירועי פריצה ובכללם שוד מזויין היו למרבה הצער עניינים שבשגרה.
לפיכך )ובאופן חריג למדי), אפיוני מערך המצלמות הגיע ישירות ממח' האבטחה במטה החברה בארה"ב.
המערכת שנבחרה הייתה של חברת Siemens ואוסיף רק שהעלות הסתכמה במספר של חמש ספרות (דולר אמריקאי) !
התקציב הועבר, המערכת נרכשה (מחוץ לדרא"פ – היות והסתבר שאין ייבוא מסודר של חומרה מסוג זה) ואחרי קשיים רבים אפילו הותקנה . למרבה ההפתעה ביצועי המערכת היו ירודים בעליל והעובדה שתמיכה מקומית לא הייתה בנמצא , לא הועילה כלל ועיקר.
אחרי שהועברו כל התשלומים בעבור המערכת, הסתבר שנשאר "עודף" תקציבי מסוים וכך אחד מאנשי ה IT המקומיים פנה אלי בהצעה לרכוש NAS שבמקביל ליכולות האחסון והגיבוי הרגילות, יודע לנהל גם מערך של מצלמות אבטחה....
תשובתי הראשונה הייתה כמובן שלילית שהרי נרכשה כבר (בממון רב) מערכת אבטחה, אך במחשבה שניה הבנתי שהצורך הראשון הוא למערכת גיבוי ונושא ניהול המצלמות מגיע כ"בונוס".
אישרתי את ההזמנה וכעבור מספר ימים התבשרתי ש NAS מדגם Synology DS1515 הותקן במקום. במקביל איש ה IT המקומי "הגדיל ראש" והוסיף שתי מצלמות אבטחה שכיסו את שטח הלובי ואת הכניסה לחדר השרתים.
מספר חודשים מאוחר יותר הגיעה הודעה על פריצה שארעה באישון לילה וגניבה של ציוד רב , כולל כספת (נעקרה ונלקחה בשלמותה) שהכילה חומרים רגישים ביותר.
מיקומה הסודי של הכספת בנוסף לעובדה המדהימה ששרת הוידאו של Siemens פורק ונלקח מחדר השרתים , העלה את החשד שהפורצים נעזרו באדם "מפנים" ....
המשטרה שכמובן חיפשה עדות מצולמת, טענה שבלי צילומי האבטחה יקשה עליהם מאד לאתר את הפורצים לפני שיעלמו עם הכספת ותכולתה הרגישה.
אחרי מספר שעות בהן כמעט והרמנו ידים, הגיע טלפון מאיש ה IT שבמקרה שמע על הפריצה (הוא היה בחופשה באותו שבוע ) שהציע לבדוק את ה NAS ואת צילומי האבטחה שאולי נשמרו עליו...
ה NAS נגנב - אמרו לו ... אבל אז הבינו שהוא מדבר על ה Synology !!!!
חמש דקות מאוחר יותר היה בידי השוטרים צילום פנים מפורט של עובד האחזקה שסייע לפורצים להכנס אל חדר השרתים ....
כמה שעות מאוחר יותר אותרו השודדים ואיתם הכספת שעדיין הייתה בשלמותה !
וסימבה ???
כאות הוקרה לאנשי ה IT המקומיים וגם לי עצמי, נשלחנו אחר כבוד לפארק קרוגר המדהים לספארי של 3 ימים 😊

[ziv_r]

חיכית לשעה 18:00 בדיוק להיות האחרון? 😀

התחרות ננעלה. הזוכים יוכרזו בהמשך.

[sigamore]

חיכית לשעה 18:00 בדיוק להיות האחרון? 😀

התחרות ננעלה. הזוכים יוכרזו בהמשך.

...

·

האמת שלא היה מתוכנן כלל ! סתם נתקעתי באיזו שיחת ועידה שנמשכה נצח...
בהצלחה לכולם

[gabiuzan]

מתי מפרסמים את הזוכים ואיפה?

[HTmag]

נפרסם בקרוב בעמוד הראשי.

[HTmag]

10 הזוכים פורסמו: https://www.htmag.co.il/article09371.html

[HTmag]

@sigamore אוסף את הפרס

[imgur]WB0WfYB[/imgur]

[oferlaor]

תתחדש!!!