Pritunl: ਨਿਯੰਤਰਣ ਸਥਿਤੀ ਬਨਾਮ ਤਿਆਰ ਕੀਤੀ ਪ੍ਰੋਫਾਈਲ

ਇੱਕ ਆਰਕਾਈਵ ਕੰਮ ਕਰਦੀ 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 /

ਫਿਰ ਪ੍ਰਕਿਰਿਆ ਦੀ ਥਾਂ ਵਸਤੂਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: ਲੌਗ ਇਨ ਕਰੋ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸੰਗਠਨ ਅਤੇ ਵਰਤੋਂਕਾਰ ਮੌਜੂਦ ਹਨ, ਅਤੇ ਤੁਹਾਡੇ ਜਾਣੇ ਕਿਸੇ ਸਰਵਰ ਪਰਿਭਾਸ਼ਾ ਦੇ ਵਿਰੁੱਧ ਇੱਕ ਟੈਸਟ ਕਲਾਇੰਟ ਸ਼ੁਰੂ ਕਰੋ। ਬਹਾਲ ਕੀਤੇ ਹੋਸਟ ਨੂੰ ਉਤਪਾਦਨ ਐਂਡਪੌਇੰਟ ਦਾ ਪ੍ਰਚਾਰ ਕਰਨ ਜਾਂ ਅਸਲ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਰੋਕੋ ਜਦ ਤੱਕ ਪਤੇ ਅਤੇ ਪਛਾਣ ਜਾਣਬੁੱਝ ਕੇ ਨਹੀਂ ਹੁੰਦੇ। ਇੱਥੇ ਤੁਸੀਂ ਇਹ ਵੀ ਖੋਜਦੇ ਹੋ ਕਿ ਆਰਕਾਈਵ ਨੂੰ ਅਜਿਹੀਆਂ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਚਾਹੀਦੀਆਂ ਹਨ ਜੋ ਸਿਰਫ਼ ਫੇਲ੍ਹ ਹੋਈ ਮਸ਼ੀਨ ਉੱਤੇ ਸਨ, ਇਸ ਲਈ ਬਹਾਲੀ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਆਜ਼ਾਦ ਜਗ੍ਹਾ ਉੱਤੇ ਰੱਖੋ। ਜੋ ਬਹਾਲੀ ਤੁਸੀਂ ਹੁਣੇ ਗੁਆਏ ਹੋਸਟ ਉੱਤੇ ਨਿਰਭਰ ਹੈ ਉਹ ਬਹਾਲੀ ਯੋਜਨਾ ਨਹੀਂ ਹੈ।

ਅੰਤ ਵਿੱਚ, ਯਾਦ ਰੱਖੋ ਕਿ ਪੁਰਾਣਾ ਸਨੈਪਸ਼ਾਟ ਪੁਰਾਣੇ ਫ਼ੈਸਲੇ ਬਹਾਲ ਕਰਦਾ ਹੈ। ਜੇ ਕਿਸੇ ਪ੍ਰਸ਼ਾਸਕ ਨੇ ਡੰਪ ਲੈਣ ਤੋਂ ਬਾਅਦ ਪਛਾਣ ਅਸਮਰੱਥ ਕੀਤੀ, ਤਾਂ ਬਹਾਲੀ ਉਸਨੂੰ ਮੁੜ ਸਮਰੱਥ ਕਰ ਦਿੰਦੀ ਹੈ। ਬਹਾਲੀ ਤੋਂ ਬਾਅਦ ਦਾ ਮੇਲ ਪ੍ਰਕਿਰਿਆ ਦਾ ਹਿੱਸਾ ਹੈ, ਦੇਰ ਦੀ ਸੋਚ ਦਾ ਨਹੀਂ।