Active Restore: آیا بازیابی بلایا سریعتر اتفاق می افتد؟ خیلی سریعتر؟

تهیه نسخه پشتیبان از اطلاعات مهم چیز خوبی است. اما اگر کار باید فوراً ادامه پیدا کند و هر دقیقه مهم باشد چه؟ ما در Acronis تصمیم گرفتیم بررسی کنیم که چگونه می توان مشکل راه اندازی سیستم را در سریع ترین زمان ممکن حل کرد. و این اولین پست از سری Active Restore است که در آن به شما خواهم گفت که چگونه پروژه را با دانشگاه Innopolis شروع کردیم، چه راه حلی پیدا کردیم و امروز روی چه چیزی کار می کنیم. جزئیات زیر برش است.

سلام! نام من Daulet Tumbayev است و امروز می خواهم تجربه خود را در توسعه سیستمی که بازیابی بلایای طبیعی را سرعت می بخشد با شما به اشتراک بگذارم. برای صحبت در مورد کل مسیر توسعه پروژه، اجازه دهید کمی از دور شروع کنیم. من در حال حاضر در Acronis کار می کنم، اما من همچنین فارغ التحصیل دانشگاه Innopolis هستم، جایی که برنامه کارشناسی ارشد را در مدیریت توسعه نرم افزار (معروف به MSIT-SE) به پایان رساندم. Innopolis یک دانشگاه جوان است و برنامه درسی حتی جوان تر است. اما بر اساس برنامه درسی دانشگاه کارنگی ملون ساخته شده است که کار آن شامل موضوعی مانند پروژه های صنعتی است.

هدف پروژه صنعتی غوطه ور ساختن دانش آموز در توسعه واقعی و تثبیت دانش کسب شده در عمل است. برای انجام این کار، دانشگاه با شرکت هایی مانند Yandex، Acronis، MTC و ده ها شرکت دیگر همکاری می کند (در مجموع، تا سال 2018، دانشگاه 144 شریک داشته است). در جریان همکاری، شرکت ها زمینه های کاری خود را به دانشگاه ارائه می دهند و دانشجویان یکی از پروژه هایی را که به علایق و سطح آموزشی آنها نزدیکتر است انتخاب می کنند. به معنای واقعی کلمه دو سال پیش من هنوز "در آن سوی سنگرها" بودم و به عنوان دانشجو در پروژه دیگری از Acronis کار می کردم. اما این بار مشاور فنی دانشجویان طرف شرکت شدم و پروژه Active Restore را به Innopolis پیشنهاد دادم. ایده Active Restore توسط تیم Kernel در Acronis فرموله شد، اما توسعه راه حل همراه با دانشگاه Innopolis آغاز شد.

بازیابی فعال - چرا به آن نیاز است؟

به طور سنتی، بازیابی بلایا طبق یک طرح استاندارد کار می کند. پس از مشکلاتی که با رایانه خود دارید، به رابط وب برخی از سیستم های پشتیبان، به عنوان مثال، Acronis True Image رفته و روی دکمه بزرگ "بازیابی" کلیک کنید. در مرحله بعد باید N دقیقه صبر کنید و تنها پس از آن می توانید به کار خود ادامه دهید.

مشکل این است که این عدد N که به عنوان RTO (هدف زمان بازیابی) نیز شناخته می شود، زمان بازیابی مجاز، می تواند بسیار چشمگیر باشد که به سرعت اتصال (اگر بازیابی از فضای ابری باشد)، اندازه هارد دیسک دستگاه شما بستگی دارد. ، و تعدادی از عوامل دیگر. آیا امکان کاهش آن وجود دارد؟ بله، می توانید، زیرا برای از سرگیری کار همیشه به دیسک کامل کامپیوتر نیاز ندارید. همین عکس ها و فیلم ها به هیچ وجه بر عملکرد دستگاه تأثیر نمی گذارد و می توان بعداً در پس زمینه بالا کشید.

نیاز به راننده ...

سیستم عامل انتظار دارد با دیسک کاملاً آماده شروع به کار کند. بنابراین، ویندوز یک سری بررسی ها را برای بررسی یکپارچگی دیسک انجام می دهد. اگر برخی از فایل‌هایی که سیستم عامل انتظار دارد پیدا شوند گم شده یا آسیب دیده باشند، سیستم اجازه راه‌اندازی عادی را نمی‌دهد. برای حل این مشکل، تصمیم بر این شد که فایل‌های به اصطلاح Redirector که ایجاد کرده‌ایم، که جایگزین فایل‌های از دست رفته یا آسیب‌دیده، اما در واقع ساختگی هستند، روی دیسک قرار دهیم. ایجاد چنین تغییر مسیرهایی طولی نمی کشد، زیرا آنها در واقع هیچ محتوایی ندارند.

ترمیم بیشتر به شرح زیر انجام می شود. توسط یک فرآیند پس زمینه، به موازات عملکرد سیستم عامل، "دومیم ها" با داده ها پر می شوند. فرآیند بازیابی پس زمینه بار دیسک را در نظر می گیرد و از حد مشخص شده تجاوز نمی کند. با این حال، کاربر یا خود سیستم عامل ممکن است به طور ناگهانی به فایلی نیاز داشته باشد که هنوز وجود ندارد. اینجاست که حالت ریکاوری دوم وارد عمل می شود. اولویت فایل درخواستی به حداکثر افزایش می یابد و فرآیند بازیابی فوری فایل را روی دیسک بارگیری می کند. سیستم عامل فایل مورد نیاز را البته با کمی تاخیر دریافت می کند.

این همان چیزی است که یک تصویر ایده آل به نظر می رسد. با این حال، در دنیای واقعی، تعداد زیادی از دام ها و بن بست های بالقوه وجود دارد. به همراه دانشجویان کارشناسی ارشد Innopolis، تصمیم گرفتیم این سناریوی بازیابی را بررسی کنیم، دستاوردهای RTO را ارزیابی کنیم و بفهمیم که آیا چنین رویکردی امکان پذیر است؟ از این گذشته ، در آن زمان چنین راه حل هایی در بازار وجود نداشت.

و اگر تصمیم گرفتم بخش خدمات را برای بچه‌های Innopolis در نظر بگیرم، کار در Acronis شروع شد مینی فیلتر توسط درایور سیستم فایل. این کار توسط تیم Windows Kernel انجام شد. طرح به این صورت بود:

• راه اندازی درایور در مرحله اولیه راه اندازی سیستم عامل،
• در حین کار، زمانی که فضای کاربر کاملا آماده خواهد شد، سرویس را دانلود کنید
• این سرویس درخواست های راننده را پردازش می کند و کارهای بعدی خود را هماهنگ می کند.

ظرافت های مهندسی راننده

اگر همکاران من در پست دیگری در مورد خدمات صحبت کنند، در این متن پیچیدگی های توسعه درایور را آشکار خواهیم کرد. درایور مینی فیلتر از قبل توسعه یافته دارای دو حالت عملیاتی است - زمانی که سیستم در حالت عادی شروع به کار کرد و زمانی که سیستم به تازگی دچار نقص شده و در حال بازیابی است. قبل از بارگیری کتابخانه‌ها و برنامه‌های کاربردی و در نتیجه سرویس ما، درایور به همین صورت عمل می‌کند. او نمی داند این سیستم در حال حاضر در کدام وضعیت است. در نتیجه، هر ایجاد، خواندن و نوشتن ثبت می‌شود و تمام ابرداده‌ها ثبت می‌شوند. و هنگامی که سرویس آنلاین است، راننده این اطلاعات را در اختیار سرویس قرار می دهد.

در صورت شروع عادی، سرویس سیگنال "Relax" را به راننده می فرستد تا "آرام شود" و ثبت نام دقیق همه داده ها را متوقف کند. در این حالت، درایور فقط به ثبت تغییرات روی دیسک تغییر می‌کند و آن‌ها را به سرویس گزارش می‌دهد که با استفاده از ابزارهای دیگر Acronis، پشتیبان‌گیری دیسک را در به‌روزترین حالت در رسانه‌ای که کاربر مشخص کرده است، حفظ می‌کند. این می تواند پشتیبان ابری، از راه دور، تدریجی یا شبانه باشد.

اگر حالت بازیابی فعال باشد، سرویس به راننده می گوید که باید در حالت «بازیابی» کار کند. سیستم به تازگی از یک خرابی بهبود یافته است، و به محض اینکه درخواستی برای باز کردن یک فایل روی دیسک می دهد، مینی فیلتر باید این عملیات را متوقف کند، خود این درخواست را انجام دهد، بررسی کند که آیا چنین فایلی روی دیسک وجود دارد یا خیر. می توان آن را باز کرد.

اگر فایلی مفقود باشد، مینی فیلتر این اطلاعات را به سرویس منتقل می کند که اولویت بازیابی فایل را افزایش می دهد (در تمام این مدت بازیابی در پس زمینه انجام می شود). معلوم می شود که این فایل به سادگی به ابتدای صف می پرد. پس از این، خود سرویس (یا سایر ابزارهای Acronis) این فایل را بازیابی می کند و به درایور می گوید که همه چیز درست است، اکنون سیستم عامل می تواند به آن دسترسی داشته باشد و درایور درخواست اصلی را از سیستم به دیسک "رها" می کند.

اگر بازیابی غیرممکن باشد، سرویس به راننده اطلاع می دهد که فایل در نسخه پشتیبان نیست. درایور مینی فیلتر ما به سادگی درخواست سیستم را بیشتر ارسال می کند و درخواست کننده اصلی (خود سیستم عامل یا برنامه) خطای "فایل یافت نشد" را دریافت می کند. با این حال، اگر فایل واقعاً روی دیسک و پشتیبان نباشد، این کاملاً طبیعی است.

البته، سیستم عامل بسیار کندتر کار خواهد کرد، زیرا خواندن هر فایل یا کتابخانه در چندین مرحله، احتمالاً با دسترسی به منابع راه دور، انجام می شود. اما کاربر می تواند در اسرع وقت در حالی که بازیابی در حال انجام است، به کار خود بازگردد.

نیاز به پایین تر، حتی پایین تر...

نمونه اولیه کارایی خود را ثابت کرده است. اما ما همچنین نیاز به حرکت را پیدا کردیم زیرا در برخی موارد هنوز بن بست وجود دارد. به عنوان مثال، سیستم عامل می تواند کتابخانه های مختلف را در چندین رشته درخواست کند، که منجر به بازگشت سرویس ما به خود می شود.

مشکلی که در حال حاضر روی آن کار می کنم افزایش سرعت Active Restore و افزایش سطح امنیت سیستم است. فرض کنید سیستم به کل فایل نیاز ندارد، بلکه فقط به بخشی از آن نیاز دارد. برای این منظور، درایور دیگری ایجاد شد - درایور فیلتر دیسک. دیگر در سطح فایل کار نمی کند، بلکه در سطح بلوک کار می کند. اصل کار مشابه است: در حالت عملکرد عادی، راننده به سادگی بلوک های تغییر یافته را روی دیسک ثبت می کند و در حالت بازیابی، سعی می کند خود بلاک را بخواند و در صورت عدم موفقیت، از سرویس درخواست می کند تا اولویت را افزایش دهد. با این حال، تمام بخش های دیگر سیستم به همان صورت باقی می مانند. به عنوان مثال، یک سرویس در سطح سیستم عامل حتی مشکوک نیست که از آن خواسته می شود با راننده دیگری ارتباط برقرار کند، زیرا وظیفه اصلی این است که دقیقاً داده هایی را که برای عملکرد لازم است در اختیار سیستم عامل قرار دهد. این حوزه نیاز به بهبودهای قابل توجهی دارد، البته فقط به این دلیل که سرویس هنوز نمی داند چگونه در سطح بلوک فکر کند.

در مرحله بعدی تصمیم گرفتم درایور را عمیق‌تر و زودتر راه‌اندازی کنم و به جای سرویس، به سطح درایورهای UEFI و برنامه‌های ویندوز بومی نزول کنم. برای این منظور توسعه یافت درایور بوت UEFI (یا درایور DXE)، که حتی قبل از شروع سیستم عامل شروع می شود و می میرد. اما ما به "تاریخچه" درایورهای UEFI، جزئیات مربوط به مونتاژ و نصب و همچنین ویژگی های برنامه های Windows Native در پست بعدی خواهیم پرداخت. پس با عضویت در وبلاگ ما، در این مدت یک داستان در مورد مرحله بعدی کار آماده خواهم کرد. خوشحال می شوم نظرات و راهنمایی های شما را ببینم.

فقط کاربران ثبت نام شده می توانند در نظرسنجی شرکت کنند. ورود، لطفا.

آیا تا به حال موقعیت هایی داشته اید که بهبودی به طرز طاقت فرسایی طولانی شود:

• ٪۱۰۰بله 28

• ٪۱۰۰شماره 10

• ٪۱۰۰بهش فکر نکردم5

43 کاربر رای دادند 3 کاربر رای ممتنع دادند.

منبع: www.habr.com