hosts ફાઇલ પુનઃસ્થાપિત કરતાં VPN કાર્યો પછીના સંપાદનો ભૂંસી નાખે છે

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

કોઈપણ કાર્યપ્રવાહ જે વહેંચાયેલી ફાઇલનો સ્નેપશોટ લે છે અને પછી તેને પુનઃસ્થાપિત કરે છે, વચ્ચે કરેલા દરેક ફેરફારને નુકસાન તરીકે વારસામાં મેળવે છે.

પછી પુનઃસ્થાપિત કરેલો બેકઅપ હમણાંનો બેકઅપ નથી

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

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

દરેક ઘટના એક સૂચના છે, વ્યવહાર નથી

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

પુનરાવર્તિત કનેક્શન ઘટનાઓ બીજો અડધો ભાગ છે: ચકાસણી વિનાનું ઉમેરણ બીજી સરખી એન્ટ્રી બનાવે છે, અને પછી કેટલાક રિઝોલ્વર એક નામ માટે બે જવાબ જુએ છે.

દરેક મેપિંગને એક માલિક આપો

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

જ્યારે બે જીવંત ટનલને એક જ મેપિંગની જરૂર હોય, ત્યારે બીજા માલિકને હજી તેની જરૂર હોય ત્યારે એક ડિસ્કનેક્શન તેને દૂર કરી શકે નહીં. તેના માટે બુલિયન નહીં, સંદર્ભ ગણતરી અથવા સ્પષ્ટ માલિકી રેકોર્ડ જરૂરી છે.

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

જ્યારે શરતી DNS જ ખરી જરૂરિયાત હોય

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

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

પુનરાવર્તિત કનેક્શન, બે સાથે ચાલતી પ્રોફાઇલ અને અસંબંધિત સંપાદન પછીનું ડિસ્કનેક્શન ચકાસો. પરિણામ એ હોવું જોઈએ કે VPNનું મેપિંગ બાકીની મશીનને પાછળ ન ધકેલતા તેના માલિકને અનુસરે.