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

[molvy]

לפני כחמש שנים רכשתי NAS של סינולוג'י מסוג DS2413+ אשר כלל 12 דיסקים של 4T מוחוברים ב RAID 5

השמחה היתה גדולה והרכישה היתה בית לאוסף סרטי ה FHD שאני אוגר כמו אוגר מאתגר וכמובן לכל האינפורמציה והגיבויים של המשרד שלי שמנוהל מהבית (יש לי חברה שעובדת מהבית)

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

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

התחלנו לבדוק את הרשת הקוית והאלחוטית

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

הפקטור של הירידה במהירות היה של 100 כך שמה שעבד ב 100 מגה התחיל לעבור ב 1 מגה

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

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

הסוויץ' שה NAS קשור אליו נחקר מכל הכיוונים ללא שום הבנות מה הבעיה

ואז אמרנו שאולי זה ה NAS

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

תכלס הלך הדיסק אבל בגלל ה RAID 5 ה NAS המשיך לעבוד אבל בקצב הרבה יותר נמוך

הדיסק הוחלף כלאחר כבוד בדיסק 4T חדש וה NAS החל את עבודת השחזור של הדיסק הדפוק

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

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

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

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

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

מאז כבר יותר משנה ה NAS עובד כמו חדש

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

[Apple6543]

@HTmag
·נתחיל הפעם דווקא מהסוף....
יושב לי בכיף ומסתכל מהחלון על הנוף המדהים של הרי פירין בבולגריה, מסלולי הסקי ממש מולי מלאים בשלג פאודר מעולה לגלישה. יושב וחושב על אלפי הגולשים שהזמינו דרכי את חופשת החורף שלהם ואז....סוף העולם מגיע....קריסה טוטאלית של דאטה בייס עם אלפי פרטי הזמנות, טיסות, מלונות,ספקי שירות וכמובן תמונות. של מה אתם שואלים? של סוכנות טיולים לחו"ל המתמחה בטיולי סקי, חופשות סקי , בית ספר ללימוד סקי ואטרקציות בשלג.
אז איך הכל התחיל? מאוד פשוט. חכמולוג אחד החליט שאפשר להרים מערך הזמנות אינטרנטי ולהסתפק במחשב שקניתי ב2500 שקל באיזה אתר אינטרנט מפוקפק. והרי מה, אנחנו ישראלים, היינו בקרבי, מי צריך גיבוי??? מה כבר יכול לקרות? אז הנה מה קרה....
מי שמבין בעולם הטיולים יודע שכל לקוח מקבל סוג של מספר מזהה בפני חברת הטיולים וספקי השירות. המספר הזה מלווה את הלקוח מהזמנת הטיסה , המלון וכל שאר הרכישות שהלקוח מבצע בפני סוכן הנסיעות. עד כאן הכל פשוט וטוב נכון? אמהמה, המערכת שומרת לכל לקוח קובץ INFO בכרטסת נפרדת וכל זה נשמר לוקאלית באותו המחשב הנייח. כך לדוגמא נשמרת בכל תיקייה פרטי הטיסה, ההעברות, המלון , שירותי הסקי שכוללים ציוד, הדרכות ואפילו האטרקציות שכל אחד עושה. אבל הכי חשוב נשמרים הנתונים האמיתיים לגבי כמה כל שירות כזה עלה, כמה הלקוח שילם בפועל ומהם החישובים לטובת הפרשות לספקי השירות השונים. והכי חשוב, כמה כסף נשאר בסופו של יום לסוכן הנסיעות ביד. וזוכרים, הכל לוקאלי על המחשב שעלה כמה מאות שקלים ...
אם לא דיי בעובדה שבעצם כל הכסף ששולם וצריך לצאת לספקי השירות נמצא שם, הרי והגאון התורן החליט גם לבקש מהלקוחות לשלוח תמונות של הפספורטים, תמונות מהחופשה לצורך פירסום עתידי ואפילו סרטונים קצרים. כל אלו כמובן תוייקו לתיקייה האישית של כל ללקוח ולקוח.
אז מה היה לנו שם? 5 שנים של פעילות, אלפי תיקיות שכל תיקייה מכילה פרטי התחשבנות לעבר ולעתיד מול חברות תעופה, בתי מלון וספקי שירות וכמובן תמונות וסרטונים. ואז... יום בהיר אחד (יותר נכון יום קריר במינוס 10 מעלות אי שם באתר סקי מפורסם בבולגריה) קפיצת חשמל קטנה, כזו שאפילו לא מרגישים. והופ...הכחול הגדול שכולם מפחדים ממנו. Reboot, והמחשב מתחיל לבדוק קבצים. כן כן , המסך הזה שאף אחד לא אוהב לראות ויודע שכשמגיע הרגע הזה יש 2 אפשרויות. האחת, שהמחשב נדלק והולכים לדרך. והשניה, שהלך עלייך. או יותר נכון שהלך על המחשב ואפילו אם תצבע אותו בכחול ותזרוק לים זה לא יעזור.
אז אופציה 2 , zed is dead, אין קול ואין עונה. המחשב לא עולה !! אמצע עונת סקי, הזמנות של תחילת העונה, הזמנות של המשך העונה. מה עושים?!?!
מומחה מיחשוב בולגרי אמר לי להביא לו את המחשב וכך היה, הבחור קיבל את המחשב, פרק את הדיסק וניסה וניסה וניסה, אבל עם כל הכבוד, בולגרי...מה הוא כבר מבין בשיחזורים? אז פרקתי את הדיסק וטסתי לארץ, לקחתי למעבדה הכי טובה שיש בהרצליה מיד לאחר הנחיתה . ובנתיחה שלאחר המוות עלה שהדיסק פשוט חרץ את עצמו למוות ואין שום דרך לשחזר אפילו לא קובץ אחד. הסיוט של החיים כבר אמרנו???
אז עכשיו להתחיל ולשחזר כל הזמנה מהמייל, כל מייל ומייל שנשלח לספקים, כל שורה שנשלחה במערכת ההזמנות של חברת התעופה, עבודה של שנים פשוט הלכה לפח. אבל רגע, מה קורה עם ההזמנות של השנה?? אז זהו , שהולכים על עיוור. מנסים לשחזר ולראות למי מגיע מה, למי כבר נשלחו הזמנות מי כבר שילם ואיזה ספק כבר קיבל כסף, עבודת נמלים !!! למה לא חשבתי על גיבוי בענן??? כ"כ פשוט, כ"כ יעיל !!!

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

[ido22]

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


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

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

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

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

התוצאה היתה הרת אסון - את המידע העסקי הוצאנו מהמערכות של ה production שהיו בענן, אך חלק מהמידע של הפיתוח הלך, אבל לא משהו שלא הצלחנו להתגבר עליו (עסקית).
מאידך, המידע האישי שלי, שכלל את כל אוסף התמונות/וידיאו של המשפחה, כולל אלו שנפטרו כשנה לפני שקרה מה שמתואר כאן, לא הצלחתי להציל.

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

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

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

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

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

[צפוני1234]

לפני מספר שנים עבדתי בחברה שנתנה פתרונות מיחשוב לעסקים.

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

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

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

מייד התקשרו אלינו לבוא ולברר את מקור הבעיה ולפתור אותה כמה שיותר מהר.

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

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

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

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

אני זוכר את מה שאמר להגנתו המנהל של החברה שעבדתי בה – שילמתם לנו עבור התקנת מערכת חדשה בלבד ואף אחד לא ביקש גם לשנות את הגיבוי.

[alchemy]

יש לי סיפור קצת ישן משנת 2005, עבדתי בתור סטודנט בחברה קטנה של 7 אנשים שעסקה בפיתוח ועריכת כרטיסים (board design), הייתי בעיקר בודק כרטיסים וגם כולבויניק כמובן.

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

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

אני לא זוכר לגמרי את כל הפרטים של התקלה, גם לא עסקתי ישירות בענייני IT בחברה וזה גם היה לפני 15 שנה, אז ממה שאני זוכר ישב על שרת פיצה של HP, עם 3 דיסקים SCSI ב- RAID5.

מה שמדהים שהשרת אפילו לא היה מחובר ל-UPS, כי לא צריך, יהיה בסדר.....

הייתה קפיצת מתח באחת הלילות ונמחקה קונפיגורציה של בקר ה-RAID (virtual disk configuration), כך הגענו בבוקר לעבודה וגילינו ששרת נפל. עד כאן הכל רגוע, הבעלים של החברה לא נלחץ, הרי יהיה בסדר, התקשר לאיש IT שנתן שירותים לחברה, הוא הגיע לחברה והגיע למסקנה שצריך רק לקנפג בקר מחדש ויהיה בסדר.

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

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

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

אישית אני הייתי בשוק מהסיפור הזה, כיוון שאני תמיד הייתי פראנויד בכל מה שקשור למידע וגיבויים, היה לי טייפ גיבוי של Conner בנפח 125MB עוד בשנת 1994 וצורב דיסקים SCSI במהירות x2 משנת 1996. לא האמנתי שאנשים מזלזלים בגיבויים של מידע קריטי כל כך לעסק וכתוצאה מזה מפסידים הרבה כסף ומוניטין.

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



לקחים שלי מהמקרה :

1. מי שמחפש בזול משלם ביוקר
2. לא לעבוד בעתיד בחברות שחוסכות עם כל דבר
3. חיזוק לגישה שלי - לעשות תמיד גיבויים לכל החומר החשוב

[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]

תתחדש!!!