Pritunl: నియంత్రణ స్థితి vs ఉత్పత్తి చేసిన ప్రొఫైల్

ఒక ఆర్కైవ్ పని చేసే Pritunl డిప్లాయ్మెంట్ను పునరుద్ధరిస్తుంది; మరొకటి దాని చిత్రాన్ని మాత్రమే పునరుద్ధరిస్తుంది. క్లయింట్ ప్రొఫైల్, హోస్ట్ కాన్ఫిగరేషన్ కాపీ మరియు స్టేట్ డైరెక్టరీ tarball అన్నీ బ్యాకప్ లాగా కనిపిస్తాయి, మరియు వాటిలో ఏదీ ఒంటరిగా Pritunl నిర్వహించే సంస్థలు, వినియోగదారులు మరియు సర్వర్ నిర్వచనాలను తిరిగి తీసుకురాదు. తేడా యాజమాన్యంలో ఉంది: స్థితిలో కొంత భాగం డేటాబేస్కు, కొంత హోస్ట్కు చెందుతుంది, మరియు కొంత మళ్లీ ఉత్పత్తి చేసిన అవుట్పుట్. తప్పు పొరను ఎంచుకుంటే, పునరుద్ధరణ ప్రారంభమై, విని, ఏమీ తెలియని సర్వర్ను సృష్టిస్తుంది. ఈ పోలిక మూడు పొరలను వేరు చేస్తుంది, మీరు ఉంచే ఆర్కైవ్ మీరు పునరుద్ధరిస్తున్న వైఫల్యానికి సరిపోయేలా చేస్తుంది.

రెండు వస్తువులు బ్యాకప్ లాగా కనిపిస్తాయి మరియు ఒకటి మాత్రమే సేవను పునరుద్ధరిస్తుంది

డౌన్లోడ్ చేసిన క్లయింట్ ప్రొఫైల్లో సర్టిఫికెట్, కీ మరియు ఎండ్పాయింట్ ఉంటాయి. అది ఆ ఒక పరికరానికి పూర్తి మరియు డిప్లాయ్మెంట్ రికార్డ్గా పనికిరాదు: అది సంస్థలు, నిలిపివేయబడిన వినియోగదారులు, సర్వర్ మార్గాలు లేదా పరిపాలనా ఖాతాలను తీసుకెళ్లదు. ప్రొఫైల్ ఫోల్డర్ నుండి పునరుద్ధరణ ఏదైనా ఒకదానితో ధృవీకరించుకోలేని క్లయింట్లను ఇస్తుంది.

హోస్ట్ కాన్ఫిగరేషన్ కాపీ కూడా అదే స్థాయిలో పాక్షికం. /etc/pritunl.conf హోస్ట్-స్థాయి సెట్టింగ్లను కలిగి ఉంది, డేటాబేస్ను చేరుకునే విధానంతో సహా, మరియు VPN వస్తువులను తానే కలిగి లేదు.

డేటాబేస్ ఏమి కలిగి ఉంది మరియు హోస్ట్ ఏమి కలిగి ఉంది

Pritunl సర్వర్ నిర్వచనాలు, వినియోగదారులు, సంస్థలు మరియు కీలను MongoDB లో ఉంచుతుంది. ఆ డేటాబేస్ అధికారిక నియంత్రణ తలం, మరియు డిస్క్లో ఉత్పత్తి అయిన ప్రతి OpenVPN ఫైల్ దాని నుండి ఉత్పన్నమైన అవుట్పుట్. ఉత్పత్తి చేసిన ఫైల్లో నేరుగా చేసిన మార్పు తదుపరి పునరుత్పత్తి వరకు ఉంటుంది, ఆ తర్వాత అదృశ్యమవుతుంది, అందుకే రన్టైమ్ ఫైళ్లను సవరించడం శాశ్వత సరిదిద్దడం కాదు. అదే నియమం ప్రభావవంతమైన మార్గాలు మరియు ఇంటర్ఫేస్లకు వర్తిస్తుంది: అవి నియంత్రణ తలం ఏమి ఉత్పత్తి చేసిందో వివరిస్తాయి, ఏమి ఉత్పత్తి చేయాలో కాదు.

హోస్ట్ చిన్న కానీ బదిలీ చేయలేని విలువల సమితిని అందిస్తుంది. వాటిలో ఒకటి /var/lib/pritunl/pritunl.uuid, ఆ నిర్దిష్ట నోడ్ యొక్క గుర్తింపు.

ఆ గుర్తింపు క్లస్టర్లో అత్యంత ముఖ్యమైనది. ప్రత్యామ్నాయ హోస్ట్కు సక్రియ నోడ్ UUID యొక్క క్లోన్కు బదులుగా దాని స్వంత నమోదు అవసరం, లేకపోతే రెండూ ఒకే గుర్తింపు కోసం పోరాడతాయి. ప్రతి హోస్ట్, దాని UUID మరియు అది సూచించే డేటాబేస్ మధ్య మ్యాపింగ్ను నమోదు చేయండి, ఎందుకంటే ఒకే డేటాబేస్ డంప్ ఏ హోస్ట్ సెట్టింగ్లు ఏ మెషీన్కు చెందాయో వివరించదు. సాఫ్ట్వేర్ వెర్షన్లు మరియు పబ్లిక్ ఎండ్పాయింట్ పేర్లు అదే రికార్డులో ఉంటాయి.

స్థిరమైన డంప్ తీసుకోండి, డైరెక్టరీ కాపీ కాదు

సేవ రాస్తున్నప్పుడు MongoDB డేటా డైరెక్టరీని కాపీ చేయడం ఉపయోగించగల డేటాబేస్ను ఏర్పరచకపోవచ్చు అనే ఫైళ్లను సృష్టిస్తుంది. బదులుగా డేటాబేస్ మద్దతు ఇచ్చే డంప్ మార్గాన్ని ఉపయోగించండి, మీకు నిజంగా ఉన్న టోపోలజీకి వ్యతిరేకంగా అమలు చేయండి:

mongodump --uri="mongodb://127.0.0.1:27017/pritunl" --out=/var/backups/pritunl/db
sudo tar czf /var/backups/pritunl/host.tgz /etc/pritunl.conf /var/lib/pritunl/pritunl.uuid

ఒంటరి హోస్ట్ ఆ సరళ రూపాన్ని తట్టుకుంటుంది. రెప్లికా సెట్కు స్థిరమైన సమయ బిందువు అవసరం, మరియు oplog ఆధారిత డంప్కు సాధారణ డంప్లో లేని అవసరాలు ఉంటాయి. మద్దతు ఇచ్చే విధానం మీ MongoDB వెర్షన్ మరియు టోపోలజీపై ఆధారపడి ఉంటుంది, కాబట్టి డేటా డైరెక్టరీ ఉనికి నుండి దాన్ని అంచనా వేయవద్దు. హోస్ట్ పొరను డంప్ పక్కన, అదే రన్లో, అదే టైమ్స్టాంప్తో ఆర్కైవ్ చేయండి.

అవసరమయ్యే ముందు పునరుద్ధరణను సాధన చేయండి

ఎవరూ పునరుద్ధరించని బ్యాకప్ ఒక పరికల్పన. సేవను వేరుచేసిన నెట్వర్క్లో నిర్మించి, డంప్ను పునరుద్ధరించి, హోస్ట్ ఫైళ్లను తిరిగి ఉంచండి:

mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /

ఆ తర్వాత ప్రక్రియను కాదు, వస్తువులను ధృవీకరించండి: లాగిన్ అవ్వండి, సంస్థలు మరియు వినియోగదారులు ఉన్నాయని నిర్ధారించండి, మరియు మీకు తెలిసిన సర్వర్ నిర్వచనానికి వ్యతిరేకంగా ఒక పరీక్ష క్లయింట్ను ప్రారంభించండి. చిరునామాలు మరియు గుర్తింపులు ఉద్దేశపూర్వకంగా అయ్యే వరకు పునరుద్ధరించిన హోస్ట్ ఉత్పత్తి ఎండ్పాయింట్ను ప్రచారం చేయడాన్ని లేదా నిజమైన కనెక్షన్లను అంగీకరించడాన్ని నిరోధించండి. ఇక్కడే ఆర్కైవ్కు వైఫల్యం చెందిన మెషీన్లో మాత్రమే ఉన్న ఆధారాలు అవసరమని మీరు కనుగొంటారు, కాబట్టి పునరుద్ధరణ ఆధారాలను స్వతంత్ర స్థలంలో నిల్వ చేయండి. మీరు ఇప్పుడే కోల్పోయిన హోస్ట్పై ఆధారపడే పునరుద్ధరణ పునరుద్ధరణ ప్రణాళిక కాదు.

చివరగా, పాత స్నాప్షాట్ పాత నిర్ణయాలను పునరుద్ధరిస్తుందని గుర్తుంచుకోండి. నిర్వాహకుడు డంప్ తీసుకున్న తర్వాత గుర్తింపును నిలిపివేసి ఉంటే, పునరుద్ధరణ దాన్ని మళ్లీ ప్రారంభిస్తుంది. పునరుద్ధరణ తర్వాత సమన్వయం విధానంలో భాగం, ఆలస్య ఆలోచనలో కాదు.