Spoiler! Dune, Ogres, Onions and Cyber-Sec

זהירות ספוילרים!

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

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

מנחשים כבר איזה סרט זה היה?

ובכן, ראינו את Dune: part one ולא היה לנו מושג שזה רק part one!

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

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

כאן מתחיל הספויילר, זהירות!!!

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

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

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

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

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

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

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

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

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

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

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

למי שרוצה להעמיק את הקריאה, יש לנו סדרה של פוסטים בנושא וגם כמובן Technical Report רלוונטיים, אחד ספציפית על התמודדות עם נוזקות כופר(TR-4572) ואחד על הקשחה כללית של מערכות   (TR-4569).

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

שלכם כמו תמיד,

ניר מליק

אמרתי לכם!

אמרתי לכם! הייתי הראשון לזהות!

הדבר הזה פשוט מטורף.

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

CPOC!

זה היה הדמו שעזר לנטו להפוך לכוכב בתוך החברה (CPOC!)

כמה דברים השתנו מאז, הרעיון של NPS היה רעיון חדשני, לשים מערכת אחסון פיזית ליד הענן, ומאז נטאפ כבר יודעת לספק במקום זה מערכת וירטואלית לחלוטין שרצה על הענן בתוך הסביבה הוירטואלית של לקוחות ובמקביל, ספקיות הענן עצמן מספקות את השירות של מערכת ליד הענן בעצמן, שירותים כמו Azure NetApp Files למשל שהם שירות של Azure לכל דבר ועניין רק שמאחוריו יש מערכת אחסון All Flash פיזית של NetApp.

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

אלו היו ימים די תמימים, עבורי לפחות, שבהם דיברנו ענן אבל בסוף מכרנו מערכות אחסון פיזיות. כל כך הרבה השתנה מאז, חלק מהמוצרים שנטו מדבר עליהם כבר לא קיימים והיכולות שלהם הוטמעו בתוך מוצרים אחרים ובאופן כללי הפורטפוליו של שירותי הענן השונים של נטאפ מאד התרחב, מהיכולת להעביר מידע קר לענן  דרך היכולת להעביר מידע לענן תוך כדי המרת הפורמט שלו ועד מערכת ניהול מידע ארגוני חכמה שרלוונטית לכולם, לא רק ללקוחות נטאפ וגם ללקוחות cloud native (תזכירו לי לכתוב בקרוב על Data Sense?!) וההכרזה של היום היא אחת הקפיצות הכי מרשימות של הסיפור של נטאפ קדימה.

היום אנחנו מכריזים על משהו חדש ביחד עם החברים מ AWS, FSxO או בשם המלא FSx for netApp ONTAP

FSxO הופך בפועל את נטאפ לספקית האחסון של AWS כלומר כל לקוח AWS, בין אם הוא לקוח נטאפ ותיק או לקוח שמעולם לא שמע על נטאפ, לקוח EC2 או EKS, VMware on cloud, זה לא משנה, יכול לצרוך את שירות האחסון שלנו בצורה שקופה לחלוטין מתוך שכבת הענן של AWS, כולל סנפשוטים, רפליקציה, יכולות דחיסה וביטול כפילויות, NFS, SMB, iSCSI, FabricPool  שאני אוהב, Flash Cache,  הכל כולל הכל!

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

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

עבור לקוחות קיימים של נטאפ, אפשר להסתכל על שלושה Use Case סופר מהירים וכדאיים והראשון הוא DR. זה סופר קל פשוט להגדיר Snap Mirror ולא לנהל שם דבר יותר, כל התשתית עבור FSxO היא מנוהלת על ידי AWS וכל מה שהלקוח צריך לעות זה להגדיר מדיניות רפליקציה ולשכוח מזה עד יום פקודה.

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

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

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

סוף שבוע נעים ושנה טובה לכולם!

שלכם,

ניר מליק

Got Silk?!

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

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

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

אפשר לראות שיש קשר ישיר בין גודל הדיסק ב GB וכמות ביצועי ה IOPS העומדת לרשותו. אפשר לראות בהערות גם שיש כמות ה CPU וכמות ה IOPS בגלל ששרתים עם יותר CPU יכולים לגבל הקצאת תקשורת נדיבה יותר, Network egress caps. משמעות הדברים היא שיתכנו מצבים בהם לקוחות צריכים לשלם על נפח דיסק ריק כדי לקבל יותר משאבי ביצועים ועל מעבדים מיותרים כדי לקבל יותר משאבי תקשורת אל הדיסקים.

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

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

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

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

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

כלי שימושי נוסף שאנחנו מאפשרים ללקוחות הוא סנפשוטים רזים. תהליך יצירת סנפשוט בענן הוא תהליך ארוך ויקר. ב AWS למשל, בתהליך יצירת הסנפשוט מועתק המידע אל S3 ובכל סנפשוט נוסף יש להעתיק מידע נוסף, את המידע החדש. אנחנו מאפשרים ליצור סנפשוטים מידיים, מבוססי הצבעות בלבד, כך שאין צורך להזיז מידע או לשלם על נפח מידע נוסף ולכל סנפשוט ניתן לייצר View כלומר להשתמש בסנפשוט כהעתק עצמאי של המידע לשרתים אחרים, test/dev או אנליטיקה וכו'.

אנחנו רואים בבמוצע חסכון של 3:1 בשימוש ביכולות חסכון בנפח ולפחות עוד 30% חסכון על ידי שימוש בThin Provisioning וזה אומר שרק על ידי זה שריכזנו את המידע של הלקוח והכלנו עליו את היכולות האלו, הלקוח צורך עכשיו פחות מרבע מהנפח שהוא צרך קודם ובגלל שאנחנו לא נסנכים על ביצועי הדיסקים של תשתית הענן הרבע הזה הוא בדיסקים זולים יותר מהדיסקים הקודמים!

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

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

עדכון לפוסט!

כמו מהשמים שלחו לי לינק לסרטון הזה היום, החל מדקה 16:54 בערך אפשר לראות בדיוק כמה מורכבות האופציות לבחירת דיסקים ב AWS והתאמת ה EC2 instance לבחירה שלכם.

כבונוס, יש שם הדגמה של יכולות של blktrace. ביחד עם blkparse, btt ועוד סקריפט פייטון קטן (כן כן הרבה חלקים זזים) אפשר ממש להציג באופן קריא ונוח עד כמה ה IO שהשרת שלכם עושה הוא Sequential או Random, נתון שהרבה פעמים חסר לנו כשאנחנו באים לעשות סייזינג מסודר למערכות סטורג', אם אתם מאלו שעוד עושים כאלו דברים 🙂

credit AWS: https://youtu.be/wsMWANWNoqQ
credit AWS: https://youtu.be/wsMWANWNoqQ

כמו תמיד אשמח מאד לשמוע מכם!

שלכם,

ניר מליק

מה זה גיבוי ומה הופך פתרון גיבוי לפתרון טוב

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

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

 נתחיל בהגדרה מילונית, מה זה גיבוי?

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

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

של נתונים – פתרון גיבוי כולל בדרך כלל את היכולת לבחור אילו נתונים מגובים ובהתאם למדיניות הארגון לשמור את סוגי המידע השונים על פי הצורך (מידע פיננסי 7 שנים, מידע רפואי 90 שנים וכו')

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

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

לא כל הגיבויים נולדו שווים?

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

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

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

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

מה עוד יכול פתרון טוב לכלול?

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

בשבוע שעבר הוכרזה חבילת העדכונים SP6 עבור Commvault 11. אחד הכלים המעניינים ביותר שנכללו בחבילה זו תחת Early Release הוא כלי מיגרציה של מידע מגובה מתוכנת הגיבוי הקודמת אל תוך ObjectStore מקוטלג של Commvault. הכלי מספק מענה לאחד האתגרים הכי משמעותיים בפרויקטים של החלפת פתרון גיבוי, ברוב המקרים, הפתרון הכי נפוץ עד היום היה פשוט להשאיר בצד את פתרון הגיבוי הישן לצרכי שחזור עד סיום ה retention. אם הלקוח הוא לא חברה בת יומיים התהליך הזה יכולת לקחת כמה שנים טובות שבהן צריך להמשיך לתחזק את הפתרון הישן, גם אם בתחזוקה בסיסית ביותר, לצד הפתרון החדש, Commvault  מאפשרת עכשיו להתגבר על פרויקט המרת הקלטות הכואב ולבצע מעבר מלא, כולל ה retention אל פתרון הגיבוי החדש.

אז מה עושים עם זה בפועל?

מדיניות גיבוי נפוצה היא מדיניות 3-2-1: שלושה העתקים של המידע, על שני סוגי מדיה שונים, לפחות העתק אחד מחוץ לאתר. על פי מרבית המקורות מייחסים הצלם דיוויד קרוג היה הראשון לנסח את המדיניות הזו והוא מקבל את הקרדיט הזה אפילו במסמך ההמלצות של US-CERT  כך שכנראה יש בזה משהו. לאחרונה ראיתי הרחבה של החוקיות הזו בבלוג של Veeam. זה לא פוסט חדש אבל נתקלתי בו רק לאחרונה והוא מדבר על 3-2-1-0 כאשר 0 הוא 0 טעויות. היכולת לבצע ולידציה של הגיבוי שנקראת אצלם SureBackup מסייעת לוודא שמשימות הגיבוי אכן התבצעו באופן תקין וכי ההעתקים קריאים ונגישים.

גם בשימוש ב snap manager for exchange  למשל, ניתן לשלב במשימת הsnap shot הרצה של eseutil כדי לוודא שההעתק שנוצר תקין. כאן, כשאני מזכיר את NetApp, אני בעצם סוגר מעגל שלם אל ראשית הבלוג וכאן התחיל הדיון אותו הזכרתי, מהו גיבוי? האם סנפשוטים הם גיבוי? לא, לדעתי לא, לא לבד בכל אופן. סנפשוטים יכולים להיות חלק מפתרון הגיבוי, הם במרבית המקרים הדרך הכי מהירה ליצור העתק של המידע וכן, במרבית המקרים, גם הדרך הכי מהירה לשחזר מידע מהעתק קצר טווח אבל, לבדם, הם לא עונים על מה שמגדיר בעיני פתרון גיבוי טוב, הם לא מקטלגים את המידע, לא שומרים אותו על עוד סוג מדיה, לא מוציאים העתק מחוץ לאתר וכו'.

פתרון כמו Commvault, פתרון כמו Veeam ברמות הרישוי הגבוהות או פתרון IntelliSnap שהוא רכיב Commvault המשולב כ OEM במערכות NetApp FAS, פתרון כזה משתמש באופן מובנה ותחת מדיניות גיבוי ארגונית אחת ביכולות הסנפשוט או הרפליקציה של מערכת האחסון וזה כבר עונה להגדרות שפירטתי.

איפה נרשמים?

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

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

שלכם,

ניר מליק