ਬਿਨਾਂ ਨਿਗਰਾਨੀ ਵਾਲੇ VPN ਸਰਵਰ ਅਪਡੇਟਾਂ ਲਈ ਪਰਖਿਆ ਹੋਇਆ ਰਿਕਵਰੀ ਰਾਹ ਚਾਹੀਦਾ ਹੈ
ਇੱਕ ਅਪਡੇਟ ਉਸੇ ਸੇਵਾ ਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸ ਰਾਹੀਂ ਤੁਸੀਂ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਦੇ ਹੋ। ਸਵੈਚਾਲਨ ਤੋਂ ਪਹਿਲਾਂ ਆਊਟ-ਆਫ-ਬੈਂਡ ਕੰਸੋਲ ਦੀ ਸਿਰਫ਼ ਟਨਲ ਵਾਲੀ ਰਿਕਵਰੀ ਯੋਜਨਾ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।
ਬਿਨਾਂ ਨਿਗਰਾਨੀ ਵਾਲੇ ਅਪਡੇਟ ਉਸ ਸਰਵਰ ਲਈ ਵਾਜਬ ਨੀਤੀ ਹਨ ਜਿਸ ਤੱਕ ਤੁਸੀਂ ਉਸਦੇ ਆਪਣੇ VPN ਰਾਹੀਂ ਪਹੁੰਚਦੇ ਹੋ, ਅਤੇ ਨਾਲ ਹੀ ਇਹ ਤੁਹਾਡੇ ਆਪਣੇ ਬਣਾਏ ਇੱਕੋ ਇੱਕ ਫੇਲ੍ਹ ਹੋਣ ਦਾ ਬਿੰਦੂ ਹਨ। ਪੈਕੇਜ ਕਾਰਵਾਈ ਸੇਵਾ ਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ, ਟਨਲ ਡਿੱਗਦੀ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਜੋ ਪ੍ਰਬੰਧਕੀ ਰਾਹ ਵਰਤ ਰਹੇ ਸੀ ਉਹ ਉਸਦੇ ਨਾਲ ਹੀ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ। ਰਿਕਵਰੀ ਦੇ ਦੋ ਮਾਡਲ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਵਿਚਕਾਰ ਚੋਣ ਇੱਕ ਸ਼ਰਤ ’ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ: ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਅਜਿਹਾ ਦਾਖਲਾ ਰਾਹ ਹੈ ਜੋ ਅਪਡੇਟ ਹੋ ਰਹੀ ਚੀਜ਼ ਵਿੱਚੋਂ ਨਹੀਂ ਲੰਘਦਾ।
ਦੋ ਰਿਕਵਰੀ ਮਾਡਲ, ਇੱਕ ਨਿਰਣਾਇਕ ਸ਼ਰਤ
ਪਹਿਲਾ ਮਾਡਲ ਅਪਡੇਟ ’ਤੇ ਭਰੋਸਾ ਕਰਦਾ ਹੈ ਅਤੇ ਮੰਨਦਾ ਹੈ ਕਿ ਬਾਅਦ ਵਿੱਚ ਤੁਸੀਂ ਦੁਬਾਰਾ ਜੁੜ ਸਕੋਗੇ। ਇਹ ਤਦ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ VPN ਹੋਸਟ ਤੱਕ ਪਹੁੰਚਣ ਦੇ ਕਈ ਰਾਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੋਵੇ ਅਤੇ ਜਦੋਂ ਟਨਲ ਦੀ ਅਸਫਲਤਾ ਇਸਨੂੰ ਜਾਂਚਣ ਦੀ ਤੁਹਾਡੀ ਸਮਰੱਥਾ ਨੂੰ ਨਾ ਹਟਾਏ। ਦੂਜਾ ਮਾਡਲ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਸੁਤੰਤਰ ਰਾਹ, ਆਮ ਤੌਰ ’ਤੇ ਹੋਸਟਿੰਗ ਪ੍ਰਦਾਤਾ ਦਾ ਕੰਸੋਲ, ਰੱਖਦਾ ਹੈ, ਅਤੇ ਟਨਲ ਨੂੰ ਉਹ ਚੀਜ਼ ਮੰਨਦਾ ਹੈ ਜਿਸਨੂੰ ਸੰਭਾਲ ਸਭ ਤੋਂ ਵੱਧ ਤੋੜ ਸਕਦੀ ਹੈ। ਦੋਵੇਂ ਮਾਡਲ ਸਮਰਥਨਯੋਗ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਕੰਮ ਚਾਹੀਦਾ ਹੈ।
ਨਿਰਣਾਇਕ ਸ਼ਰਤ ਦੱਸਣਾ ਸੌਖਾ ਹੈ ਅਤੇ ਛੱਡਣਾ ਵੀ ਸੌਖਾ ਹੈ। ਜੇ ਮਸ਼ੀਨ ਤੱਕ ਦਾ ਹਰ ਪ੍ਰਬੰਧਕੀ ਰਾਹ ਅਪਡੇਟ ਹੋ ਰਹੀ ਸੇਵਾ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ ਰਿਕਵਰੀ ਮਾਡਲ ਨਹੀਂ, ਸਿਰਫ਼ ਇੱਕ ਆਸ ਹੈ। ਤਬਦੀਲੀ ਸਮੀਖਿਆ ਵਿੱਚ ਇਹ ਉੱਚੀ ਆਵਾਜ਼ ਵਿੱਚ ਕਹੋ।
ਉਸ ਸ਼ਰਤ ਨੂੰ ਪਰਖਣ ਵਿੱਚ ਦਸ ਮਿੰਟ ਲੱਗਦੇ ਹਨ ਅਤੇ ਇਹ ਪਹਿਲੇ ਬਿਨਾਂ ਨਿਗਰਾਨੀ ਵਾਲੇ ਅਪਡੇਟ ਤੋਂ ਪਹਿਲਾਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਘਟਨਾ ਵੇਲੇ ਨਹੀਂ। ਜਦੋਂ ਸਭ ਕੁਝ ਚੱਲ ਰਿਹਾ ਹੋਵੇ ਤਦ ਕੰਸੋਲ ਖੋਲ੍ਹੋ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪ੍ਰਮਾਣ ਪੱਤਰ ਮੌਜੂਦਾ ਹਨ, ਅਤੇ ਦੁਬਾਰਾ ਬੰਦ ਕਰੋ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕੰਸੋਲ ਉਸੇ ਹੋਸਟ ’ਤੇ ਖੁੱਲ੍ਹਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ। ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਰਾਤ 3 ਵਜੇ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਜੋ ਲੌਗਇਨ ਵਰਤੋਗੇ ਉਹ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ।
ਉਹ ਆਖਰੀ ਹਿੱਸਾ ਸੁਣਨ ਨਾਲੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜਿਸ ਕੰਸੋਲ ਖਾਤੇ ਦਾ ਪਾਸਵਰਡ ਛੇ ਮਹੀਨੇ ਪਹਿਲਾਂ ਬਦਲਿਆ ਗਿਆ ਅਤੇ ਕਦੇ ਜਾਂਚਿਆ ਨਹੀਂ ਗਿਆ, ਉਹ ਰਿਕਵਰੀ ਰਾਹ ਨਹੀਂ ਹੈ; ਉਹ ਅਜਿਹੇ ਰਾਹ ਦਾ ਵਰਣਨ ਕਰਨ ਵਾਲਾ ਦਸਤਾਵੇਜ਼ ਹੈ।
ਬੈਕਅਪ ਕੀ ਬਹਾਲ ਨਹੀਂ ਕਰਦਾ
ਕਨਫਿਗਰੇਸ਼ਨ ਆਰਕਾਈਵ ਫਾਈਲਾਂ ਦਾ ਰਿਕਾਰਡ ਹੈ, ਅਤੇ ਅਪਡੇਟ ਫਾਈਲਾਂ ਤੋਂ ਵੱਧ ਬਦਲਦਾ ਹੈ। ਪੈਕੇਜ ਸਥਿਤੀ, ਕਰਨਲ ਮੌਡਿਊਲ, ਸਮਰੱਥ ਯੂਨਿਟ ਲਿੰਕ ਅਤੇ ਵੱਖਰੇ ਸੰਦ ਰਾਹੀਂ ਲਾਗੂ ਕੀਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਸਭ ਕਨਫਿਗਰੇਸ਼ਨ ਡਾਇਰੈਕਟਰੀ ਤੋਂ ਬਾਹਰ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਵਾਲੀ ਬਹਾਲੀ ਅਜਿਹੀ ਮਸ਼ੀਨ ਬਣਾਉਂਦੀ ਹੈ ਜੋ ਕਨਫਿਗਰ ਦਿਖਦੀ ਹੈ ਪਰ ਅੱਗੇ ਨਹੀਂ ਭੇਜਦੀ।
| What changed | Restored by a configuration backup | Needs its own action |
|---|---|---|
| Service unit or startup ordering | Partly, if the unit file was included | Package state and enabled links |
| Kernel module or interface support | No | Kernel or module rollback, or a boot-time decision |
| Peer or device authorization | Only if the backup predates the revocation | A deliberate decision about which peers return |
| Firewall rules applied outside the config | Only if they were captured | Replaying and verifying each rule |
ਅਧਿਕਾਰਤਾ ਆਪਣੀ ਵੱਖਰੀ ਲਾਈਨ ਦਾ ਹੱਕਦਾਰ ਹੈ। ਕਿਸੇ ਸਮਝੌਤਾ-ਗ੍ਰਸਤ ਜੰਤਰ ਨੂੰ ਹਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿਆ ਬੈਕਅਪ ਉਸ ਜੰਤਰ ਦੀ ਪਹੁੰਚ ਖੁਸ਼ੀ ਨਾਲ ਬਹਾਲ ਕਰ ਦੇਵੇਗਾ। ਰੁਕਾਵਟ ਵੇਲੇ ਉਸ ਵੱਲ ਵਾਪਸ ਜਾਣਾ ਹੀ ਇੱਕ ਘਟਨਾ ਨੂੰ ਦੋ ਬਣਾਉਣ ਦਾ ਤਰੀਕਾ ਹੈ, ਅਤੇ ਬਹਾਲੀ ਦਾ ਫੈਸਲਾ ਸਾਥੀਆਂ ਬਾਰੇ ਵੀ ਓਨਾ ਹੀ ਸਪਸ਼ਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿੰਨਾ ਫਾਈਲਾਂ ਬਾਰੇ।
ਰੋਲਬੈਕ ਦਾ ਢੰਗ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਪੈਕੇਜ-ਪ੍ਰਬੰਧਿਤ ਫਾਈਲ ਉੱਤੇ ਪੁਰਾਣੀ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਕਾਪੀ ਕਰਨਾ ਪੈਕੇਜ ਤਬਦੀਲੀ ਦਾ ਸਮਰਥਿਤ ਉਲਟਾਅ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਹ ਪੈਕੇਜ ਡੇਟਾਬੇਸ ਨੂੰ ਅਜਿਹੀ ਸਥਿਤੀ ਦੱਸਣ ਦਿੰਦਾ ਹੈ ਜੋ ਫਾਈਲਸਿਸਟਮ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ। ਪੈਕੇਜ ਮੈਨੇਜਰ ਦਾ ਆਪਣਾ ਡਾਊਨਗ੍ਰੇਡ ਰਾਹ ਜਾਂ ਪ੍ਰਦਾਤਾ ਵੱਲੋਂ ਦਿੱਤਾ ਸਨੈਪਸ਼ਾਟ ਵਰਤੋ। ਪੈਕੇਜ ਡੇਟਾਬੇਸ ਜੋ ਡਾਊਨਗ੍ਰੇਡ ਦਰਜ ਕਰਦਾ ਹੈ, ਉਹੀ ਤੁਸੀਂ ਦੁਹਰਾ ਸਕਦੇ ਹੋ।
ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਬੈਕਅਪ ਦੇ ਖਿਲਾਫ਼ ਨਹੀਂ ਹੈ। ਇਹ ਇਸ ਗੱਲ ਦੇ ਪੱਖ ਵਿੱਚ ਹੈ ਕਿ ਹਰ ਕਲਾਕ੍ਰਿਤੀ ਕਿਹੜੀ ਪਰਤ ਢਕਦੀ ਹੈ, ਕਿਉਂਕਿ ਅੰਸ਼ਕ ਬਹਾਲੀ ਦੀ ਅਸਫਲਤਾ ਦਾ ਢੰਗ ਮੂਲ ਰੁਕਾਵਟ ਨਾਲੋਂ ਵੱਧ ਉਲਝਾਉਣ ਵਾਲਾ ਹੈ। ਰਨਬੁੱਕ ਵਿੱਚ ਹਰ ਬੈਕਅਪ ਦੇ ਕੋਲ ਪਰਤ ਲਿਖੋ।
ਚੈਕਪੌਇੰਟ, ਅਪਡੇਟ, ਫਿਰ ਬਾਹਰੋਂ ਤਸਦੀਕ
ਤਬਦੀਲੀ ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਸਥਿਤੀ ਇਸ ਤਰ੍ਹਾਂ ਦਰਜ ਕਰੋ ਕਿ ਬਾਅਦ ਵਿੱਚ ਤੁਲਨਾ ਕੀਤੀ ਜਾ ਸਕੇ: ਸਥਾਪਿਤ ਸੰਸਕਰਣ, ਸੰਬੰਧਿਤ ਸੇਵਾ ਯੂਨਿਟ, ਸੁਣਦੇ ਸਾਕੇਟ ਅਤੇ ਮੌਜੂਦਾ ਸਾਥੀ ਸੂਚੀ। ਲੀਨਕਸ ਹੋਸਟ ’ਤੇ ਚਾਰ ਕਮਾਂਡ ਇਸਦਾ ਬਹੁਤਾ ਹਿੱਸਾ ਢਕ ਦਿੰਦੀਆਂ ਹਨ।
systemctl list-units --type=service | grep -E 'openvpn|wg-quick'
ss -lunp | grep -E ':51820|:1194'
journalctl -u wg-quick@wg0 --since '-10 min'ਪਹਿਲੀ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਯੂਨਿਟ ਹਨ ਅਤੇ ਉਹ ਚੱਲ ਰਹੀਆਂ ਹਨ ਜਾਂ ਨਹੀਂ, ਦੂਜੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ ਕਿ ਸਰੋਤਾ ਅਸਲ ਵਿੱਚ ਬੱਝਾ ਹੋਇਆ ਹੈ, ਅਤੇ ਤੀਜੀ ਤੁਹਾਨੂੰ ਪਿਛਲੇ ਕੁਝ ਮਿੰਟਾਂ ਦਾ ਸੇਵਾ ਦਾ ਆਪਣਾ ਬਿਆਨ ਦਿੰਦੀ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਕੋਈ ਕਲਾਇੰਟ ਜੁੜ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਅਗਲਾ ਕਦਮ ਹੋਸਟ ਤੋਂ ਬਾਹਰ ਹੁੰਦਾ ਹੈ। ਉਹ ਪੜ੍ਹਤਾਂ ਨੂੰ ਆਪਣਾ ਤੁਲਨਾ ਆਧਾਰ ਰੱਖੋ।
ਅਜਿਹੇ ਨੈੱਟਵਰਕ ਤੋਂ ਤਸਦੀਕ ਕਰੋ ਜੋ ਟਨਲ ਨਹੀਂ ਵਰਤਦਾ: ਇੱਕ ਅਧਿਕ੍ਰਿਤ ਕਲਾਇੰਟ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰੋ, ਇੱਕ ਨਾਮ ਹੱਲ ਕਰੋ, ਅਤੇ ਇੱਕ ਲੋੜੀਂਦੀ ਐਪਲੀਕੇਸ਼ਨ ਤੱਕ ਪਹੁੰਚੋ। ਇੰਟਰਫੇਸ ਉੱਪਰ ਹੈ ਇਹ ਕਹਿਣ ਵਾਲੀ ਸਥਾਨਕ ਸਥਿਤੀ ਲਾਈਨ ਇੰਟਰਫੇਸ ਬਾਰੇ ਬਿਆਨ ਹੈ, ਰੂਟਿੰਗ, ਕੁੰਜੀਆਂ ਜਾਂ ਸਾਥੀ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਨ ਵਾਲੀ ਨੀਤੀ ਬਾਰੇ ਨਹੀਂ।
ਫਿਰ ਦੁਬਾਰਾ ਜੁੜਨ ਦੇ ਰਾਹ ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਪਰਖੋ। ਸੇਵਾ ਨੂੰ ਇੱਕ ਵਾਰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਟਨਲ ਬਿਨਾਂ ਹੱਥੀਂ ਦਖਲ ਦੇ ਵਾਪਸ ਆਉਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਜੋ ਸੇਵਾ ਸਿਰਫ਼ ਬੂਟ ’ਤੇ ਹੀ ਠੀਕ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਉਹ ਤੁਹਾਨੂੰ ਸਭ ਤੋਂ ਮਾੜੇ ਪਲ ਵਿੱਚ ਹੈਰਾਨ ਕਰੇਗੀ।
ਜਦੋਂ ਇਹ ਫੇਲ੍ਹ ਹੋਵੇ, ਪਰਖਿਆ ਹੋਇਆ ਰਾਹ ਵਰਤੋ
ਰਿਕਵਰੀ ਦਾ ਕ੍ਰਮ ਸ਼ਾਨਦਾਰ ਨਹੀਂ ਹੈ ਅਤੇ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ: ਸੁਤੰਤਰ ਰਾਹ ਰਾਹੀਂ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚੋ, ਸੇਵਾ ਦੇ ਆਪਣੇ ਲੌਗ ਪੜ੍ਹੋ, ਅਤੇ ਅਸਫਲਤਾ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਖਾਸ ਚੈਕਪੌਇੰਟ ਬਹਾਲ ਕਰੋ। ਹਰ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਇੱਕ ਚੀਜ਼ ਬਦਲੋ ਤਾਂ ਜੋ ਅਗਲੀ ਲੌਗ ਪੜ੍ਹਤ ਦਾ ਕੋਈ ਅਰਥ ਹੋਵੇ।
ਕਨੈਕਟੀਵਿਟੀ ਵਾਪਸ ਲਿਆਉਣ ਲਈ ਕਈ ਬਿਨਾਂ ਦਰਜ ਕੀਤੇ ਬਦਲਾਅ ਕਰਨ ਦੀ ਲਾਲਸਾ ਦਾ ਵਿਰੋਧ ਕਰੋ। ਇੱਕੋ ਸਮੇਂ ਪੰਜ ਸੋਧਾਂ ਨਾਲ ਠੀਕ ਕੀਤੀ ਮਸ਼ੀਨ ਦੀ ਬਾਅਦ ਵਿੱਚ ਵਿਆਖਿਆ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ, ਅਤੇ ਅਗਲਾ ਅਪਡੇਟ ਉਹੀ ਬਦਲਾਅ ਦੁਬਾਰਾ ਲਿਆਵੇਗਾ ਜੋ ਅਸਲ ਵਿੱਚ ਭਾਰ ਚੁੱਕ ਰਿਹਾ ਸੀ।
ਫਿਰ ਸਬੂਤਾਂ ਨਾਲ ਸਥਾਈ ਨੀਤੀ ਤੈਅ ਕਰੋ। ਜੇ ਅਪਡੇਟ ਨੇ ਅਜਿਹੀ ਨਿਰਭਰਤਾ ਖੋਲ੍ਹੀ ਜੋ ਕਿਸੇ ਨੇ ਦਰਜ ਨਹੀਂ ਕੀਤੀ, ਤਾਂ ਸੁਧਾਰ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਅਤੇ ਇੱਕ ਜਾਂਚ ਹੈ, ਅਪਡੇਟ ਬੰਦ ਕਰਨਾ ਨਹੀਂ। ਜੇ ਇਸਨੇ ਅਜਿਹੀ ਸੇਵਾ ਖੋਲ੍ਹੀ ਜੋ ਸਾਫ਼-ਸੁਥਰੇ ਢੰਗ ਨਾਲ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋ ਸਕਦੀ, ਤਾਂ ਸੁਧਾਰ ਯੂਨਿਟ ਵਿੱਚ ਹੈ, ਸਮਾਂ-ਸਾਰਣੀ ਵਿੱਚ ਨਹੀਂ।
ਸ਼ਰਤ ਦਾ ਨਾਮ ਆਉਣ ਸਾਰ ਤੁਲਨਾ ਸਾਫ਼ ਤੌਰ ’ਤੇ ਹੱਲ ਹੋ ਜਾਂਦੀ ਹੈ। ਸੁਤੰਤਰ ਰਾਹ ਬਿਨਾਂ ਨਿਗਰਾਨੀ ਵਾਲੇ ਅਪਡੇਟਾਂ ਨੂੰ ਸੰਭਾਲਣਯੋਗ ਜੋਖਮ ਬਣਾਉਂਦਾ ਹੈ। ਇਸਦੀ ਗੈਰਹਾਜ਼ਰੀ ਉਸੇ ਨੀਤੀ ਨੂੰ ਅਣਜਾਣ ਰਿਕਵਰੀ ਸਮੇਂ ਵਾਲੀ ਯੋਜਨਾਬੱਧ ਰੁਕਾਵਟ ਬਣਾ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਸਵੈਚਾਲਨ ਉਸ ਗਣਿਤ ਨੂੰ ਨਹੀਂ ਬਦਲਦਾ।