Die Sicherung wichtiger Daten ist essenziell. Aber was, wenn die Arbeit sofort fortgesetzt werden muss und jede Minute zählt? Bei Acronis haben wir uns gefragt, wie wir das Problem der maximal schnellen Systembereitstellung angehen können. Dies ist der erste Beitrag unserer Reihe zur Aktiven Wiederherstellung, in dem ich erläutere, wie wir gemeinsam mit der Innopolis-Universität an diesem Projekt gearbeitet haben, welche Lösung wir gefunden haben und woran wir aktuell arbeiten. Weitere Informationen finden Sie im Folgenden.
Hallo! Mein Name ist Daulet Tumbaev, und heute möchte ich Ihnen von meinen Erfahrungen bei der Entwicklung eines Systems berichten, das die Notfallwiederherstellung beschleunigt. Um den gesamten Entwicklungspfad des Projekts zu erläutern, fangen wir ein wenig weiter hinten an. Momentan arbeite ich bei Acronis, bin aber auch Absolvent der Universität Innopolis, die ich im Rahmen eines Masterstudiengangs in "Softwareentwicklungsmanagement" (bekannt als MSIT-SE) abgeschlossen habe. Innopolis ist eine junge Universität, und das Curriculum ist noch jünger. Dennoch basiert es auf den Lehrplänen der Carnegie Mellon University, die ein Thema wie industrielle Projekte abdecken.
Das Ziel des Industrieprojekts ist es, die Studierenden in die reale Entwicklung einzuführen und das erworbene Wissen praktisch anzuwenden. Zu diesem Zweck kooperiert die Universität mit Unternehmen wie Yandex, Acronis, MTC und vielen anderen (insgesamt gab es im Jahr 2018 144 Partner). Im Rahmen dieser Zusammenarbeit bieten die Unternehmen der Universität ihre Arbeitsgebiete an, während die Studierenden ein Projekt auswählen, das ihren Interessen und ihrem Kenntnisstand am nächsten kommt. Noch vor zwei Jahren war ich „auf der anderen Seite der Barrikade“ und arbeitete als Student an einem anderen Projekt von Acronis. Diesmal jedoch fungierte ich als technischer Berater für die Studierenden seitens des Unternehmens und schlug der Innopolis-Universität das Projekt Active Restore vor. Die Idee von Active Restore wurde vom Kernel-Team bei Acronis formuliert, die Lösung wurde jedoch in Zusammenarbeit mit der Universität Innopolis entwickelt.
Active Restore – wozu ist das notwendig?
Traditionell funktioniert die Notfallwiederherstellung nach einem festgelegten Schema. Nach einem Computerproblem melden Sie sich über die Web-Oberfläche eines Backup-Systems wie Acronis True Image an und klicken auf die große Schaltfläche „Wiederherstellen“. Danach müssen Sie N Minuten warten, bevor Sie Ihre Arbeit fortsetzen können.
Das Problem ist, dass diese Zahl N, auch bekannt als RTO (Recovery Time Objective), die zulässige Wiederherstellungszeit, erheblich sein kann und von der Geschwindigkeit der Verbindung (wenn die Wiederherstellung aus der Cloud erfolgt), der Größe der Festplatte Ihres Geräts und mehreren anderen Faktoren abhängt. Kann man sie verringern? Ja, das ist möglich, denn um die Arbeit wieder aufzunehmen, ist nicht immer die gesamte Festplatte des Computers erforderlich. Fotos und Videos haben keinen Einfluss auf die Funktionalität des Geräts und können später im Hintergrund wiederhergestellt werden.
Driver needed…
Das Betriebssystem ist darauf ausgelegt, mit einer vollständig vorbereiteten Festplatte zu starten. Daher führt Windows eine Reihe von Integritätsprüfungen der Festplatte durch. Das System erlaubt keinen ordnungsgemäßen Start, wenn bestimmte Dateien fehlen oder beschädigt sind, die das OS erwartet zu finden. Um dieses Problem zu lösen, haben wir uns entschieden, sogenannte Umleitungsdateien auf der Festplatte zu platzieren, die fehlende oder beschädigte Dateien ersetzen, jedoch in der Realität leer sind. Solche Umleitungen zu erstellen, ist schnell erledigt, da sie tatsächlich keinen Inhalt haben.
Das Wiederherstellungsverfahren erfolgt wie folgt: Während das Betriebssystem läuft, werden die 'Lücken' im Hintergrund mit Daten gefüllt. Der Hintergrund-Wiederherstellungsprozess berücksichtigt die Belastung der Festplatte und überschreitet nicht das festgelegte Limit. Allerdings kann es sein, dass der Benutzer oder das Betriebssystem plötzlich eine Datei anfordert, die noch nicht vorhanden ist. In diesem Fall kommt der zweite Wiederherstellungsmodus ins Spiel. Die Priorität der angeforderten Datei wird auf maximal gesetzt, und der Wiederherstellungsprozess lädt die Datei dringend auf die Festplatte. Das Betriebssystem erhält die benötigte Datei, jedoch mit einer kleinen Verzögerung.
So sieht das ideale Szenario aus. In der realen Welt gibt es jedoch zahlreiche Fallstricke und potenzielle Deadlocks. Zusammen mit den Master-Studenten von Innopolis haben wir beschlossen, dieses Wiederherstellungsszenario zu untersuchen, den Gewinn in der RTO zu bewerten und zu verstehen, ob ein solcher Ansatz umsetzbar ist. Solche Lösungen waren zu diesem Zeitpunkt auf dem Markt schlichtweg nicht vorhanden.
Während ich den Service-Aspekt den Kollegen aus Innopolis überlassen habe, wurde intern bei Acronis an . Das übernahm das Team des Windows Kernels. Der Plan war folgender:
- Den Treiber in einer frühen Phase des Systemstarts zu laden,
- während der Betrieb läuft, wenn vollständig bereit ist, den Dienst zu laden.
- Der Dienst verarbeitet die Anfragen des Treibers und koordiniert dessen weitere Arbeit.
Details zur Treiberentwicklung
Während meine Kollegen in einem anderen Post über den Dienst berichten, werden wir in diesem Text die Feinheiten der Treiberentwicklung erläutern. Der bereits entwickelte Mini-Filter-Treiber hat zwei Betriebsmodi – wenn das System im Normalbetrieb gestartet wurde und wenn das System gerade einen Fehler erlebt hat und sich im Wiederherstellungsprozess befindet. Vor dem Laden der Benutzerbibliotheken und Anwendungen, und folglich auch unseres Dienstes, verhält sich der Treiber gleich. Er weiß nicht, in welchem Zustand sich das System gerade befindet. Infolge dessen werden jeder create, read und write protokolliert, und alle Metadaten werden erfasst. Und wenn der Dienst online ist, stellt der Treiber diese Informationen dem Dienst zur Verfügung.
Bei einem regulären Start sendet der Dienst ein Signal "Relax" an den Treiber, damit dieser "entspannt" und aufhört, alle Daten penibel zu protokollieren. In diesem Fall wechselt der Treiber zu einer Protokollierung, die nur die Änderungen auf der Festplatte erfasst, und informiert den Dienst, der mithilfe anderer Acronis-Tools das Backup der Festplatte in einem möglichst aktuellen Zustand auf dem vom Benutzer festgelegten Medium hält. Dies kann ein cloudbasiertes, entferntes, inkrementelles oder nächtliches Backup sein.
Wenn der Wiederherstellungsmodus aktiviert wird, informiert der Dienst den Treiber, dass er im Modus "Recovery" arbeiten muss. Das System hat sich gerade von einem Absturz erholt, und sobald es eine Anfrage zum Öffnen einer Datei auf der Festplatte stellt, muss der Mini-Filter diese Operation abfangen, die Anfrage selbst stellen, überprüfen, ob eine solche Datei auf der Festplatte vorhanden ist und ob sie geöffnet werden kann.
Wenn die Datei fehlt, überträgt der Minifilter diese Information an den Dienst, der die Wiederherstellung der Datei priorisiert (währenddessen erfolgt im Hintergrund die Wiederherstellung). Das bedeutet, dass diese Datei einfach an den Anfang der Warteschlange springt. Danach stellt der Dienst selbst (oder andere Acronis-Mittel) diese Datei wieder her und informiert den Treiber, dass alles in Ordnung ist. Nun kann das Betriebssystem darauf zugreifen und der Treiber "gibt" die ursprüngliche Anfrage vom System an die Festplatte frei.
Wenn die Wiederherstellung nicht möglich ist, informiert der Dienst den Treiber, dass die Datei auch im Backup nicht vorhanden ist. unser Minifilter-Treiber leitet die systemtechnische Anfrage einfach weiter, und die ursprüngliche anfragende Entität (das Betriebssystem oder die Anwendung) erhält den Fehler "Datei nicht gefunden". Das ist durchaus normal, wenn die Datei tatsächlich nicht auf der Festplatte und im Backup vorhanden war.
Natürlich wird das Betriebssystem deutlich langsamer arbeiten, da das Lesen einer Datei oder Bibliothek mehrere Schritte erfordert, möglicherweise mit Zugriff auf remote Ressourcen. Dennoch kann der Benutzer so schnell wie möglich mit der Arbeit beginnen, während die Wiederherstellung weiterhin im Gange ist.
Noch weiter nach unten, noch weiter nach unten...
Der Prototyp hat seine Funktionsfähigkeit bewiesen. Allerdings haben wir auch die Notwendigkeit erkannt, weiterzugehen, da in einigen Fällen weiterhin Deadlocks auftreten. Zum Beispiel kann das Betriebssystem mehrere Bibliotheken in mehreren Threads anfordern, was dazu führt, dass unser Service sich selbst blockiert.
Das Problem, an dem ich gerade arbeite, ist die Verbesserung der Geschwindigkeit von Active Restore und die Erhöhung der Sicherheit des Systems. Angenommen, das System benötigt nicht die gesamte Datei, sondern nur einen Teil davon. Zu diesem Zweck wurde ein weiterer Treiber entwickelt – ein Filter-Treiber für Laufwerke. Dieser arbeitet nicht auf Dateiebene, sondern auf Blockebene. Der Arbeitsprinzip ist ähnlich: Im normalen Betriebsmodus protokolliert der Treiber einfach die geänderten Blöcke auf dem Laufwerk, und im Wiederherstellungsmodus versucht er, den Block selbst zu lesen; im Falle eines Fehlschlags fordert er eine Prioritätserhöhung vom Dienst an. Dabei bleiben alle anderen Teile des Systems unverändert. Beispielsweise ahnt der Dienst auf Betriebssystemebene nicht einmal, dass er mit einem anderen Treiber kommunizieren soll, denn die Hauptaufgabe besteht darin, dem Betriebssystem genau die Daten bereitzustellen, die für den Betrieb erforderlich sind. Diese Richtung erfordert erhebliche Nachbesserungen, zumal der Dienst noch nicht auf Blockebene denken kann.
Als nächsten Schritt entschied ich mich, den Treiber tiefer und früher zu starten, indem ich auf die Ebene der UEFI-Treiber und nativen Windows-Anwendungen anstelle des Dienstes wechselte. Zu diesem Zweck wurde entwickelt (oder DXE-Treiber), der startet und stirbt, bevor das Betriebssystem überhaupt hochfährt. Doch die „Geschichte“ der UEFI-Treiber, Details zur Erstellung und Installation sowie spezifische Informationen zu Windows Native-Anwendungen werden wir im nächsten Beitrag behandeln. Also abonnieren Sie unseren Blog, während ich die nächsten Schritte vorbereite. Ich freue mich auf Ihre Kommentare und Ratschläge.
Nur registrierte Benutzer können an der Umfrage teilnehmen. Sind Sie an Contour interessiert?
Hatten Sie schon einmal Situationen, in denen die Wiederherstellung quälend lange dauerte:
65.1%Ja28
23.2%Nein10
11.6%Habe nicht darüber nachgedacht5
43 Benutzer haben abgestimmt. 3 Benutzer haben sich enthalten.
Quelle: habr.com
