VPN ਸਰਵਰ ਦੀ ਡਿਸਕ ਵਾਧਾ ਕਿੱਥੋਂ ਆਉਂਦੀ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਕਿਵੇਂ ਸੀਮਿਤ ਕਰੀਏ

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

ਵਧਿਆ ਭੰਡਾਰ ਅਤੇ ਉਹ ਦਰ ਲੱਭੋ ਜਿਸ ਨਾਲ ਇਹ ਵਧਿਆ

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

df -h /var
df -i /var

ਫਿਰ ਵਾਧੇ ਨੂੰ ਮਾਲਕ ਨਾਲ ਜੋੜੋ। journal ਦੀ ਆਪਣੀ ਵਰਤੋਂ ਸੰਖਿਆ ਸਿਰਫ਼ journal ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਹ ਕਦੇ ਉਸ ਡੈਮਨ ਨੂੰ ਨਹੀਂ ਵੇਖੇਗੀ ਜੋ ਆਪਣੀ ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਦੇ ਕਿਸੇ ਰਾਹ ਉੱਤੇ ਲਿਖਦਾ ਹੈ।

journalctl --disk-usage

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

ਰੋਟੇਸ਼ਨ ਖੁੱਲ੍ਹੀ ਫਾਈਲ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ

ਲੌਗ ਫਾਈਲ inode ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਨਾਂ ਹੈ, ਅਤੇ ਥਾਂ ਸਿਰਫ਼ ਤਦ ਵਾਪਸ ਆਉਂਦੀ ਹੈ ਜਦੋਂ ਆਖਰੀ ਖੁੱਲ੍ਹਾ ਹੈਂਡਲ ਬੰਦ ਹੁੰਦਾ ਹੈ। ਫਾਈਲ ਦਾ ਨਾਂ ਬਦਲੋ, ਲੇਖਕ ਉਹੀ inode ਭਰਦਾ ਰਹਿੰਦਾ ਹੈ; ਹਟਾ ਦਿਓ, ਲੇਖਕ ਬਿਲਕੁਲ ਨਾਂ ਰਹਿਤ inode ਭਰਦਾ ਰਹਿੰਦਾ ਹੈ। ਇਸੇ ਹਾਲਤ ਕਾਰਨ 'ਮੈਂ ਫਾਈਲ ਹਟਾ ਦਿੱਤੀ ਪਰ ਡਿਸਕ ਭਰੀ ਰਹੀ' ਵਾਕ ਟੁੱਟੇ ਫਾਈਲਸਿਸਟਮ ਦੀ ਨਹੀਂ, ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰਾਂ ਦੀ ਗੱਲ ਕਰਦਾ ਹੈ। ਲੇਖਕ ਨੂੰ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨਾ, ਜਾਂ ਫਾਈਲ ਮੁੜ ਖੋਲ੍ਹਣ ਵਾਲੀ ਰੋਟੇਸ਼ਨ ਵਿਧੀ ਚੁਣਨਾ, ਹੀ ਬਲਾਕ ਸੱਚਮੁੱਚ ਵਾਪਸ ਦਿੰਦਾ ਹੈ।

lsof +L1 | head

ਨੀਤੀ ਉਸ ਹਿੱਸੇ ਦੀ ਹੈ ਜੋ ਫਾਈਲ ਲਿਖਦਾ ਹੈ। journal ਆਪਣੀ ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਤੋਂ ਆਪਣੀਆਂ ਸਟੋਰੇਜ ਸੀਮਾਵਾਂ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਜਦਕਿ ਫਾਈਲ-ਆਧਾਰਿਤ ਸੇਵਾ ਆਮ ਤੌਰ 'ਤੇ logrotate ਉੱਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਜਾਂ ਤਾਂ ਬਣਾਉਣ ਦੇ ਨਿਯਮ ਅਤੇ ਮੁੜ ਖੋਲ੍ਹਣ ਦੇ ਸੰਕੇਤ ਨਾਲ, ਜਾਂ ਜਦੋਂ ਲੇਖਕ ਮੁੜ ਨਹੀਂ ਖੋਲ੍ਹ ਸਕਦਾ ਤਾਂ ਉੱਥੇ ਹੀ ਕੱਟਣ ਦੀ ਵਿਧੀ ਨਾਲ। ਪਹਿਲਾਂ ਕੁਝ ਵੀ ਬਦਲੇ ਬਿਨਾਂ ਫੈਸਲੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ:

logrotate -d /etc/logrotate.conf

ਸੀਮਾ ਕਿੱਥੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਕਿੰਨੀ ਵੱਡੀ

ਸੀਮਾ ਉੱਥੇ ਰੱਖੋ ਜਿੱਥੇ ਲੇਖਕ ਕਨਫਿਗਰ ਹੈ, ਮਾਊਂਟ ਪੁਆਇੰਟ ਉੱਤੇ ਨਹੀਂ। ਪੂਰੇ ਵਾਲੀਅਮ ਉੱਤੇ ਕੋਟਾ ਹੋਸਟ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ ਪਰ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਕਿਹੜੀ ਸੇਵਾ ਪਹਿਲਾਂ ਫੇਲ੍ਹ ਹੋਵੇਗੀ, ਅਤੇ ਗਲੋਬਲ ਸਫ਼ਾਈ ਸਕ੍ਰਿਪਟ ਅਗਲੀ ਘਟਨਾ ਲਈ ਲੋੜੀਂਦੇ ਸਬੂਤ ਹਟਾਉਣ ਵੱਲ ਝੁਕਦੀ ਹੈ। journal ਸੀਮਾ, ਵੱਧ ਤੋਂ ਵੱਧ ਆਕਾਰ ਵਾਲੀ ਰੋਟੇਸ਼ਨ ਗਿਣਤੀ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ ਦੀ ਸੰਭਾਲ ਹਰ ਇੱਕ ਇੱਕ ਉਤਪਾਦਕ ਨੂੰ ਬੰਨ੍ਹਦੀ ਹੈ। ਮਿਲ ਕੇ ਉਹ ਕੁੱਲ ਬੰਨ੍ਹਦੀਆਂ ਹਨ; ਇਕੱਲੇ ਵਿੱਚ ਹਰ ਇੱਕ ਅੰਦਾਜ਼ਾ ਹੈ।

ਉਹ ਸੀਮਾ ਉਸ ਸੰਭਾਲ ਮਿਆਦ ਤੋਂ ਤੈਅ ਕਰੋ ਜਿਸ ਦਾ ਤੁਸੀਂ ਬਚਾਅ ਕਰ ਸਕਦੇ ਹੋ, ਉਪਲਬਧ ਖਾਲੀ ਥਾਂ ਤੋਂ ਨਹੀਂ। ਜੇ ਸਮੀਖਿਆ ਨੂੰ ਇੱਕ ਹਫ਼ਤੇ ਦੇ ਕਨੈਕਸ਼ਨ ਯਤਨ ਚਾਹੀਦੇ ਹਨ, ਤਾਂ journal ਨੂੰ ਸਭ ਤੋਂ ਰੁੱਝੀ ਉਮੀਦ ਦਰ ਉੱਤੇ ਇੱਕ ਹਫ਼ਤਾ ਰੱਖਣਾ ਪਵੇਗਾ, ਅਤੇ ਉਹ ਦਰ ਪਹਿਲਾਂ ਮਾਪੀ ਸੰਖਿਆ ਹੈ।

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

ਰੀਸਟਾਰਟ ਤੋਂ ਬਾਅਦ ਸੀਮਾ ਜਾਂਚੋ

ਅਗਲੇ ਰੀਬੂਟ ਤੱਕ ਚੱਲਣ ਵਾਲੀ ਸੰਭਾਲ ਤਬਦੀਲੀ ਤਬਦੀਲੀ ਨਹੀਂ ਹੈ। ਲੇਖਕ ਨੂੰ ਮੁੜ ਸ਼ੁਰੂ ਕਰੋ, ਨਵੀਂ ਸੀਮਾ ਲਾਗੂ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਜਾਂਚੋ ਕਿ ਉਸ ਤੋਂ ਬਾਅਦ ਵੀ ਰੋਟੇਸ਼ਨ ਚੱਲਦਾ ਹੈ। journal ਲਈ, ਇੱਕ ਰੀਸਟਾਰਟ ਅਤੇ ਇੱਕ ਵਰਤੋਂ ਰੀਡਿੰਗ ਦੋਵੇਂ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ:

systemctl restart systemd-journald
journalctl --disk-usage

ਫਾਈਲ-ਆਧਾਰਿਤ ਸੇਵਾ ਲਈ, ਰੋਟੇਸ਼ਨ ਦਾ ਕੰਮ ਇੱਕ ਵਾਰ ਹੱਥ ਨਾਲ ਚਲਾਓ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਫਾਈਲ ਬਦਲੀ ਗਈ ਅਤੇ ਡਿਸਕ੍ਰਿਪਟਰ ਮੁੜ ਖੁੱਲ੍ਹਿਆ। ਪੁਰਾਣਾ ਹੈਂਡਲ ਰੱਖਣ ਵਾਲਾ ਲੇਖਕ ਉੱਪਰੀ ਜਾਂਚ ਪਾਸ ਕਰ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅਗਲੀ ਵਾਰ ਵਾਲੀਅਮ ਭਰਨ 'ਤੇ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। ਟੈਸਟ ਦੌਰਾਨ ਖਾਲੀ ਥਾਂ ਵੇਖੋ, ਕਿਉਂਕਿ ਫਾਈਲ ਛੋਟੀ ਹੋਈ ਪਰ ਥਾਂ ਵਾਪਸ ਨਹੀਂ ਆਈ ਦਾ ਅਰਥ ਹੈ ਪੁਰਾਣਾ inode ਅਜੇ ਵੀ ਫੜਿਆ ਹੋਇਆ ਹੈ।

ਅਗਲੀ ਰੀਡਿੰਗ ਦੀ ਇਸ ਨਾਲ ਤੁਲਨਾ ਕਰੋ

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

ਬੈਕਅਪ ਉਸੇ ਵਾਲੀਅਮ ਤੋਂ ਬਾਹਰ ਰੱਖੋ, ਜਾਂ ਮੰਨ ਲਓ ਕਿ ਇੱਕ ਭਰੀ ਡਿਸਕ ਬੈਕਅਪ ਵੀ ਲੈ ਜਾਵੇਗੀ। ਜਿਸ ਹੋਸਟ ਦੀ ਇਹ ਰੱਖਿਆ ਕਰਦੀ ਹੈ ਉਸੇ 'ਤੇ ਲਿਖੀ ਕਾਪੀ ਬਹਾਲੀ ਯੋਜਨਾ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਸ ਦੀ ਸੰਭਾਲ ਨੂੰ ਆਪਣਾ ਜਵਾਬ ਚਾਹੀਦਾ ਹੈ।

ਕੀ, ਕਿੱਥੇ, ਕਿੰਨੇ ਸਮੇਂ ਲਈ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕੌਣ ਹਟਾਉਂਦਾ ਹੈ, ਇਹ ਲਿਖੋ। ਉਹੀ ਵਾਕ ਨਤੀਜਾ ਹੈ, ਅਤੇ ਇਹ ਇਸ ਕੰਮ ਦਾ ਇੱਕੋ ਹਿੱਸਾ ਹੈ ਜੋ ਅਗਲੇ ਰੀਸਟਾਰਟ ਤੱਕ ਬਚਦਾ ਹੈ।