ਬੈਕਅੱਪ, ਭਾਗ 1: ਉਦੇਸ਼, ਵਿਧੀਆਂ ਅਤੇ ਤਕਨਾਲੋਜੀਆਂ ਦੀ ਸਮੀਖਿਆ

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

ਇੱਕ ਆਦਰਸ਼ ਪ੍ਰੋਗਰਾਮ ਤੇਜ਼ੀ ਨਾਲ ਚੱਲਦਾ ਹੈ, ਮੈਮੋਰੀ ਲੀਕ ਨਹੀਂ ਕਰਦਾ, ਕੋਈ ਛੇਕ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਮੌਜੂਦ ਨਹੀਂ ਹੁੰਦਾ।

-ਅਣਜਾਣ

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

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

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

ਚੰਗੇ ਕਲਾਕਾਰ ਨਕਲ ਕਰਦੇ ਹਨ, ਮਹਾਨ ਕਲਾਕਾਰ ਚੋਰੀ ਕਰਦੇ ਹਨ।

-ਪਾਬਲੋ ਪਿਕਾਸੋ।

ਸਭ ਤੋਂ ਸਫਲ ਹੱਲ ਅਤੇ ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ ਸਧਾਰਨ ਚੀਜ਼ਾਂ ਆਮ ਤੌਰ 'ਤੇ ਵਾਪਰਦੀਆਂ ਹਨ ਜਿੱਥੇ ਸੰਕਲਪਾਂ, ਤਕਨਾਲੋਜੀਆਂ, ਗਿਆਨ ਅਤੇ ਵਿਗਿਆਨ ਦੇ ਖੇਤਰ ਜੋ ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ ਬਿਲਕੁਲ ਅਸੰਗਤ ਹਨ, ਮਿਲਦੇ ਹਨ।

ਉਦਾਹਰਨ ਲਈ, ਪੰਛੀਆਂ ਅਤੇ ਹਵਾਈ ਜਹਾਜ਼ਾਂ ਦੇ ਖੰਭ ਹੁੰਦੇ ਹਨ, ਪਰ ਕਾਰਜਸ਼ੀਲ ਸਮਾਨਤਾ ਦੇ ਬਾਵਜੂਦ - ਕੁਝ ਮੋਡਾਂ ਵਿੱਚ ਸੰਚਾਲਨ ਦਾ ਸਿਧਾਂਤ ਇੱਕੋ ਜਿਹਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਤਕਨੀਕੀ ਸਮੱਸਿਆਵਾਂ ਦਾ ਹੱਲ ਉਸੇ ਤਰ੍ਹਾਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: ਖੋਖਲੀਆਂ ​​ਹੱਡੀਆਂ, ਮਜ਼ਬੂਤ ​​ਅਤੇ ਹਲਕੇ ਭਾਰ ਵਾਲੀਆਂ ਸਮੱਗਰੀਆਂ ਦੀ ਵਰਤੋਂ, ਆਦਿ - ਨਤੀਜੇ ਬਿਲਕੁਲ ਵੱਖਰੇ ਹਨ, ਹਾਲਾਂਕਿ ਬਹੁਤ ਸਮਾਨ ਹਨ। ਸਾਡੀ ਟੈਕਨਾਲੋਜੀ ਵਿੱਚ ਜੋ ਸਭ ਤੋਂ ਵਧੀਆ ਉਦਾਹਰਣਾਂ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਉਹ ਵੀ ਜ਼ਿਆਦਾਤਰ ਕੁਦਰਤ ਤੋਂ ਉਧਾਰ ਲਈਆਂ ਗਈਆਂ ਹਨ: ਜਹਾਜ਼ਾਂ ਅਤੇ ਪਣਡੁੱਬੀਆਂ ਦੇ ਦਬਾਅ ਵਾਲੇ ਡੱਬੇ ਐਨੀਲਿਡਜ਼ ਨਾਲ ਸਿੱਧੇ ਸਮਾਨਤਾ ਹਨ; ਰੇਡ ਐਰੇ ਬਣਾਉਣਾ ਅਤੇ ਡੇਟਾ ਦੀ ਇਕਸਾਰਤਾ ਦੀ ਜਾਂਚ ਕਰਨਾ - ਡੀਐਨਏ ਚੇਨ ਦੀ ਨਕਲ ਕਰਨਾ; ਨਾਲ ਹੀ ਜੋੜਾਬੱਧ ਅੰਗ, ਕੇਂਦਰੀ ਨਸ ਪ੍ਰਣਾਲੀ (ਦਿਲ ਦਾ ਆਟੋਮੇਸ਼ਨ) ਅਤੇ ਪ੍ਰਤੀਬਿੰਬਾਂ ਤੋਂ ਵੱਖ-ਵੱਖ ਅੰਗਾਂ ਦੇ ਕੰਮ ਦੀ ਸੁਤੰਤਰਤਾ - ਇੰਟਰਨੈਟ ਤੇ ਆਟੋਨੋਮਸ ਸਿਸਟਮ. ਬੇਸ਼ੱਕ, ਤਿਆਰ ਕੀਤੇ ਹੱਲਾਂ ਨੂੰ ਲੈਣਾ ਅਤੇ ਲਾਗੂ ਕਰਨਾ "ਹੈੱਡ-ਆਨ" ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਭਰਿਆ ਹੋਇਆ ਹੈ, ਪਰ ਕੌਣ ਜਾਣਦਾ ਹੈ, ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਕੋਈ ਹੋਰ ਹੱਲ ਨਾ ਹੋਵੇ।

ਕਾਸ਼ ਮੈਨੂੰ ਪਤਾ ਹੁੰਦਾ ਕਿ ਤੁਸੀਂ ਕਿੱਥੇ ਡਿੱਗੋਗੇ, ਮੈਂ ਤੂੜੀ ਵਿਛਾ ਦਿੱਤੀ ਹੁੰਦੀ!

- ਬੇਲਾਰੂਸੀ ਲੋਕ ਕਹਾਵਤ

ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਬੈਕਅੱਪ ਕਾਪੀਆਂ ਉਹਨਾਂ ਲਈ ਜ਼ਰੂਰੀ ਹਨ ਜੋ ਇਹ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ:

• ਘੱਟੋ-ਘੱਟ ਡਾਊਨਟਾਈਮ ਦੇ ਨਾਲ, ਜਾਂ ਇਸ ਤੋਂ ਬਿਨਾਂ ਵੀ ਆਪਣੇ ਸਿਸਟਮਾਂ ਦੇ ਸੰਚਾਲਨ ਨੂੰ ਬਹਾਲ ਕਰਨ ਦੇ ਯੋਗ ਬਣੋ
• ਦਲੇਰੀ ਨਾਲ ਕੰਮ ਕਰੋ, ਕਿਉਂਕਿ ਇੱਕ ਗਲਤੀ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਹਮੇਸ਼ਾ ਇੱਕ ਰੋਲਬੈਕ ਦੀ ਸੰਭਾਵਨਾ ਹੁੰਦੀ ਹੈ
• ਜਾਣਬੁੱਝ ਕੇ ਡੇਟਾ ਭ੍ਰਿਸ਼ਟਾਚਾਰ ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰੋ

ਇੱਥੇ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਸਿਧਾਂਤ ਹੈ

ਕੋਈ ਵੀ ਵਰਗੀਕਰਨ ਆਪਹੁਦਰਾ ਹੁੰਦਾ ਹੈ। ਕੁਦਰਤ ਵਰਗੀਕਰਨ ਨਹੀਂ ਕਰਦੀ। ਅਸੀਂ ਵਰਗੀਕਰਨ ਕਰਦੇ ਹਾਂ ਕਿਉਂਕਿ ਇਹ ਸਾਡੇ ਲਈ ਵਧੇਰੇ ਸੁਵਿਧਾਜਨਕ ਹੈ। ਅਤੇ ਅਸੀਂ ਡੇਟਾ ਦੇ ਅਨੁਸਾਰ ਵਰਗੀਕਰਨ ਕਰਦੇ ਹਾਂ ਜੋ ਅਸੀਂ ਮਨਮਾਨੇ ਢੰਗ ਨਾਲ ਲੈਂਦੇ ਹਾਂ.

- ਜੀਨ ਬਰੁਲਰ

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

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

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

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

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

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

— ਇੱਥੇ ਦੋ ਕਿਸਮ ਦੇ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਹਨ, ਉਹ ਜਿਹੜੇ ਬੈਕਅੱਪ ਨਹੀਂ ਲੈਂਦੇ ਹਨ, ਅਤੇ ਉਹ ਜੋ ਪਹਿਲਾਂ ਹੀ ਕਰਦੇ ਹਨ।
- ਅਸਲ ਵਿੱਚ, ਇੱਥੇ ਤਿੰਨ ਕਿਸਮਾਂ ਹਨ: ਇੱਥੇ ਉਹ ਵੀ ਹਨ ਜੋ ਇਹ ਜਾਂਚ ਕਰਦੇ ਹਨ ਕਿ ਬੈਕਅਪ ਰੀਸਟੋਰ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।

-ਅਣਜਾਣ

ਇਹ ਵੀ ਸਮਝਣ ਯੋਗ ਹੈ ਕਿ ਡੇਟਾ ਬੈਕਅਪ ਪ੍ਰਕਿਰਿਆ ਆਪਣੇ ਆਪ ਪ੍ਰੋਗਰਾਮਾਂ ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਇਸਲਈ ਇਸਦੇ ਕਿਸੇ ਵੀ ਹੋਰ ਪ੍ਰੋਗਰਾਮ ਦੇ ਸਮਾਨ ਨੁਕਸਾਨ ਹਨ. ਮਨੁੱਖੀ ਕਾਰਕ 'ਤੇ ਨਿਰਭਰਤਾ ਨੂੰ ਦੂਰ ਕਰਨ ਲਈ (ਨਾ ਖਤਮ ਕਰਨਾ!) ਅਤੇ ਨਾਲ ਹੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ - ਜੋ ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ ਕੋਈ ਮਜ਼ਬੂਤ ​​ਪ੍ਰਭਾਵ ਨਹੀਂ ਪਾਉਂਦੀਆਂ, ਪਰ ਇਕੱਠੇ ਇੱਕ ਧਿਆਨ ਦੇਣ ਯੋਗ ਪ੍ਰਭਾਵ ਦੇ ਸਕਦੀਆਂ ਹਨ - ਅਖੌਤੀ ਨਿਯਮ 3-2-1. ਇਸ ਨੂੰ ਸਮਝਣ ਦੇ ਤਰੀਕੇ ਲਈ ਬਹੁਤ ਸਾਰੇ ਵਿਕਲਪ ਹਨ, ਪਰ ਮੈਨੂੰ ਹੇਠਾਂ ਦਿੱਤੀ ਵਿਆਖਿਆ ਬਿਹਤਰ ਪਸੰਦ ਹੈ: ਇੱਕੋ ਡੇਟਾ ਦੇ 3 ਸੈੱਟ ਸਟੋਰ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ, 2 ਸੈੱਟ ਵੱਖ-ਵੱਖ ਫਾਰਮੈਟਾਂ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ 1 ਸੈੱਟ ਇੱਕ ਭੂਗੋਲਿਕ ਤੌਰ 'ਤੇ ਰਿਮੋਟ ਸਟੋਰੇਜ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਸਟੋਰੇਜ ਫਾਰਮੈਟ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਸਮਝਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ:

• ਜੇ ਭੌਤਿਕ ਸਟੋਰੇਜ ਵਿਧੀ 'ਤੇ ਨਿਰਭਰਤਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਭੌਤਿਕ ਵਿਧੀ ਨੂੰ ਬਦਲਦੇ ਹਾਂ।
• ਜੇਕਰ ਲਾਜ਼ੀਕਲ ਸਟੋਰੇਜ ਵਿਧੀ 'ਤੇ ਨਿਰਭਰਤਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਲਾਜ਼ੀਕਲ ਢੰਗ ਨੂੰ ਬਦਲਦੇ ਹਾਂ।

3-2-1 ਨਿਯਮ ਦੇ ਵੱਧ ਤੋਂ ਵੱਧ ਪ੍ਰਭਾਵ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਸਟੋਰੇਜ ਫਾਰਮੈਟ ਨੂੰ ਦੋਵਾਂ ਤਰੀਕਿਆਂ ਨਾਲ ਬਦਲਣ ਦੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

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

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

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

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

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

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

ipsos custodes ਨੂੰ ਕਸਟੋਡਾਈਟ ਕੀ ਹੈ?

(ਪਹਿਰੇਦਾਰਾਂ ਦੀ ਰਾਖੀ ਕੌਣ ਕਰੇਗਾ? - lat.)

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

• ਸਰੋਤ ਡੇਟਾ ਦੀ ਇਕਸਾਰਤਾ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤਾ ਗਿਆ ਹੈ।
• ਬੈਕਅੱਪ ਸਟੋਰੇਜ ਖਰਾਬ ਹੋ ਗਈ ਹੈ।
• ਬਹਾਲੀ ਬਹੁਤ ਹੌਲੀ-ਹੌਲੀ ਕੰਮ ਕਰਦੀ ਹੈ; ਤੁਸੀਂ ਉਸ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਸਕਦੇ ਜੋ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਮੁੜ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ ਹੈ।

ਇੱਕ ਸਹੀ ਢੰਗ ਨਾਲ ਬਣਾਈ ਗਈ ਬੈਕਅੱਪ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਅਜਿਹੀਆਂ ਟਿੱਪਣੀਆਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਪਹਿਲੀਆਂ ਦੋ।

ਸਰੋਤ ਡੇਟਾ ਦੀ ਇਕਸਾਰਤਾ ਦੀ ਕਈ ਤਰੀਕਿਆਂ ਨਾਲ ਗਾਰੰਟੀ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਸਭ ਤੋਂ ਵੱਧ ਵਰਤੇ ਜਾਂਦੇ ਹਨ: a) ਬਲਾਕ ਪੱਧਰ 'ਤੇ ਫਾਈਲ ਸਿਸਟਮ ਦੇ ਸਨੈਪਸ਼ਾਟ ਬਣਾਉਣਾ, b) ਫਾਈਲ ਸਿਸਟਮ ਦੀ ਸਥਿਤੀ ਨੂੰ "ਫ੍ਰੀਜ਼ ਕਰਨਾ", c) ਸੰਸਕਰਣ ਸਟੋਰੇਜ ਵਾਲਾ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਬਲਾਕ ਡਿਵਾਈਸ, d) ਫਾਈਲਾਂ ਦੀ ਕ੍ਰਮਵਾਰ ਰਿਕਾਰਡਿੰਗ ਜਾਂ ਬਲਾਕ. ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਚੈੱਕਸਮ ਵੀ ਲਾਗੂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਕਿ ਰਿਕਵਰੀ ਦੌਰਾਨ ਡੇਟਾ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਗਈ ਹੈ।

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

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

ਮਸਾਲਿਆਂ ਦਾ ਮਾਹਰ ਉਹ ਨਹੀਂ ਹੈ ਜੋ ਹਰ ਪਕਵਾਨ ਵਿੱਚ ਉਨ੍ਹਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ, ਪਰ ਉਹ ਜੋ ਕਦੇ ਵੀ ਇਸ ਵਿੱਚ ਕੁਝ ਵਾਧੂ ਨਹੀਂ ਜੋੜਦਾ ਹੈ।

-ਆਈ.ਐਨ. ਸਿਨੀਆਵਸਕੀ

ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕਾਂ ਦੁਆਰਾ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਸੌਫਟਵੇਅਰ ਦੇ ਸੰਬੰਧ ਵਿੱਚ ਅਭਿਆਸ ਵੱਖੋ-ਵੱਖਰੇ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਆਮ ਸਿਧਾਂਤ ਅਜੇ ਵੀ, ਇੱਕ ਜਾਂ ਦੂਜੇ ਤਰੀਕੇ ਨਾਲ, ਇੱਕੋ ਜਿਹੇ ਹਨ, ਖਾਸ ਤੌਰ 'ਤੇ:

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

ਬਲਾਕ ਡਿਵਾਈਸਾਂ ਤੋਂ ਬੈਕਅੱਪ ਲੈਣ ਲਈ ਹੇਠਾਂ ਦਿੱਤੇ ਆਮ ਪ੍ਰੋਗਰਾਮ ਹਨ:

• dd, ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਨ ਦੇ ਸਾਬਕਾ ਫੌਜੀਆਂ ਤੋਂ ਜਾਣੂ ਹੈ, ਇਸ ਵਿੱਚ ਸਮਾਨ ਪ੍ਰੋਗਰਾਮ ਵੀ ਸ਼ਾਮਲ ਹਨ (ਉਦਾਹਰਣ ਲਈ ਉਹੀ dd_rescue)।
• ਕੁਝ ਫਾਈਲ ਸਿਸਟਮਾਂ ਵਿੱਚ ਬਣੀਆਂ ਸਹੂਲਤਾਂ ਜੋ ਫਾਈਲ ਸਿਸਟਮ ਦਾ ਡੰਪ ਬਣਾਉਂਦੀਆਂ ਹਨ।
• ਸਰਵਵਿਆਪਕ ਉਪਯੋਗਤਾਵਾਂ; ਉਦਾਹਰਨ ਲਈ partclone.
• ਆਪਣੇ, ਅਕਸਰ ਮਲਕੀਅਤ, ਫੈਸਲੇ; ਉਦਾਹਰਨ ਲਈ, NortonGhost ਅਤੇ ਬਾਅਦ ਵਿੱਚ।

ਫਾਈਲ ਸਿਸਟਮਾਂ ਲਈ, ਬਲਾਕ ਡਿਵਾਈਸਾਂ ਲਈ ਲਾਗੂ ਤਰੀਕਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬੈਕਅੱਪ ਸਮੱਸਿਆ ਨੂੰ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਹੱਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਸਮੱਸਿਆ ਨੂੰ ਵਧੇਰੇ ਕੁਸ਼ਲਤਾ ਨਾਲ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ:

• Rsync, ਇੱਕ ਆਮ-ਉਦੇਸ਼ ਵਾਲਾ ਪ੍ਰੋਗਰਾਮ ਅਤੇ ਫਾਈਲ ਸਿਸਟਮਾਂ ਦੀ ਸਥਿਤੀ ਨੂੰ ਸਮਕਾਲੀ ਕਰਨ ਲਈ ਪ੍ਰੋਟੋਕੋਲ।
• ਬਿਲਟ-ਇਨ ਆਰਕਾਈਵਿੰਗ ਟੂਲ (ZFS)।
• ਤੀਜੀ ਧਿਰ ਪੁਰਾਲੇਖ ਸੰਦ; ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ ਪ੍ਰਤੀਨਿਧੀ ਟਾਰ ਹੈ. ਹੋਰ ਵੀ ਹਨ, ਉਦਾਹਰਨ ਲਈ, ਡਾਰ - ਆਧੁਨਿਕ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਉਦੇਸ਼ ਨਾਲ ਟਾਰ ਦਾ ਬਦਲ.

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

• ਫਾਈਲ ਸਿਸਟਮ ਨੂੰ ਸਿਰਫ-ਪੜ੍ਹਨ ਵਾਲੇ ਮੋਡ ਵਿੱਚ ਮਾਊਂਟ ਕਰਨਾ, ਜਾਂ ਫਾਈਲ ਸਿਸਟਮ ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰਨਾ (ਫ੍ਰੀਜ਼) - ਵਿਧੀ ਸੀਮਤ ਲਾਗੂ ਹੋਣ ਦੀ ਹੈ।
• ਫਾਈਲ ਸਿਸਟਮਾਂ ਜਾਂ ਬਲਾਕ ਡਿਵਾਈਸਾਂ (LVM, ZFS) ਦੀ ਸਥਿਤੀ ਦੇ ਸਨੈਪਸ਼ਾਟ ਬਣਾਉਣਾ।
• ਪ੍ਰਭਾਵ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਲਈ ਤੀਜੀ-ਧਿਰ ਦੇ ਸਾਧਨਾਂ ਦੀ ਵਰਤੋਂ, ਭਾਵੇਂ ਕਿ ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ ਜਿੱਥੇ ਪਿਛਲੇ ਪੁਆਇੰਟ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ (ਹਾਟਕਾਪੀ ਵਰਗੇ ਪ੍ਰੋਗਰਾਮ)।
• ਕਾਪੀ-ਆਨ-ਚੇਂਜ ਤਕਨੀਕ (CopyOnWrite), ਹਾਲਾਂਕਿ, ਇਹ ਅਕਸਰ ਵਰਤੇ ਗਏ ਫਾਈਲ ਸਿਸਟਮ (BTRFS, ZFS) ਨਾਲ ਜੁੜੀ ਹੁੰਦੀ ਹੈ।

ਇਸ ਲਈ, ਇੱਕ ਛੋਟੇ ਸਰਵਰ ਲਈ ਤੁਹਾਨੂੰ ਇੱਕ ਬੈਕਅੱਪ ਸਕੀਮ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਜੋ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦੀ ਹੈ:

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

ਉਹਨਾਂ ਤੋਂ ਬਿਨੈਕਾਰ ਜੋ ਘੱਟ ਜਾਂ ਘੱਟ ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦੇ ਹਨ:

• rdiff-ਬੈਕਅੱਪ
• rsnapshot
• ਬਰਪ
• ਡੁਪਲੀਕੇਟ
• ਦੁਹਰਾਓ
• ਚੁੱਪ ਕਰਾਓ
• Dar
• zbackup
• ਆਰਾਮਦਾਇਕ
• borgbackup

ਹੇਠ ਲਿਖੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਾਲੀ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ (XenServer 'ਤੇ ਅਧਾਰਤ) ਨੂੰ ਇੱਕ ਟੈਸਟ ਬੈਂਚ ਵਜੋਂ ਵਰਤਿਆ ਜਾਵੇਗਾ:

• 4 ਕੋਰ 2.5 GHz,
• 16 ਜੀਬੀ ਰੈਮ,
• 50 GB ਹਾਈਬ੍ਰਿਡ ਸਟੋਰੇਜ (ਵਰਚੁਅਲ ਡਿਸਕ ਆਕਾਰ ਦੇ 20% SSD 'ਤੇ ਕੈਚਿੰਗ ਦੇ ਨਾਲ ਸਟੋਰੇਜ ਸਿਸਟਮ) ਬਿਨਾਂ ਵਿਭਾਗੀਕਰਨ ਦੇ ਵੱਖਰੀ ਵਰਚੁਅਲ ਡਿਸਕ ਦੇ ਰੂਪ ਵਿੱਚ,
• 200 Mbits ਇੰਟਰਨੈੱਟ ਚੈਨਲ।

ਲਗਭਗ ਇੱਕੋ ਮਸ਼ੀਨ ਨੂੰ ਬੈਕਅੱਪ ਰਿਸੀਵਰ ਸਰਵਰ ਵਜੋਂ ਵਰਤਿਆ ਜਾਵੇਗਾ, ਸਿਰਫ਼ 500 GB ਹਾਰਡ ਡਰਾਈਵ ਨਾਲ।

ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ - Centos 7 x64: ਸਟੈਂਡਰਡ ਭਾਗ, ਵਾਧੂ ਭਾਗ ਡੇਟਾ ਸਰੋਤ ਵਜੋਂ ਵਰਤਿਆ ਜਾਵੇਗਾ।

ਸ਼ੁਰੂਆਤੀ ਡੇਟਾ ਦੇ ਤੌਰ 'ਤੇ, ਆਓ 40 GB ਮੀਡੀਆ ਫਾਈਲਾਂ ਅਤੇ ਇੱਕ mysql ਡੇਟਾਬੇਸ ਦੇ ਨਾਲ ਇੱਕ ਵਰਡਪਰੈਸ ਸਾਈਟ ਲੈ ਲਈਏ। ਕਿਉਂਕਿ ਵਰਚੁਅਲ ਸਰਵਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਬਹੁਤ ਭਿੰਨ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਬਿਹਤਰ ਪ੍ਰਜਨਨਯੋਗਤਾ ਲਈ ਵੀ, ਇੱਥੇ ਹੈ

sysbench ਵਰਤ ਕੇ ਸਰਵਰ ਟੈਸਟਿੰਗ ਨਤੀਜੇ.sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu ਰਨ
sysbench 1.1.0-18a9f86 (ਬੰਡਲਡ LuaJIT 2.1.0-beta3 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ)
ਹੇਠ ਲਿਖੀਆਂ ਚੋਣਾਂ ਨਾਲ ਟੈਸਟ ਚਲਾਉਣਾ:
ਥ੍ਰੈੱਡਾਂ ਦੀ ਗਿਣਤੀ: 4
ਮੌਜੂਦਾ ਸਮੇਂ ਤੋਂ ਬੇਤਰਤੀਬ ਨੰਬਰ ਜਨਰੇਟਰ ਸ਼ੁਰੂ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

ਪ੍ਰਧਾਨ ਨੰਬਰਾਂ ਦੀ ਸੀਮਾ: 20000

ਵਰਕਰ ਥ੍ਰੈਡ ਸ਼ੁਰੂ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ...

ਧਾਗੇ ਸ਼ੁਰੂ!

ਸੀਪੀਯੂ ਦੀ ਗਤੀ:
ਘਟਨਾਵਾਂ ਪ੍ਰਤੀ ਸਕਿੰਟ: 836.69

ਥਰੋਪੁਟ:
ਘਟਨਾਵਾਂ/s (eps): 836.6908
ਸਮਾਂ ਬੀਤਿਆ: 30.0039s
ਸਮਾਗਮਾਂ ਦੀ ਕੁੱਲ ਗਿਣਤੀ: 25104

ਲੇਟੈਂਸੀ (ms):
ਮਿੰਟ: 2.38
ਔਸਤ: 4.78
ਅਧਿਕਤਮ: 22.39
95ਵਾਂ ਪ੍ਰਤੀਸ਼ਤ: 10.46
ਜੋੜ: 119923.64

ਧਾਗੇ ਨਿਰਪੱਖਤਾ:
ਇਵੈਂਟਸ (ਔਸਤ/stddev): 6276.0000/13.91
ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਟਾਈਮ (ਔਸਤ/stddev): 29.9809/0.01

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=ਰੀਡ ਮੈਮੋਰੀ ਰਨ
sysbench 1.1.0-18a9f86 (ਬੰਡਲਡ LuaJIT 2.1.0-beta3 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ)
ਹੇਠ ਲਿਖੀਆਂ ਚੋਣਾਂ ਨਾਲ ਟੈਸਟ ਚਲਾਉਣਾ:
ਥ੍ਰੈੱਡਾਂ ਦੀ ਗਿਣਤੀ: 4
ਮੌਜੂਦਾ ਸਮੇਂ ਤੋਂ ਬੇਤਰਤੀਬ ਨੰਬਰ ਜਨਰੇਟਰ ਸ਼ੁਰੂ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

ਹੇਠਾਂ ਦਿੱਤੇ ਵਿਕਲਪਾਂ ਨਾਲ ਮੈਮੋਰੀ ਸਪੀਡ ਟੈਸਟ ਚੱਲ ਰਿਹਾ ਹੈ:
ਬਲਾਕ ਦਾ ਆਕਾਰ: 1KiB
ਕੁੱਲ ਆਕਾਰ: 102400MiB
ਕਾਰਵਾਈ: ਪੜ੍ਹੋ
ਸਕੋਪ: ਗਲੋਬਲ

ਵਰਕਰ ਥ੍ਰੈਡ ਸ਼ੁਰੂ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ...

ਧਾਗੇ ਸ਼ੁਰੂ!

ਕੁੱਲ ਸੰਚਾਲਨ: 50900446 (1696677.10 ਪ੍ਰਤੀ ਸਕਿੰਟ)

49707.47 MiB ਟ੍ਰਾਂਸਫਰ (1656.91 MiB/sec)

ਥਰੋਪੁਟ:
ਘਟਨਾਵਾਂ/s (eps): 1696677.1017
ਸਮਾਂ ਬੀਤਿਆ: 30.0001s
ਸਮਾਗਮਾਂ ਦੀ ਕੁੱਲ ਗਿਣਤੀ: 50900446

ਲੇਟੈਂਸੀ (ms):
ਮਿੰਟ: 0.00
ਔਸਤ: 0.00
ਅਧਿਕਤਮ: 24.01
95ਵਾਂ ਪ੍ਰਤੀਸ਼ਤ: 0.00
ਜੋੜ: 39106.74

ਧਾਗੇ ਨਿਰਪੱਖਤਾ:
ਇਵੈਂਟਸ (ਔਸਤ/stddev): 12725111.5000/137775.15
ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਟਾਈਮ (ਔਸਤ/stddev): 9.7767/0.10

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=ਰਾਈਟ ਮੈਮੋਰੀ ਰਨ
sysbench 1.1.0-18a9f86 (ਬੰਡਲਡ LuaJIT 2.1.0-beta3 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ)
ਹੇਠ ਲਿਖੀਆਂ ਚੋਣਾਂ ਨਾਲ ਟੈਸਟ ਚਲਾਉਣਾ:
ਥ੍ਰੈੱਡਾਂ ਦੀ ਗਿਣਤੀ: 4
ਮੌਜੂਦਾ ਸਮੇਂ ਤੋਂ ਬੇਤਰਤੀਬ ਨੰਬਰ ਜਨਰੇਟਰ ਸ਼ੁਰੂ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

ਹੇਠਾਂ ਦਿੱਤੇ ਵਿਕਲਪਾਂ ਨਾਲ ਮੈਮੋਰੀ ਸਪੀਡ ਟੈਸਟ ਚੱਲ ਰਿਹਾ ਹੈ:
ਬਲਾਕ ਦਾ ਆਕਾਰ: 1KiB
ਕੁੱਲ ਆਕਾਰ: 102400MiB
ਕਾਰਵਾਈ: ਲਿਖੋ
ਸਕੋਪ: ਗਲੋਬਲ

ਵਰਕਰ ਥ੍ਰੈਡ ਸ਼ੁਰੂ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ...

ਧਾਗੇ ਸ਼ੁਰੂ!

ਕੁੱਲ ਸੰਚਾਲਨ: 35910413 (1197008.62 ਪ੍ਰਤੀ ਸਕਿੰਟ)

35068.76 MiB ਟ੍ਰਾਂਸਫਰ (1168.95 MiB/sec)

ਥਰੋਪੁਟ:
ਘਟਨਾਵਾਂ/s (eps): 1197008.6179
ਸਮਾਂ ਬੀਤਿਆ: 30.0001s
ਸਮਾਗਮਾਂ ਦੀ ਕੁੱਲ ਗਿਣਤੀ: 35910413

ਲੇਟੈਂਸੀ (ms):
ਮਿੰਟ: 0.00
ਔਸਤ: 0.00
ਅਧਿਕਤਮ: 16.90
95ਵਾਂ ਪ੍ਰਤੀਸ਼ਤ: 0.00
ਜੋੜ: 43604.83

ਧਾਗੇ ਨਿਰਪੱਖਤਾ:
ਇਵੈਂਟਸ (ਔਸਤ/stddev): 8977603.2500/233905.84
ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਟਾਈਮ (ਔਸਤ/stddev): 10.9012/0.41

sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G ਫਾਈਲਿਓ ਰਨ
sysbench 1.1.0-18a9f86 (ਬੰਡਲਡ LuaJIT 2.1.0-beta3 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ)
ਹੇਠ ਲਿਖੀਆਂ ਚੋਣਾਂ ਨਾਲ ਟੈਸਟ ਚਲਾਉਣਾ:
ਥ੍ਰੈੱਡਾਂ ਦੀ ਗਿਣਤੀ: 4
ਮੌਜੂਦਾ ਸਮੇਂ ਤੋਂ ਬੇਤਰਤੀਬ ਨੰਬਰ ਜਨਰੇਟਰ ਸ਼ੁਰੂ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

ਵਾਧੂ ਫਾਈਲ ਓਪਨ ਫਲੈਗ: (ਕੋਈ ਨਹੀਂ)
128 ਫ਼ਾਈਲਾਂ, ਹਰੇਕ 8MiB
1GiB ਕੁੱਲ ਫ਼ਾਈਲ ਦਾ ਆਕਾਰ
ਬਲਾਕ ਆਕਾਰ 4KiB
IO ਬੇਨਤੀਆਂ ਦੀ ਸੰਖਿਆ: 0
ਸੰਯੁਕਤ ਬੇਤਰਤੀਬੇ IO ਟੈਸਟ ਲਈ ਪੜ੍ਹੋ/ਲਿਖੋ ਅਨੁਪਾਤ: 1.50
ਸਮੇਂ-ਸਮੇਂ 'ਤੇ FSYNC ਸਮਰਥਿਤ, ਹਰੇਕ 100 ਬੇਨਤੀਆਂ 'ਤੇ fsync() ਨੂੰ ਕਾਲ ਕਰਨਾ।
ਟੈਸਟ ਦੇ ਅੰਤ ਵਿੱਚ fsync() ਨੂੰ ਕਾਲ ਕਰਨਾ, ਯੋਗ ਕੀਤਾ ਗਿਆ।
ਸਮਕਾਲੀ I/O ਮੋਡ ਦੀ ਵਰਤੋਂ ਕਰਨਾ
ਬੇਤਰਤੀਬ r/w ਟੈਸਟ ਕਰਨਾ
ਵਰਕਰ ਥ੍ਰੈਡ ਸ਼ੁਰੂ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ...

ਧਾਗੇ ਸ਼ੁਰੂ!

ਥਰੋਪੁਟ:
ਪੜ੍ਹੋ: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
ਲਿਖੋ: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98

ਲੇਟੈਂਸੀ (ms):
ਮਿੰਟ: 0.00
ਔਸਤ: 0.27
ਅਧਿਕਤਮ: 18.01
95ਵਾਂ ਪ੍ਰਤੀਸ਼ਤ: 1.08
ਜੋੜ: 238469.45

ਇਹ ਨੋਟ ਇੱਕ ਵੱਡੀ ਸ਼ੁਰੂਆਤ ਕਰਦਾ ਹੈ

ਬੈਕਅੱਪ ਬਾਰੇ ਲੇਖਾਂ ਦੀ ਲੜੀ

1. ਬੈਕਅੱਪ, ਭਾਗ 1: ਬੈਕਅੱਪ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ, ਤਰੀਕਿਆਂ, ਤਕਨਾਲੋਜੀਆਂ ਦੀ ਸੰਖੇਪ ਜਾਣਕਾਰੀ
2. ਬੈਕਅੱਪ ਭਾਗ 2: rsync-ਅਧਾਰਿਤ ਬੈਕਅੱਪ ਟੂਲਸ ਦੀ ਸਮੀਖਿਆ ਅਤੇ ਜਾਂਚ ਕਰਨਾ
3. ਬੈਕਅੱਪ ਭਾਗ 3: ਡੁਪਲੀਸੀਟੀ, ਡੁਪਲੀਕੇਟੀ, ਡੀਜਾ ਡੁਪ ਦੀ ਸਮੀਖਿਆ ਅਤੇ ਜਾਂਚ ਕਰਨਾ
4. ਬੈਕਅੱਪ ਭਾਗ 4: zbackup, restic, borgbackup ਦੀ ਸਮੀਖਿਆ ਅਤੇ ਜਾਂਚ ਕਰਨਾ
5. ਬੈਕਅੱਪ ਭਾਗ 5: ਲੀਨਕਸ ਲਈ ਬੈਕੂਲਾ ਅਤੇ ਵੀਮ ਬੈਕਅੱਪ ਦੀ ਜਾਂਚ
6. ਬੈਕਅੱਪ ਭਾਗ 6: ਬੈਕਅੱਪ ਟੂਲਸ ਦੀ ਤੁਲਨਾ ਕਰਨਾ
7. ਬੈਕਅੱਪ ਭਾਗ 7: ਸਿੱਟਾ

ਸਰੋਤ: www.habr.com