ਜਦੋਂ ਤੁਹਾਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਬੈਕਅੱਪ ਅਕਸਰ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ। ਜਾਣੋ ਕਿ ਰੀਸਟੋਰ ਟੈਸਟਿੰਗ ਅਤੇ ਡਿਸਾਸਟਰ ਰਿਕਵਰੀ ਕਿਉਂ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਸਲੀ ਖਤਰੇ ਕੀ ਹਨ, ਅਤੇ ਇਕ ਐਸਾ ਰੁਟੀਨ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਵੇ ਜੋ ਸਮਝਦਾਰ ਹੋਵੇ।
ਟੀਮਾਂ ਅਕਸਰ ਕਹਿੰਦੀਆਂ ਹਨ “ਅਸੀਂ ਬੈਕਅੱਪ ਰੱਖਦੇ ਹਾਂ,” ਪਰ ਅਕਸਰ ਉਹ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਅਮਲਾਂ ਨੂੰ ਮਿਲਾ ਦੇਂਦੀਆਂ ਹਨ। ਇਹ ਲੇਖ ਉੱਦੇ ਰੂਪ ਵਿੱਚ ਉਹਨਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਹਰ ਇੱਕ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੁੰਦਾ ਹੈ।
ਬੈਕਅੱਪ ਤੁਹਾਡੇ ਡਾਟਾ ਦੀਆਂ ਵਾਧੂ ਕਾਪੀਆਂ ਹਨ (ਅਕਸਰ ਪੂਰੇ ਸਿਸਟਮ ਵੀ) ਜੋ ਕਿਸੇ ਹੋਰ ਥਾਂ ਸਟੋਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ—ਕਲਾਉਡ ਸਟੋਰੇਜ, ਹੋਰ ਸਰਵਰ, ਜਾਂ ਆਫਲਾਈਨ ਡਿਵਾਈਸ। ਇੱਕ ਬੈਕਅੱਪ ਰਣਨੀਤੀ ਮੁੱਖ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ: ਕੀ ਬੈਕਅੱਪ ਹੁੰਦਾ ਹੈ, ਕਿੰਨੀ ਵਾਰ, ਕਿੱਥੇ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕਿੰਨੀ ਦੇਰ ਤੱਕ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ।
ਰੀਸਟੋਰ ਟੈਸਟਿੰਗ ਉਹ ਆਦਤ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਬੈਕਅੱਪਾਂ ਤੋਂ ਡਾਟਾ ਜਾਂ ਸਿਸਟਮ ਵਾਪਸ ਲਿਆਉਂਦੇ ਹੋ। ਇਹ “ਅਸੀਂ ਸੋਚਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਰੀਸਟੋਰ ਕਰ ਸਕਦੇ ਹਾਂ” ਅਤੇ “ਅਸੀਂ ਪਿਛਲੇ ਹਫਤੇ ਰੀਸਟੋਰ ਕੀਤਾ ਅਤੇ ਉਹ ਚੱਲਿਆ” ਦੇ ਵਿਚਕਾਰ ਫਰਕ ਹੈ। ਟੈਸਟਿੰਗ ਇਹ ਵੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਆਪਣੇ RTO ਅਤੇ RPO ਟਾਰਗੇਟ ਮਿਲਾ ਸਕਦੇ ਹੋ:
ਡਿਸਾਸਟਰ ਰਿਕਵਰੀ ਯੋਜਨਾ ਵਪਾਰ ਨੂੰ ਗੰਭੀਰ ਘਟਨਾ ਤੋਂ ਬਾਅਦ ਮੁੜ ਚਲਾਉਣ ਲਈ ਸਹਿਮਤ ਖੇਡ-ਯੋਜਨਾ ਹੈ। ਇਹ ਰੋਲ, ਤਰਜੀحات, ਨਿਰਭਰਤਾਵਾਂ, ਐਕਸੇਸ, ਅਤੇ ਸੰਚਾਰ ਕਵਰ ਕਰਦੀ ਹੈ—ਸਿਰਫ ਬੈਕਅੱਪਾਂ ਦਾ ਥਾਂ ਨਹੀਂ।
“ਜ਼ਿਆਦਾ ਦੇਰ” ਉਹ ਹੈ ਜਦੋਂ ਪਹਿਲੀ ਅਸਲੀ ਟੈਸਟ ਕਿਸੇ ਆਊਟੇਜ, ਰੈਨਸਮਵੇਅਰ ਨੋਟ, ਜਾਂ ਗਲਤੀ ਨਾਲ ਮਿਟਾਏ ਜਾਣ ਵਾਲੇ ਡਾਟਾ ਦੌਰਾਨ ਹੁੰਦੀ ਹੈ—ਜਦੋਂ ਤਣਾਅ ਉੱਚਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸਮਾਂ ਮਹਿੰਗਾ ਹੁੰਦਾ ਹੈ।
ਇਹ ਲੇਖ ਛੋਟੀ ਅਤੇ ਮੱਧਮ-ਸਾਈਜ਼ ਟੀਮਾਂ ਲਈ ਪ੍ਰਯੋਗਯੋਗ ਕਦਮਾਂ 'ਤੇ ਧਿਆਨ ਦੇਂਦਾ ਹੈ। ਮਕਸਦ ਸਧਾਰਨ ਹੈ: ਘੱਟ ਹਨੇਰੇ, ਤੇਜ਼ ਰਿਕਵਰੀ, ਅਤੇ ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਮਾਲਕੀ ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੋਵੇ।
ਜਿਆਦਾਤਰ ਕੰਪਨੀਆਂ ਬੈਕਅੱਪ ਨੂੰ ਸਿੱਧਾ ਅਣਡਿੱਠਾ ਨਹੀਂ ਕਰਦੀਆਂ। ਉਹ ਇਕ ਬੈਕਅੱਪ ਟੂਲ ਲੈਂਦੀਆਂ ਹਨ, ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ “ਸਫਲ” ਨੌਕਰੀਆਂ ਵੇਖਦੀਆਂ ਹਨ, ਅਤੇ ਇਹ ਮੰਨ ਲੈਂਦੀਆਂ ਹਨ ਕਿ ਉਹ ਕਵਰ ਹਨ। ਪਰ ਅਚਾਨਕਤਾ ਬਾਅਦ ਆਉਂਦੀ ਹੈ: ਪਹਿਲਾ ਅਸਲੀ ਰੀਸਟੋਰ ਆਊਟੇਜ, ਰੈਨਸਮਵੇਅਰ ਘਟਨਾ, ਜਾਂ ਇਕ ਤੁਰਤ “ਸਾਨੂੰ ਪਿਛਲੇ ਮਹੀਨੇ ਦੀ ਫਾਈਲ ਚਾਹੀਦੀ ਹੈ” ਦੀ ਬੀਚ ਹੋਦਾ ਹੈ—ਅਤੇ ਇਹੀ ਸਮਾਂ ਹੈ ਜਦੋਂ ਗੈਪ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ।
ਇੱਕ ਬੈਕਅੱਪ ਪੂਰਾ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਬੇਕਾਰ ਹੋ ਸਕਦਾ ਹੈ। ਆਮ ਕਾਰਨਾਂ ਵਿੱਚ ਸਧਾਰਨ ਗਲਤੀਆਂ ਸ਼ਾਮਲ ਹਨ: ਐਪਲੀ케ਸ਼ਨ ਡਾਟਾ ਗਾਇਬ, ਆਰਕਾਇਵ ਖਰਾਬ ਹੋਣਾ, ਇੰਕ੍ਰਿਪਸ਼ਨ ਕੀਜ਼ ਗਲ ਥਾਂ 'ਤੇ ਰੱਖੀਆਂ ਜਾਣਾ, ਜਾਂ ਰੀਟੇਨਸ਼ਨ ਨਿਯਮਾਂ ਨੇ ਉਹੀ ਵਰਜਨ ਮਿਟਾ ਦਿੱਤਾ ਜੋ ਤੁਹਾਨੂੰ ਚਾਹੀਦਾ ਸੀ।
ਜਦੋਂ ਡਾਟਾ ਮੌਜੂਦ ਹੋਵੇ, ਤਦ ਵੀ ਰੀਸਟੋਰ ਅਸਫਲ ਹੋ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਕਿਸੇ ਨੇ ਕਦਮਾਂ ਦੀ ਅਭਿਆਸ ਨਹੀਂ ਕੀਤਾ, ਸਹੁਲਤਾਂ ਬਦਲ ਗਈਆਂ, ਜਾਂ ਰੀਸਟੋਰ ਉਮੀਦ ਤੋਂ ਕਾਫੀ ਲੰਮਾ ਲੈਂਦਾ ਹੈ। “ਅਸੀਂ ਬੈਕਅੱਪ ਰੱਖਦੇ ਹਾਂ” ਖਾਮੋਸ਼ੀ ਨਾਲ “ਸਾਡੇ ਕੋਲ ਕਿਹੜੇ ਬੈਕਅੱਪ ਫਾਈਲਾਂ ਹਨ, ਕਿਸੇ ਥਾਂ” ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ।
ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਕੋਲ DR ਯੋਜਨਾ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਆਡਿਟ ਜਾਂ ਬੀਮਾ ਲਈ ਲੋੜ ਸੀ। ਪਰ ਦਬਾਅ ਹਾਲਤ ਵਿੱਚ, ਇੱਕ ਦਸਤਾਵੇਜ਼ ਇੱਕ ਯੋਜਨਾ ਨਹੀਂ ਹੁੰਦਾ—ਅਮਲ ਹੈ। ਜੇ ਰਨਬੁੱਕ ਕੁਝ ਲੋਕਾਂ ਦੀ ਯਾਦ ਤੇ ਨਿਰਭਰ ਹੈ, ਕਿਸੇ ਖਾਸ ਲੈਪਟਾਪ ਤੇ ਨਿਰਭਰ ਹੈ, ਜਾਂ ਉਹ ਪ੍ਰਣਾਲੀਆਂ ਜੋ ਡਾਊਨ ਹਨ ਉਨ੍ਹਾਂ ਤੱਕ ਪਹੁੰਚ ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ ਇਹ ਗੰਦੇ ਹਾਲਾਂ ਵਿੱਚ ਕੰਮ ਨਹੀਂ ਕਰੇਗੀ।
ਤਿੰਨ ਹਿੱਸੇਦਾਰਾਂ ਤੋਂ ਪੁੱਛੋ ਕਿ ਰਿਕਵਰੀ ਟਾਰਗੇਟ ਕੀ ਹਨ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਤਿੰਨ ਵੱਖਰੇ ਜਵਾਬ ਮਿਲਣਗੇ—ਜਾਂ ਕੋਈ ਨਹੀਂ। ਜੇ RTO ਅਤੇ RPO ਪਰिभਾਸ਼ਿਤ ਤੇ ਸਹਿਮਤ ਨਹੀਂ ਹਨ, ਉਹ "ਜਲਦੀ ਤੋਂ ਜਲਦੀ" 'ਤੇ ਡਿਫੌਲਟ ਕਰ ਲੈਂਦੇ ਹਨ, ਜੋ ਕਿ ਟਾਰਗੇਟ ਨਹੀਂ ਹੈ।
ਮਾਲਕੀ ਹੋਰ ਇੱਕ ਚੁਪ ਪ੍ਰਾਪਤਿ ਬਿੰਦੂ ਹੈ। ਕੀ ਰਿਕਵਰੀ IT, ਸਿਕਿਊਰਿਟੀ, ਜਾਂ ਓਪਰੇਸ਼ਨ ਦੁਆਰਾ ਚਲਾਈ ਜਾਂਦੀ ਹੈ? ਜੇ ਇਹ ਸਪਸ਼ਟ ਨਹੀਂ, ਤਾਂ ਇਕ ਘੰਟੇ ਦਾ ਸਮਾਂ ਹੱਥ-ਬਦਲੀ ਵਾਦ-ਵਿਵਾਦ ਬਣ ਕੇ ਬੀਤ ਜਾਂਦਾ ਹੈ ਬਜਾਏ ਰਿਕਵਰੀ ਦੇ।
ਬੈਕਅੱਪ, ਰੀਸਟੋਰ ਟੈਸਟਿੰਗ, ਅਤੇ DR ਇਨ੍ਹਾਂ “ਚੁੱਪ ਜੋਖਮਾਂ” ਦੇ ਕੈਟੇਗਰੀ ਵਿੱਚ ਆਉਂਦੇ ਹਨ: ਜਦੋਂ ਉਹ ਕੰਮ ਕਰਦੇ ਹਨ, ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ। ਕੋਈ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਜਿੱਤ ਨਹੀਂ, ਕੋਈ ਤੁਰੰਤ ਯੂਜ਼ਰ-ਆਧਾਰਿਤ ਸੁਧਾਰ ਨਹੀਂ, ਅਤੇ ਕੋਈ ਤੁਰੰਤ ਆਮਦਨ ਪ੍ਰਭਾਵ ਨਹੀਂ। ਇਹਨਾਂ ਨੂੰ ਟਾਲਣਾ ਆਸਾਨ ਬਣ ਜਾਂਦਾ ਹੈ—ਭਾਵੇਂ ਉਹ ਸੰਗਠਨ ਭਰੋਸੇਯੋਗਤਾ ਲਈ ਸੋਚਦੇ ਹੋਣ।
ਕੁਝ ਪ੍ਰਚਲਿਤ ਮਾਨਸਿਕ ਛੂਟਾਂ ਟੀਮਾਂ ਨੂੰ ਨਿਰੀਤੀ ਕਰਨ ਵੱਲ ਧੱਕ ਦਿੰਦੀਆਂ ਹਨ:
DR ਤਿਆਰੀ ਜ਼ਿਆਦਾਤਰ ਤਿਆਰੀ ਹੈ: ਦਸਤਾਵੇਜ਼, ਐਕਸੇਸ ਚੈੱਕ, ਰਨਬੁੱਕ, ਅਤੇ ਟੈਸਟ ਰੀਸਟੋਰ। ਇਹ ਉਨ੍ਹਾਂ ਕੰਮਾਂ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਦੇ ਨਤੀਜੇ ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਹੁੰਦੇ ਹਨ, ਜਿਵੇਂ ਪ੍ਰਦਰਸ਼ਨ ਸੁਧਾਰ ਜਾਂ ਗਾਹਕ ਦੀਆਂ ਬੇਨਤੀਆਂ। ਇੱਥੇ ਤੱਕ ਕਿ ਉਹ ਨੇਤਾ ਜੋ ਬੈਕਅੱਪ ਖਰਚ ਨੂੰ मंजੂਰ ਕਰਦੇ ਹਨ, ਅਣਜਾਣੀ ਤੌਰ 'ਤੇ ਟੈਸਟਿੰਗ ਅਤੇ ਡ੍ਰਿਲਜ਼ ਨੂੰ "প্রਕਿਰਿਆ" ਵਾਂਗ ਸੰਭਾਲ ਸਕਦੇ ਹਨ, ਨਾ ਕਿ ਪ੍ਰੋਡਕਸ਼ਨ-ਗਰੇਡ ਕੰਮ ਵਾਂਗ।
ਨਤੀਜਾ ਇਕ ਖਤਰਨਾਕ ਗੈਪ ਹੈ: ਧਾਰਣਾ ਦੇ ਆਧਾਰ 'ਤੇ ਆਤਮ-ਭਰੋਸਾ ਨਾ ਕਿ ਸਬੂਤ 'ਤੇ। ਅਤੇ ਕਿਉਂਕਿ ਅਕਸਰ ਫੇਲ੍ਹ ਸਿਰਫ ਅਸਲੀ ਆਊਟੇਜ ਦੌਰਾਨ ਹੀ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਸੰਗਠਨ ਸੱਚਾਈ ਸਿਖਣ ਲਈ ਸਭ ਤੋਂ ਵੱਡੇ ਸਮੇਂ 'ਤੇ ਹੋਰ ਨਹੀਂ ਸਹੀ ਸਮਾਂ ਹੁੰਦਾ।
ਜ਼ਿਆਦਾਤਰ ਬੈਕਅੱਪ ਅਤੇ DR ਫੇਲ੍ਹ “ਪਰਵਾਹ ਨਾ ਕਰਨ” ਕਾਰਨ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਇਸ ਕਰਕੇ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਛੋਟੀ-ਛੋਟੀ ਓਪਰੇਸ਼ਨਲ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਇਕੱਤਰ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਜਦ ਤੱਕ ਕੋਈ ਯਕੀਨ ਨਾਲ ਨਹੀਂ ਕਹਿ ਸਕਦਾ, “ਹਾਂ, ਅਸੀਂ ਇਹ ਰੀਸਟੋਰ ਕਰ ਸਕਦੇ ਹਾਂ।” ਕੰਮ ਟਾਲਿਆ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਆਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਭੁੱਲਿਆ ਜਾਂਦਾ ਹੈ—ਜਦ ਤੱਕ ਉਹ ਦਿਨ ਨਹੀਂ ਆਉਂਦਾ ਜਦੋਂ ਇਹ ਮਾਮਲਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ।
ਬੈਕਅੱਪ ਦੀ ਸੀਮਾ ਅਕਸਰ ਸਪਸ਼ਟ ਤੋਂ ਨਿਰਲਾ ਹੋ ਜਾਂਦੀ ਹੈ। ਕੀ ਲੈਪਟਾਪ ਸ਼ਾਮਲ ਹਨ, ਜਾਂ ਸਿਰਫ ਸਰਵਰ? SaaS ਡਾਟਾ, ਡੇਟਾਬੇਸ, ਸ਼ੇਅਰਡ ਡਰਾਈਵ, ਅਤੇ ਉਹ ਇਕ ਫਾਈਲ-ਸ਼ੇਅਰ ਜੋ ਹਰ ਕੋਈ ਅਜੇ ਵੀ ਵਰਤਦਾ ਹੈ—ਇਹ ਸਭ ਕਿਵੇਂ ਰੱਖੇ ਜਾਂਦੇ ਹਨ? ਜੇ ਜਵਾਬ "ਇਹਨੂੰ ਨਿਰਭਰ ਕਰਦਾ ਹੈ", ਤਾਂ ਤੁਸੀਂ ਦੇਰ ਨਾਲ ਪਤਾ ਲਾਉਗੇ ਕਿ ਅਹੰਕਾਰਪੂਰਣ ਡਾਟਾ ਕਦੇ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ।
ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ ਮਦਦ ਕਰਦਾ ਹੈ: ਜੇ ਕਾਰੋਬਾਰ ਕੱਲ੍ਹ ਨੂੰ ਇਸਦੀ ਘਾਟ ਮਹਿਸੂਸ ਕਰੇਗਾ, ਤਾਂ ਇਸ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਬੈਕਅੱਪ ਫੈਸਲਾ ਲਾਜ਼ਮੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਰੱਖਿਆ, ਆਧੇ-ਰੱਖਿਆ, ਜਾਂ ਜਾਣ-ਬੁਝ ਕੇ ਬਾਹਰ ਰੱਖਿਆ)।
ਕਈ ਸੰਗਠਨ ਅੰਤ ਵਿੱਚ ਮਹਰੂਮ ਹੋ ਜਾਂਦੇ ਹਨ ਕਈ ਬੈਕਅੱਪ ਸਿਸਟਮਾਂ ਨਾਲ—ਇਕ VM ਲਈ, ਇਕ ਐਂਡਪੌਇੰਟ ਲਈ, ਇਕ SaaS ਲਈ, ਹੋਰ ਡੇਟਾਬੇਸ ਲਈ। ਹਰ ਇਕ ਦਾ ਆਪਣਾ ਡੈਸ਼ਬੋਰਡ, ਅਲਰਟ, ਅਤੇ “ਸਫਲਤਾ” ਦੀ ਪੜਤਾਲ ਹੁੰਦੀ ਹੈ। ਨਤੀਜਾ ਇਕ ਇਕਲੌਤਾ ਦਰਸ਼ਨ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਰੀਸਟੋਰ ਅਸਲ ਵਿੱਚ ਸੰਭਵ ਹਨ।
ਹੋਰ ਖਰਾਬ: “ਬੈਕਅੱਪ ਸਫਲ ਹੋਇਆ” ਮੈਟਰਿਕ ਬਣ ਜਾਂਦਾ ਹੈ, ਨਾ ਕਿ “ਰੀਸਟੋਰ ਤਸਦੀਕ ਹੋਇਆ।” ਜੇ ਅਲਰਟ ਸ਼ੋਰ ਕਰਦੇ ਹਨ, ਲੋਕ ਉਹਨਾਂ ਨੂੰ ਅਣਦੇਖਾ ਕਰਨਾ ਸਿਖ ਲੈਂਦੇ ਹਨ, ਅਤੇ ਛੋਟੀ ਫੇਲ੍ਹ ਚੁਪ ਚਾਪ ਇਕੱਠੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
ਰੀਸਟੋਰ ਅਕਸਰ ਉਹਨਾਂ ਖਾਤਿਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਹੁਣ ਕੰਮ ਨਹੀਂ ਕਰਦੀਆਂ, ਪਰਮਿਸ਼ਨ ਬਦਲੇ ਗਏ, ਜਾਂ MFA ਵਰਕਫ্লੋਜ਼ ਜੋ ਕਿਸੇ ਘਟਨਾ ਦੌਰਾਨ ਟੈਸਟ ਨਹੀਂ ਕੀਤੀਆਂ ਗਈਆਂ। ਇਸ ਵਿੱਚ ਮਿਸਿੰਗ ਇੰਕ੍ਰਿਪਸ਼ਨ ਕੀਜ਼, ਪੁਰਾਣੇ ਪਾਸਵਰਡ, ਜਾਂ ਰਨਬੁੱਕ ਜੋ ਕਿਸੇ ਪੁਰਾਣੇ ਵਿਕੀ ਵਿੱਚ ਹਨ ਸ਼ਾਮਲ ਹਨ, ਅਤੇ ਰੀਸਟੋਰ ਇੱਕ ਖੋਜੀ ਮੁਹਿੰਮ ਬਣ ਜਾਂਦੇ ਹਨ।
ਘਰਮੀ ਘਟਾਓ: ਸੀਮਾ ਦਸਤਾਵੇਜ਼ ਕਰੋ, ਰਿਪੋਰਟਿੰਗ ਇਕੱਠਾ ਕਰੋ, ਅਤੇ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ/ਕੀਜ ਅਤੇ ਰਨਬੁੱਕ ਅਪ-ਟੂ-ਡੇਟ ਰੱਖੋ। ਜਦੋਂ ਰੀਸਟੋਰ ਰੁਟੀਨ ਬਣ ਜਾਂਦੀ ਹੈ, ਤਿਆਰੀ ਸੁਧਰਦੀ ਹੈ—ਨਾ ਕਿ ਇਹ ਕੋਈ ਵਿਸ਼ੇਸ਼ ਘਟਨਾ ਹੋਵੇ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਰੀਸਟੋਰ ਟੈਸਟਿੰਗ ਇਸ ਲਈ ਨਹੀਂ ਛੱਡਦੀਆਂ ਕਿ ਉਹ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦੀਆਂ। ਉਹ ਇਸ ਲਈ ਛੱਡਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਇਹ ਅਨੀਕਸਾਨੀ ਹੈ ਤੇ ਉਹ ਤਰੀਕੇ ਜੋ ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਨਹੀਂ ਦਿਖਦੇ—ਜਦ ਤੱਕ ਉਹ ਦਿਨ ਨਹੀਂ ਆਉਂਦਾ।
ਅਸਲੀ ਰੀਸਟੋਰ ਟੈਸਟ ਯੋਜਨਾ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ: ਸਹੀ ਡਾਟਾ ਸੈੱਟ ਚੁਣਨਾ, ਕਮਪਿਊਟ ਰਿਜ਼ਰਵ ਕਰਨਾ, ਐਪ ਮਾਲਕਾਂ ਨਾਲ ਸਹਯੋਗ, ਅਤੇ ਨਤੀਜੇ ਨੂੰ ਯੂਜ਼ਏਬਲ ਸਾਬਤ ਕਰਨਾ—ਸਿਰਫ ਫਾਈਲਾਂ ਦੀ ਕਾਪੀ ਹੋਣ ਨਹੀਂ।
ਜੇ ਟੈਸਟਿੰਗ ਠੀਕ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ, ਤਾਂ ਇਹ ਪ੍ਰੋਡਕਸ਼ਨ ਨੂੰ ਬੱਖੇੜਾ ਕਰ ਸਕਦੀ ਹੈ (ਵੱਧਲੋਡ, ਫਾਈਲਾਂ ਲਾਕ ਹੋਣਾ, ਅਣ ਉਮੀਦਤ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਬਦਲਾਅ)। ਇਕ ਵੱਖਰਾ ਮਾਹੌਲ ਵਿੱਚ ਟੈਸਟ ਕਰਨਾ ਵੀ ਸੈਟਅੱਪ ਕਰਨ ਅਤੇ ਨਿਭਾਉਣ ਲਈ ਸਮਾਂ ਲੈਂਦਾ ਹੈ। ਇਸ ਲਈ ਇਹ ਫੀਚਰ ਕੰਮ, ਅਪਗਰੇਡ, ਅਤੇ ਦੈਨਿਕ ਐਗਜ਼ਿਆਸ ਜਾਂਚ ਤੋਂ ਪਿੱਛੇ ਰਹਿ ਜਾਂਦਾ ਹੈ।
ਰੀਸਟੋਰ ਟੈਸਟਿੰਗ ਕੋਲ ਇਕ ਅਸੁਖਦ ਗੁਣ ਹੈ: ਇਹ ਬੁਰੀ ਖ਼ਬਰ ਲਿਆ ਸਕਦੀ ਹੈ।
ਅਸਫਲ ਰੀਸਟੋਰ ਦਾ ਮਤਲਬ ਤੁਰੰਤ ਫਾਲੋਅਪ ਕੰਮ ਹੈ—ਪਰਮਿਸ਼ਨ ਠੀਕ ਕਰਨਾ, ਮਿਸਿੰਗ ਇੰਕ੍ਰਿਪਸ਼ਨ ਕੀਜ਼, ਟੁੱਟੇ ਬੈਕਅੱਪ ਚੇਨ, ਬੇਦਸਤਾਵੇਜ਼ ਨਿਰਭਰਤਾਵਾਂ, ਜਾਂ "ਅਸੀਂ ਡਾਟਾ ਬੈਕਅੱਪ ਕੀਤਾ ਪਰ ਉਸੇ ਸਿਸਟਮ ਨੂੰ ਨਹੀਂ ਜਿੱਦਾ ਉਪਯੋਗੀ ਬਣਾਉਂਦਾ।" ਕਈ ਟੀਮਾਂ ਟੈਸਟਿੰਗ ਤੋਂ ਬਚਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਪਹਿਲਾਂ ਹੀ ਵੱਧ ਭਾਰੇ ਹਨ ਅਤੇ ਨਵੇਂ ਉੱਚ-ਪ੍ਰਾਥਮਿਕਤਾ ਮੁੱਦੇ ਨਹੀਂ ਖੋਲ੍ਹਣਾ ਚਾਹੁੰਦੀਆਂ।
ਸੰਗਠਨ ਅਕਸਰ "ਬੈਕਅੱਪ ਨੌਕਰੀ ਸਫਲ" ਨੂੰ ਟਰੈਕ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ ਮਾਪਣਾ ਅਤੇ ਰਿਪੋਰਟ ਕਰਨਾ ਆਸਾਨ ਹੈ। ਪਰ "ਰੀਸਟੋਰ ਕੰਮਿਆਬ" ਹੋਣਾ ਇੱਕ ਮਨੁੱਖ-ਦਿੱਸਣ ਵਾਲਾ ਨਤੀਜਾ ਮੰਗਦਾ ਹੈ: ਕੀ ਐਪਲੀਕੇਸ਼ਨ ਸਟਾਰਟ ਹੋ ਸਕਦੀ ਹੈ, ਯੂਜ਼ਰ ਲੌਗਿਨ ਕਰ ਸਕਦੇ ਹਨ, ਡਾਟਾ ਤੁਹਾਡੇ RTO ਅਤੇ RPO ਲਈ ਕਾਫੀ ਤਾਜ਼ਾ ਹੈ?
ਜਦੋਂ ਲੀਡਰਸ਼ਿਪ ਹਰੇ ਰੰਗ ਦੇ ਬੈਕਅੱਪ ਰਿਪੋਰਟ ਵੇਖਦੀ ਹੈ, ਰੀਸਟੋਰ ਟੈਸਟਿੰਗ ਓਪਸ਼ਨਲ ਲੱਗਦੀ ਹੈ—ਜਦ ਤੱਕ ਕੋਈ ਘਟਨਾ ਇਸ ਸਵਾਲ ਨੂੰ ਮਜ਼ਬੂਰ ਨਾ ਕਰ ਦੇਵੇ।
ਇੱਕ ਵਾਰੀ ਹੋਈ ਰੀਸਟੋਰ ਟੈਸਟ ਤੇਜ਼ੀ ਨਾਲ ਬੁਜ਼ੁਰਗ ਹੋ ਜਾਂਦੀ ਹੈ। ਸਿਸਟਮ ਬਦਲ ਜਾਂਦੇ ਹਨ, ਟੀਮਾਂ ਬਦਲਦੀਆਂ ਹਨ, ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਰੋਟੇਟ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਨਵੀਆਂ ਨਿਰਭਰਤਾਵਾਂ ਆ ਜਾਂਦੀਆਂ ਹਨ।
ਜਦੋਂ ਰੀਸਟੋਰ ਟੈਸਟਿੰਗ ਪੈਚਿੰਗ ਜਾਂ ਬਿਲਿੰਗ ਜਿਹੇ ਨਿਯਮਤ ਕੰਮਾਂ ਵਾਂਗ ਤਹਿ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ—ਛੋਟੀ, ਅਕਸਰ, ਉਮੀਦ ਕੀਤੀ ਜਾਣੀ—ਤਦ ਇਹ ਵੱਡੀ ਘਟਨਾ ਬਣ ਜਾਂਦੀ ਹੈ। ਵੱਡੀਆਂ ਘਟਨਾਵਾਂ ਨੂੰ ਟਾਲਣਾ ਅਸਾਨ ਹੁੰਦਾ ਹੈ, ਇਸੀ ਲਈ ਪਹਿਲੀ "ਅਸਲੀ" ਰੀਸਟੋਰ ਟੈਸਟ ਅਕਸਰ ਆਊਟੇਜ ਵੇਲੇ ਹੁੰਦੀ ਹੈ।
ਬੈਕਅੱਪ ਰਣਨੀਤੀ ਅਤੇ ਡਿਸਾਸਟਰ ਰਿਕਵਰੀ ਯੋਜਨਾ ਦਾ ਕੰਮ ਅਕਸਰ ਬਜਟ ਦੀਆਂ ਲੜਾਈਆਂ ਹਾਰ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸਨੂੰ ਸਿਰਫ਼ "ਲਾਗਤ ਕੇਂਦਰ" ਵਾਂਗ ਅੰਕਿਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਮੱਸਿਆ ਇਹ ਨਹੀਂ ਕਿ ਨੇਤਾ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦੇ—ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਜੋ ਆਕੜੇ ਉਨ੍ਹਾਂ ਨੂੰ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ ਉਹ ਅਕਸਰ ਅਸਲੀ ਰਿਕਵਰੀ ਦੀ ਲੋੜ ਨੂੰ ਦਰਸਾਉਂਦੇ ਨਹੀਂ।
ਸਿੱਧੇ ਖਰਚੇ ਇਨਵੌਇਸ ਅਤੇ ਟਾਈਮਸ਼ੀਟਾਂ 'ਤੇ ਸਪਸ਼ਟ ਹੁੰਦੇ ਹਨ: ਸਟੋਰੇਜ, ਬੈਕਅੱਪ ਟੂਲਿੰਗ, ਸੈਕੰਡਰੀ ਮਾਹੌਲ, ਅਤੇ ਰੀਸਟੋਰ ਟੈਸਟਿੰਗ ਅਤੇ ਬੈਕਅੱਪ ਤਸਦੀਕ ਲਈ ਸਟਾਫ਼ ਸਮਾਂ। ਜਦੋਂ ਬਜਟ ਘੱਟ ਹੁੰਦਾ ਹੈ, ਇਹ ਲਾਈਨ ਆਈਟਮ ਵਿਕਲਪਿਕ ਲੱਗਦੇ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਜੇ "ਸਾਨੂੰ ਹਾਲ ਹੀ ਵਿੱਚ ਕੋਈ ਘਟਨਾ ਨਹੀਂ ਹੋਈ।"
ਅਪਰੋਕਤ ਖਰਚੇ ਹਕੀਕਤ ਵਿੱਚ ਮੌਜੂਦ ਹਨ, ਪਰ ਉਹ ਸਸਤੇ ਨਹੀਂ ਆਉਂਦੇ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਤੱਕਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ ਜਦ ਤੱਕ ਕੁਝ ਟੁੱਟ ਨਾ ਜਾਵੇ। ਇੱਕ ਫੇਲ੍ਹ ਰੀਸਟੋਰ ਜਾਂ ਧੀਰੀ ਰੈਨਸਮਵੇਅਰ ਰਿਕਵਰੀ ਡਾਉਨਟਾਈਮ, ਗੁੰਮ ਹੋਏ ਆਰਡਰ, ਗਾਹਕ ਸਹਾਇਤਾ ਪ੍ਰਕਾਸ਼ਿਤ ਹੋਣਾ, SLA ਜੁਰਮਾਨੇ, ਨਿਯਮਕ ਖਤਰਾ, ਅਤੇ ਇਮেজ ਨੁਕਸਾਨ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ ਜੋ ਘਟਨਾ ਤੋਂ ਬਾਅਦ ਲੰਬੇ ਸਮੇਂ ਰਹਿ ਸਕਦੇ ਹਨ।
ਇੱਕ ਆਮ ਬਜਟ ਗਲਤੀ ਰਿਕਵਰੀ ਨੂੰ ਦੋ-ਬਟਵਾਰਾ ਵਾਂਗ ਦੇਖਣਾ ਹੈ ("ਅਸੀਂ ਰੀਸਟੋਰ ਕਰ ਸਕਦੇ ਹਾਂ" ਬਨਾਮ "ਅਸੀਂ ਨਹੀਂ ਕਰ ਸਕਦੇ")। ਹਕੀਕਤ ਵਿੱਚ, RTO ਅਤੇ RPO ਕਾਰੋਬਾਰੀ ਪ੍ਰਭਾਵ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ। ਇੱਕ ਸਿਸਟਮ ਜੋ 48 ਘੰਟਿਆਂ ਵਿੱਚ ਰੀਸਟੋਰ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦ ਕਿ ਕਾਰੋਬਾਰ ਨੂੰ 8 ਘੰਟੇ ਚਾਹੀਦੇ ਹਨ, ਉਹ "ਕਵਰਡ" ਨਹੀਂ—ਉਹ ਇੱਕ ਯੋਜਨਾ ਕੀਤੀ ਹੋਈ ਡਾਊਨਟਾਈਮ ਹੈ।
ਗਲਤ ਤਰੀਕੇ ਦੇ ਇਨਾਮ ਤਿਆਰੀ ਨੂੰ ਘੱਟ ਰੱਖਦੇ ਹਨ। ਟੀਮਾਂ ਨੂੰ ਅਪਟਾਈਮ ਅਤੇ ਫੀਚਰ ਡੈਲਿਵਰੀ ਲਈ ਇਨਾਮ ਮਿਲਦਾ ਹੈ, ਨਾ ਕਿ ਰਿਕਵਰੇਬਿਲਟੀ ਲਈ। ਰੀਸਟੋਰ ਟੈਸਟਾਂ ਨਾਲ ਯੋਜਿਤ ਵਿਘਨ ਹੋ ਸਕਦੀ ਹੈ, ਅਣਆਰਾਮਦਾਇਕ ਗੈਪ ਉੱਘਾ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਥੋੜੀ ਮੁਦਤ ਲਈ ਸਮਰੱਥਾ ਘਟਾ ਸਕਦੀ ਹੈ—ਇਸ ਲਈ ਉਹ ਨੇੜ-ਦਾਇਮੀ ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ ਦੇ ਖਿਲਾਫ ਹਾਰ ਜਾਂਦੀ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਯੋਗ ਸੁਧਾਰ ਇਹ ਹੈ ਕਿ ਰਿਕਵਰੇਬਿਲਟੀ ਨੂੰ ਮਾਪਯੋਗ ਅਤੇ ਮਾਲਕੀ ਬਣਾਇਆ ਜਾਵੇ: ਘੱਟੋ-ਘੱਟ ਇੱਕ ਉਦੇਸ਼ ਨੂੰ ਕਿਸੇ ਨਾਜ਼ੁਕ ਸਿਸਟਮ ਲਈ ਸਫਲ ਰੀਸਟੋਰ ਟੈਸਟ ਨਤੀਜਿਆਂ ਨਾਲ ਜੋੜੋ, ਸਿਰਫ਼ ਬੈਕਅੱਪ ਨੌਕਰੀ "ਸਫਲ" ਨਾਲ ਨਹੀਂ।
ਪਰਚੇਜ਼ਿੰਗ ਦੇਰੀ ਇੱਕ ਹੋਰ ਚੁਪ ਰੋਕ ਹੈ। DR ਸੁਧਾਰਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਕ੍ਰਾਸ-ਟੀਮ ਸਹਿਮਤੀ (ਸਿਕਿਊਰਿਟੀ, IT, ਫਾਇਨੈਨਸ, ਐਪ ਮਾਲਕ) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਕਈ ਵਾਰੀ ਨਵੇਂ ਵੇਂਡਰ ਜਾਂ ਕਾਨਟਰੈਕਟ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇ ਉਹ ਚੱਕਰ ਮਹੀਨੇ ਲੈਂਦਾ ਹੈ, ਟੀਮਾਂ ਸੁਧਾਰ ਲਜਾਉਣ बंद ਕਰ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਖਤਰਨਾਕ ਡਿਫੋਲਟ ਕਬੂਲ ਕਰ ਲੈਂਦੀਆਂ ਹਨ।
ਨਤੀਜਾ: DR ਖਰਚ ਨੂੰ ਕਾਰੋਬਾਰੀ ਲਗਾਤਾਰਤਾ ਬੀਮਾ ਵਾਂਗ ਪ੍ਰਸਤੁਤ ਕਰੋ ਜਿਸਦੇ ਨਿਰਧਾਰਿਤ RTO/RPO ਟਾਰਗੇਟ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਮਿਲਾਉਣ ਦਾ ਇੱਕ ਟੈਸਟ ਕੀਤਾ ਰਸਤਾ—ਨਾ ਕਿ ਸਿਰਫ਼ "ਹੋਰ ਸਟੋਰੇਜ।"
ਬੈਕਅੱਪ ਅਤੇ ਰਿਕਵਰੀ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਦੀ ਲਾਗਤ ਪਹਿਲਾਂ ਸਿਰਫ਼ "ਕਿਸੇ ਨਸੀਬ ਵਾਲੇ ਆਊਟੇਜ" ਵਜੋਂ ਆਉਂਦੀ ਸੀ। ਹੁਣ ਇਹ ਅਕਸਰ ਇਕ ਜਾਣ-ਪਛਾਣ ਹਮਲਾ ਜਾਂ ਇਕ ਨਿਰਭਰਤਾ ਅਸਫਲਤਾ ਵਜੋਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ ਜੋ ਆਮਦਨੀ, ਖਿਆਤੀ, ਅਤੇ ਅਨੁਕੂਲਤਾ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੀ ਹੈ।
ਆਧੁਨਿਕ ਰੈਨਸਮਵੇਅਰ ਗਰુપ ਤੁਹਾਡੇ ਰਿਕਵਰੀ ਰਸਤੇ ਦੀ ਤਲਾਸ਼ ਕਰਦੇ ਹਨ। ਉਹ ਬੈਕਅੱਪ ਨੂੰ ਮਿਟਾਉਣ, ਖਰਾਬ ਕਰਨ ਜਾਂ ਇਨਕ੍ਰਿਪਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਅਤੇ ਅਕਸਰ ਪਹਿਲਾਂ ਬੈਕਅੱਪ ਕੰਸੋਲਾਂ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੇ ਬੈਕਅੱਪ ਹਮੇਸ਼ਾਂ ਆਨਲਾਈਨ, ਲਿਖੇ-ਜਾ ਸਕਦੇ, ਅਤੇ ਉਹੀ ਐਡਮਿਨ ਖਾਤਿਆਂ ਨਾਲ ਸੁਰੱਖਿਅਤ ਹਨ, ਤਾਂ ਉਹ ਤੁਹਾਡੇ ਵਿਸਫੋਟ ਖੇਤਰ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦੇ ਹਨ।
ਇਸਲਈ ਇਨਸੋਲੇਸ਼ਨ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਵੱਖਰੇ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ, ਅਟੁੱਟ ਸਟੋਰੇਜ, ਆਫਲਾਈਨ ਜਾਂ ਏਅਰ-ਗੈਪਡ ਕਾਪੀਆਂ, ਅਤੇ ਸਪਸ਼ਟ ਰੀਸਟੋਰ ਕਾਰਵਾਈਆਂ ਜੋ ਇੱਕੋ ਹੀ ਸੰਕ੍ਰਮਿਤ ਸਿਸਟਮਾਂ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੋਣ।
ਕਲਾਉਡ ਅਤੇ SaaS ਸਰਵਿਸز ਆਪਣੇ ਪਲੇਟਫਾਰਮ ਦੀ ਸੁਰੱਖਿਆ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਇਹ ਤੁਹਾਡੇ ਕਾਰੋਬਾਰ ਦੀ ਰਿਕਵਰੀ ਕਵਰੇਜ ਤੋਂ ਵੱਖਰਾ ਹੈ। ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ عملی ਪ੍ਰਸ਼ਨਾਂ ਦੇ ਜਵਾਬ ਦੇਣੇ ਪਾਉਣਗੇ:
ਪ੍ਰੋਵਾਇਡਰ 'ਤੇ ਨਿਰਭਰ ਹੋਣਾ ਆਮ ਤੌਰ 'ਤੇ ਘਟਨਾ ਦੌਰਾਨ ਗੈਪਾਂ ਖੋਲ੍ਹਦਾ ਹੈ—ਜਦੋਂ ਸਮਾਂ ਸਭ ਤੋਂ ਮਹਿੰਗਾ ਹੁੰਦਾ ਹੈ।
ਲੈਪਟਾਪ, ਘਰੇਲੂ ਨੈੱਟਵਰਕ, ਅਤੇ BYOD ਨਾਲ ਕੀਮਤੀ ਡਾਟਾ ਅਕਸਰ ਡੇਟਾ ਸੈਂਟਰ ਤੋਂ ਅਤੇ ਪਰੰਪਰਾਗਤ ਬੈਕਅੱਪ ਜਾਬਾਂ ਤੋਂ ਬਾਹਰ ਰਹਿੰਦਾ ਹੈ। ਇੱਕ ਚੁਰਾਇਆ ਗਿਆ ਡਿਵਾਈਸ, ਇੱਕ ਸਿੰਕ ਹੋਈ ਫੋਲਡਰ ਜੋ ਮਿਟਾਉਣ ਨੂੰ ਫੈਲਾਉਂਦੀ ਹੈ, ਜਾਂ ਇੱਕ ਸੰਕ੍ਰਮਿਤ ਐਂਡਪੌਇੰਟ ਬਿਨਾਂ ਸਿਰਫ਼ ਸਰਵਰ ਨੂੰ ਛੂਹੇ ਹੀ ਡਾਟਾ-ਲੋਸ ਘਟਨਾ ਬਣ ਸਕਦੀ ਹੈ।
ਭੁਗਤਾਨ ਪ੍ਰੋਸੈਸਰ, ਆਈਡੈਂਟੀਟੀ ਪ੍ਰੋਵਾਇਡਰ, DNS, ਅਤੇ ਮੁੱਖ ਇন্টੇਗ੍ਰੇਸ਼ਨ ਡਾਊਨ ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ ਪ੍ਰਭਾਵਤ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਵੀ ਲੈ ਜਾ ਸਕਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੀ ਰਿਕਵਰੀ ਯੋਜਨਾ "ਸਮਝਦੀ ਹੈ ਕਿ ਸਾਡੀਆਂ ਸਿਸਟਮਾਂ ਹੀ ਸਮੱਸਿਆ ਹਨ," ਤਾਂ ਕਿਸੇ ਭਾਈਦਾਰ ਦੀ ਨਾਕਾਮੀ ਦੌਰਾਨ ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ ਕਾਰਗਰ ਵੱਧ-ਥਾਂ ਨਹੀਂ ਹੋਏਗਾ।
ਇਹ ਖਤਰੇ ਸਿਰਫ਼ ਘਟਨਾ ਦੀ ਸੰਭਾਵਨਾ ਵਧਾਉਂਦੇ ਨਹੀਂ—ਉਹ ਇਹ ਭੀ ਵਧਾਉਂਦੇ ਹਨ ਕਿ ਰਿਕਵਰੀ ਧੀਮੀ, ਅਧੂਰੀ, ਜਾਂ ਅਸੰਭਵ ਹੋ ਸਕਦੀ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਬੈਕਅੱਪ ਅਤੇ DR ਯਤਨਾਂ ਰੁਕ ਜਾਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਟੂਲ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ ("ਅਸੀਂ ਬੈਕਅੱਪ ਸਿਖਿਆ ਹੈ") ਬਜਾਏ ਫੈਸਲਿਆਂ ਨਾਲ ("ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਬੈਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕੌਣ ਐਹ ਫੈਸਲਾ ਕਰੇਗਾ?"). ਇੱਕ ਰਿਕਵਰੀ ਮੈਪ ਉਹਨਾਂ ਫੈਸਲਿਆਂ ਨੂੰ ਦਰਸ਼ਨੀ ਬਣਾਉਣ ਦਾ ਹਰਕਤਨਾਸ਼ੀ ਤਰੀਕਾ ਹੈ।
ਇਕ ਸਾਂਝਾ ਦਸਤਾਵੇਜ਼ ਜਾਂ ਸਪਰੇਡਸ਼ੀਟ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਲਿਸਟ ਕਰੋ:
ਇੱਕ ਹੋਰ ਕਾਲਮ ਸ਼ਾਮਲ ਕਰੋ: ਤੁਸੀਂ ਇਹ ਕਿਵੇਂ ਰੀਸਟੋਰ ਕਰਦੇ ਹੋ (ਵੇਂਡਰ ਰੀਸਟੋਰ, VM ਇਮੇਜ, ਡੇਟਾਬੇਸ ਡੰਪ, ਫਾਈਲ-ਲੇਵਲ ਰੀਸਟੋਰ)। ਜੇ ਤੁਸੀਂ ਇੱਕ ਵਾਕ ਵਿੱਚ ਇਸ ਨੂੰ ਵਰਣਨ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਇਹ ਲਾਲ ਝੰਡਾ ਹੈ।
ਇਹ ਟੈਕਨੀਕੀ ਨਿਸ਼ਾਨ ਨਹੀਂ—ਇਹ ਕਾਰੋਬਾਰੀ ਸਹਿਣਸ਼ੀਲਤਾਵਾਂ ਹਨ। ਸਧਾਰਨ ਉਦਾਹਰਣ ਵਰਤੋ (ਆਰਡਰ, ਟਿਕਟ, ਪੇਰੋਲ) ਤਾਂ ਜੋ ਹਰ ਕੋਈ "ਖੋਇਆ" ਦਾ ਮਤਲਬ ਸਮਝ ਸਕੇ।
ਸਿਸਟਮਾਂ ਨੂੰ ਗਰੁੱਪ ਕਰੋ:
ਇੱਕ ਛੋਟੀ “Day 1” ਚੈੱਕਲਿਸਟ ਲਿਖੋ: ਉਹ ਸਭ ਤੋਂ ਘੱਟ ਸੇਵਾਵਾਂ ਅਤੇ ਡਾਟਾ ਸੈੱਟ ਜੋ ਤੁਸੀਂ ਆਊਟੇਜ ਦੌਰਾਨ ਚਲਾਉਣ ਲਈ ਚਾਹੀਦੇ ਹੋ। ਇਹ ਤੁਹਾਡੇ ਡਿਫਾਲਟ ਰੀਸਟੋਰ ਅਨੁਕ੍ਰਮ ਅਤੇ ਟੈਸਟਿੰਗ ਅਤੇ ਬਜਟਿੰਗ ਲਈ ਮਾਪਦੰਡ ਬਣ ਜਾਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਅੰਦਰੂਨੀ ਟੂਲ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ (ਉਦਾਹਰਨ ਵਜੋਂ Koder.ai ਵਰਗੀ vibe-coding ਪਲੇਟਫਾਰਮ ਨਾਲ), ਤਾਂ ਉਹਨਾਂ ਜਨਰੇਟ ਕੀਤੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਇਕੋ ਮੈਪ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ: ਐਪ, ਉਸਦਾ ਡੇਟਾਬੇਸ, ਸੀਕ੍ਰੇਟ, ਕਸਟਮ ਡੋਮੇਨ/DNS, ਅਤੇ ਸਹੀ ਰੀਸਟੋਰ ਰਸਤਾ। ਤੇਜ਼ੀ ਨਾਲ ਬਣੇ ਟੂਲਾਂ ਨੂੰ ਵੀ ਬੋਰੀਂਗ, ਸਪਸ਼ਟ ਰਿਕਵਰੀ ਮਾਲਕੀ ਚਾਹੀਦੀ ਹੈ।
ਇੱਕ ਰੀਸਟੋਰ ਟੈਸਟ ਸਿਰਫ਼ ਤਦ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਸਧਾਰਨ ਓਪਰੇਸ਼ਨਾਂ ਵਿੱਚ ਫਿੱਟ ਬੈਠਦਾ ਹੈ। ਮਕਸਦ ਕੋਈ ਨਾਟਕੀ "ਸਾਰੇ ਹੱਥ" ਵਰਕਸ਼ਾਪ ਹਰ ਸਾਲ ਨਹੀਂ—ਇਹ ਇਕ ਛੋਟੀ, ਪੇਸ਼ਗੋਈ ਰੁਟੀਨ ਹੈ ਜੋ ਆਸਫਲਤਾ ਉਨ੍ਹਾਂ ਦੀਆਂ ਕਿਮਤਾਂ ਛੋਟੀਆਂ ਹੋਣ 'ਤੇ ਹੀ ਦਰਸਾਉਂਦੀ ਹੈ।
ਦੋ ਪਰਤਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ:
ਦੋਹਾਂ ਨੂੰ ਕੈਲੰਡਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਰੱਖੋ, ਜਿਵੇਂ ਵਿੱਤੀ ਬੰਦ ਜਾਂ ਪੈਚਿੰਗ। ਜੇ ਇਹ ਵਿਕਲਪਿਕ ਹੈ, ਤਾਂ ਇਹ ਪਿੱਛੇ ਲੱਬ ਜਾਂਦਾ ਹੈ।
ਹਰ ਵਾਰੀ ਇੱਕੋ “ਖੁਸ਼ੀ ਰਸਤੇ” ਦੀ ਟੈਸਟ ਨਾ ਕਰੋ। ਉਹ ਸਥਿਤੀਆਂ ਚੁਣੋ ਜੋ ਅਸਲ ਘਟਨਾਵਾਂ ਨੂੰ ਦਿਖਾਉਂਦੀਆਂ ਹਨ:
ਜੇ ਤੁਹਾਡੇ ਕੋਲ SaaS ਡਾਟਾ ਹੈ (ਜਿਵੇਂ Microsoft 365, Google Workspace), ਤਾਂ ਮੈਲਬਾਕਸ/ਫਾਈਲਾਂ ਦੀ ਰਿਕਵਰੀ ਲਈ ਵੀ ਇੱਕ ਸਥਿਤੀ ਸ਼ਾਮਲ ਕਰੋ।
ਹਰ ਟੈਸਟ ਲਈ ਦਰਜ ਕਰੋ:
ਸਮੇਂ ਨਾਲ, ਇਹ ਤੁਹਾਡੀ ਸਭ ਤੋਂ਼ ਸੱਚੀ "DR ਦਸਤਾਵੇਜ਼" ਬਣ ਜਾਂਦੀ ਹੈ।
ਜਦ ਤੱਕ ਸਮੱਸਿਆ ਚੁਪ ਰਿਹਾ, ਇਕ ਰੁਟੀਨ ਮਰ ਜਾਂਦੀ ਹੈ। ਆਪਣੇ ਬੈਕਅੱਪ ਟੂਲਿੰਗ ਨੂੰ ਅਸਫਲ ਨੌਕਰੀਆਂ, ਛੁੱਟ ਗਏ ਸ਼ੈਡਿਊਲ, ਅਤੇ ਤਸਦੀਕ ਤ੍ਰੁੱਟੀਆਂ 'ਤੇ ਅਲਰਟ ਕਰਨ ਲਈ ਸੰਰਚਿਤ ਕਰੋ, ਅਤੇ ਹਿੱਸੇਦਾਰਾਂ ਨੂੰ ਮਹੀਨਾਵਾਰ ਛੋਟੀ ਰਿਪੋਰਟ ਭੇਜੋ: ਪਾਸ/ਫੇਲ ਰੇਟ, ਰੀਸਟੋਰ ਸਮਾਂ, ਅਤੇ ਖੁੱਲ੍ਹੀ ਮੁਰੰਮਤਾਂ। ਵਿਸ਼ੇਸ਼ਤਾ ਪੈਦਾ ਕਰਦੀ ਹੈ ਕਾਰਵਾਈ—ਅਤੇ ਤਿਆਰੀ ਨੂੰ ਘਟਨੇ ਦਰਮਿਆਨ ਫੇਡ ਹੋਣ ਤੋਂ ਰੋਕਦੀ ਹੈ।
ਬੈਕਅੱਪ ਅਕਸਰ ਆਮ ਕਾਰਨਾਂ ਕਰਕੇ ਫੇਲ ਹੁੰਦੇ ਹਨ: ਉਹ ਉਨ੍ਹਾਂ ਹੀ ਖਾਤਿਆਂ ਨਾਲ ਪਹੁੰਚਯੋਗ ਹਨ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਲਈ ਵੀ ਹਨ, ਉਹ ਠੀਕ ਸਮੇਂ ਦੀ ਕਵਰੇਜ ਨਹੀਂ ਕਰਦੇ, ਜਾਂ ਕੋਈ ਉਹਨਾਂ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਨਹੀਂ ਕਰ ਸਕਦਾ ਜਦ ਲੋੜ ਹੋਵੇ। ਚੰਗਾ ਡਿਜ਼ਾਈਨ ਫੈਂਸੀ ਟੂਲਾਂ ਦੀ ਬਜਾਏ ਕੁਝ ਵਰਤੋਂਯੋਗ ਗਾਰਡਰੈਲਸ 'ਤੇ ਧਿਆਨ ਦਿੰਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਬੇਸਲਾਇਨ ਹੈ 3-2-1 ਵਿਚਾਰ:
ਇਹ ਰਿਕਵਰੀ ਦੀ ਗਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ, ਪਰ ਇਹ ਤੁਹਾਨੂੰ “ਇੱਕ ਬੈਕਅੱਪ, ਇੱਕ ਥਾਂ, ਇੱਕ ਫੇਲ੍ਹ” ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡਾ ਬੈਕਅੱਪ ਸਿਸਟਮ ਉਨ੍ਹਾਂ ਹੀ ਐਡਮਿਨ ਖਾਤਿਆਂ ਨਾਲ ਪੁੱਜਾ ਜਾ ਸਕਦਾ ਹੈ ਜੋ ਸਰਵਰ, ਈਮੇਲ, ਜਾਂ ਕਲਾਉਡ ਕਨਸੋਲ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਇੱਕ ਹੀ ਸਮਝੌਤਾ ਪਾਸਵਰਡ ਦੋਵੇਂ ਪ੍ਰੋਡਕਸ਼ਨ ਅਤੇ ਬੈਕਅੱਪ ਨੁਕਸਾਨ ਕਰ ਸਕਦਾ ਹੈ।
ਅਲੱਗੀਅਤ ਲਈ ਕੋਸ਼ਿਸ਼ ਕਰੋ:
ਰੀਟੇਨਸ਼ਨ ਦੋ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ: “ਅਸੀਂ ਕਿੰਨਾ ਪਿੱਛੇ ਜਾ ਸਕਦੇ ਹਾਂ?” ਅਤੇ “ਅਸੀਂ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਰੀਸਟੋਰ ਕਰ ਸਕਦੇ ਹਾਂ?”
ਇਸਨੂੰ ਦੋ ਪਰਤਾਂ ਵਜੋਂ ਦੇਖੋ:
ਇੰਕ੍ਰਿਪਸ਼ਨ ਕੀ ਕੀਮਤੀ ਹੈ—ਜਦ ਤੱਕ ਕੁੰਜੀ ਘਟਨਾ ਦੌਰਾਨ ਲੱਭ ਨਾ ਸਕੇ।
ਪਹਿਲਾਂ ਨਿਰਧਾਰਿਤ ਕਰੋ:
ਇੱਕ ਬੈਕਅੱਪ ਜੋ ਤੁਰੰਤ ਪਹੁੰਚਯੋਗ, ਡੀਕ੍ਰਿਪਟ ਕਰਨਯੋਗ, ਜਾਂ ਲੱਭਣਯੋਗ ਨਹੀਂ ਹੈ—ਉਹ ਬੈਕਅੱਪ ਨਹੀਂ, ਸਿਰਫ ਸਟੋਰੇਜ ਹੈ।
ਇੱਕ ਡੀ.ਆਰ. ਯੋਜਨਾ ਜੋ PDF ਵਿੱਚ ਪਈ ਹੋਵੇ ਉਹ ਕੁਝ ਹੈ—ਪਰ ਆਊਟੇਜ ਦੌਰਾਨ ਲੋਕ "ਪਲੇਨ ਨਹੀਂ ਪੜ੍ਹਦੇ।" ਉਹ ਤੇਜ਼ ਫੈਸਲੇ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ ਜਿਸਦੇ ਕੋਲ ਅੰਸ਼ਿਕ ਜਾਣਕਾਰੀ ਹੁੰਦੀ ਹੈ। ਮਕਸਦ ਹੈ DR ਨੂੰ ਸੰਦਰਭੀ ਸਮਗਰੀ ਤੋਂ ਉਹ ਕ੍ਰਮਬੱਧ ਲੜੀ ਬਨਾਉਣਾ ਜੋ ਤੁਸੀਂ ਅਸਲੀ ਠੇਠ ਚਲਾ ਸਕੋ।
ਇੱਕ ਇੱਕ-ਪੇਜ਼ ਰਨਬੁੱਕ ਬਣਾਉ ਜੋ ਉਹ ਸਵਾਲ ਜਵਾਬ ਕਰਦਾ ਹੈ ਜੋ ਹਰ ਕੋਈ ਦਬਾਅ ਹੇਠਾਂ ਪੁੱਛਦਾ ਹੈ:
ਵਿਸਥਾਰਤ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਐਪੈਂਡਿਕਸ ਵਿੱਚ ਰੱਖੋ। ਇੱਕ ਪੇਜ਼ ਉਹੀ ਹੈ ਜੋ ਦਬਾਅ ਹੇਠਾਂ ਵਰਤਿਆ ਜਾਵੇਗਾ।
ਅਪਡੇਟਾਂ ਜਦ ਅਨੁਕੂਲ ਤਰੀਕੇ ਨਾਲ ਹੁੰਦੀਆਂ ਹਨ ਤਾਂ ਗੁਮਰਾਹੀ ਵਧਦੀ ਹੈ। ਨਿਰਧਾਰਤ ਕਰੋ:
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਸਟੇਟਸ ਪੇਜ਼ ਹੈ, ਤਾਂ ਰਨਬੁੱਕ ਵਿੱਚ ਇਸਨੂੰ ਜ਼ਿਕਰ ਕਰੋ (ਉਦਾਹਰਨ: /status)।
ਫੈਸਲੇ ਅਤੇ ਮਾਲਿਕ ਪਹਿਲਾਂ ਲਿਖ ਦਿਓ:
ਪਲੇਅਬੁੱਕ ਨੂੰ ਇਸ ਜਗ੍ਹਾਂ 'ਤੇ ਰੱਖੋ ਜਿੱਥੇ ਉਹ ਤੁਹਾਡੀਆਂ ਪ੍ਰਣਾਲੀਆਂ ਨਾਲ ਗਾਇਬ ਨਹੀਂ ਹੋਵੇ: ਇੱਕ ਆਫਲਾਈਨ ਕਾਪੀ ਅਤੇ ਇੱਕ ਸੁਰੱਖਿਅਤ ਸਾਂਝਾ ਸਥਾਨ break-glass ਪਹੁੰਚ ਨਾਲ।
ਜੇ ਬੈਕਅੱਪ ਅਤੇ DR ਸਿਰਫ਼ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਹੀ ਰਹਿਣ, ਉਹ ਭਟਕ ਜਾਂਦੇ ਹਨ। ਪ੍ਰਯੋਗਯੋਗ ਸੁਧਾਰ ਇਹ ਹੈ ਕਿ ਰਿਕਵਰੀ ਨੂੰ ਹੋਰ ਕਿਸੇ ਓਪਰੇਸ਼ਨਲ ਸਮਰੱਥਾ ਵਾਂਗ ਮਾਪੋ: ਇਸਨੂੰ ਅਸਾਈਨ ਕਰੋ, ਮਾਪੋ, ਅਤੇ ਨਿਯਮਤ ਸਮੇਂ ਤੇ ਸਮੀਖਿਆ ਕਰੋ।
ਤੁਹਾਨੂੰ charts ਦੀ ਲੋੜ ਨਹੀਂ। ਇੱਕ ਛੋਟੀ ਸੈੱਟ ਟਰੈਕ ਕਰੋ ਜੋ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ: "ਕੀ ਅਸੀਂ ਰਿਕਵਰ ਕਰ ਸਕਦੇ ਹਾਂ?":
ਇਨ੍ਹਾਂ ਨੂੰ ਤੁਹਾਡੇ RTO ਅਤੇ RPO ਟਾਰਗੇਟ ਨਾਲ ਜੋੜੋ ਤਾਂ ਜੋ ਇਹ ਸ਼ਾਨਦਾਰ ਨੰਬਰ ਨਾ ਬਣ ਜਾਣ। ਜੇ ਟਾਈਮ-ਟੂ-ਰੀਸਟੋਰ ਹਮੇਸ਼ਾ ਤੁਹਾਡੇ RTO ਤੋਂ ਉਪਰ ਹੈ, ਤਾਂ ਇਹ "ਬਾਅਦ ਵਿੱਚ" ਸਮੱਸਿਆ ਨਹੀਂ—ਇਹ ਨੁਕਸਾਨ ਹੈ।
ਤਿਆਰੀ ਉਹ ਦਿਨੋਂ ਹੀ ਮਰਦੀ ਹੈ ਜਦ ਸਭ "ਸ਼ਾਮਿਲ" ਹਨ ਪਰ ਕੋਈ ਜਵਾਬਦੇਹ ਨਹੀਂ। ਨਿਰਧਾਰਿਤ ਕਰੋ:
ਮਾਲਕੀ ਵਿੱਚ ਟੈਸਟ ਸ਼ਡਿਊਲ ਕਰਨ ਅਤੇ ਗੈਪਾਂ ਨੂੰ ਐਸਕੇਲੇਟ ਕਰਨ ਦੀ ਸ਼ਕਤੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਨਹੀਂ ਤਾਂ ਕੰਮ ਅਨੰਤ ਤੱਕ ਟਾਲਿਆ ਜਾਵੇਗਾ।
ਹਰ ਸਾਲ, ਇਕ "ਅਨੁਮਾਨ ਸਮੀਖਿਆ" ਮੀਟਿੰਗ ਚਲਾਓ ਅਤੇ ਆਪਣੀ ਡਿਸਾਸਟਰ ਰਿਕਵਰੀ ਯੋਜਨਾ ਨੂੰ ਹਕੀਕਤ ਦੇ ਅਨੁਸਾਰ ਅਪਡੇਟ ਕਰੋ:
ਇਹ ਵੀ ਇੱਕ ਵਧੀਆ ਮੌਕਾ ਹੈ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕਿ ਤੁਹਾਡਾ ਰਿਕਵਰੀ ਮੈਪ ਹਾਲੀ-ਹਾਲੀ ਮਾਲਿਕਾਂ ਅਤੇ ਨਿਰਭਰਤਾਵਾਂ ਨਾਲ ਮਿਲਦਾ-ਜੁਲਦਾ ਹੈ।
ਆਪਣੇ ਅੰਦਰੂਨੀ ਰਨਬੁੱਕ ਦੇ ਸਿਖਰ 'ਤੇ ਇੱਕ ਛੋਟੀ ਚੈੱਕਲਿਸਟ ਰੱਖੋ ਤਾਂ ਜੋ ਲੋਕ ਦਬਾਅ ਹੇਠਾਂ ਕੀਤਾ ਕਰ ਸਕਣ। ਜੇ ਤੁਸੀਂ ਆਪਣੀ ਪਹੁੰਚ ਬਣਾ ਰਹੇ ਹੋ ਜਾਂ ਸੁਧਾਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ /pricing ਜਾਂ /blog ਵਰਗੀਆਂ ਸਾਧਾਰਨਾਂ ਨੂੰ ਐਡਰੈਸ ਕਰ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ ਵਿਕਲਪ, ਰੁਟੀਨ, ਅਤੇ "ਪ੍ਰੋਡਕਸ਼ਨ-ਰੇਡੀ" ਰਿਕਵਰੀ ਵਿਖੇ ਭਿੰਨ-ਭਿੰਨ ਪਲੇਟਫਾਰਮਾਂ (ਜਿਸ ਵਿੱਚ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਸ਼ਾਮਲ ਹਨ ਜੋ ਸਨੇਪਸ਼ਾਟ/ਰੋਲਬੈਕ ਅਤੇ ਸੋర్స్ ਨਿਰਯਾਤ ਨੂੰ ਸਹਾਰਾ ਦਿੰਦੇ ਹਨ) ਦੀ ਤੁਲਨਾ ਕੀਤੀ ਜਾ ਸਕੇ।
Backups are copies of data/systems stored elsewhere. Restore testing is proof you can recover from those backups. Disaster recovery (DR) is the operational plan—people, roles, priorities, dependencies, and communications—to resume the business after a serious incident.
A team can have backups and still fail restore tests; it can pass restores and still fail DR if coordination and access break down.
Because a “successful backup job” only proves a file was written somewhere—not that it’s complete, uncorrupted, decryptable, and restorable within your needed time.
Common failures include missing application data, corrupted archives, retention deleting the needed version, or restores failing due to permissions, expired credentials, or missing keys.
Translate them into business examples (orders, tickets, payroll). If you need payments back in 4 hours, RTO is 4 hours; if you can lose only 30 minutes of orders, RPO is 30 minutes.
Start with a simple recovery map:
Then tier systems (Critical / Important / Nice-to-have) and define a “Day 1 minimal operations” restore order.
Because it’s inconvenient and it often produces bad news.
Treat restore testing like routine operations work, not a one-time project.
Use two layers you can sustain:
Log what you restored, which backup set, time-to-usable, and what failed (with fixes).
Track a few metrics that answer “Can we recover?”
Tie them back to RTO/RPO so you can see when you’re meeting (or missing) business tolerances.
Reduce blast radius and make backups harder to destroy:
Assume attackers may target backup consoles first.
Your provider may protect their platform, but you still need to ensure your business can recover.
Validate:
Document the restore path in your recovery map and test it.
Make it executable and reachable:
