מטרות גיבוי על דיסק כפי שעולה משיחות עם לקוחות הן:
1. גיבוי מהיר יותר. מסתבר שזו מטרה שלא תמיד מסתייעת. הסיבה לכך היא שנכון להיום רובוטים\טייפים מאוד מהירים וגם מאפשרים multiplexing דבר שלא מתבצע בד"כ בסביבת גיבוי לדיסק וכנראה שלא בסביבה של dedup. לקוחות דיברו על כך שהם התפלאו שגיבוי על דיסק היה יותר איטי מגיבוי על קלטות ורק כאשר פירמטו את הדיסק מחדש ב- stripping הכי נרחב – אז קיבלו ביצועים טובים מספיק.
2. שחזור מהיר יותר ואמין יותר – זאת מטרה שמצליחה ראלית. גם מהירות מבחינת השחזור וגם אמינות לעומת קלטות שמתקלקלות.
3. לחסוך שינוע קלטות. לקוחות מרפלקים סביבת VTL אחת לשנייה וכך מכפילים "קלטות" ללא צורך בשינוע פיזי.
4. דחייה של שדרוג\השקעה ברובוטים.
5. תפעול נוח יותר –נראה שזו מטרה ראלית.
כמו כן, לקוחות ציינו שכאשר משתמשים בדיסק בתור VTL הוא "מאבד" את חלק מתכונות שלו – לדוגמה, בזמן שמרפלקים ספרייה אחת לשנייה (דבר די גדול) – הכל נעול ולא ניתן לבצע כלום (כולל המשך גיבוי). כמו כן בזמן שמבצעים העתקה מקלטת על דיסק לקלטת פיזית גם יש נעילה של חלקים נרחבים של המערכת. כמו כן לקוחות דיברו על כל שהיו מקרים שבהם "נגעו" בקלטות וירטואליות בטעות (או לא בטעות) – העבירו "קלטות" מ- LUN אחד לשני או ניתקו LUN ועליו קלטות ולאחר מכן חיברו מחדש והסתבר שתוכנת הגיבוי לא מצליחה לזהות את הקלטות הוירטואלית.
נקודה נוספת היא שלא תמיד חושבים על עלות החשמל\מיזוג של פתרון גיבוי על דיסק לעומת קלטות.
לגבי יחסים של dedup מה שלקוחות מציינים הם יחסים של החל מ- 1 ל- 20 יותר אבל גם פחות. אם מדיניות הגיבוי הראשונית הייתה גיבוי אינקרמנטלי אז מצליחים פחות לדחוס. לקוח שעבר ל- dedup מגיבוי אינקרמנטלי דיבר על דחיסה של 1 ל- 7 בלבד (גם זה מספר לא מבוטל).
נקודה נוספת היא שלא כל האפליקציות נתמכות – לדוגמה לא כל הפתרונות תומכים ב- Exchange .
לסיכום, גיבוי על דיסק, VTL ו- DEDUP הן טכנולוגיות מבטיחות אולם מבחינת בשלות אנו נמצאים בתחילת שלב הבשלות.
1. גיבוי מהיר יותר. מסתבר שזו מטרה שלא תמיד מסתייעת. הסיבה לכך היא שנכון להיום רובוטים\טייפים מאוד מהירים וגם מאפשרים multiplexing דבר שלא מתבצע בד"כ בסביבת גיבוי לדיסק וכנראה שלא בסביבה של dedup. לקוחות דיברו על כך שהם התפלאו שגיבוי על דיסק היה יותר איטי מגיבוי על קלטות ורק כאשר פירמטו את הדיסק מחדש ב- stripping הכי נרחב – אז קיבלו ביצועים טובים מספיק.
2. שחזור מהיר יותר ואמין יותר – זאת מטרה שמצליחה ראלית. גם מהירות מבחינת השחזור וגם אמינות לעומת קלטות שמתקלקלות.
3. לחסוך שינוע קלטות. לקוחות מרפלקים סביבת VTL אחת לשנייה וכך מכפילים "קלטות" ללא צורך בשינוע פיזי.
4. דחייה של שדרוג\השקעה ברובוטים.
5. תפעול נוח יותר –נראה שזו מטרה ראלית.
כמו כן, לקוחות ציינו שכאשר משתמשים בדיסק בתור VTL הוא "מאבד" את חלק מתכונות שלו – לדוגמה, בזמן שמרפלקים ספרייה אחת לשנייה (דבר די גדול) – הכל נעול ולא ניתן לבצע כלום (כולל המשך גיבוי). כמו כן בזמן שמבצעים העתקה מקלטת על דיסק לקלטת פיזית גם יש נעילה של חלקים נרחבים של המערכת. כמו כן לקוחות דיברו על כל שהיו מקרים שבהם "נגעו" בקלטות וירטואליות בטעות (או לא בטעות) – העבירו "קלטות" מ- LUN אחד לשני או ניתקו LUN ועליו קלטות ולאחר מכן חיברו מחדש והסתבר שתוכנת הגיבוי לא מצליחה לזהות את הקלטות הוירטואלית.
נקודה נוספת היא שלא תמיד חושבים על עלות החשמל\מיזוג של פתרון גיבוי על דיסק לעומת קלטות.
לגבי יחסים של dedup מה שלקוחות מציינים הם יחסים של החל מ- 1 ל- 20 יותר אבל גם פחות. אם מדיניות הגיבוי הראשונית הייתה גיבוי אינקרמנטלי אז מצליחים פחות לדחוס. לקוח שעבר ל- dedup מגיבוי אינקרמנטלי דיבר על דחיסה של 1 ל- 7 בלבד (גם זה מספר לא מבוטל).
נקודה נוספת היא שלא כל האפליקציות נתמכות – לדוגמה לא כל הפתרונות תומכים ב- Exchange .
לסיכום, גיבוי על דיסק, VTL ו- DEDUP הן טכנולוגיות מבטיחות אולם מבחינת בשלות אנו נמצאים בתחילת שלב הבשלות.
אין תגובות:
הוסף רשומת תגובה