કન્ટેનરનો કે તેની ફાઇલોનો બેકઅપ? પુનઃસ્થાપનની આકાર પ્રમાણે નિર્ણય કરો
ઇમેજ અને ફાઇલ-સ્તરીય બેકઅપ જુદી જુદી વસ્તુઓ પુનઃસ્થાપિત કરે છે અને જુદી જુદી કી પર આધાર રાખે છે. સંગ્રહિત ઑબ્જેક્ટને તમને ખરેખર જરૂરી પુનઃસ્થાપન સાથે મેળવો.
તમે એન્ક્રિપ્ટેડ કન્ટેનરનો એક જ ઑબ્જેક્ટ તરીકે બેકઅપ લઈ શકો છો, અથવા તેને માઉન્ટ કરીને અંદરની ફાઇલોનો બેકઅપ લઈ શકો છો. બંને VPNમાંથી સરળતાથી પસાર થાય છે, અને સામ્ય ત્યાં જ પૂરું થાય છે. તે જુદી જુદી વસ્તુઓ પુનઃસ્થાપિત કરે છે, જુદી જુદી કી પર આધાર રાખે છે, જુદો જગ્યા વપરાશ ધરાવે છે, અને કોઈને ડેટા પાછો જોઈએ ત્યારે જુદી રીતે નિષ્ફળ જાય છે. પહેલાં પુનઃસ્થાપન ઑબ્જેક્ટ પસંદ કરો, પછી પરિવહન, પછી સંગ્રહિત નકલનું એન્ક્રિપ્શન. નીચેની ચેકલિસ્ટ તે જ ક્રમમાં ચાલે છે, કારણ કે લગભગ દરેક બેકઅપ વિવાદ વાસ્તવમાં એ અંગેનો મતભેદ છે કે આ ત્રણમાંથી કયો નિર્ણય પહેલાં લેવાયો.
બે ઑબ્જેક્ટ, બે પુનઃસ્થાપન આકાર
ઇમેજ બેકઅપ કન્ટેનર પુનઃસ્થાપિત કરે છે: એન્ક્રિપ્ટેડ વૉલ્યુમ પાછું મળે છે અને તેને ખોલવા માટે હજુ તેની પુનઃસ્થાપન સામગ્રી જોઈએ. ફાઇલ-સ્તરીય બેકઅપ ફાઇલો અને ડિરેક્ટરી-વૃક્ષો પુનઃસ્થાપિત કરે છે, અને તેમને સુરક્ષિત રાખતું જે પણ એન્ક્રિપ્શન હોય તે બેકઅપ રિપોઝિટરીની વિશેષતા છે, મૂળ કન્ટેનરની નહીં. દૂરના ફોલ્ડરમાં સાદી નકલ ત્રીજો કિસ્સો છે, અને તે તે ફોલ્ડરમાં આકસ્મિક રૂપે જે સુરક્ષા હોય તે વારસામાં લે છે.
| Object | What a restore gives you | Where the encryption question lands |
|---|---|---|
| Encrypted container image | The volume, still locked | The container format and its recovery key material |
| Mounted files into a backup tool | Selected files and metadata | The backup repositorys own keys and design |
| Plain copy to a remote folder | Whatever the copy process kept | Whatever protects that storage afterwards |
વચ્ચેની પંક્તિ એ છે જે લોકો ખોટી વાંચે છે. તે સંપૂર્ણ સારી રચના હોઈ શકે: બેકઅપ પ્રોગ્રામ સ્થાનિક રૂપે પ્લેઇનટેક્સ્ટ વાંચે છે અને એન્ક્રિપ્ટેડ, પ્રમાણિત રિપોઝિટરી લખે છે. પછી સુરક્ષા તે પ્રોગ્રામ અને તેની ઓળખપત્રો પર રહે છે, મૂળ કન્ટેનરના પાસવર્ડ પર નહીં, અને બંનેને એક જ નિયંત્રણ તરીકે વર્ણવવા જોઈએ નહીં.
તપાસ 1: પુનઃસ્થાપને શું પુનર્નિર્માણ કરવું પડે?
પ્રશ્નને બેકઅપના નહીં, પુનઃસ્થાપનના સ્વરૂપમાં પૂછો. જો આવશ્યકતા “આ સેવાને બીજા હોસ્ટ પર પાછી લાવો” હોય, તો ઇમેજ અને તેની પુનઃસ્થાપન સામગ્રી સુસંગત જવાબ છે. જો આવશ્યકતા “માર્ચની નાણાકીય સ્પ્રેડશીટ પાછી લાવો” હોય, તો એક ફાઇલ કાઢવા માટે ઘણા ગીગાબાઇટની ઇમેજ પુનઃસ્થાપિત કરવી એ મોંઘો જવાબ છે. બંને કાયદેસર પુનઃસ્થાપન છે, અને તે અદલાબદલી શકાય તેવા બજેટ નથી. જે યોજના ફક્ત એકનું નામ લે છે તે આખરે બીજા દ્વારા ચકાસાશે.
પુનઃસ્થાપન લક્ષ્ય યોજનામાં લખો: આખું વૉલ્યુમ, ડિરેક્ટરી-વૃક્ષ, અથવા વ્યક્તિગત ફાઇલો. પછી નોંધો કે કયા મેટાડેટાને તેમની સાથે મુસાફરી કરવી પડે, કારણ કે માલિકી, પરવાનગીઓ, વિસ્તૃત લક્ષણો અને સમય-છાપ ફાઇલ-સ્તરીય પુનઃસ્થાપનનો ભાગ છે અને પરીક્ષણ દરમિયાન પર્યાપ્ત લાગતા નકલ-આધારિત કાર્યપ્રવાહોમાં ઘણી વાર ખોવાઈ જાય છે.
પુનઃસ્થાપન કોણ કરશે તે પણ નક્કી કરો. કોઈ પણ ઓપરેટર માઉન્ટ કરી શકે તેવી ફાઇલ-સ્તરીય રિપોઝિટરી એ કી-ધારકની હાજરી જરૂરી હોય તેવી ઇમેજ કરતાં જુદું પ્રવેશ મોડેલ છે, અને બંનેમાંથી કોઈ આપોઆપ સારું નથી. મહત્ત્વનું એ છે કે પસંદગી સભાન અને લખાયેલી હોય.
તપાસ 2: સંગ્રહિત નકલને શું સુરક્ષિત રાખે છે?
VPN પરિવહન-વિભાગને સુરક્ષિત રાખે છે. સ્થાનાંતરણ પૂરું થયા પછી સંગ્રહિત નકલ વિશે તે કંઈ કહેતું નથી, અને “તે ટનલમાંથી ગયું” એ બેકઅપ ઓપરેટરની તમારો ડેટા વાંચવાની ક્ષમતા વિશેનું નિવેદન નથી. જો દૂરની બાજુ બીજું કોઈ ચલાવે છે, તો પ્રશ્ન એ છે કે તેઓ શું વાંચી શકે છે, કે લિંક એન્ક્રિપ્ટેડ હતી કે નહીં.
ઇમેજ માટે તેનો અર્થ કન્ટેનરની કી સામગ્રીને ઇમેજથી અલગ રીતે સુરક્ષિત કરવી. હેડર ગુમાવવો એ વૉલ્યુમ ગુમાવવું છે, તેથી હેડરનો બેકઅપ એવી જગ્યાએ લો જ્યાં ઇમેજ ન હોય:
cryptsetup luksHeaderBackup /dev/vg0/data --header-backup-file data-header.img
cryptsetup luksDump /dev/vg0/data | head -20ફાઇલ-સ્તરીય રિપોઝિટરી માટે ચકાસો કે સાધન સામગ્રી અને મેટાડેટાને હોસ્ટ છોડતા પહેલાં એન્ક્રિપ્ટ અને પ્રમાણિત કરે છે, અને જાણો કે કી કોની પાસે છે. Resticનું રચના દસ્તાવેજીકરણ સ્પષ્ટ કહે છે કે તે વિશ્વસનીય સ્રોત-હોસ્ટ ધારે છે અને એન્ક્રિપ્શન સંગ્રહ પર પ્રવેશ ધરાવતા કોઈને બેકઅપ ડિલીટ કરતાં રોકતું નથી. બંને ચેતવણીઓ મહત્ત્વની છે: રિપોઝિટરી ગુપ્ત હોઈ શકે અને તોપણ નાશ પામી શકે.
તપાસ 3: નકલ સુસંગત છે?
જે બેકઅપ બદલાતી ફાઇલસિસ્ટમને કેપ્ચર કરે છે તે નકલ છે, પુનઃસ્થાપન-બિંદુ નહીં. ઇમેજ માટે વૉલ્યુમ સાધનની સમર્થિત પદ્ધતિથી સ્થિર સ્નેપશોટ લો, જેનો અર્થ સામાન્ય રીતે સ્નેપશોટ ક્રિયા અથવા અનમાઉન્ટ છે, મોટી ફાઇલ બદલાતી હોય ત્યારે વાંચવું નહીં:
lvcreate -L 5G -s -n data-snap /dev/vg0/data
cryptsetup open /dev/vg0/data-snap data-snap --readonlyમાઉન્ટ કરેલી ફાઇલો માટે જીવંત ડેટાબેઝ અને અન્ય સંકલિત ડેટા માટે એપ્લિકેશનની સમર્થિત સુસંગતતા-પ્રક્રિયા વાપરો. ફાઇલસિસ્ટમ-સ્તરીય નકલ અને એપ્લિકેશન-સુસંગત પુનઃસ્થાપન-બિંદુ જુદા જ વર્ણન છે, અને તફાવત ત્યારે જ દેખાય છે જ્યારે તમે પુનઃસ્થાપિત નકલમાંથી એપ્લિકેશન શરૂ કરવાનો પ્રયાસ કરો છો.
પુનઃસ્થાપન સામગ્રીને સ્વતંત્ર સુરક્ષિત માર્ગ પર રાખો. મૂળ મશીન ગુમાવવાથી તેનો બેકઅપ ખોલતી એકમાત્ર ઓળખપત્ર પણ ક્યારેય ગુમાવવી ન જોઈએ, અને કી-ફાઇલ બેકઅપ લેવાઈ રહેલા વૉલ્યુમ પર રહે ત્યારે બરાબર એમ જ થાય છે. તે અલગીકરણ સભાનપણે ચકાસો: એવા હોસ્ટ પર પુનઃસ્થાપિત કરો જેણે મૂળ ક્યારેય જોયું નથી, ફક્ત યોજના કહે છે તે ઉપલબ્ધ વસ્તુનો ઉપયોગ કરીને.
તપાસ 4: આ ઑબ્જેક્ટ માટે ફેરફાર-શોધ કામ કરે છે?
એન્ક્રિપ્ટેડ કન્ટેનર મોટાભાગના સ્થાનાંતરણ સાધનોને એક મોટી અપારદર્શક ફાઇલ જેવું લાગે છે, તેથી નાનું પ્લેઇનટેક્સ્ટ સંપાદન સાધન અને ફોર્મેટ પ્રમાણે મોટું પુનઃવાંચન અથવા સંપૂર્ણ પુનઃઅપલોડ કરી શકે છે. ચલ-કદના ટુકડા અને નકલ-દૂરીકરણ, જેમ restic દસ્તાવેજીકરણ કરે છે, તે ઘટાડી શકે છે, પણ તે તે સાધનની વિશેષતા છે, સામાન્ય રૂપે એન્ક્રિપ્ટેડ કન્ટેનરની નહીં.
ધારવાને બદલે માપો. નાના, નિરુપદ્રવી ફેરફાર પછી પ્રથમ રનની સરખામણી બીજા રન સાથે કરો, અને સ્થાનાંતરિત બાઇટ તથા વીતેલો સમય નોંધો. પ્રયોગ કરતી વખતે જાણીતો-સારો બેકઅપ સાચવો, જેથી એક પરીક્ષણ તમારું એકમાત્ર પુનઃસ્થાપન-બિંદુ ખાઈ ન જાય.
પછી ચેકલિસ્ટ એકમાત્ર મહત્ત્વની પરીક્ષાથી પૂરી કરો: મૂળ મશીન વિના પુનઃસ્થાપન. પુનઃસ્થાપિત કન્ટેનર ખોલો, અથવા પસંદ કરેલી ફાઇલો તેમના મેટાડેટા સાથે પુનઃસ્થાપિત કરો, અને ખાતરી કરો કે એપ્લિકેશન કે વપરાશકર્તા પરિણામ વાપરી શકે છે. ઝડપી, સારી રીતે એન્ક્રિપ્ટ થયેલું સ્થાનાંતરણ જે આ પરીક્ષાનો જવાબ આપી શકતું નથી તે તમારા ડેટાની નકલ છે, તેનો બેકઅપ નહીં.