GitLab ਵੱਡੀਆਂ NextCloud ਸਟੋਰੇਜਾਂ ਦਾ ਬੈਕਅੱਪ ਲੈਣ ਵਿੱਚ ਤੁਹਾਡੀ ਕਿਵੇਂ ਮਦਦ ਕਰਦਾ ਹੈ

ਹੇ ਹਬਰ!

ਅੱਜ ਮੈਂ ਵੱਖ-ਵੱਖ ਸੰਰਚਨਾਵਾਂ ਵਿੱਚ ਨੈਕਸਟ ਕਲਾਉਡ ਸਟੋਰੇਜ ਤੋਂ ਵੱਡੇ ਡੇਟਾ ਦੇ ਬੈਕਅੱਪ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਨ ਵਿੱਚ ਸਾਡੇ ਅਨੁਭਵ ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ। ਮੈਂ Molniya AK ਵਿਖੇ ਇੱਕ ਸਰਵਿਸ ਸਟੇਸ਼ਨ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹਾਂ, ਜਿੱਥੇ ਅਸੀਂ IT ਸਿਸਟਮਾਂ ਦਾ ਸੰਰਚਨਾ ਪ੍ਰਬੰਧਨ ਕਰਦੇ ਹਾਂ; Nextcloud ਨੂੰ ਡਾਟਾ ਸਟੋਰੇਜ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਸਮੇਤ, ਇੱਕ ਵੰਡੇ ਢਾਂਚੇ ਦੇ ਨਾਲ, ਰਿਡੰਡੈਂਸੀ ਦੇ ਨਾਲ।

ਇੰਸਟਾਲੇਸ਼ਨ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਤੋਂ ਪੈਦਾ ਹੋਣ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਇਹ ਹਨ ਕਿ ਬਹੁਤ ਸਾਰਾ ਡੇਟਾ ਹੈ. ਨੈਕਸਟਕਲਾਉਡ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤਾ ਗਿਆ ਸੰਸਕਰਣ, ਰਿਡੰਡੈਂਸੀ, ਵਿਅਕਤੀਗਤ ਕਾਰਨ ਅਤੇ ਹੋਰ ਬਹੁਤ ਸਾਰੇ ਡੁਪਲੀਕੇਟ ਬਣਾਉਂਦੇ ਹਨ।

prehistory

ਨੈਕਸਟ ਕਲਾਉਡ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੇ ਸਮੇਂ, ਇੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬੈਕਅਪ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਦੀ ਸਮੱਸਿਆ ਪੈਦਾ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਡੇਟਾ ਕੀਮਤੀ ਹੈ.

ਅਸੀਂ ਨੈਕਸਟਕਲਾਊਡ ਤੋਂ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ 'ਤੇ ਸਾਡੇ ਸਥਾਨ 'ਤੇ ਜਾਂ ਗਾਹਕਾਂ 'ਤੇ ਬੈਕਅੱਪ ਸਟੋਰ ਕਰਨ ਲਈ ਵਿਕਲਪ ਪੇਸ਼ ਕਰਦੇ ਹਾਂ, ਜਿਸ ਲਈ ਪ੍ਰਸ਼ਾਸਨ ਲਈ ਲਚਕਦਾਰ ਸਵੈਚਾਲਿਤ ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਬਹੁਤ ਸਾਰੇ ਗਾਹਕ ਹਨ, ਉਹ ਸਾਰੇ ਵੱਖ-ਵੱਖ ਸੰਰਚਨਾਵਾਂ ਦੇ ਨਾਲ, ਅਤੇ ਸਾਰੇ ਉਹਨਾਂ ਦੀਆਂ ਆਪਣੀਆਂ ਸਾਈਟਾਂ ਤੇ ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਆਪਣੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਨਾਲ। ਇਹ ਇੱਕ ਮਿਆਰੀ ਤਕਨੀਕ ਹੈ ਜਦੋਂ ਪੂਰੀ ਸਾਈਟ ਤੁਹਾਡੀ ਹੈ, ਅਤੇ ਬੈਕਅੱਪ ਤਾਜਾਂ ਤੋਂ ਬਣਾਏ ਜਾਂਦੇ ਹਨ; ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਨਹੀਂ ਬੈਠਦਾ।

ਪਹਿਲਾਂ, ਆਓ ਇਨਪੁਟ ਡੇਟਾ ਨੂੰ ਵੇਖੀਏ। ਸਾਨੂੰ ਲੋੜ ਹੈ:

• ਇੱਕ ਨੋਡ ਜਾਂ ਕਈ ਦੇ ਰੂਪ ਵਿੱਚ ਸਕੇਲੇਬਿਲਟੀ। ਵੱਡੀਆਂ ਸਥਾਪਨਾਵਾਂ ਲਈ ਅਸੀਂ ਸਟੋਰੇਜ਼ ਵਜੋਂ ਮਿਨੀਓ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।
• ਬੈਕਅੱਪ ਕਰਨ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਪਤਾ ਲਗਾਓ।
• ਤੁਹਾਨੂੰ ਆਪਣੇ ਗਾਹਕਾਂ ਅਤੇ/ਜਾਂ ਸਾਡੇ ਨਾਲ ਬੈਕਅੱਪ ਰੱਖਣ ਦੀ ਲੋੜ ਹੈ।
• ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਜਲਦੀ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਨਜਿੱਠੋ।
• ਕਲਾਇੰਟ ਅਤੇ ਸਥਾਪਨਾਵਾਂ ਇੱਕ ਦੂਜੇ ਤੋਂ ਬਹੁਤ ਵੱਖਰੀਆਂ ਹਨ - ਇਕਸਾਰਤਾ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ।
• ਰਿਕਵਰੀ ਦੀ ਗਤੀ ਦੋ ਸਥਿਤੀਆਂ ਵਿੱਚ ਘੱਟ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ: ਪੂਰੀ ਰਿਕਵਰੀ (ਆਫਤ), ਇੱਕ ਫੋਲਡਰ ਗਲਤੀ ਨਾਲ ਮਿਟਾਇਆ ਗਿਆ।
• ਡੁਪਲੀਕੇਸ਼ਨ ਫੰਕਸ਼ਨ ਦੀ ਲੋੜ ਹੈ।

ਬੈਕਅੱਪ ਪ੍ਰਬੰਧਨ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਅਸੀਂ GitLab ਨੂੰ ਸਥਾਪਿਤ ਕੀਤਾ ਹੈ। ਨਜਿੱਠਣ ਦੁਆਰਾ ਹੋਰ ਵੇਰਵੇ।

ਬੇਸ਼ੱਕ, ਅਸੀਂ ਅਜਿਹੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਵਾਲੇ ਪਹਿਲੇ ਨਹੀਂ ਹਾਂ, ਪਰ ਇਹ ਸਾਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਸਾਡਾ ਵਿਹਾਰਕ, ਸਖ਼ਤ ਮਿਹਨਤ ਦਾ ਅਨੁਭਵ ਦਿਲਚਸਪ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਸਾਂਝਾ ਕਰਨ ਲਈ ਤਿਆਰ ਹਾਂ.

ਕਿਉਂਕਿ ਸਾਡੀ ਕੰਪਨੀ ਦੀ ਇੱਕ ਓਪਨ ਸੋਰਸ ਨੀਤੀ ਹੈ, ਅਸੀਂ ਇੱਕ ਓਪਨ ਸੋਰਸ ਹੱਲ ਲੱਭ ਰਹੇ ਸੀ। ਬਦਲੇ ਵਿੱਚ, ਅਸੀਂ ਆਪਣੇ ਵਿਕਾਸ ਨੂੰ ਸਾਂਝਾ ਕਰਦੇ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪੋਸਟ ਕਰਦੇ ਹਾਂ। ਉਦਾਹਰਨ ਲਈ, GitHub 'ਤੇ ਹੈ Nextcloud ਲਈ ਸਾਡਾ ਪਲੱਗਇਨ, ਜੋ ਅਸੀਂ ਗਾਹਕਾਂ ਨੂੰ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਾਂ, ਦੁਰਘਟਨਾ ਜਾਂ ਜਾਣਬੁੱਝ ਕੇ ਮਿਟਾਏ ਜਾਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਡੇਟਾ ਸੁਰੱਖਿਆ ਨੂੰ ਵਧਾਉਂਦੇ ਹੋਏ।

ਬੈਕਅੱਪ ਟੂਲ

ਅਸੀਂ ਬੈਕਅੱਪ ਬਣਾਉਣ ਵਾਲੇ ਟੂਲ ਦੀ ਚੋਣ ਕਰਕੇ ਹੱਲ ਦੇ ਤਰੀਕਿਆਂ ਦੀ ਖੋਜ ਸ਼ੁਰੂ ਕੀਤੀ।

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

ਡੁਪਲੀਕੇਸ਼ਨ ਦੇ ਨਾਲ ਬੈਕਅੱਪ ਟੂਲ ਓਪਨ ਸੋਰਸ ਵਿੱਚ ਉਪਲਬਧ ਹਨ (ਹਬਰੇ ਉੱਤੇ ਉੱਥੇ ਸਨ ਲੇਖ ਇਸ ਥੀਮ ਬਾਰੇ) ਅਤੇ ਸਾਡੇ ਫਾਈਨਲਿਸਟ ਸਨ ਬੋਰਗ и ਰੈਸਟਿਕ. ਦੋ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਸਾਡੀ ਤੁਲਨਾ ਹੇਠਾਂ ਦਿੱਤੀ ਗਈ ਹੈ, ਪਰ ਹੁਣ ਲਈ ਅਸੀਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗੇ ਕਿ ਅਸੀਂ ਪੂਰੀ ਸਕੀਮ ਨੂੰ ਕਿਵੇਂ ਵਿਵਸਥਿਤ ਕੀਤਾ।

ਬੈਕਅੱਪ ਦਾ ਪ੍ਰਬੰਧਨ

ਬੋਰਗ ਅਤੇ ਰੈਸਟਿਕ ਚੰਗੇ ਹਨ, ਪਰ ਕਿਸੇ ਵੀ ਉਤਪਾਦ ਵਿੱਚ ਕੇਂਦਰੀ ਨਿਯੰਤਰਣ ਵਿਧੀ ਨਹੀਂ ਹੈ। ਪ੍ਰਬੰਧਨ ਅਤੇ ਨਿਯੰਤਰਣ ਦੇ ਉਦੇਸ਼ ਲਈ, ਅਸੀਂ ਇੱਕ ਟੂਲ ਚੁਣਿਆ ਹੈ ਜੋ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਲਾਗੂ ਕੀਤਾ ਹੈ, ਜਿਸ ਤੋਂ ਬਿਨਾਂ ਅਸੀਂ ਆਟੋਮੇਸ਼ਨ ਸਮੇਤ ਆਪਣੇ ਕੰਮ ਦੀ ਕਲਪਨਾ ਨਹੀਂ ਕਰ ਸਕਦੇ - ਇਹ ਮਸ਼ਹੂਰ CI/CD - GitLab ਹੈ।

ਇਹ ਵਿਚਾਰ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਹੈ: gitlab-runner ਨੈਕਸਟ ਕਲਾਉਡ ਡੇਟਾ ਨੂੰ ਸਟੋਰ ਕਰਨ ਵਾਲੇ ਹਰੇਕ ਨੋਡ 'ਤੇ ਸਥਾਪਿਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਦੌੜਾਕ ਇੱਕ ਅਨੁਸੂਚੀ 'ਤੇ ਇੱਕ ਸਕ੍ਰਿਪਟ ਚਲਾਉਂਦਾ ਹੈ ਜੋ ਬੈਕਅੱਪ ਪ੍ਰਕਿਰਿਆ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਬੋਰਗ ਜਾਂ ਰੈਸਟਿਕ ਲਾਂਚ ਕਰਦਾ ਹੈ.

ਸਾਨੂੰ ਕੀ ਮਿਲਿਆ? ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਤੋਂ ਫੀਡਬੈਕ, ਬਦਲਾਵਾਂ 'ਤੇ ਸੁਵਿਧਾਜਨਕ ਨਿਯੰਤਰਣ, ਗਲਤੀ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਵੇਰਵੇ।

ਇੱਥੇ ਇੱਥੇ GitHub 'ਤੇ ਅਸੀਂ ਵੱਖ-ਵੱਖ ਕਾਰਜਾਂ ਲਈ ਸਕ੍ਰਿਪਟ ਦੀਆਂ ਉਦਾਹਰਨਾਂ ਪੋਸਟ ਕੀਤੀਆਂ ਹਨ, ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਨਾ ਸਿਰਫ਼ ਨੈਕਸਟ ਕਲਾਉਡ, ਸਗੋਂ ਹੋਰ ਬਹੁਤ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਦੇ ਬੈਕਅੱਪ ਨਾਲ ਜੋੜਿਆ ਹੈ। ਉੱਥੇ ਇੱਕ ਸ਼ਡਿਊਲਰ ਵੀ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਹੱਥੀਂ ਕੌਂਫਿਗਰ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ (ਅਤੇ ਅਸੀਂ ਨਹੀਂ ਚਾਹੁੰਦੇ) ਅਤੇ .gitlab-ci.yml

Gitlab API ਵਿੱਚ ਅਜੇ ਤੱਕ CI/CD ਸਮਾਂ ਸਮਾਪਤੀ ਨੂੰ ਬਦਲਣ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਛੋਟਾ ਹੈ। ਇਸ ਨੂੰ ਵਧਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਨੂੰ ਕਹਿਣਾ 1d.

GitLab, ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਨਾ ਸਿਰਫ ਇੱਕ ਵਚਨਬੱਧਤਾ ਦੇ ਅਨੁਸਾਰ, ਪਰ ਸਿਰਫ ਇੱਕ ਅਨੁਸੂਚੀ ਦੇ ਅਨੁਸਾਰ, ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜਿਸਦੀ ਸਾਨੂੰ ਲੋੜ ਹੈ.

ਹੁਣ ਰੈਪਰ ਸਕ੍ਰਿਪਟ ਬਾਰੇ.

ਅਸੀਂ ਇਸ ਸਕ੍ਰਿਪਟ ਲਈ ਹੇਠ ਲਿਖੀਆਂ ਸ਼ਰਤਾਂ ਸੈਟ ਕਰਦੇ ਹਾਂ:

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

ਪੂਰਾ ਲੌਗ GitLab ਵਿੱਚ ਇੱਕ ਆਰਟੀਫੈਕਟ ਵਜੋਂ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਗਿਆ ਹੈ; ਜੇਕਰ ਕੋਈ ਗਲਤੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਲੌਗ ਮਿਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਅਸੀਂ ਸਕ੍ਰਿਪਟ ਨੂੰ ਬਾਸ਼ ਵਿੱਚ ਲਿਖਦੇ ਹਾਂ।

ਸਾਨੂੰ ਓਪਨ ਸੋਰਸ ਦੇ ਸੰਬੰਧ ਵਿੱਚ ਕਿਸੇ ਵੀ ਸੁਝਾਅ ਅਤੇ ਟਿੱਪਣੀਆਂ 'ਤੇ ਵਿਚਾਰ ਕਰਨ ਵਿੱਚ ਖੁਸ਼ੀ ਹੋਵੇਗੀ - ਸਵਾਗਤ ਹੈ।

ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ

ਬੈਸ਼ ਐਗਜ਼ੀਕਿਊਟਰ ਵਾਲਾ ਦੌੜਾਕ ਬੈਕਅੱਪ ਨੋਡ 'ਤੇ ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਹੈ। ਸ਼ਡਿਊਲਰ ਦੇ ਅਨੁਸਾਰ, ਜੌਬ CI/CD ਨੂੰ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਟਰਨਿਪ ਵਿੱਚ ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਹੈ। ਦੌੜਾਕ ਅਜਿਹੇ ਕੰਮਾਂ ਲਈ ਇੱਕ ਯੂਨੀਵਰਸਲ ਰੈਪਰ ਸਕ੍ਰਿਪਟ ਲਾਂਚ ਕਰਦਾ ਹੈ, ਇਹ ਬੈਕਅੱਪ ਰਿਪੋਜ਼ਟਰੀ, ਮਾਊਂਟ ਪੁਆਇੰਟਸ ਅਤੇ ਹਰ ਚੀਜ਼ ਦੀ ਵੈਧਤਾ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ ਜੋ ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ, ਫਿਰ ਬੈਕਅੱਪ ਲੈਂਦਾ ਹੈ ਅਤੇ ਪੁਰਾਣੀ ਨੂੰ ਸਾਫ਼ ਕਰਦਾ ਹੈ। ਮੁਕੰਮਲ ਬੈਕਅੱਪ ਆਪਣੇ ਆਪ ਨੂੰ S3 ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਹੈ.

ਅਸੀਂ ਇਸ ਸਕੀਮ ਦੇ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦੇ ਹਾਂ - ਇਹ ਇੱਕ ਬਾਹਰੀ AWS ਪ੍ਰਦਾਤਾ ਜਾਂ ਇੱਕ ਰੂਸੀ ਬਰਾਬਰ ਹੈ (ਇਹ ਤੇਜ਼ ਹੈ ਅਤੇ ਡੇਟਾ ਰੂਸੀ ਸੰਘ ਨੂੰ ਨਹੀਂ ਛੱਡਦਾ)। ਜਾਂ ਅਸੀਂ ਇਹਨਾਂ ਉਦੇਸ਼ਾਂ ਲਈ ਕਲਾਇੰਟ ਲਈ ਉਸਦੀ ਸਾਈਟ 'ਤੇ ਇੱਕ ਵੱਖਰਾ ਮਿਨੀਓ ਕਲੱਸਟਰ ਸਥਾਪਤ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਆ ਕਾਰਨਾਂ ਕਰਕੇ ਅਜਿਹਾ ਕਰਦੇ ਹਾਂ, ਜਦੋਂ ਕਲਾਇੰਟ ਇਹ ਨਹੀਂ ਚਾਹੁੰਦਾ ਕਿ ਡੇਟਾ ਆਪਣੇ ਸਰਕਟ ਨੂੰ ਛੱਡ ਦੇਵੇ।

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

ਤੁਹਾਡੀ ਸਥਾਨਕ ਮਸ਼ੀਨ ਨੂੰ ਹੈਕਰ ਤੋਂ ਬਚਾਉਣ ਲਈ, ਕਿਉਂਕਿ ਉਹ S3 'ਤੇ ਡਾਟਾ ਮਿਟਾ ਸਕਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਵਰਜਨਿੰਗ ਨੂੰ ਸਮਰੱਥ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਬੈਕਅੱਪ ਹਮੇਸ਼ਾ ਬੈਕਅੱਪ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ।

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

ਇੱਕ ਵੱਖਰਾ ਸ਼ਡਿਊਲਰ ਸੂਚਕਾਂਕ ਅਤੇ ਸਮੱਗਰੀ ਦੀ ਇਕਸਾਰਤਾ ਲਈ ਬੈਕਅੱਪ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਜਾਂਚ ਹੌਲੀ ਅਤੇ ਲੰਬੀ ਹੈ, ਇਸਲਈ ਅਸੀਂ ਇਸਨੂੰ ਮਹੀਨੇ ਵਿੱਚ ਇੱਕ ਵਾਰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਚਲਾਉਂਦੇ ਹਾਂ। ਇਸ ਵਿੱਚ ਕਈ ਦਿਨ ਲੱਗ ਸਕਦੇ ਹਨ।

ਰੂਸੀ ਵਿੱਚ ਪੜ੍ਹੋ

ਮੁੱਖ ਫੰਕਸ਼ਨ

• prepare ਸਿਖਲਾਈ
• testcheck ਤਿਆਰੀ ਦੀ ਜਾਂਚ
• maincommand ਕੋਰ ਟੀਮ
• forcepostscript ਇੱਕ ਫੰਕਸ਼ਨ ਜੋ ਅੰਤ ਵਿੱਚ ਜਾਂ ਗਲਤੀ ਦੁਆਰਾ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ। ਅਸੀਂ ਇਸਨੂੰ ਭਾਗ ਨੂੰ ਅਨਮਾਊਂਟ ਕਰਨ ਲਈ ਵਰਤਦੇ ਹਾਂ।

ਸੇਵਾ ਫੰਕਸ਼ਨ

• cleanup ਅਸੀਂ ਗਲਤੀਆਂ ਨੂੰ ਰਿਕਾਰਡ ਕਰਦੇ ਹਾਂ ਜਾਂ ਲੌਗ ਫਾਈਲ ਨੂੰ ਮਿਟਾ ਦਿੰਦੇ ਹਾਂ।
• checklog ਇੱਕ ਗਲਤੀ ਨਾਲ ਇੱਕ ਲਾਈਨ ਦੀ ਮੌਜੂਦਗੀ ਲਈ ਲਾਗ ਨੂੰ ਪਾਰਸ ਕਰੋ.
• ret ਐਗਜ਼ਿਟ ਹੈਂਡਲਰ।
• checktimeout ਸਮਾਂ ਸਮਾਪਤੀ ਦੀ ਜਾਂਚ ਕਰੋ।

ਵਾਤਾਵਰਣ

• VERBOSE=1 ਅਸੀਂ ਤੁਰੰਤ ਸਕਰੀਨ 'ਤੇ ਗਲਤੀਆਂ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੇ ਹਾਂ (stdout).
• SAVELOGSONSUCCES=1 ਸਫਲਤਾ 'ਤੇ ਲਾਗ ਨੂੰ ਬਚਾਓ.
• INIT_REPO_IF_NOT_EXIST=1 ਇੱਕ ਰਿਪੋਜ਼ਟਰੀ ਬਣਾਓ ਜੇਕਰ ਇਹ ਮੌਜੂਦ ਨਹੀਂ ਹੈ। ਮੂਲ ਰੂਪ ਵਿੱਚ ਅਸਮਰੱਥ।
• TIMEOUT ਮੁੱਖ ਕਾਰਵਾਈ ਲਈ ਵੱਧ ਤੋਂ ਵੱਧ ਸਮਾਂ. ਤੁਸੀਂ ਇਸ ਨੂੰ ਅੰਤ 'ਤੇ 'm', 'h' ਜਾਂ 'd' ਦੇ ਤੌਰ 'ਤੇ ਸੈੱਟ ਕਰ ਸਕਦੇ ਹੋ।

ਪੁਰਾਣੀਆਂ ਕਾਪੀਆਂ ਲਈ ਸਟੋਰੇਜ ਮੋਡ। ਪੂਰਵ-ਨਿਰਧਾਰਤ:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

ਸਕ੍ਰਿਪਟ ਦੇ ਅੰਦਰ ਵੇਰੀਏਬਲ

• ERROR_STRING — ਗਲਤੀ ਲਈ ਲਾਗਇਨ ਚੈੱਕ ਕਰਨ ਲਈ ਸਤਰ।
• EXTRACT_ERROR_STRING — ਸ਼ੋ ਸਤਰ ਲਈ ਸਮੀਕਰਨ ਜੇਕਰ ਗਲਤੀ ਹੈ।
• KILL_TIMEOUT_SIGNAL - ਸਮਾਂ ਸਮਾਪਤ ਹੋਣ 'ਤੇ ਮਾਰਨ ਲਈ ਸੰਕੇਤ।
• TAIL - ਸਕਰੀਨ 'ਤੇ ਗਲਤੀਆਂ ਨਾਲ ਕਿੰਨੀਆਂ ਸਤਰ ਹਨ।
• COLORMSG - ਸੁਨੇਹੇ ਦਾ ਰੰਗ (ਡਿਫਾਲਟ ਪੀਲਾ)।

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

ਰੈਸਟਿਕ ਬਨਾਮ ਬੋਰਗ

ਬੋਰਗ ਅਤੇ ਰੈਸਟਿਕ ਵਿਚਕਾਰ ਵੀ ਤੁਲਨਾਵਾਂ ਹਨ ਇੱਥੇ Habré 'ਤੇ, ਅਤੇ ਸਾਡੇ ਕੋਲ ਸਿਰਫ਼ ਇੱਕ ਹੋਰ ਬਣਾਉਣ ਦਾ ਕੰਮ ਨਹੀਂ ਸੀ, ਪਰ ਸਾਡਾ ਆਪਣਾ। ਇਹ ਸਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸੀ ਕਿ ਇਹ ਸਾਡੇ ਡੇਟਾ 'ਤੇ, ਸਾਡੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਨਾਲ ਕਿਵੇਂ ਦਿਖਾਈ ਦੇਵੇਗਾ। ਅਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਲਿਆਉਂਦੇ ਹਾਂ.

ਸਾਡੇ ਚੋਣ ਮਾਪਦੰਡ, ਪਹਿਲਾਂ ਹੀ ਦੱਸੇ ਗਏ (ਡਿਪਲਿਕੇਸ਼ਨ, ਤੇਜ਼ ਰਿਕਵਰੀ, ਆਦਿ) ਤੋਂ ਇਲਾਵਾ:

• ਅਧੂਰੇ ਕੰਮ ਦਾ ਵਿਰੋਧ. ਮਾਰਨ ਲਈ ਜਾਂਚ ਕਰੋ -9.
• ਡਿਸਕ 'ਤੇ ਆਕਾਰ.
• ਸਰੋਤਾਂ ਦੀ ਲੋੜ (CPU, ਮੈਮੋਰੀ)।
• ਸਟੋਰ ਕੀਤੇ ਬਲੌਬਾਂ ਦਾ ਆਕਾਰ।
• S3 ਨਾਲ ਕੰਮ ਕਰਨਾ।
• ਇਕਸਾਰਤਾ ਦੀ ਜਾਂਚ.

ਜਾਂਚ ਲਈ, ਅਸੀਂ ਅਸਲ ਡੇਟਾ ਅਤੇ ਕੁੱਲ 1,6 TB ਦੇ ਨਾਲ ਇੱਕ ਕਲਾਇੰਟ ਲਿਆ।
ਹਾਲਾਤ.

ਬੋਰਗ ਨੂੰ ਪਤਾ ਨਹੀਂ ਹੈ ਕਿ S3 ਨਾਲ ਸਿੱਧੇ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ, ਅਤੇ ਅਸੀਂ ਡਿਸਕ ਨੂੰ ਫਿਊਜ਼ ਦੇ ਰੂਪ ਵਿੱਚ ਮਾਊਂਟ ਕੀਤਾ, ਦੁਆਰਾ ਮੂਰਖ. ਰੈਸਟਿਕ ਨੇ ਇਸਨੂੰ ਖੁਦ S3 'ਤੇ ਭੇਜਿਆ ਹੈ।

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

ਨੈਟਵਰਕ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਘਟਾਉਣ ਲਈ, ਅਸੀਂ ਇੱਕ ਸਥਾਨਕ ਪ੍ਰਦਾਤਾ - ਯਾਂਡੇਕਸ ਕਲਾਉਡ ਦੀ ਵਰਤੋਂ ਕੀਤੀ.

ਤੁਲਨਾ ਟੈਸਟਿੰਗ ਨਤੀਜੇ.

• ਇੱਕ ਹੋਰ ਰੀਸਟਾਰਟ ਦੇ ਨਾਲ ਕਿਲ -9 ਦੋਵੇਂ ਸਫਲ ਸਨ।
• ਡਿਸਕ 'ਤੇ ਆਕਾਰ. ਬੋਰਗ ਸੰਕੁਚਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਨਤੀਜੇ ਉਮੀਦ ਅਨੁਸਾਰ ਹਨ.

ਬੈਕਅੱਪ
ਦਾ ਆਕਾਰ

ਬੋਰਗ
562Gb

ਰੈਸਟਿਕ
628Gb

• CPU ਦੁਆਰਾ
  ਬੋਰਗ ਆਪਣੇ ਆਪ ਵਿੱਚ ਡਿਫੌਲਟ ਕੰਪਰੈਸ਼ਨ ਦੇ ਨਾਲ ਬਹੁਤ ਘੱਟ ਖਪਤ ਕਰਦਾ ਹੈ, ਪਰ ਇਸਦਾ ਮੁਲਾਂਕਣ ਗੋਫਿਸ ਪ੍ਰਕਿਰਿਆ ਦੇ ਨਾਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਕੁੱਲ ਮਿਲਾ ਕੇ, ਉਹ ਤੁਲਨਾਤਮਕ ਹਨ ਅਤੇ ਉਸੇ ਟੈਸਟ ਵਰਚੁਅਲ ਮਸ਼ੀਨ 'ਤੇ ਲਗਭਗ 1,2 ਕੋਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।
• ਮੈਮੋਰੀ। ਰੈਸਟਿਕ ਲਗਭਗ 0,5GB ਹੈ, ਬੋਰਗ ਲਗਭਗ 200MB ਹੈ। ਪਰ ਸਿਸਟਮ ਫਾਈਲ ਕੈਸ਼ ਦੇ ਮੁਕਾਬਲੇ ਇਹ ਸਭ ਮਾਮੂਲੀ ਹੈ. ਇਸ ਲਈ ਵਧੇਰੇ ਮੈਮੋਰੀ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਸਲਾਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ.
• ਬਲੌਬ ਦੇ ਆਕਾਰ ਵਿੱਚ ਫਰਕ ਹੈਰਾਨਕੁਨ ਸੀ।

ਬੈਕਅੱਪ
ਦਾ ਆਕਾਰ

ਬੋਰਗ
ਲਗਭਗ 500MB

ਰੈਸਟਿਕ
ਲਗਭਗ 5MB

• ਰੈਸਟਿਕ ਦਾ S3 ਅਨੁਭਵ ਸ਼ਾਨਦਾਰ ਹੈ। ਬੋਰਗ ਦੇ ਨਾਲ ਗੁਫੀਆਂ ਦੁਆਰਾ ਕੰਮ ਕਰਨਾ ਕੋਈ ਸਵਾਲ ਨਹੀਂ ਉਠਾਉਂਦਾ, ਪਰ ਇਹ ਨੋਟ ਕੀਤਾ ਗਿਆ ਹੈ ਕਿ ਕੈਸ਼ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੀਸੈਟ ਕਰਨ ਲਈ ਬੈਕਅੱਪ ਪੂਰਾ ਹੋਣ ਤੋਂ ਬਾਅਦ umount ਕਰਨ ਦੀ ਸਲਾਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। S3 ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਇਹ ਹੈ ਕਿ ਅੰਡਰ-ਪੰਪਡ ਚੰਕਸ ਕਦੇ ਵੀ ਬਾਲਟੀ ਵਿੱਚ ਨਹੀਂ ਭੇਜੇ ਜਾਣਗੇ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਧੂਰਾ ਭਰਿਆ ਡੇਟਾ ਵੱਡਾ ਨੁਕਸਾਨ ਕਰਦਾ ਹੈ।
• ਅਖੰਡਤਾ ਜਾਂਚ ਦੋਵਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਪਰ ਗਤੀ ਕਾਫ਼ੀ ਵੱਖਰੀ ਹੁੰਦੀ ਹੈ।
  ਆਰਾਮਦਾਇਕ 3,5 ਘੰਟੇ.
  ਬੋਰਗ, ਇੱਕ 100GB SSD ਫਾਈਲ ਕੈਸ਼ ਦੇ ਨਾਲ - 5 ਘੰਟੇ.ਲਗਭਗ ਉਸੇ ਗਤੀ ਦਾ ਨਤੀਜਾ ਜੇਕਰ ਡੇਟਾ ਸਥਾਨਕ ਡਿਸਕ 'ਤੇ ਹੈ।
  ਬੋਰਗ ਬਿਨਾਂ ਕੈਸ਼ ਦੇ S3 ਤੋਂ ਸਿੱਧਾ ਪੜ੍ਹਦਾ ਹੈ 33 ਘੰਟੇ. ਭਿਆਨਕ ਤੌਰ 'ਤੇ ਲੰਬੇ.

ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਬੋਰਗ ਸੰਕੁਚਿਤ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਵੱਡੇ ਬਲੌਬ ਹਨ - ਜੋ S3 ਵਿੱਚ ਸਟੋਰੇਜ ਅਤੇ GET/PUT ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਸਸਤਾ ਬਣਾਉਂਦਾ ਹੈ। ਪਰ ਇਹ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਅਤੇ ਹੌਲੀ ਤਸਦੀਕ ਦੀ ਕੀਮਤ 'ਤੇ ਆਉਂਦਾ ਹੈ। ਜਿੱਥੋਂ ਤੱਕ ਰਿਕਵਰੀ ਦੀ ਗਤੀ ਲਈ, ਸਾਨੂੰ ਕੋਈ ਫਰਕ ਨਜ਼ਰ ਨਹੀਂ ਆਇਆ। ਰੈਸਟਿਕ ਬਾਅਦ ਵਿੱਚ ਬੈਕਅੱਪ ਲੈਂਦਾ ਹੈ (ਪਹਿਲੇ ਤੋਂ ਬਾਅਦ) ਥੋੜਾ ਲੰਬਾ, ਪਰ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ।

ਚੋਣ ਵਿੱਚ ਆਖਰੀ ਪਰ ਘੱਟੋ ਘੱਟ ਨਹੀਂ ਸੀ ਭਾਈਚਾਰੇ ਦਾ ਆਕਾਰ।

ਅਤੇ ਅਸੀਂ ਬੋਰਗ ਨੂੰ ਚੁਣਿਆ।

ਕੰਪਰੈਸ਼ਨ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ

ਬੋਰਗ ਕੋਲ ਇਸਦੇ ਸ਼ਸਤਰ ਵਿੱਚ ਇੱਕ ਸ਼ਾਨਦਾਰ ਨਵਾਂ ਕੰਪਰੈਸ਼ਨ ਐਲਗੋਰਿਦਮ ਹੈ - zstd. ਕੰਪਰੈਸ਼ਨ ਗੁਣਵੱਤਾ gzip ਨਾਲੋਂ ਮਾੜੀ ਨਹੀਂ ਹੈ, ਪਰ ਬਹੁਤ ਤੇਜ਼ ਹੈ. ਅਤੇ ਡਿਫੌਲਟ lz4 ਨਾਲ ਸਪੀਡ ਵਿੱਚ ਤੁਲਨਾਤਮਕ.

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

ਬੋਰਗ ਦੀ ਬਜਾਏ ਇੱਕ ਬੋਨਸ ਕੰਪਰੈਸ਼ਨ ਮੋਡ ਹੈ - ਜੇਕਰ ਫਾਈਲ ਵਿੱਚ ਉੱਚ ਐਂਟਰੋਪੀ ਹੈ, ਤਾਂ ਕੰਪਰੈਸ਼ਨ ਬਿਲਕੁਲ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਗਤੀ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ। ਬਣਾਉਣ ਵੇਲੇ ਵਿਕਲਪ ਦੁਆਰਾ ਸਮਰਥਿਤ
-C auto,zstd
zstd ਐਲਗੋਰਿਦਮ ਲਈ
ਇਸ ਲਈ ਇਸ ਵਿਕਲਪ ਦੇ ਨਾਲ, ਡਿਫਾਲਟ ਕੰਪਰੈਸ਼ਨ ਦੇ ਮੁਕਾਬਲੇ, ਸਾਨੂੰ ਮਿਲਿਆ ਹੈ
ਕ੍ਰਮਵਾਰ 560Gb ਅਤੇ 562Gb। ਉਪਰੋਕਤ ਉਦਾਹਰਨ ਤੋਂ ਡੇਟਾ, ਮੈਨੂੰ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਣ ਦਿਓ, ਬਿਨਾਂ ਕੰਪਰੈਸ਼ਨ ਦੇ ਨਤੀਜਾ 628Gb ਹੈ. 2GB ਫਰਕ ਦੇ ਨਤੀਜੇ ਨੇ ਸਾਨੂੰ ਕੁਝ ਹੱਦ ਤੱਕ ਹੈਰਾਨ ਕਰ ਦਿੱਤਾ, ਪਰ ਅਸੀਂ ਸੋਚਿਆ ਕਿ ਅਸੀਂ ਸਭ ਤੋਂ ਬਾਅਦ ਇਸਨੂੰ ਚੁਣਾਂਗੇ। auto,zstd.

ਬੈਕਅੱਪ ਪੁਸ਼ਟੀਕਰਨ ਵਿਧੀ

ਸ਼ਡਿਊਲਰ ਦੇ ਅਨੁਸਾਰ, ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਸਿੱਧੇ ਪ੍ਰਦਾਤਾ ਜਾਂ ਕਲਾਇੰਟ ਤੋਂ ਲਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਨੈਟਵਰਕ ਲੋਡ ਨੂੰ ਬਹੁਤ ਘਟਾਉਂਦੀ ਹੈ। ਘੱਟੋ ਘੱਟ ਇਹ ਇਸਨੂੰ ਆਪਣੇ ਆਪ ਵਧਾਉਣ ਅਤੇ ਟ੍ਰੈਫਿਕ ਚਲਾਉਣ ਨਾਲੋਂ ਸਸਤਾ ਹੈ.

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

ਉਸੇ ਸਕੀਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਐਂਟੀਵਾਇਰਸ ਨਾਲ ਫਾਈਲਾਂ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਾਂ (ਅਸਲ ਤੋਂ ਬਾਅਦ). ਆਖ਼ਰਕਾਰ, ਉਪਭੋਗਤਾ ਨੈਕਸਟ ਕਲਾਉਡ 'ਤੇ ਵੱਖੋ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਅਪਲੋਡ ਕਰਦੇ ਹਨ ਅਤੇ ਹਰ ਕਿਸੇ ਕੋਲ ਐਂਟੀਵਾਇਰਸ ਨਹੀਂ ਹੁੰਦਾ. ਡੋਲ੍ਹਣ ਦੇ ਸਮੇਂ ਨਿਰੀਖਣ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ ਅਤੇ ਕਾਰੋਬਾਰ ਵਿੱਚ ਵਿਘਨ ਪੈਂਦਾ ਹੈ।

ਸਕੇਲੇਬਿਲਟੀ ਵੱਖ-ਵੱਖ ਟੈਗਾਂ ਦੇ ਨਾਲ ਵੱਖ-ਵੱਖ ਨੋਡਾਂ 'ਤੇ ਦੌੜਾਕਾਂ ਨੂੰ ਚਲਾ ਕੇ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
ਸਾਡੀ ਨਿਗਰਾਨੀ ਇੱਕ ਵਿੰਡੋ ਵਿੱਚ GitLab API ਦੁਆਰਾ ਬੈਕਅੱਪ ਸਥਿਤੀਆਂ ਨੂੰ ਇਕੱਠਾ ਕਰਦੀ ਹੈ; ਜੇਕਰ ਲੋੜ ਹੋਵੇ, ਸਮੱਸਿਆਵਾਂ ਆਸਾਨੀ ਨਾਲ ਦੇਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਉਸੇ ਤਰ੍ਹਾਂ ਹੀ ਆਸਾਨੀ ਨਾਲ ਸਥਾਨੀਕਰਨ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

ਸਿੱਟਾ

ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਜਾਣਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਬੈਕਅੱਪ ਬਣਾਉਂਦੇ ਹਾਂ, ਕਿ ਸਾਡੇ ਬੈਕਅੱਪ ਵੈਧ ਹਨ, ਉਹਨਾਂ ਨਾਲ ਪੈਦਾ ਹੋਣ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਥੋੜਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ ਅਤੇ ਡਿਊਟੀ ਪ੍ਰਬੰਧਕ ਦੇ ਪੱਧਰ 'ਤੇ ਹੱਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। tar.gz ਜਾਂ Bacula ਦੇ ਮੁਕਾਬਲੇ ਬੈਕਅੱਪ ਬਹੁਤ ਘੱਟ ਥਾਂ ਲੈਂਦੇ ਹਨ।

ਸਰੋਤ: www.habr.com