DevOps ਇੰਜੀਨੀਅਰਾਂ ਅਤੇ ਸਿਸਟਮ ਐਡਮਿਨਿਸਟ੍ਰੇਟਰਾਂ ਲਈ, ਵਰਚੁਅਲ ਮਸ਼ੀਨ (VM) ਸਨੈਪਸ਼ਾਟ ਇੱਕ ਬੁਨਿਆਦੀ ਸਾਧਨ ਹਨ। ਇਹ ਕਿਸੇ ਜੋਖਮ ਭਰੇ ਪੈਚ, ਵੱਡੇ ਕੌਂਫਿਗਰੇਸ਼ਨ ਬਦਲਾਅ, ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਡਿਪਲਾਇਮੈਂਟ ਤੋਂ ਪਹਿਲਾਂ ਸਰਵਰ ਦੀ ਸਥਿਤੀ ਨੂੰ ਕੈਪਚਰ ਕਰਨ ਦਾ ਇੱਕ ਤੇਜ਼ ਅਤੇ ਸੁਵਿਧਾਜਨਕ ਤਰੀਕਾ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਜੇਕਰ ਕੁਝ ਗਲਤ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਰੋਲਿੰਗ ਬੈਕ (ਪੁਰਾਣੀ ਸਥਿਤੀ ‘ਤੇ ਵਾਪਸ ਜਾਣਾ) ਵਿੱਚ ਸਕਿੰਟਾਂ ਦਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ।
ਹਾਲਾਂਕਿ, ਜਦੋਂ ਇਹੀ ਵਿਧੀ ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਡੇਟਾਬੇਸ—ਜਿਵੇਂ ਕਿ PostgreSQL, MySQL, Oracle, ਜਾਂ Microsoft SQL Server—ਤੇ ਲਾਗੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ VM ਸਨੈਪਸ਼ਾਟ ਇੱਕ ਸੁਰੱਖਿਆ ਕਵਚ ਤੋਂ ਬਦਲ ਕੇ ਇੱਕ ਟਾਈਮ ਬੰਬ ਬਣ ਜਾਂਦੇ ਹਨ।
ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਲਈ ਸਟੈਂਡਰਡ ਹਾਈਪਰਵਾਈਜ਼ਰ ਸਨੈਪਸ਼ਾਟ ‘ਤੇ ਨਿਰਭਰ ਰਹਿਣਾ ਡੇਟਾ ਦੇ ਖਰਾਬ ਹੋਣ, ਟੁੱਟੇ ਹੋਏ ਪੰਨਿਆਂ (torn pages), ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਨਾ ਠੀਕ ਹੋਣ ਵਾਲੇ ਆਊਟੇਜ ਦੇ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਇਸ ਲੇਖ ਵਿੱਚ, ਅਸੀਂ ਹਾਈਪਰਵਾਈਜ਼ਰਾਂ ਅਤੇ ਡੇਟਾਬੇਸ ਇੰਜਣਾਂ ਵਿਚਕਾਰ ਆਰਕੀਟੈਕਚਰਲ ਟਕਰਾਅ, ਸਨੈਪਸ਼ਾਟ ਦੌਰਾਨ ਡੇਟਾ ਦੇ ਖਰਾਬ ਹੋਣ ਦੀ ਪ੍ਰਕਿਰਿਆ, ਅਤੇ ਵਰਚੁਅਲਾਈਜ਼ਡ ਡੇਟਾਬੇਸ ਦਾ ਸੁਰੱਖਿਅਤ ਬੈਕਅੱਪ ਲੈਣ ਲਈ ਲੋੜੀਂਦੇ ਇੰਜੀਨੀਅਰਿੰਗ ਦੇ ਵਧੀਆ ਅਭਿਆਸਾਂ ਬਾਰੇ ਚਰਚਾ ਕਰਾਂਗੇ।
ਆਰਕੀਟੈਕਚਰ ਟਕਰਾਅ: ਹਾਈਪਰਵਾਈਜ਼ਰ ਬਨਾਮ ਡੇਟਾਬੇਸ ਇੰਜਣ
ਇਹ ਸਮਝਣ ਲਈ ਕਿ VM ਸਨੈਪਸ਼ਾਟ ਡੇਟਾਬੇਸ ਨੂੰ ਖ਼ਤਰੇ ਵਿੱਚ ਕਿਉਂ ਪਾਉਂਦੇ ਹਨ, ਸਾਨੂੰ ਪਹਿਲਾਂ ਇਹ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਦੋਵੇਂ ਸਿਸਟਮ ਸਟੇਟ ਅਤੇ I/O ਓਪਰੇਸ਼ਨਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਿਵੇਂ ਕਰਦੇ ਹਨ।
ਹਾਈਪਰਵਾਈਜ਼ਰ ਸਨੈਪਸ਼ਾਟ ਕਿਵੇਂ ਚਲਾਉਂਦੇ ਹਨ
ਜਦੋਂ ਇੱਕ ਹਾਈਪਰਵਾਈਜ਼ਰ (ਜਿਵੇਂ ਕਿ VMware ESXi, Microsoft Hyper-V, ਜਾਂ KVM) ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਡਿਸਕ ਨੂੰ ਕਾਪੀ ਨਹੀਂ ਕਰਦਾ। ਇਸ ਦੀ ਬਜਾਏ, ਇਹ ਮੌਜੂਦਾ ਵਰਚੁਅਲ ਡਿਸਕ ਫਾਈਲ (ਜਿਵੇਂ ਕਿ .vmdk ਜਾਂ .vhdx) ਨੂੰ ਰੀਡ-ਓਨਲੀ ਸਥਿਤੀ ਵਿੱਚ ਫ੍ਰੀਜ਼ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਨਵੀਂ ਡੈਲਟਾ ਡਿਸਕ (ਅੰਤਰ ਡਿਸਕ) ਬਣਾਉਂਦਾ ਹੈ। ਸਾਰੇ ਬਾਅਦ ਦੇ ਰਾਈਟਸ (writes) ਇਸ ਡੈਲਟਾ ਡਿਸਕ ਵੱਲ ਭੇਜੇ ਜਾਂਦੇ ਹਨ।
ਜਦੋਂ ਸਨੈਪਸ਼ਾਟ ਨੂੰ ਡਿਲੀਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਹਾਈਪਰਵਾਈਜ਼ਰ ਨੂੰ ਡੈਲਟਾ ਡਿਸਕ ਤੋਂ ਡੇਟਾ ਨੂੰ ਵਾਪਸ ਬੇਸ ਡਿਸਕ ਵਿੱਚ ਕਮਿਟ (ਏਕੀਕ੍ਰਿਤ) ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਸਟੈਂਡਰਡ ਸਨੈਪਸ਼ਾਟ ਗੈਸਟ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਅੰਦਰ ਚੱਲ ਰਹੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਣਜਾਣ ਹੁੰਦੇ ਹਨ। ਉਹ ਡਿਸਕ ਦੀ ਸਥਿਤੀ ਨੂੰ ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ ਕੈਪਚਰ ਕਰਦੇ ਹਨ ਜਿਵੇਂ ਉਹ ਉਸ ਮਾਈਕ੍ਰੋਸੈਕਿੰਡ ਵਿੱਚ ਮੌਜੂਦ ਹੁੰਦੀ ਹੈ।
ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਡੇਟਾਬੇਸ ਸਟੇਟ ਦਾ ਪ੍ਰਬੰਧਨ ਕਿਵੇਂ ਕਰਦੇ ਹਨ
ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਡੇਟਾਬੇਸ ACID ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ (Atomicity, Consistency, Isolation, Durability) ਦੇ ਆਧਾਰ ‘ਤੇ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਗਏ ਹਨ। ACID ਪਾਲਣਾ ਨੂੰ ਕਾਇਮ ਰੱਖਦੇ ਹੋਏ ਉੱਚ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਡੇਟਾਬੇਸ ਹਰ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਨੂੰ ਤੁਰੰਤ ਡਿਸਕ ‘ਤੇ ਪ੍ਰਾਇਮਰੀ ਡੇਟਾ ਫਾਈਲਾਂ ਵਿੱਚ ਨਹੀਂ ਲਿਖਦੇ। ਇਸ ਦੀ ਬਜਾਏ, ਉਹ ਇੱਕ ਗੁੰਝਲਦਾਰ, ਮਲਟੀ-ਟੀਅਰ ਆਰਕੀਟੈਕਚਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ:
- ਬਫਰ ਪੂਲ / ਸ਼ੇਅਰਡ ਬਫਰ: ਡੇਟਾ ਨੂੰ ਸਿਸਟਮ ਮੈਮੋਰੀ ਵਿੱਚ ਪੜ੍ਹਿਆ ਅਤੇ ਸੋਧਿਆ ਜਾਂਦਾ ਹੈ।
- ਰਾਈਟ-ਅਹੈੱਡ ਲੌਗ (WAL) / ਰੀਡੋ ਲੌਗਸ: ਟਿਕਾਊਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਤਬਦੀਲੀਆਂ ਨੂੰ ਡਿਸਕ ‘ਤੇ ਇੱਕ ਉੱਚ-ਅਨੁਕੂਲਿਤ ਲੌਗ ਫਾਈਲ ਵਿੱਚ ਕ੍ਰਮਵਾਰ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ।
- ਚੈੱਕਪੁਆਇੰਟਸ / ਲੇਜ਼ੀ ਰਾਈਟਰਸ: ਸਮੇਂ-ਸਮੇਂ ‘ਤੇ, ਡੇਟਾਬੇਸ ਮੈਮੋਰੀ ਤੋਂ ਸੋਧੇ ਹੋਏ (dirty) ਪੰਨਿਆਂ ਨੂੰ ਡਿਸਕ ‘ਤੇ ਅਸਲ ਡੇਟਾ ਫਾਈਲਾਂ ਵਿੱਚ ਫਲੱਸ਼ ਕਰਦਾ ਹੈ।
ਇਸ ਆਰਕੀਟੈਕਚਰ ਦੇ ਕਾਰਨ, ਡਿਸਕ ‘ਤੇ ਭੌਤਿਕ ਡੇਟਾ ਫਾਈਲਾਂ ਲਗਭਗ ਹਮੇਸ਼ਾ ਡੇਟਾਬੇਸ ਦੀ ਅਸਲ ਸਥਿਤੀ ਨਾਲ ਸਿੰਕ ਤੋਂ ਬਾਹਰ ਹੁੰਦੀਆਂ ਹਨ। ਡੇਟਾਬੇਸ ਦੀ ਅਸਲ ਸਥਿਤੀ ਸਿਰਫ ਡਿਸਕ ‘ਤੇ ਡੇਟਾ ਫਾਈਲਾਂ, WAL/ਰੀਡੋ ਲੌਗਸ, ਅਤੇ ਮੌਜੂਦਾ ਸਮੇਂ ਵਿੱਚ ਮੈਮੋਰੀ ਵਿੱਚ ਮੌਜੂਦ ਡੇਟਾ ਦੇ ਸੁਮੇਲ ਵਜੋਂ ਹੋਂਦ ਵਿੱਚ ਹੁੰਦੀ ਹੈ।
ਖ਼ਤਰੇ ਦਾ ਖੇਤਰ: VM ਸਨੈਪਸ਼ਾਟ ਦੌਰਾਨ ਕੀ ਹੁੰਦਾ ਹੈ
ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਡੇਟਾਬੇਸ ਸਰਵਰ ਦਾ ਸਟੈਂਡਰਡ VM ਸਨੈਪਸ਼ਾਟ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਕ੍ਰੈਸ਼-ਕਨਸਿਸਟੈਂਟ ਸਥਿਤੀ ਨੂੰ ਕੈਪਚਰ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹੋ।
ਕ੍ਰੈਸ਼ ਕਨਸਿਸਟੈਂਸੀ ਬਨਾਮ ਐਪਲੀਕੇਸ਼ਨ ਕਨਸਿਸਟੈਂਸੀ
ਇੱਕ ਕ੍ਰੈਸ਼-ਕਨਸਿਸਟੈਂਟ ਸਨੈਪਸ਼ਾਟ ਭੌਤਿਕ ਸਰਵਰ ਤੋਂ ਪਾਵਰ ਕੋਰਡ ਨੂੰ ਬਾਹਰ ਕੱਢਣ ਦੇ ਬਰਾਬਰ ਹੈ। ਡਿਸਕ ਦੀ ਸਥਿਤੀ ਕੈਪਚਰ ਹੋ ਜਾਂਦੀ ਹੈ, ਪਰ ਮੈਮੋਰੀ ਵਿੱਚ ਜੋ ਕੁਝ ਵੀ ਸੀ ਉਹ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਜੋ ਕੁਝ ਵੀ ਸਟੋਰੇਜ ਕੰਟਰੋਲਰ ਵੱਲ ਜਾ ਰਿਹਾ ਸੀ ਉਹ ਅਚਾਨਕ ਕੱਟਿਆ ਜਾਂਦਾ ਹੈ।
ਹਾਲਾਂਕਿ ਆਧੁਨਿਕ ਡੇਟਾਬੇਸ ਰਾਈਟ-ਅਹੈੱਡ ਲੌਗ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾ ਕੇ ਅਚਾਨਕ ਪਾਵਰ ਨੁਕਸਾਨ ਤੋਂ ਉਭਰਨ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹਨ, ਪਰ ਆਪਣੀ ਮੁੱਖ ਬੈਕਅੱਪ ਰਣਨੀਤੀ ਵਜੋਂ ਕ੍ਰੈਸ਼ ਰਿਕਵਰੀ ‘ਤੇ ਨਿਰਭਰ ਕਰਨਾ ਬਹੁਤ ਖਤਰਨਾਕ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਕਈ ਵਰਚੁਅਲ ਡਿਸਕਾਂ (ਜਿਵੇਂ ਕਿ Drive D: ‘ਤੇ ਡੇਟਾ ਫਾਈਲਾਂ ਅਤੇ Drive E: ‘ਤੇ WAL) ਵਿੱਚ ਫੈਲਿਆ ਹੋਇਆ ਹੈ, ਤਾਂ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਹਾਈਪਰਵਾਈਜ਼ਰ ਦੋਵਾਂ ਡਿਸਕਾਂ ਨੂੰ ਬਿਲਕੁਲ ਉਸੇ ਮਾਈਕ੍ਰੋਸੈਕਿੰਡ ਵਿੱਚ ਸਨੈਪਸ਼ਾਟ ਨਾ ਕਰੇ। ਜੇਕਰ WAL ਡਿਸਕ ਸਨੈਪਸ਼ਾਟ ਡੇਟਾ ਡਿਸਕ ਸਨੈਪਸ਼ਾਟ ਤੋਂ ਇੱਕ ਸਕਿੰਟ ਦੇ ਇੱਕ ਹਿੱਸੇ ਬਾਅਦ ਵੀ ਕੈਪਚਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਡੇਟਾਬੇਸ ਰੀਸਟੋਰ ਕਰਨ ‘ਤੇ ਕ੍ਰਮ ਨੰਬਰਾਂ ਦਾ ਮੇਲ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਜਿਸ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਘਾਤਕ ਭ੍ਰਿਸ਼ਟਾਚਾਰ (corruption) ਹੋ ਸਕਦਾ ਹੈ।
ਹਾਈ-ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਸਿਸਟਮਾਂ ‘ਤੇ “VM ਸਟਨ” ਪ੍ਰਭਾਵ
ਸਨੈਪਸ਼ਾਟ ਬਣਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ—ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਸਨੈਪਸ਼ਾਟ ਏਕੀਕਰਣ ਪ੍ਰਕਿਰਿਆ—ਇੱਕ ਵਰਤਾਰੇ ਦਾ ਕਾਰਨ ਬਣਦੀ ਹੈ ਜਿਸਨੂੰ “VM ਸਟਨ” ਕਿਹਾ ਜਾਂਦਾ ਹੈ।
I/O ਨੂੰ ਬੇਸ ਡਿਸਕ ਤੋਂ ਡੈਲਟਾ ਡਿਸਕ ‘ਤੇ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਬਦਲਣ ਲਈ, ਹਾਈਪਰਵਾਈਜ਼ਰ ਨੂੰ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨੂੰ ਸੰਖੇਪ ਵਿੱਚ ਰੋਕਣਾ (stun) ਪੈਂਦਾ ਹੈ। ਇੱਕ ਹਲਕੇ ਲੋਡ ਵਾਲੇ ਵੈੱਬ ਸਰਵਰ ਲਈ, ਇਹ ਸਟਨ 10-50 ਮਿਲੀਸਕਿੰਟ ਤੱਕ ਰਹਿ ਸਕਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਦਾ ਧਿਆਨ ਨਹੀਂ ਜਾਂਦਾ। ਹਾਲਾਂਕਿ, ਵੱਡੇ I/O ਵਾਲੇ ਉੱਚ-ਥ੍ਰੂਪੁੱਟ ਡੇਟਾਬੇਸ ਲਈ, ਇੱਕ ਵੱਡੀ ਡੈਲਟਾ ਡਿਸਕ ਨੂੰ ਏਕੀਕ੍ਰਿਤ ਕਰਨਾ VM ਨੂੰ ਕਈ ਸਕਿੰਟਾਂ ਲਈ ਰੋਕ ਸਕਦਾ ਹੈ।
VM ਸਟਨ ਦੌਰਾਨ:
* ਨੈੱਟਵਰਕ ਕਨੈਕਸ਼ਨ ਡ੍ਰੌਪ ਹੋ ਜਾਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨ ਟਾਈਮਆਊਟ ਹੁੰਦਾ ਹੈ।
* ਉੱਚ-ਉਪਲਬਧਤਾ ਕਲੱਸਟਰ (ਜਿਵੇਂ ਕਿ SQL Server Always On, PostgreSQL Patroni, ਜਾਂ MySQL Galera) ਹਾਰਟਬੀਟ ਜਾਂਚਾਂ ਨੂੰ ਗੁਆ ਦਿੰਦੇ ਹਨ।
* ਕਲੱਸਟਰ ਇਹ ਮੰਨ ਸਕਦਾ ਹੈ ਕਿ ਸਟਨ ਹੋਇਆ ਨੋਡ ਮਰ ਚੁੱਕਾ ਹੈ, ਜਿਸ ਨਾਲ ਇੱਕ ਬੇਲੋੜਾ ਅਤੇ ਵਿਘਨਕਾਰੀ ਫੇਲਓਵਰ (ਸਪਲਿਟ-ਬ੍ਰੇਨ ਦ੍ਰਿਸ਼) ਸ਼ੁਰੂ ਹੋ ਸਕਦਾ ਹੈ।
ਟੋਰਨ ਪੇਜ ਅਤੇ I/O ਗਲਤ ਅਲਾਈਨਮੈਂਟ
ਡੇਟਾਬੇਸ ਇੰਜਣ ਆਮ ਤੌਰ ‘ਤੇ ਖਾਸ ਪੰਨੇ ਦੇ ਆਕਾਰਾਂ (ਜਿਵੇਂ ਕਿ PostgreSQL ਅਤੇ SQL Server ਲਈ 8KB, InnoDB ਲਈ 16KB) ਵਿੱਚ ਡੇਟਾ ਲਿਖਦੇ ਹਨ। ਹਾਲਾਂਕਿ, ਅੰਡਰਲਾਈੰਗ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਅਤੇ ਸਟੋਰੇਜ ਐਰੇ ਛੋਟੇ ਬਲਾਕਾਂ (ਜਿਵੇਂ ਕਿ 4KB ਜਾਂ 512 ਬਾਈਟਸ) ਵਿੱਚ I/O ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦੇ ਹਨ।
ਜੇਕਰ ਕੋਈ ਹਾਈਪਰਵਾਈਜ਼ਰ ਬਿਲਕੁਲ ਉਸੇ ਸਮੇਂ ਸਨੈਪਸ਼ਾਟ ਲੈਂਦਾ ਹੈ ਜਦੋਂ ਡੇਟਾਬੇਸ 8KB ਦਾ ਪੰਨਾ ਲਿਖ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਸਨੈਪਸ਼ਾਟ ਨਵੇਂ ਡੇਟਾ ਦੇ ਪਹਿਲੇ 4KB ਅਤੇ ਪੁਰਾਣੇ ਡੇਟਾ ਦੇ ਆਖਰੀ 4KB ਨੂੰ ਕੈਪਚਰ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਇੱਕ ਟੋਰਨ ਪੇਜ ਬਣਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਸਨੈਪਸ਼ਾਟ ਨੂੰ ਰੀਸਟੋਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ, ਤਾਂ ਡੇਟਾਬੇਸ ਪੰਨੇ ਨੂੰ ਪੜ੍ਹੇਗਾ, ਚੈੱਕਸਮ ਵੈਧਤਾ ਵਿੱਚ ਅਸਫਲ ਹੋ ਜਾਵੇਗਾ, ਅਤੇ ਡੇਟਾਬੇਸ ਨੂੰ ਖਰਾਬ (corrupt) ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕਰੇਗਾ।
ਵਿਸ਼ੇਸ਼ ਡੇਟਾਬੇਸ ਇੰਜਣਾਂ ਲਈ ਅਸਲ-ਸੰਸਾਰ ਦੇ ਨਤੀਜੇ
ਵੱਖ-ਵੱਖ ਡੇਟਾਬੇਸ ਇੰਜਣ ਕ੍ਰੈਸ਼-ਕਨਸਿਸਟੈਂਟ ਸਨੈਪਸ਼ਾਟਾਂ ‘ਤੇ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦੇ ਹਨ, ਪਰ ਕੋਈ ਵੀ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਤਾਵਰਣ ਵਿੱਚ ਸੁਚਾਰੂ ਢੰਗ ਨਾਲ ਨਹੀਂ ਸੰਭਾਲਦਾ।
- PostgreSQL: PostgreSQL ਬਹੁਤ ਜ਼ਿਆਦਾ
pg_walਡਾਇਰੈਕਟਰੀ ‘ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਸਨੈਪਸ਼ਾਟ ਡੇਟਾ ਡਾਇਰੈਕਟਰੀ ($PGDATA) ਅਤੇ WAL ਨੂੰ ਸਿੰਕ ਤੋਂ ਬਾਹਰ ਕੈਪਚਰ ਕਰਦਾ ਹੈ, ਤਾਂ PostgreSQL ਸ਼ੁਰੂ ਹੋਣ ਵਿੱਚ ਅਸਫਲ ਹੋ ਜਾਵੇਗਾ, ਅਤੇPANIC: could not locate a valid checkpoint recordਗਲਤੀ ਦਿਖਾਏਗਾ। - MySQL/InnoDB: InnoDB ਟੋਰਨ ਪੇਜਾਂ ਨੂੰ ਰੋਕਣ ਲਈ ਡਬਲ-ਰਾਈਟ ਬਫਰ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜੋ ਕ੍ਰੈਸ਼-ਕਨਸਿਸਟੈਂਟ ਸਥਿਤੀਆਂ ਦੇ ਵਿਰੁੱਧ ਕੁਝ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਜੇਕਰ
ibdata1ਫਾਈਲ ਅਤੇib_logfileਸਿੰਕ ਤੋਂ ਬਾਹਰ ਕੈਪਚਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ InnoDB ਇੰਜਣ ਰਿਕਵਰੀ ‘ਤੇ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਵੇਗਾ। - Microsoft SQL Server: SQL Server I/O ਫ੍ਰੀਜ਼ਿੰਗ ਲਈ ਬਹੁਤ ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ। ਸਹੀ VSS (Volume Shadow Copy Service) ਏਕੀਕਰਣ ਤੋਂ ਬਿਨਾਂ, ਸਟੈਂਡਰਡ VM ਸਨੈਪਸ਼ਾਟ ਤੋਂ SQL Server ਨੂੰ ਰੀਸਟੋਰ ਕਰਨ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਅਕਸਰ ਸ਼ੱਕੀ ਡੇਟਾਬੇਸ ਅਤੇ ਟੁੱਟੀਆਂ ਲੌਗ ਚੇਨਾਂ ਬਣ ਜਾਂਦੀਆਂ ਹਨ, ਜੋ ਤੁਹਾਡੀ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ (PITR) ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਨਸ਼ਟ ਕਰ ਦਿੰਦੀਆਂ ਹਨ।
ਵਰਚੁਅਲਾਈਜ਼ਡ ਡੇਟਾਬੇਸ ਦਾ ਸੁਰੱਖਿਅਤ ਬੈਕਅੱਪ ਲੈਣ ਲਈ ਵਧੀਆ ਅਭਿਆਸ
ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਡੇਟਾਬੇਸ ਦੀ ਸੁਰੱਖਿਆ ਲਈ, ਤੁਹਾਨੂੰ ਕ੍ਰੈਸ਼-ਕਨਸਿਸਟੈਂਟ ਬੈਕਅੱਪ ਤੋਂ ਐਪਲੀਕੇਸ਼ਨ-ਕਨਸਿਸਟੈਂਟ ਬੈਕਅੱਪ ਵੱਲ ਵਧਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਲਈ ਬੈਕਅੱਪ ਵਿਧੀ ਨੂੰ ਡੇਟਾਬੇਸ ਇੰਜਣ ਨਾਲ ਸੰਚਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਇਹ ਮੈਮੋਰੀ ਨੂੰ ਡਿਸਕ ‘ਤੇ ਫਲੱਸ਼ ਕਰਨ ਅਤੇ ਸਨੈਪਸ਼ਾਟ ਲੈਂਦੇ ਸਮੇਂ I/O ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਅਸਥਾਈ ਤੌਰ ‘ਤੇ ਰੋਕਣ ਲਈ ਮਜਬੂਰ ਹੁੰਦਾ ਹੈ।
1. ਐਪਲੀਕੇਸ਼ਨ-ਅਵੇਅਰ ਕੁਇਜ਼ਿੰਗ (VSS ਅਤੇ fsfreeze) ਦਾ ਲਾਭ ਉਠਾਓ
Windows (SQL Server) ਲਈ:
ਹਮੇਸ਼ਾ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡਾ ਬੈਕਅੱਪ ਹੱਲ Microsoft Volume Shadow Copy Service (VSS) ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ VSS-ਅਵੇਅਰ ਬੈਕਅੱਪ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਤਾਂ SQL Server VSS Writer ਡੇਟਾਬੇਸ I/O ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰ ਦਿੰਦਾ ਹੈ, ਬਕਾਇਆ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਡਿਸਕ ‘ਤੇ ਫਲੱਸ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਸਨੈਪਸ਼ਾਟ ਪੂਰੀ ਤਰ੍ਹਾਂ ਐਪਲੀਕੇਸ਼ਨ-ਕਨਸਿਸਟੈਂਟ ਹੈ।
Linux (PostgreSQL / MySQL) ਲਈ:
Linux ਕੋਲ VSS ਦਾ ਕੋਈ ਮੂਲ ਬਰਾਬਰ ਨਹੀਂ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਕਨਸਿਸਟੈਂਸੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਹਾਈਪਰਵਾਈਜ਼ਰ ਦੇ ਗੈਸਟ ਟੂਲਸ (ਜਿਵੇਂ ਕਿ VMware Tools) ਦੇ ਨਾਲ ਪ੍ਰੀ-ਫ੍ਰੀਜ਼ ਅਤੇ ਪੋਸਟ-ਥੌਅ ਸਕ੍ਰਿਪਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।
ਇੱਥੇ PostgreSQL 15+ ਲਈ ਇੱਕ VMware pre-freeze-script ਦੀ ਉਦਾਹਰਣ ਹੈ ਜੋ ਸਨੈਪਸ਼ਾਟ ਲਈ ਡੇਟਾਬੇਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਤਿਆਰ ਕਰਦੀ ਹੈ:
#!/bin/bash
# /usr/sbin/pre-freeze-script
# ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇਹ ਸਕ੍ਰਿਪਟ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਹੈ (chmod +x)
# 1. PostgreSQL ਨੂੰ ਬੈਕਅੱਪ ਲਈ ਤਿਆਰ ਹੋਣ ਲਈ ਕਹੋ
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""
# 2. ਫਾਈਲ ਸਿਸਟਮ ਬਫਰਾਂ ਨੂੰ ਡਿਸਕ 'ਤੇ ਫਲੱਸ਼ ਕਰੋ
sync
# 3. ਫਾਈਲ ਸਿਸਟਮ ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰੋ (ਇਹ ਮੰਨ ਕੇ ਕਿ ਡੇਟਾ /var/lib/pgsql 'ਤੇ ਹੈ)
fsfreeze -f /var/lib/pgsql
ਅਤੇ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਸੰਬੰਧਿਤ post-thaw-script:
#!/bin/bash
# /usr/sbin/post-thaw-script
# 1. ਫਾਈਲ ਸਿਸਟਮ ਨੂੰ ਅਨਫ੍ਰੀਜ਼ ਕਰੋ
fsfreeze -u /var/lib/pgsql
# 2. PostgreSQL ਨੂੰ ਦੱਸੋ ਕਿ ਬੈਕਅੱਪ ਪੂਰਾ ਹੋ ਗਿਆ ਹੈ
su - postgres -c "psql -c "SELECT pg_backup_stop();""
2. ਨੇਟਿਵ ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਉਪਯੋਗਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ
ਹਾਲਾਂਕਿ ਐਪਲੀਕੇਸ਼ਨ-ਕਨਸਿਸਟੈਂਟ ਸਨੈਪਸ਼ਾਟ ਸਟੈਂਡਰਡ ਸਨੈਪਸ਼ਾਟ ਨਾਲੋਂ ਬਿਹਤਰ ਹਨ, ਉਹਨਾਂ ਵਿੱਚ ਅਜੇ ਵੀ VM ਸਟਨ ਦਾ ਜੋਖਮ ਹੁੰਦਾ ਹੈ। ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਲਈ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਪਹੁੰਚ ਨੇਟਿਵ, ਸਟ੍ਰੀਮਿੰਗ ਬੈਕਅੱਪ ਉਪਯੋਗਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ ਜੋ ਹਾਈਪਰਵਾਈਜ਼ਰ ਤੋਂ ਸੁਤੰਤਰ ਤੌਰ ‘ਤੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ।
PostgreSQL (pg_basebackup):
pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P
MySQL/MariaDB (Percona XtraBackup / Mariabackup):
ਇਹ ਟੂਲ ਡੇਟਾ ਫਾਈਲਾਂ ਨੂੰ ਕਾਪੀ ਕਰਕੇ ਅਤੇ ਨਾਲ ਹੀ ਰੀਡੋ ਲੌਗ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਟਰੈਕ ਕਰਕੇ ਹੌਟ, ਨਾਨ-ਬਲੌਕਿੰਗ ਬੈਕਅੱਪ ਲੈਂਦੇ ਹਨ।
mariabackup --backup --target-dir=/mnt/backups/mysql_backup --user=root --password=SecurePass
SQL Server (T-SQL):
BACKUP DATABASE [ProductionDB]
TO DISK = N'Z:BackupsProductionDB.bak'
WITH NOFORMAT, NOINIT, NAME = N'ProductionDB-Full Backup',
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;
GO
3. ਲੌਗ ਆਰਕਾਈਵਿੰਗ ਰਾਹੀਂ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ (PITR) ਲਾਗੂ ਕਰੋ
ਇੱਕ ਰੋਜ਼ਾਨਾ ਸਨੈਪਸ਼ਾਟ ਜਾਂ ਪੂਰਾ ਬੈਕਅੱਪ ਤੁਹਾਨੂੰ ਸਿਰਫ ਉਸ ਸਮੇਂ ਤੱਕ ਸੁਰੱਖਿਅਤ ਕਰਦਾ ਹੈ ਜਦੋਂ ਉਹ ਲਿਆ ਗਿਆ ਸੀ। ਜੇਕਰ ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਸ਼ਾਮ 4:00 ਵਜੇ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡਾ ਆਖਰੀ ਸਨੈਪਸ਼ਾਟ ਸਵੇਰੇ 2:00 ਵਜੇ ਸੀ, ਤਾਂ ਤੁਸੀਂ 14 ਘੰਟਿਆਂ ਦਾ ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਡੇਟਾ ਗੁਆ ਦਿੰਦੇ ਹੋ।
ਸੱਚੀ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਲਚਕਤਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਪੂਰੇ ਐਪਲੀਕੇਸ਼ਨ-ਕਨਸਿਸਟੈਂਟ ਬੈਕਅੱਪਾਂ ਨੂੰ ਨਿਰੰਤਰ ਲੌਗ ਆਰਕਾਈਵਿੰਗ (ਹਰ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ WAL, ਰੀਡੋ ਲੌਗਸ, ਜਾਂ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗਸ ਦਾ ਬੈਕਅੱਪ ਲੈਣਾ) ਨਾਲ ਜੋੜਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ DBA ਨੂੰ ਕਿਸੇ ਆਫ਼ਤ ਤੋਂ ਪਹਿਲਾਂ ਡੇਟਾਬੇਸ ਨੂੰ ਇੱਕ ਖਾਸ ਮਿੰਟ ਜਾਂ ਕਿਸੇ ਖਾਸ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ID ‘ਤੇ ਰੀਸਟੋਰ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।
CloudSave ਨਾਲ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਬੈਕਅੱਪ ਰਣਨੀਤੀਆਂ
ਕਸਟਮ ਪ੍ਰੀ-ਫ੍ਰੀਜ਼ ਸਕ੍ਰਿਪਟਾਂ, ਨੇਟਿਵ ਡੰਪਾਂ ਲਈ ਕ੍ਰੌਨ ਜੌਬਸ, ਅਤੇ ਦਰਜਨਾਂ ਡੇਟਾਬੇਸ ਸਰਵਰਾਂ ਵਿੱਚ ਲੌਗ ਸ਼ਿਪਿੰਗ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ DevOps ਟੀਮਾਂ ਲਈ ਇੱਕ ਸੰਚਾਲਨ ਸੁਪਨਾ ਹੈ। ਇੱਥੇ CloudSave ਵਰਗਾ ਇੱਕ ਐਂਟਰਪ੍ਰਾਈਜ਼-ਗ੍ਰੇਡ ਪਲੇਟਫਾਰਮ ਮਹੱਤਵਪੂਰਨ ਬਣ ਜਾਂਦਾ ਹੈ।
CloudSave ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਅਤੇ ਡੇਟਾਬੇਸ ਆਰਕੀਟੈਕਚਰ ਵਿਚਕਾਰ ਪਾੜੇ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ। ਅੰਨ੍ਹੇ ਹਾਈਪਰਵਾਈਜ਼ਰ ਸਨੈਪਸ਼ਾਟ ‘ਤੇ ਨਿਰਭਰ ਕਰਨ ਦੀ ਬਜਾਏ, CloudSave ਐਪਲੀਕੇਸ਼ਨ-ਅਵੇਅਰ ਏਜੰਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜੋ SQL Server, PostgreSQL, MySQL, ਅਤੇ Oracle ਨਾਲ ਨੇਟਿਵ ਤੌਰ ‘ਤੇ ਏਕੀਕ੍ਰਿਤ ਹੁੰਦੇ ਹਨ।
ਜਦੋਂ CloudSave ਇੱਕ ਬੈਕਅੱਪ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ:
1. ਇਹ ਨੇਟਿਵ API (ਜਿਵੇਂ ਕਿ Windows ਲਈ VSS ਜਾਂ Linux ਲਈ ਨੇਟਿਵ WAL ਸਟ੍ਰੀਮਿੰਗ) ਰਾਹੀਂ ਸਿੱਧੇ ਡੇਟਾਬੇਸ ਇੰਜਣ ਨਾਲ ਸੰਚਾਰ ਕਰਦਾ ਹੈ।
2. ਇਹ ਵਿਘਨਕਾਰੀ VM ਸਟਨ ਪੈਦਾ ਕੀਤੇ ਬਿਨਾਂ ਮੈਮੋਰੀ ਬਫਰਾਂ ਨੂੰ ਡਿਸਕ ‘ਤੇ ਫਲੱਸ਼ ਕਰਨ ਦਾ ਪ੍ਰਬੰਧ ਕਰਦਾ ਹੈ।
3. ਇਹ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਡੇਟਾ ਫਾਈਲਾਂ ਨੂੰ ਕੈਪਚਰ ਕਰਦਾ ਹੈ ਅਤੇ ਆਪਣੇ ਆਪ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਟ੍ਰੰਕੇਸ਼ਨ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ।
4. ਇਹ ਲਗਾਤਾਰ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗਸ ਦਾ ਬੈਕਅੱਪ ਲੈਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਕੁਝ ਕਲਿੱਕਾਂ ਨਾਲ ਗ੍ਰੈਨਿਊਲਰ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ (PITR) ਸਮਰੱਥ ਹੁੰਦੀ ਹੈ।
ਐਪਲੀਕੇਸ਼ਨ ਕਨਸਿਸਟੈਂਸੀ ਦੀ ਗੁੰਝਲਤਾ ਨੂੰ CloudSave ‘ਤੇ ਆਫਲੋਡ ਕਰਕੇ, DBA ਅਤੇ sysadmins ਆਪਣੇ ਪ੍ਰੋਡਕਸ਼ਨ ਕਲੱਸਟਰਾਂ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਜਾਂ ਉਪਲਬਧਤਾ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤੇ ਬਿਨਾਂ ਡੇਟਾ ਦੀ ਇਕਸਾਰਤਾ ਦੀ ਗਰੰਟੀ ਦੇ ਸਕਦੇ ਹਨ।
ਸਿੱਟਾ
ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਸਨੈਪਸ਼ਾਟ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਇੱਕ ਸ਼ਾਨਦਾਰ ਸਾਧਨ ਹਨ, ਪਰ ਉਹ ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਡੇਟਾਬੇਸ ਦੀਆਂ ACID ਲੋੜਾਂ ਨਾਲ ਮੂਲ ਰੂਪ ਵਿੱਚ ਅਸੰਗਤ ਹਨ। ਕ੍ਰੈਸ਼-ਕਨਸਿਸਟੈਂਟ ਹਾਈਪਰਵਾਈਜ਼ਰ ਸਨੈਪਸ਼ਾਟ ‘ਤੇ ਨਿਰਭਰ ਕਰਨਾ ਤੁਹਾਡੀ ਸੰਸਥਾ ਨੂੰ ਟੋਰਨ ਪੇਜਾਂ, ਟੁੱਟੀਆਂ ਰੀਪਲੀਕੇਸ਼ਨ ਚੇਨਾਂ, ਅਤੇ ਵਿਨਾਸ਼ਕਾਰੀ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਦੇ ਜੋਖਮ ਵਿੱਚ ਪਾਉਂਦਾ ਹੈ।
ਆਪਣੇ ਮਿਸ਼ਨ-ਕ੍ਰਿਟੀਕਲ ਡੇਟਾ ਦੀ ਸੁਰੱਖਿਆ ਲਈ, ਤੁਹਾਨੂੰ ਐਪਲੀਕੇਸ਼ਨ-ਅਵੇਅਰ ਕੁਇਜ਼ਿੰਗ ਲਾਗੂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਨੇਟਿਵ ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਵਿਧੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਨਿਰੰਤਰ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਆਰਕਾਈਵਜ਼ ਨੂੰ ਕਾਇਮ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਦੇਸ਼-ਨਿਰਮਿਤ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਬੈਕਅੱਪ ਹੱਲਾਂ ਨੂੰ ਅਪਣਾ ਕੇ, ਤੁਸੀਂ ਇਹ ਯਕੀਨੀ ਬਣਾ ਸਕਦੇ ਹੋ ਕਿ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਉੱਚ ਪੱਧਰ ‘ਤੇ ਉਪਲਬਧ, ਪੂਰੀ ਤਰ੍ਹਾਂ ਰਿਕਵਰ ਕਰਨ ਯੋਗ, ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੁਰੱਖਿਅਤ ਰਹਿਣ।
