સક્રિય પુનઃસ્થાપના: શું આપત્તિ પુનઃપ્રાપ્તિ ઝડપથી થઈ શકે છે? વધુ ઝડપી?

મહત્વપૂર્ણ ડેટાનો બેકઅપ લેવો એ સારી બાબત છે. પરંતુ જો કાર્ય તરત જ ચાલુ રાખવાની જરૂર હોય, અને દરેક મિનિટ ગણાય? અમે Acronis ખાતે શક્ય તેટલી ઝડપથી સિસ્ટમ શરૂ કરવાની સમસ્યાનું નિરાકરણ કેટલું શક્ય છે તે તપાસવાનું નક્કી કર્યું. અને સક્રિય પુનઃસ્થાપિત શ્રેણીની આ પ્રથમ પોસ્ટ છે, જેમાં હું તમને કહીશ કે અમે ઇનોપોલિસ યુનિવર્સિટી સાથે મળીને પ્રોજેક્ટ કેવી રીતે શરૂ કર્યો, અમને કયો ઉકેલ મળ્યો અને આજે અમે શું કામ કરી રહ્યા છીએ. વિગતો કટ હેઠળ છે.

નમસ્તે! મારું નામ દૌલેટ તુમ્બાયેવ છે, અને આજે હું તમારી સાથે આપત્તિ પુનઃપ્રાપ્તિને ઝડપી બનાવતી સિસ્ટમ વિકસાવવાનો મારો અનુભવ શેર કરવા માંગુ છું. પ્રોજેક્ટના સમગ્ર વિકાસ માર્ગ વિશે વાત કરવા માટે, ચાલો થોડી દૂરથી શરૂ કરીએ. હું હાલમાં એક્રોનિસમાં કામ કરું છું, પરંતુ હું ઇનોપોલિસ યુનિવર્સિટીનો સ્નાતક પણ છું, જ્યાં મેં સોફ્ટવેર ડેવલપમેન્ટ મેનેજમેન્ટ (MSIT-SE તરીકે ઓળખાય છે) માં માસ્ટર પ્રોગ્રામ પૂર્ણ કર્યો છે. ઇનોપોલિસ એક યુવાન યુનિવર્સિટી છે, અને અભ્યાસક્રમ પણ નાનો છે. પરંતુ તે કાર્નેગી મેલોન યુનિવર્સિટીના અભ્યાસક્રમ પર બનેલ છે, જેના કાર્યમાં ઔદ્યોગિક પ્રોજેક્ટ્સ જેવા વિષયનો સમાવેશ થાય છે.

ઔદ્યોગિક પ્રોજેક્ટનો હેતુ વિદ્યાર્થીને વાસ્તવિક વિકાસમાં નિમજ્જિત કરવાનો અને પ્રાપ્ત જ્ઞાનને વ્યવહારમાં એકીકૃત કરવાનો છે. આ કરવા માટે, યુનિવર્સિટી યાન્ડેક્સ, એક્રોનિસ, એમટીસી અને અન્ય ડઝનેક જેવી કંપનીઓ સાથે સહકાર આપે છે (કુલ 2018 સુધીમાં, યુનિવર્સિટીના 144 ભાગીદારો હતા). સહકાર દરમિયાન, કંપનીઓ તેમના કાર્ય ક્ષેત્રો યુનિવર્સિટીને ઓફર કરે છે, અને વિદ્યાર્થીઓ તેમની રુચિઓ અને તાલીમના સ્તરની નજીક હોય તેવા પ્રોજેક્ટ્સમાંથી એક પસંદ કરે છે. શાબ્દિક રીતે બે વર્ષ પહેલાં હું હજી પણ "બેરિકેડ્સની બીજી બાજુ" હતો અને અન્ય એક્રોનિસ પ્રોજેક્ટ પર વિદ્યાર્થી તરીકે કામ કર્યું હતું. પરંતુ આ વખતે હું કંપનીના વિદ્યાર્થીઓ માટે ટેકનિકલ સલાહકાર બન્યો અને ઇનોપોલિસને એક્ટિવ રિસ્ટોર પ્રોજેક્ટનો પ્રસ્તાવ મૂક્યો. એક્ટિવ રિસ્ટોરનો ખૂબ જ વિચાર એક્રોનિસમાં કર્નલ ટીમ દ્વારા ઘડવામાં આવ્યો હતો, પરંતુ સોલ્યુશનનો વિકાસ ઇનોપોલિસ યુનિવર્સિટી સાથે મળીને શરૂ થયો હતો.

સક્રિય પુનઃસ્થાપના - તે શા માટે જરૂરી છે?

પરંપરાગત રીતે, આપત્તિ પુનઃપ્રાપ્તિ પ્રમાણભૂત યોજના અનુસાર કાર્ય કરે છે. તમારા કમ્પ્યુટરમાં મુશ્કેલીઓ પછી, તમે કેટલીક બેકઅપ સિસ્ટમના વેબ ઇન્ટરફેસ પર જાઓ, ઉદાહરણ તરીકે, એક્રોનિસ ટ્રુ ઇમેજ, અને મોટા "રીસ્ટોર" બટનને ક્લિક કરો. આગળ તમારે N મિનિટ રાહ જોવાની જરૂર છે, અને તે પછી જ તમે કામ કરવાનું ચાલુ રાખી શકો છો.

સમસ્યા એ છે કે આ નંબર N, જેને RTO (પુનઃપ્રાપ્તિ સમય ઉદ્દેશ્ય) તરીકે પણ ઓળખવામાં આવે છે, માન્ય પુનઃપ્રાપ્તિ સમય, ખૂબ પ્રભાવશાળી હોઈ શકે છે, જે કનેક્શન ઝડપ (જો પુનઃપ્રાપ્તિ ક્લાઉડમાંથી છે), તમારા મશીનની હાર્ડ ડ્રાઈવના કદ પર આધારિત છે. , અને અન્ય ઘણા પરિબળો. શું તેને ઘટાડવું શક્ય છે? હા, તમે કરી શકો છો, કારણ કે કામ ફરી શરૂ કરવા માટે તમારે હંમેશા સંપૂર્ણ કમ્પ્યુટર ડિસ્કની જરૂર નથી. સમાન ફોટા અને વિડિયો ઉપકરણની કાર્યક્ષમતાને કોઈપણ રીતે અસર કરતા નથી અને પાછળથી પૃષ્ઠભૂમિમાં ખેંચી શકાય છે.

ડ્રાઈવરની જરૂર છે...

ઑપરેટિંગ સિસ્ટમ સંપૂર્ણપણે તૈયાર ડિસ્ક સાથે શરૂ થવાની અપેક્ષા રાખે છે. તેથી, વિન્ડોઝ ડિસ્કની અખંડિતતા ચકાસવા માટે શ્રેણીબદ્ધ તપાસ કરે છે. સિસ્ટમ સામાન્ય સ્ટાર્ટઅપને મંજૂરી આપશે નહીં જો કેટલીક ફાઇલો કે જે OS શોધવાની અપેક્ષા રાખે છે તે ખૂટે છે અથવા ક્ષતિગ્રસ્ત છે. આ સમસ્યાને ઉકેલવા માટે, અમે બનાવેલી કહેવાતી રીડાયરેક્ટર ફાઇલોને ડિસ્ક પર મૂકવાનું નક્કી કરવામાં આવ્યું હતું, જે ગુમ થયેલ અથવા ક્ષતિગ્રસ્ત ફાઇલોને બદલે છે, પરંતુ હકીકતમાં તે ડમી છે. આવા રીડાયરેક્ટર્સ બનાવવામાં લાંબો સમય લાગતો નથી, કારણ કે તેમની પાસે વાસ્તવમાં કોઈ સામગ્રી નથી.

વધુ પુનઃસંગ્રહ નીચે પ્રમાણે થાય છે. પૃષ્ઠભૂમિ પ્રક્રિયા દ્વારા, ઑપરેટિંગ સિસ્ટમના સંચાલનની સમાંતર, "ડમી" ડેટાથી ભરેલી હોય છે. પૃષ્ઠભૂમિ પુનઃપ્રાપ્તિ પ્રક્રિયા ડિસ્ક લોડને ધ્યાનમાં લે છે અને ઉલ્લેખિત મર્યાદા કરતાં વધી જતી નથી. જો કે, વપરાશકર્તા અથવા ઓપરેટિંગ સિસ્ટમને અચાનક એવી ફાઇલની જરૂર પડી શકે છે જે હજી અસ્તિત્વમાં નથી. આ તે છે જ્યાં બીજો પુનઃપ્રાપ્તિ મોડ રમતમાં આવે છે. વિનંતી કરેલ ફાઇલની પ્રાથમિકતા મહત્તમ સુધી વધારવામાં આવે છે, અને પુનઃપ્રાપ્તિ પ્રક્રિયા તાત્કાલિક ફાઇલને ડિસ્ક પર લોડ કરે છે. ઓપરેટિંગ સિસ્ટમ થોડો વિલંબ હોવા છતાં જરૂરી ફાઇલ મેળવે છે.

આ એક આદર્શ ચિત્ર જેવો દેખાય છે. જો કે, વાસ્તવિક દુનિયામાં, મોટી સંખ્યામાં મુશ્કેલીઓ અને સંભવિત અવરોધો છે. ઇનોપોલિસ માસ્ટરના વિદ્યાર્થીઓ સાથે મળીને, અમે આ પુનઃપ્રાપ્તિ દૃશ્યનું અન્વેષણ કરવાનું, RTOમાં થયેલા લાભોનું મૂલ્યાંકન કરવાનું અને સમજીએ છીએ કે શું આવો અભિગમ શક્ય છે? છેવટે, તે સમયે બજારમાં આવા કોઈ ઉકેલો નહોતા.

અને જો મેં ઇનોપોલિસના છોકરાઓને સર્વિસ કમ્પોનન્ટ આપવાનું નક્કી કર્યું, તો પછી એક્રોનિસમાં કામ શરૂ થયું ફાઇલ સિસ્ટમ ડ્રાઇવર દ્વારા મિની-ફિલ્ટર. આ વિન્ડોઝ કર્નલ ટીમ દ્વારા કરવામાં આવ્યું હતું. યોજના આ પ્રમાણે હતી:

• OS સ્ટાર્ટઅપના પ્રારંભિક તબક્કે ડ્રાઇવરને લોંચ કરો,
• કામ દરમિયાન, જ્યારે વપરાશકર્તા જગ્યા સંપૂર્ણપણે તૈયાર થઈ જશે, સેવા ડાઉનલોડ કરો
• સેવા ડ્રાઇવરની વિનંતીઓ પર પ્રક્રિયા કરે છે અને તેના આગળના કાર્યનું સંકલન કરે છે.

ડ્રાઇવર એન્જિનિયરિંગની સૂક્ષ્મતા

જો મારા સાથીદારો બીજી પોસ્ટમાં સેવા વિશે વાત કરશે, તો આ ટેક્સ્ટમાં આપણે ડ્રાઇવર વિકાસની જટિલતાઓને જાહેર કરીશું. પહેલેથી જ વિકસિત મિની-ફિલ્ટર ડ્રાઇવરમાં બે ઓપરેટિંગ મોડ્સ છે - જ્યારે સિસ્ટમ સામાન્ય મોડમાં શરૂ થાય છે, અને જ્યારે સિસ્ટમમાં હમણાં જ નિષ્ફળતાનો અનુભવ થયો છે અને તેને પુનઃસ્થાપિત કરવામાં આવી રહી છે. વપરાશકર્તા પુસ્તકાલયો અને એપ્લિકેશન લોડ કરતા પહેલા, અને તેથી અમારી સેવા, ડ્રાઇવર સમાન વર્તન કરે છે. તેને ખબર નથી કે સિસ્ટમ હાલમાં કઈ સ્થિતિમાં છે. પરિણામે, દરેક બનાવો, વાંચો અને લખો લોગ થયેલ છે, અને તમામ મેટાડેટા રેકોર્ડ કરવામાં આવે છે. અને જ્યારે સેવા ઓનલાઈન હોય છે, ત્યારે ડ્રાઈવર સેવાને આ માહિતી પ્રદાન કરે છે.

સામાન્ય શરૂઆતના કિસ્સામાં, સેવા ડ્રાઇવરને "રિલેક્સ" સિગ્નલ મોકલે છે જેથી કરીને તે "આરામ" કરે અને તમામ ડેટાને સાવચેતીપૂર્વક લોગ કરવાનું બંધ કરે. આ કિસ્સામાં, ડ્રાઇવર ફક્ત ડિસ્ક પરના ફેરફારોને લોગિંગ પર સ્વિચ કરે છે અને તેમને સેવાને જાણ કરે છે, જે અન્ય એક્રોનિસ ટૂલ્સનો ઉપયોગ કરીને, વપરાશકર્તા દ્વારા ઉલ્લેખિત મીડિયા પર સૌથી અપ-ટુ-ડેટ સ્થિતિમાં ડિસ્ક બેકઅપને જાળવી રાખે છે. આ ક્લાઉડ, રિમોટ, ક્રમિક અથવા રાત્રિ બેકઅપ હોઈ શકે છે.

જો પુનઃપ્રાપ્તિ મોડ સક્ષમ હોય, તો સેવા ડ્રાઇવરને કહે છે કે તેને "પુનઃપ્રાપ્તિ" મોડમાં કામ કરવાની જરૂર છે. સિસ્ટમ હમણાં જ ક્રેશમાંથી પુનઃપ્રાપ્ત થઈ છે, અને જલદી તે ડિસ્ક પર ફાઇલ ખોલવાની વિનંતી કરે છે, મિની-ફિલ્ટરે આ ઑપરેશનને અટકાવવું જોઈએ, આ વિનંતી પોતે જ કરવી જોઈએ, તપાસો કે આવી કોઈ ફાઇલ ડિસ્ક પર અસ્તિત્વમાં છે કે કેમ અને તે ખોલી શકાય છે.

જો કોઈ ફાઇલ ખૂટે છે, તો મિની-ફિલ્ટર આ માહિતીને સેવામાં પ્રસારિત કરે છે, જે ફાઇલ પુનઃપ્રાપ્તિની પ્રાથમિકતામાં વધારો કરે છે (આ બધા સમયે, પુનઃપ્રાપ્તિ પૃષ્ઠભૂમિમાં ચાલુ છે). તે તારણ આપે છે કે આ ફાઇલ ફક્ત કતારની શરૂઆતમાં જમ્પ કરે છે. આ પછી, સેવા પોતે (અથવા અન્ય એક્રોનિસ અર્થ) આ ફાઇલને પુનઃસ્થાપિત કરે છે અને ડ્રાઇવરને કહે છે કે બધું બરાબર છે, હવે ઑપરેટિંગ સિસ્ટમ તેને ઍક્સેસ કરી શકે છે અને ડ્રાઇવર સિસ્ટમથી ડિસ્ક સુધીની મૂળ વિનંતીને "રિલીઝ" કરે છે.

જો પુનઃપ્રાપ્તિ અશક્ય છે, તો સેવા ડ્રાઇવરને જાણ કરે છે કે ફાઇલ બેકઅપમાં નથી. અમારું મિની-ફિલ્ટર ડ્રાઇવર સિસ્ટમ વિનંતીને આગળ પસાર કરે છે અને મૂળ વિનંતીકર્તા (ઓએસ પોતે અથવા એપ્લિકેશન) "ફાઇલ મળી નથી" ભૂલ પ્રાપ્ત કરે છે. જો કે, જો ફાઇલ ખરેખર ડિસ્ક પર અને બેકઅપમાં ન હોય તો આ એકદમ સામાન્ય છે.

અલબત્ત, ઓપરેટિંગ સિસ્ટમ ખૂબ જ ધીમી ગતિએ કામ કરશે, કારણ કે કોઈપણ ફાઇલ અથવા લાઇબ્રેરીનું વાંચન ઘણા તબક્કામાં થાય છે, સંભવતઃ દૂરસ્થ સંસાધનોની ઍક્સેસ સાથે. પરંતુ પુનઃપ્રાપ્તિ હજુ પણ થઈ રહી છે ત્યારે વપરાશકર્તા શક્ય તેટલી વહેલી તકે કામ પર પાછા આવી શકે છે.

નીચું જોઈએ, નીચું પણ...

પ્રોટોટાઇપે તેની કાર્યક્ષમતા સાબિત કરી છે. પરંતુ અમને આગળ વધવાની જરૂર પણ મળી કારણ કે કેટલાક કિસ્સાઓમાં હજુ પણ મડાગાંઠ છે. ઉદાહરણ તરીકે, ઑપરેટિંગ સિસ્ટમ વિવિધ થ્રેડોમાં વિવિધ લાઇબ્રેરીઓને વિનંતી કરી શકે છે, જે અમારી સેવાને પોતાની તરફ લૂપ કરવા તરફ દોરી જાય છે.

હું હાલમાં જે સમસ્યા પર કામ કરી રહ્યો છું તે સક્રિય પુનઃસ્થાપનની ઝડપને વધારીને અને સિસ્ટમ સુરક્ષાના સ્તરને વધારી રહી છે. ચાલો કહીએ કે સિસ્ટમને આખી ફાઇલની જરૂર નથી, પરંતુ તેનો માત્ર એક ભાગ છે. આ હેતુ માટે, બીજો ડ્રાઇવર વિકસાવવામાં આવ્યો હતો - ડિસ્ક ફિલ્ટર ડ્રાઇવર. તે હવે ફાઇલ લેવલ પર કામ કરતું નથી, પરંતુ બ્લોક લેવલ પર. ઑપરેશનનો સિદ્ધાંત સમાન છે: સામાન્ય ઑપરેશન મોડમાં, ડ્રાઇવર ફક્ત ડિસ્ક પર બદલાયેલા બ્લોક્સને લૉગ કરે છે, અને પુનઃપ્રાપ્તિ મોડમાં, તે તેની જાતે બ્લોક વાંચવાનો પ્રયાસ કરે છે, અને જો અસફળ હોય, તો સેવાને અગ્રતા વધારવા વિનંતી કરે છે. જો કે, સિસ્ટમના અન્ય તમામ ભાગો સમાન રહે છે. ઉદાહરણ તરીકે, OS-સ્તરની સેવાને શંકા પણ નથી હોતી કે તેને બીજા ડ્રાઇવર સાથે વાતચીત કરવા માટે કહેવામાં આવી રહ્યું છે, કારણ કે મુખ્ય કાર્ય એ છે કે OS ને ઑપરેશન માટે જરૂરી ડેટા સાથે બરાબર પ્રદાન કરવું. આ ક્ષેત્રમાં નોંધપાત્ર સુધારાની જરૂર છે, જો માત્ર એટલા માટે કે સેવા હજુ સુધી બ્લોક સ્તરે કેવી રીતે વિચારવું તે જાણતી નથી.

આગળનું પગલું મેં ડ્રાઇવરને વધુ ઊંડાણમાં અને વહેલું શરૂ કરવાનું નક્કી કર્યું, સેવાને બદલે UEFI ડ્રાઇવરો અને નેટિવ વિન્ડોઝ એપ્લીકેશનના સ્તર પર ઉતરી. આ હેતુ માટે તે વિકસાવવામાં આવી હતી UEFI બુટ ડ્રાઈવર (અથવા DXE ડ્રાઇવર), જે OS શરૂ થાય તે પહેલાં જ શરૂ થાય છે અને મૃત્યુ પામે છે. પરંતુ અમે આગામી પોસ્ટમાં UEFI ડ્રાઇવરોનો "ઇતિહાસ", એસેમ્બલી અને ઇન્સ્ટોલેશન વિશેની વિગતો તેમજ Windows નેટિવ એપ્લિકેશન્સની વિશિષ્ટતાઓ જોઈશું. તેથી અમારા બ્લોગ પર સબ્સ્ક્રાઇબ કરો, અને તે દરમિયાન હું કામના આગલા તબક્કા વિશે વાર્તા તૈયાર કરીશ. મને તમારી ટિપ્પણીઓ અને સલાહ જોઈને આનંદ થશે.

ફક્ત નોંધાયેલા વપરાશકર્તાઓ જ સર્વેમાં ભાગ લઈ શકે છે. સાઇન ઇન કરો, મહેરબાની કરીને.

શું તમને ક્યારેય એવી પરિસ્થિતિઓ આવી છે કે જ્યાં પુનઃપ્રાપ્તિમાં ખૂબ જ લાંબો સમય લાગ્યો છે:

• 65.1%હા 28

• 23.2%નંબર 10

• 11.6%તેના વિશે વિચાર્યું નથી5

43 વપરાશકર્તાઓએ મત ​​આપ્યો. 3 વપરાશકર્તાઓ દૂર રહ્યા.

સોર્સ: www.habr.com