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

પુનઃનિર્માણના લક્ષ્યથી શરૂ કરો

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

સામગ્રીને ત્રણ ટોપલામાં જૂથબદ્ધ કરો: ઓળખ, રૂપરેખાંકન અને સ્થિતિ. ઓળખ એ કી, પ્રમાણપત્રો અને તેમના પર સહી કરતી સત્તા છે. રૂપરેખાંકન એ ડીમન સેટિંગ્સ, પૂલ, રૂટ અને ફાયરવોલ નીતિ છે, જ્યારે સ્થિતિ એ પીઅર, ખાતા અને રદીકરણોનો સમૂહ છે જે દરરોજ બદલાય છે.

ઓળખ એ ભાગ છે જે તમે ફરી બનાવી શકતા નથી

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

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

એક ક્ષણમાં સ્થિતિ કેપ્ચર કરો

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

wg showconf wg0 > /srv/backup/wg0.runtime.conf
sqlite3 /var/lib/vpn/admin.db ".backup '/srv/backup/admin.db'"
cp -a /etc/wireguard /srv/backup/etc-wireguard
sha256sum /srv/backup/*.conf > /srv/backup/MANIFEST

પ્રથમ આદેશ ચાલતા ઇન્ટરફેસને રૂપરેખાંકન તરીકે પાછું છાપે છે, જે મેનેજમેન્ટ સાધનને બદલે હાથે ઉમેરાયેલા પીઅરને પકડવાનો સૌથી ઝડપી માર્ગ છે; આ wg(8) મેન્યુઅલ તેને દસ્તાવેજ કરે છે. sqlite લાઇન મેનેજમેન્ટ ડેટાબેઝ માટેની પેટર્ન છે: બેકઅપ આદેશ લેખક ચાલુ રહેતાં સુસંગત નકલ બનાવે છે. ડિરેક્ટરી નકલ પરવાનગીઓ સાચવે છે, જે મહત્ત્વનું છે કારણ કે તે કી ફાઇલો ફક્ત root વાંચી શકે છે. મેનિફેસ્ટ એ છે જે તમને સંપૂર્ણ આર્કાઇવને કપાયેલી આર્કાઇવથી અલગ પાડવા દે છે.

પુનઃસ્થાપન શક્ય બનાવો અને પછી તેનો પ્રયાસ કરો

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

બાકાતોને સામગ્રી જેટલી જ કાળજીથી દસ્તાવેજ કરો. ક્લાઉડ ફાયરવોલ નિયમો, DNS રેકોર્ડ અને બાહ્ય ડિરેક્ટરી—દરેકને પોતાનું પુનઃપ્રાપ્તિ પગલું જોઈ શકે છે. સફળ ફાઇલ નકલ એ સેવા પાછી આવે તેનો પુરાવો નથી; એકમાત્ર પુરાવો જે ગણાય છે તે પુનઃનિર્મિત એન્ડપોઇન્ટ છે જે મૂળ જેવી જ સ્વીકૃતિ કસોટી પાસ કરે છે.

સંબંધિત લેખો