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

כתב ויתור: ההערה מיועדת למטרות בידור. הצפיפות הספציפית של מידע שימושי בו נמוכה. זה נכתב "לעצמי".

הקדמה לירית

dump הקבצים בארגון שלנו פועל על מכונה וירטואלית VMware ESXi 6 המריץ את Windows Server 2016. וזה לא רק מזבלה. זהו שרת חילופי קבצים בין חטיבות מבניות: יש שיתוף פעולה, תיעוד פרויקטים ותיקיות מסורקי רשת. באופן כללי, כל חיי הייצור נמצאים כאן.

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

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

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

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

בסוף האשף הופיע ברשימה ה-Datastore הטרי... ויחד איתו ה-Datastores מהדיסקים הפיזיים שנותרו.

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

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

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

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

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

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

שוב גוגל, פורומים, KB'shki ושוב הבכי של ירוסלבנה: VMware ESXi לא מספק מנגנון שחזור נתונים. לכל שרשורי הדיון יש שני סופים: מישהו שוחזר באמצעות ה-VMFS Recovery היקר של DiskInternals, או שמישהו נעזר במומחה תוכנה שמקדם את שירותיו באופן פעיל vmfs-tools и dd. האפשרות של רכישת רישיון DiskInternals VMFS Recovery תמורת $700 אינה אופציה. לאפשר לאדם מבחוץ מ"שטחו של אויב פוטנציאלי" לגשת לנתונים ארגוניים היא גם לא אופציה. אבל בוצע בגוגל שניתן לקרוא מחיצות VMFS גם על ידי UFS Explorer.

שחזור VMFS של DiskInternals

גרסת הניסיון הורדה והותקנה. התוכנית ראתה בהצלחה את מחיצת VMFS הריקה:

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

התצוגה המקדימה הראתה שהקבצים חיים:

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

שלוש שורות של בושההניסיון לנעול את התוכנה ללא בושה הסתיים בכישלון. אבל UFS Explorer ננעל.

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

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

סייר UFS

סריקת דיסק הראתה נוכחות של 7 צמתים. מספר הצמתים "באופן מפתיע" עלה בקנה אחד עם מספר קבצי *-flat.vmdk שזוהו על ידי VMFS Recovery:

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

באופן כללי, דיסקי vmdk מנקודת המבט של ESXi מורכבים משני קבצים: קובץ נתונים (<שם מכונה>-flat.vmdk) וקובץ פריסת דיסק "פיזי" (<שם מכונה>.vmdk). אם תעלה קובץ *-flat.vmdk ל-Datastore ממחשב מקומי, ESXi לא יזהה אותו כקובץ דיסק חוקי. ל-VMware Knowledge Base יש מאמר כיצד ליצור באופן ידני קובץ מתאר דיסק: kb.vmware.com/s/article/1002511, אבל לא הייתי צריך לעשות זאת, פשוט העתקתי את התוכן של הקבצים המתאימים מאזור התצוגה המקדימה של תוכן הקבצים ב-DiskInternals VMFS Recovery:

לאחר 4 שעות של פריקת צומת של 2,5 TB מ-UFS Explorer ו-20 שעות של טעינה ל-Datastore של ה-Hypervisor, קובצי הדיסק הקורסים חוברו למחשב הוירטואלי החדש שנוצר. הדיסקים נקלטו. לא נצפה אובדן נתונים.

מקור: www.habr.com