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

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

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

ਇਹ ਉਹ ਦਿਲਚਸਪ ਚੀਜ਼ਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਅਸੀਂ ਅੱਜ ਗੱਲ ਕਰਾਂਗੇ. ਪਹਿਲਾਂ, ਇਸ ਬਾਰੇ VBR9.5u4 ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕੀਤਾ, ਅਤੇ ਫਿਰ ਦਸਵੇਂ ਸੰਸਕਰਣ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਬਾਰੇ।

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

• ਬਿਨਾਂ ਕਿਸੇ ਪਛਤਾਵੇ ਦੇ। ਲੇਖ ਦੇ ਲੇਖਕ.

ਜਿਵੇਂ ਕਿ ਇਹ ਸੀ

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

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

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

ਪਰ ਇੱਕ ਸੀਲਬੰਦ ਚੇਨ ਦਾ ਅਸਲ ਵਿੱਚ ਕੀ ਮਤਲਬ ਸੀ ਅਤੇ ਅਪਡੇਟ 4 ਵਿੱਚ ਸਮਰੱਥਾ ਸ਼ੂਟਿੰਗ ਰੇਂਜ ਵਿੱਚ ਕੀ ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ?

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

ਰਿਵਰਸ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਇਹ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਹਨ ਜੋ ਓਪਰੇਟਿੰਗ ਵਿੰਡੋ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦੀਆਂ.

ਰੋਲਬੈਕ ਦੇ ਨਾਲ ਫਾਰਵਰਡ ਵਾਧੇ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਇਹ ਸਾਰੇ ਰੋਲਬੈਕ ਹਨ ਅਤੇ .vbk, ਜੇਕਰ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਹੱਦ 'ਤੇ ਕੋਈ ਹੋਰ .vbk ਹੈ

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

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

ਆਓ ਦੇਖੀਏ ਕਿ ਇਹ ਇੱਕ ਉਦਾਹਰਨ ਨਾਲ ਕਿਹੋ ਜਿਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ: ਮੰਨ ਲਓ ਕਿ ਸਾਡੇ ਕੋਲ ਇੱਕ .vbk ਹੈ ਜੋ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਵਿੰਡੋ ਤੋਂ ਬਾਹਰ ਆਇਆ ਹੈ ਅਤੇ ਇੱਕ ਸੀਲਬੰਦ ਚੇਨ ਨਾਲ ਸਬੰਧਤ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਾਡੇ ਕੋਲ ਇਸਨੂੰ ਸਮਰੱਥਾ ਦੀ ਸ਼ੂਟਿੰਗ ਰੇਂਜ ਵਿੱਚ ਲਿਜਾਣ ਦਾ ਪੂਰਾ ਅਧਿਕਾਰ ਹੈ। ਮੂਵ ਕਰਨ ਦੇ ਸਮੇਂ, ਟ੍ਰਾਂਸਫਰ ਕੀਤੀ ਫਾਈਲ ਦੇ ਸਮਰੱਥਾ ਡੈਸ਼ ਅਤੇ ਬਲਾਕਾਂ ਵਿੱਚ ਇੱਕ ਮੈਟਾਡੇਟਾ ਫਾਈਲ ਬਣਾਈ ਜਾਂਦੀ ਹੈ। ਲਿੰਕ-ਪੱਧਰ ਦੀ ਮੈਟਾਡੇਟਾ ਫ਼ਾਈਲ ਦੱਸਦੀ ਹੈ ਕਿ ਸਾਡੀ ਫ਼ਾਈਲ ਵਿੱਚ ਕਿਹੜੀਆਂ ਬਲਾਕਾਂ ਹਨ। ਤਸਵੀਰ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਸਾਡੀ ਪਹਿਲੀ ਫਾਈਲ ਵਿੱਚ ਬਲਾਕ a, b, c ਹਨ ਅਤੇ ਮੈਟਾਡੇਟਾ ਵਿੱਚ ਇਹਨਾਂ ਬਲਾਕਾਂ ਦੇ ਲਿੰਕ ਸ਼ਾਮਲ ਹਨ। ਜਦੋਂ ਸਾਡੇ ਕੋਲ ਦੂਜੀ .vbk ਫਾਈਲ ਹੁੰਦੀ ਹੈ, ਜੋ ਮੂਵ ਕਰਨ ਲਈ ਤਿਆਰ ਹੁੰਦੀ ਹੈ ਅਤੇ ਜਿਸ ਵਿੱਚ ਬਲਾਕ a, b ਅਤੇ d ਹੁੰਦੇ ਹਨ, ਅਸੀਂ ਡੀਹਾਈਡਰੇਸ਼ਨ ਸੂਚਕਾਂਕ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਹਾਂ, ਸਮਝਦੇ ਹਾਂ ਕਿ ਸਿਰਫ ਬਲਾਕ d ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਅਤੇ ਇਸਦੀ ਮੈਟਾਡੇਟਾ ਫਾਈਲ ਵਿੱਚ ਦੋ ਪਿਛਲੇ ਬਲਾਕਾਂ ਅਤੇ ਇੱਕ ਨਵੇਂ ਇੱਕ ਦੇ ਲਿੰਕ ਸ਼ਾਮਲ ਹੋਣਗੇ।

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

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

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

ਇਹ ਕਿੱਦਾਂ ਹੋਇਆ?

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

ਕਾਪੀ ਮੋਡ

ਇਹ ਜ਼ਿਆਦਾਤਰ ਮੌਜੂਦਾ ਤਕਨਾਲੋਜੀਆਂ 'ਤੇ ਅਧਾਰਤ ਹੈ, ਪਰ ਵਰਤੋਂ ਦਾ ਇੱਕ ਬਿਲਕੁਲ ਵੱਖਰਾ ਤਰਕ ਰੱਖਦਾ ਹੈ। 

ਇਸ ਮੋਡ ਦਾ ਉਦੇਸ਼ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ ਸਥਾਨਕ ਹੱਦ 'ਤੇ ਸਥਿਤ ਸਾਰੇ ਡੇਟਾ ਦੀ ਸਮਰੱਥਾ ਡੈਸ਼ ਵਿੱਚ ਇੱਕ ਕਾਪੀ ਹੈ।

ਜੇ ਤੁਸੀਂ ਮੂਵ ਅਤੇ ਕਾਪੀ ਮੋਡ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ:

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

ਨਵੇਂ ਮੋਡ 'ਤੇ ਵਿਚਾਰ ਕਰਦੇ ਹੋਏ, ਮੈਂ ਸਧਾਰਨ ਉਦਾਹਰਣਾਂ ਤੋਂ ਗੁੰਝਲਦਾਰਾਂ ਵੱਲ ਜਾਣ ਦਾ ਪ੍ਰਸਤਾਵ ਕਰਦਾ ਹਾਂ।

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

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

ਸਵਾਲ ਉੱਠਦਾ ਹੈ - ਜੇ ਤੁਸੀਂ UI ਨੂੰ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਇੱਕੋ ਸਮੇਂ ਦੋਵਾਂ ਵਿਕਲਪਾਂ ਨੂੰ ਚੁਣਨ ਦਾ ਮੌਕਾ ਹੈ. ਅਜਿਹਾ ਸੰਯੁਕਤ ਮੋਡ ਕਿਵੇਂ ਕੰਮ ਕਰੇਗਾ?

ਚਲੋ ਇਸਦਾ ਪਤਾ ਲਗਾਓ.

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

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

ਸਾਨੂੰ ਇਸ ਕਾਪੀ ਮੋਡ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ?

ਸਵਾਲ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਦੁਹਰਾਉਣਾ ਹੋਰ ਵੀ ਬਿਹਤਰ ਹੈ: ਇਸਦੀ ਮਦਦ ਨਾਲ ਅਸੀਂ ਕਿਹੜੇ ਖਤਰਿਆਂ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹਾਂ? ਇਹ ਕਿਹੜੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ ਸਾਡੀ ਮਦਦ ਕਰਦਾ ਹੈ?

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

ਇਸ ਲਈ ਆਉ ਸਭ ਤੋਂ ਸਰਲ ਤੋਂ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਤੱਕ, ਸੰਭਾਵਿਤ ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚੋਂ ਲੰਘੀਏ।

ਸਭ ਤੋਂ ਸਰਲ ਬਦਕਿਸਮਤੀ ਜੋ ਸਾਡੇ ਸਿਰ 'ਤੇ ਡਿੱਗ ਸਕਦੀ ਹੈ ਉਹ ਹੈ ਬੈਕਅਪ ਚੇਨ ਦੀਆਂ ਫਾਈਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਅਸਮਰਥਤਾ.

ਇੱਕ ਦੁਖਦਾਈ ਕਹਾਣੀ ਇਹ ਹੈ ਕਿ ਸਾਡੇ SOBR ਰਿਪੋਜ਼ਟਰੀ ਦੀ ਇੱਕ ਹੱਦ ਟੁੱਟ ਗਈ ਹੈ.

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

ਆਓ ਹੁਣ ਹਰੇਕ ਸਥਿਤੀ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਵੇਖੀਏ.

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

ਹੁਣ ਸਥਿਤੀ ਹੋਰ ਗੁੰਝਲਦਾਰ ਹੈ. ਚਲੋ ਇਹ ਮੰਨ ਲਓ ਕਿ ਸਾਡੇ SOBR ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਮੋਡ ਵਿੱਚ ਚੱਲ ਰਹੇ ਦੋ ਐਕਸਟੈਂਟ ਹਨ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਾਡੇ .vbk ਅਤੇ .vib ਉਹਨਾਂ ਉੱਤੇ ਇੱਕ ਅਸਮਾਨ ਪਰਤ ਵਿੱਚ ਫੈਲੇ ਹੋਏ ਹਨ। ਅਤੇ ਸਮੇਂ ਦੇ ਕਿਸੇ ਬਿੰਦੂ 'ਤੇ, ਇੱਕ ਹੱਦ ਅਣਉਪਲਬਧ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਤੁਰੰਤ ਮਸ਼ੀਨ ਨੂੰ ਬਹਾਲ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ, ਜਿਸਦਾ ਡੇਟਾ ਦਾ ਇੱਕ ਹਿੱਸਾ ਇਸ ਹੱਦ 'ਤੇ ਬਿਲਕੁਲ ਸਹੀ ਹੁੰਦਾ ਹੈ।

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

ਇਸ ਕੇਸ ਦਾ ਇੱਕ ਉਪ-ਕਿਸਮ ਇਹ ਹੈ ਕਿ ਸਮੁੱਚੀ SOBR ਰਿਪੋਜ਼ਟਰੀ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੋ ਗਈ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸਾਡੇ ਕੋਲ ਸਥਾਨਕ ਸਟੋਰੇਜ ਤੋਂ ਕਾਪੀ ਕਰਨ ਲਈ ਕੁਝ ਨਹੀਂ ਹੈ, ਅਤੇ ਸਾਰੇ ਬਲਾਕ ਕਲਾਉਡ ਤੋਂ ਡਾਊਨਲੋਡ ਕੀਤੇ ਗਏ ਹਨ.

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

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

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

ਇਹ ਸ਼ਾਇਦ ਕਾਪੀ ਮੋਡ ਬਾਰੇ ਹੈ ਅਤੇ ਅਸੀਂ ਅੱਗੇ ਵਧਦੇ ਹਾਂ

ਸੀਲਬੰਦ ਮੋਡ

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

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

ਇਸ ਅਨੁਸਾਰ, ਓਪਰੇਸ਼ਨ ਦਾ ਸਿਧਾਂਤ ਕਾਫ਼ੀ ਸਰਲ ਹੈ: ਸਾਰੇ ਲਿਖਣ ਕਾਰਜਾਂ (ਨਵੇਂ ਡੇਟਾ ਦੀ ਦਿੱਖ), ਪੜ੍ਹਨਾ (ਬਹਾਲ ਕਰਨਾ) ਅਤੇ ਮਿਟਾਉਣਾ (ਬਹਾਲੀ) ਨੂੰ ਛੱਡਣਾ ਜ਼ਰੂਰੀ ਹੈ.

ਦੋਵੇਂ ਮੋਡ ਇੱਕੋ ਸਮੇਂ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਪਰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ ਕਿ ਰੱਖ-ਰਖਾਅ ਨੂੰ ਉੱਚ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।

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

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

ਰਿਵਰਸ ਇਨਕਰੀਮੈਂਟਲ ਨਾਲ ਚੀਜ਼ਾਂ ਸਰਲ ਹੁੰਦੀਆਂ ਹਨ। ਇਸ ਵਿੱਚ, ਸਭ ਤੋਂ ਪੁਰਾਣੇ ਬਿੰਦੂ ਕਿਸੇ ਵੀ ਚੀਜ਼ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਦੇ ਹਨ ਅਤੇ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਮਿਟਾਏ ਜਾ ਸਕਦੇ ਹਨ. ਇਸ ਲਈ, ਜਿਵੇਂ ਹੀ ਇੱਕ ਨਵੀਂ ਹੱਦ 'ਤੇ ਇੱਕ ਨਵਾਂ .vbk ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ, ਪੁਰਾਣੇ .vrbs ਇੱਕ ਇੱਕ ਕਰਕੇ ਮਿਟਾ ਦਿੱਤੇ ਜਾਣਗੇ।

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

ਸਮਰੱਥਾ ਸ਼ੂਟਿੰਗ ਰੇਂਜ ਦੇ ਨਾਲ ਚੀਜ਼ਾਂ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਹਨ।

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

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

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

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

ਜੋ ਕਿ ਅਸਲ ਵਿੱਚ ਇਸ ਨੂੰ ਕਰਨ ਲਈ ਹੈ, ਜੋ ਕਿ ਸਭ ਹੈ. ਤਾਂ ਆਓ ਸਭ ਤੋਂ ਹਾਰਡਕੋਰ ਵਿਸ਼ੇਸ਼ਤਾ ਵੱਲ ਵਧੀਏ -

ਅਚੱਲਤਾ

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

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

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

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

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

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

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

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

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

ਅਤੇ, ਆਮ ਵਾਂਗ, ਕੁਝ ਉਪਯੋਗੀ ਲਿੰਕ:

• 'ਤੇ ਬਲਾਕ ਜਨਰੇਸ਼ਨ ਹਰ ਵੇਰਵੇ ਵਿੱਚ.
• ਬਾਰੇ ਸਾਰੀ ਜਾਣਕਾਰੀ ਵੀਮ ਬੈਕਅੱਪ ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ 10 ਇਸ ਦੇ ਵਧੀਆ 'ਤੇ
• О ਸਮਰੱਥਾ ਟੀਅਰ ਵੇਰਵੇ ਵਿੱਚ

ਸਰੋਤ: www.habr.com