Sikkerhetskopiering av viktige data er en god ting. Men hva om arbeidet må fortsette med en gang, og hvert minutt teller? Vi i Acronis bestemte oss for å sjekke hvor mulig det er å løse problemet med å starte systemet så raskt som mulig. Og dette er det første innlegget i Active Restore-serien, der jeg skal fortelle deg hvordan vi startet prosjektet sammen med Innopolis University, hvilken løsning vi fant, og hva vi jobber med i dag. Detaljer er under kuttet.
Hallo! Jeg heter Daulet Tumbayev, og i dag vil jeg dele min erfaring med å utvikle et system som fremskynder katastrofegjenoppretting. For å snakke om hele utviklingsveien til prosjektet, la oss starte litt langveisfra. Jeg jobber for tiden på Acronis, men jeg er også utdannet ved Innopolis University, hvor jeg fullførte masterprogrammet i Software Development Management (kjent som MSIT-SE). Innopolis er et ungt universitet, og læreplanen er enda yngre. Men det er bygget på læreplanen til Carnegie Mellon University, hvis arbeid inkluderer et slikt emne som industrielle prosjekter.
Hensikten med industriprosjektet er å fordype studenten i reell utvikling og konsolidere den ervervede kunnskapen i praksis. For å gjøre dette samarbeider universitetet med selskaper som Yandex, Acronis, MTC og dusinvis av andre (totalt, per 2018, hadde universitetet 144 partnere). I løpet av samarbeidet tilbyr bedrifter sine arbeidsområder til universitetet, og studentene velger et av prosjektene som er nærmere deres interesser og opplæringsnivå. For bokstavelig talt to år siden var jeg fortsatt "på den andre siden av barrikadene" og jobbet som student på et annet Acronis-prosjekt. Men denne gangen ble jeg teknisk konsulent for studenter på selskapets side og foreslo Active Restore-prosjektet til Innopolis. Selve ideen om Active Restore ble formulert av Kernel-teamet på Acronis, men utviklingen av løsningen begynte sammen med Innopolis University.
Active Restore – hvorfor er det nødvendig?
Tradisjonelt fungerer katastrofegjenoppretting i henhold til et standardskjema. Etter problemer med datamaskinen din, går du til nettgrensesnittet til et sikkerhetskopisystem, for eksempel Acronis True Image, og klikker på den store "gjenoppretting"-knappen. Deretter må du vente N minutter, og først etter det kan du fortsette å jobbe.
Problemet er at dette tallet N, også kjent som RTO (gjenopprettingstidsobjektiv), den tillatte gjenopprettingstiden, kan være ganske imponerende, noe som avhenger av tilkoblingshastigheten (hvis gjenopprettingen er fra skyen), størrelsen på maskinens harddisk , og en rekke andre faktorer. Er det mulig å redusere det? Ja, det kan du, for for å gjenoppta arbeidet trenger du ikke alltid en full datamaskindisk. De samme bildene og videoene påvirker ikke funksjonaliteten til enheten på noen måte og kan trekkes opp senere i bakgrunnen.
Trenger sjåfør...
Operativsystemet forventer å starte med disken helt klar. Derfor utfører Windows en rekke kontroller for å sjekke integriteten til disken. Systemet vil ikke tillate normal oppstart hvis noen filer som operativsystemet forventer å bli funnet mangler eller er skadet. For å løse dette problemet ble det besluttet å plassere de såkalte omdirigeringsfilene som vi opprettet på disken, som erstatter manglende eller skadede filer, men som faktisk er dummies. Det tar ikke lang tid å lage slike omdirigerere, fordi de faktisk ikke har noe innhold.
Videre restaurering skjer som følger. Ved en bakgrunnsprosess, parallelt med driften av operativsystemet, fylles "dummies" med data. Bakgrunnsgjenopprettingsprosessen tar hensyn til diskbelastningen og overskrider ikke den angitte grensen. Imidlertid kan brukeren eller selve operativsystemet plutselig kreve en fil som ennå ikke eksisterer. Det er her den andre gjenopprettingsmodusen kommer inn i bildet. Prioriteten til den forespurte filen økes til maksimum, og gjenopprettingsprosessen laster filen inn på disken. Operativsystemet mottar den nødvendige filen, om enn med en liten forsinkelse.
Slik ser et ideelt bilde ut. Men i den virkelige verden er det et stort antall fallgruver og potensielle dødpunkter. Sammen med Innopolis masterstudenter bestemte vi oss for å utforske dette utvinningsscenarioet, evaluere gevinstene i RTO og forstå om en slik tilnærming er gjennomførbar? Tross alt var det rett og slett ingen slike løsninger på markedet på den tiden.
Og hvis jeg bestemte meg for å bygge ut servicekomponenten til gutta fra Innopolis, så begynte arbeidet innen Acronis med . Dette ble gjort av Windows Kernel-teamet. Planen var slik:
- Start driveren på et tidlig stadium av OS-oppstart,
- Under arbeid, når vil være helt klar, last ned tjenesten
- Tjenesten behandler sjåførforespørsler og koordinerer sitt videre arbeid.
Finesser av sjåførteknikk
Hvis kollegene mine vil snakke om tjenesten i et annet innlegg, vil vi i denne teksten avsløre vanskelighetene med sjåførutvikling. Den allerede utviklede minifilterdriveren har to driftsmoduser - når systemet startet i normal modus, og når systemet nettopp har opplevd en feil og blir gjenopprettet. Før du laster inn brukerbiblioteker og applikasjoner, og derfor tjenesten vår, oppfører sjåføren seg på samme måte. Han vet ikke hvilken tilstand systemet er i nå. Som et resultat blir hver opprettelse, lesing og skriving logget, og alle metadata blir registrert. Og når tjenesten er online, gir sjåføren denne informasjonen til tjenesten.
Ved normal start sender tjenesten et "Relax"-signal til sjåføren slik at den "slapper av" og slutter å logge alle data nøye. I dette tilfellet bytter driveren til kun å logge endringer på disken og rapporterer dem til tjenesten, som ved hjelp av andre Acronis-verktøy opprettholder disksikkerhetskopien i den mest oppdaterte tilstanden på mediet spesifisert av brukeren. Dette kan være sky, ekstern, gradvis eller nattlig sikkerhetskopiering.
Hvis gjenopprettingsmodus er aktivert, forteller tjenesten sjåføren at den må fungere i "gjenopprettingsmodus". Systemet har nettopp kommet seg etter et krasj, og så snart det sender en forespørsel om å åpne en fil på disken, må minifilteret avskjære denne operasjonen, gjøre denne forespørselen selv, sjekke om en slik fil finnes på disken og om den kan åpnes.
Hvis en fil mangler, overfører minifilteret denne informasjonen til tjenesten, noe som øker prioriteringen av filgjenoppretting (hele denne tiden pågår gjenoppretting i bakgrunnen). Det viser seg at denne filen ganske enkelt hopper til begynnelsen av køen. Etter dette gjenoppretter selve tjenesten (eller andre Acronis-midler) denne filen og forteller driveren at alt er ok, nå kan operativsystemet få tilgang til den og driveren "frigir" den opprinnelige forespørselen, fra systemet til disken.
Hvis gjenoppretting er umulig, informerer tjenesten sjåføren om at filen ikke er i sikkerhetskopien. Vår minifilterdriver sender ganske enkelt systemforespørselen videre, og den opprinnelige forespørselen (selve operativsystemet eller applikasjonen) mottar en "fil ikke funnet"-feil. Dette er imidlertid ganske normalt hvis filen virkelig ikke var på disken og i sikkerhetskopien.
Selvfølgelig vil operativsystemet fungere mye tregere, fordi lesing av en fil eller et bibliotek skjer i flere stadier, muligens med tilgang til eksterne ressurser. Men brukeren kan komme tilbake til jobb så snart som mulig mens gjenoppretting fortsatt pågår.
Trenger lavere, enda lavere...
Prototypen har bevist sin funksjonalitet. Men vi fant også et behov for å gå videre fordi det i noen tilfeller fortsatt er vranglås. Operativsystemet kan for eksempel be om ulike biblioteker i flere tråder, noe som fører til at tjenesten vår går tilbake på seg selv.
Problemet jeg jobber med er å øke hastigheten på Active Restore og øke nivået på systemsikkerhet. La oss si at systemet ikke trenger hele filen, men bare en del av den. For dette formålet ble det utviklet en annen driver - diskfilterdriveren. Det fungerer ikke lenger på filnivå, men på blokknivå. Driftsprinsippet er likt: i normal driftsmodus logger sjåføren ganske enkelt endrede blokker på disken, og i gjenopprettingsmodus prøver den å lese blokken på egen hånd, og hvis den ikke lykkes, ber den tjenesten om å øke prioriteten. Alle andre deler av systemet forblir imidlertid de samme. For eksempel mistenker ikke en tjeneste på OS-nivå at den blir bedt om å kommunisere med en annen driver, fordi hovedoppgaven er å gi OS-et nøyaktig de dataene som er nødvendige for drift. Dette området krever betydelige forbedringer, om ikke annet fordi tjenesten ennå ikke vet hvordan den skal tenke på blokknivå.
Det neste trinnet bestemte meg for å starte driveren dypere og tidligere, og gå ned til nivået med UEFI-drivere og Native Windows-applikasjoner i stedet for tjenesten. For dette formålet ble den utviklet (eller DXE-driver), som starter og dør selv før operativsystemet starter. Men vi vil se på "historien" til UEFI-drivere, detaljer om montering og installasjon, samt spesifikasjonene til Windows Native-applikasjoner i neste innlegg. Så abonner på bloggen vår, og i mellomtiden vil jeg forberede en historie om neste trinn i arbeidet. Jeg vil gjerne se dine kommentarer og råd.
Kun registrerte brukere kan delta i undersøkelsen. , vær så snill.
Har du noen gang hatt situasjoner der restitusjonen tok uendelig lang tid:
-
65.1%Ja 28
-
23.2%No10
-
11.6%Tenkte ikke på det5
43 brukere stemte. 3 brukere avsto.
Kilde: www.habr.com