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

על ידי צוות Techopedia, 7 ביוני 2017

ברק: המארח אריק קוואנה דן בגיבוי ושחזור עם Tep Chantra של IDERA בפרק זה של הוט טכנולוגיות.

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

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

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

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

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

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

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

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

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

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

אז, האקרים, כמובן - אני הולך לדבר כמה דקות על האקרים ומדוע הם מהווים איום כזה. וכמובן תוכנות כופר, פשוט תגידו את כל המקרה הזה עם WannaCry, ה- Rannaomware של WannaCry, שרק כיסה את כדור הארץ בסדר קצר מאוד, וכנראה כמה אנשים לא ידידותיים וחכמים לקבוצה של מידע מ- NSA, היו כלי פריצה ששימשו ו חשוף. לכן, אני מזכיר לאנשים, ישנו אגדה ישנה, ​​המשל של אייסופ, שאומר שלעתים קרובות אנו נותנים לאויבינו את כלי ההרס שלנו. זה משהו שכדאי לזכור, מכיוון ששוב, הטכנולוגיה הזו נותקה על ידי ה- NSA, על ידי האיגוד לביטחון לאומי - אינני יכול לזכור מה הוא עומד בעצם. אבל זה נחשף ויצא לעולם, ופשוט עורר הרס. נחש מה? והרבה חברות לא שדרגו את סביבת Windows שלהם, אז זו הייתה ישנה, ​​חשבו שמדובר ב- Windows XP, שנפגעה. אז שוב, אם אתה שקדן, אם אתה נשאר על גבי המדבקות והגרסאות שלך למערכות ההפעלה שלך ואם אתה מגבה את הנתונים שלך ומשחזר את הנתונים שלך. אם אתה עושה את כל הדברים שאתה צריך לעשות, דברים כאלה אינם כה גדולים מהבעיה. אבל אתה יכול פשוט לומר לאנשים שהם אנשי הציר, "היי, נחשו מה? לא אכפת לנו, כבה את המערכת, הפעל אותה מחדש, טען את הגיבויים. "ואתה יוצא למירוצים.

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

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

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

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

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

אז, האינטרנט של הדברים, אוקיי, IoT. ובכן, אם אתה חושב על IoT, זה לא כל כך חדש. למען האמת, ישנם יצרנים מתקדמים שעושים דברים מסוג זה לפני 20 ו -30 שנה, ואז לפני כ -15, 20 שנה, זה היה הרגע שבו הגיע RFID - תגי זיהוי תדרים רדיו - שהיו שימושיים ביותר לעזור מאוד גדול ארגונים, כמו קמעונאים, למשל חברות שילוח, כל חברת מוצרים שמעבירה דברים ברחבי הארץ, ברחבי העולם, כדאי מאוד לקבל את כל הנתונים האלה, תגלה לאן הדברים שלך הולכים; אם משהו נעלם, תגלה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

טיפ צ'נטרה: בסדר, תודה, אריק. שמי טפ צ'נטרה, ואני מנהל המוצר כאן ב- IDERA. היום, רציתי לדבר על פיתרון הגיבוי הארגוני של IDERA, כלומר SQL Safe Backup. לאלו מכם מכירים גיבוי SQL בטוח, בואו נסתכל במהירות על כמה מדגשי המוצר - תסלחו לי. אז כפי שכבר ניחשתם, אנשים אומרים גיבוי, גיבוי ושחזור של SQL Server של מוצר, אחת התכונות העיקריות של SQL Safe היא היכולת לבצע גיבויים מהירים. וזו תכונה חשובה, בהתחשב בכך שרוב הגיבויים חייבים להתבצע וברוב המקרים יש לבצעם במהירות רבה, בחלון זמן קטן.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מהירות גבוהה בעיקרון מנסה להשלים את הגיבוי מהר ככל האפשר, תוך כלול מידה מסוימת של דחיסה. ISize מתמקד יותר בהכללת כמה שיותר דחיסה אך הוא יכול - מכיוון שאנו מנסים לדחוס אותו כל כך הרבה - זה עלול לקחת קצת יותר זמן, וסביר להניח להשתמש במעבד קצת יותר. רמה 1 פירושה למעשה את כמות הדחיסה הנמוכה ביותר עד לרמה 4, הכמות הגדולה ביותר של דחיסה שנוכל להוסיף. אז זה קצת יותר מפורט, iSpeed ​​בדרך כלל - מה המילה? נע בין דחיסת רמה 1 לרמה 2; זה מסתכל על המערכת שלך כדי לראות כמה מעבד ומשאבים זמינים זמינים ומקבל פסקי דין לגבי דחיסה רבה, עליה להשתמש בין רמה 1 לרמה 2.

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

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

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

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

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

טיפ צ'נטרה: תגיד עוד פעם אחת, אני מצטער?

אריק קוואנה: כן, אז אתה יודע אם IDERA משתמש ב- CDC, משנה טכנולוגיית לכידת נתונים כדי לבצע גיבויים קטנים יותר, או שמא מבצע גיבויים מלאים בכל פעם?

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

אז עכשיו כשטעתי את המדיניות שלי - אה, אני מצטער, האם הייתה לך שאלה נוספת?

אריק קוונהאג: לא, זהו. לך על זה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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