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 /

ನಂತರ ಪ್ರಕ್ರಿಯೆಯನ್ನಲ್ಲ, ವಸ್ತುಗಳನ್ನು ಪರಿಶೀಲಿಸಿ: ಲಾಗಿನ್ ಆಗಿ, ಸಂಸ್ಥೆಗಳು ಮತ್ತು ಬಳಕೆದಾರರು ಇವೆ ಎಂದು ದೃಢೀಕರಿಸಿ, ಮತ್ತು ನಿಮಗೆ ತಿಳಿದಿರುವ ಸರ್ವರ್ ವ್ಯಾಖ್ಯಾನಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ ಒಂದು ಪರೀಕ್ಷಾ ಕ್ಲೈಂಟ್ ಪ್ರಾರಂಭಿಸಿ. ವಿಳಾಸಗಳು ಮತ್ತು ಗುರುತುಗಳು ಉದ್ದೇಶಪೂರ್ವಕವಾಗುವವರೆಗೆ ಮರುಸ್ಥಾಪಿಸಿದ ಹೋಸ್ಟ್ ಉತ್ಪಾದನಾ ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು ಜಾಹೀರಾತು ಮಾಡುವುದನ್ನು ಅಥವಾ ನಿಜವಾದ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನು ತಡೆಯಿರಿ. ಇಲ್ಲಿಯೇ ಆರ್ಕೈವ್ಗೆ ವಿಫಲವಾದ ಯಂತ್ರದಲ್ಲಿ ಮಾತ್ರ ಇದ್ದ ರುಜುವಾತುಗಳು ಬೇಕು ಎಂದು ನೀವು ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ, ಆದ್ದರಿಂದ ಮರುಸ್ಥಾಪನೆ ರುಜುವಾತುಗಳನ್ನು ಸ್ವತಂತ್ರ ಸ್ಥಳದಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ. ನೀವು ಈಗಷ್ಟೇ ಕಳೆದುಕೊಂಡ ಹೋಸ್ಟ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುವ ಮರುಸ್ಥಾಪನೆ ಮರುಸ್ಥಾಪನೆ ಯೋಜನೆ ಅಲ್ಲ.

ಕೊನೆಯದಾಗಿ, ಹಳೆಯ ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಹಳೆಯ ನಿರ್ಧಾರಗಳನ್ನು ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ ಎಂದು ನೆನಪಿಡಿ. ನಿರ್ವಾಹಕರು ಡಂಪ್ ತೆಗೆದ ನಂತರ ಗುರುತನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿದ್ದರೆ, ಮರುಸ್ಥಾಪನೆ ಅದನ್ನು ಮತ್ತೆ ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. ಮರುಸ್ಥಾಪನೆಯ ನಂತರದ ಸಮನ್ವಯವು ಕಾರ್ಯವಿಧಾನದ ಭಾಗ, ತಡವಾದ ಯೋಚನೆಯದಲ್ಲ.