Categories
Database Backup

** Discover how DevOps engineers and DBAs can detect corrupted database backups before disaster strikes. Learn advanced techniques for PostgreSQL, SQL Server, and MySQL, including automated restore testing and checksum validation.

ਡੇਟਾਬੇਸ ਪ੍ਰਸ਼ਾਸਨ ਅਤੇ ਸਾਈਟ ਰਿਲਾਇਬਿਲਟੀ ਇੰਜੀਨੀਅਰਿੰਗ ਦੀ ਉੱਚ-ਦਾਅ ਵਾਲੀ ਦੁਨੀਆ ਵਿੱਚ, ਇੱਕ ਜਾਣਿਆ-ਪਛਾਣਿਆ ਸਿਧਾਂਤ ਹੈ: ਸ਼੍ਰੋਡਿੰਜਰ ਦਾ ਬੈਕਅੱਪ (Schrödinger’s Backup)। ਕਿਸੇ ਵੀ ਬੈਕਅੱਪ ਦੀ ਸਥਿਤੀ ਉਦੋਂ ਤੱਕ ਅਣਜਾਣ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਇਸਨੂੰ ਰੀਸਟੋਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਦੇ। ਉਸ ਪਲ ਤੱਕ, ਇਹ ਇੱਕ ਕੁਆਂਟਮ ਸਥਿਤੀ ਵਿੱਚ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਾਰਜਸ਼ੀਲ ਵੀ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਰਾਬ ਵੀ।

DevOps ਇੰਜੀਨੀਅਰਾਂ ਅਤੇ DBA ਲਈ, ਇੱਕ ਸਰਗਰਮ ਘਟਨਾ ਦੌਰਾਨ ਇਹ ਪਤਾ ਲੱਗਣਾ ਕਿ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਖਰਾਬ ਹੋ ਗਿਆ ਹੈ, ਸਭ ਤੋਂ ਭਿਆਨਕ ਸਥਿਤੀ ਹੈ। ਇਹ ਇੱਕ ਰੁਟੀਨ ਰਿਕਵਰੀ ਕਾਰਵਾਈ ਨੂੰ ਡੇਟਾ ਦੇ ਵਿਨਾਸ਼ਕਾਰੀ ਨੁਕਸਾਨ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਡੇਟਾ ਦੀ ਇਕਸਾਰਤਾ ਦਾ ਇਹ “ਚੁੱਪ ਕਾਤਲ” ਅਕਸਰ ਕਿਸੇ ਦਾ ਧਿਆਨ ਨਹੀਂ ਖਿੱਚਦਾ ਕਿਉਂਕਿ ਬੈਕਅੱਪ ਜੌਬਸ ਅਕਸਰ ਸਫਲ Exit Code 0 ਦੀ ਰਿਪੋਰਟ ਦਿੰਦੇ ਹਨ, ਭਾਵੇਂ ਕਿ ਅਸਲ ਡੇਟਾ ਖਰਾਬ ਹੋ ਚੁੱਕਾ ਹੋਵੇ।

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

ਬੈਕਅੱਪ ਦੇ ਖਰਾਬ ਹੋਣ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ

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

ਭੌਤਿਕ ਖਰਾਬੀ (Physical Corruption)

ਭੌਤਿਕ ਖਰਾਬੀ ਉਦੋਂ ਵਾਪਰਦੀ ਹੈ ਜਦੋਂ ਸਟੋਰੇਜ ਮੀਡੀਆ ‘ਤੇ ਅਸਲ ਬਿੱਟ ਬਦਲ ਜਾਂਦੇ ਹਨ। ਇਹ ਸਰੋਤ ਡਿਸਕ ਤੋਂ ਪੜ੍ਹਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ, ਨੈੱਟਵਰਕ ਟ੍ਰਾਂਸਫਰ ਦੌਰਾਨ, ਜਾਂ ਟਾਰਗੇਟ ਸਟੋਰੇਜ ‘ਤੇ ਆਰਾਮ ਕਰਨ ਵੇਲੇ ਹੋ ਸਕਦਾ ਹੈ।
* ਬਿੱਟ ਰੌਟ (Bit Rot): ਸਟੋਰੇਜ ਮੀਡੀਆ ਦਾ ਹੌਲੀ-ਹੌਲੀ ਖਰਾਬ ਹੋਣਾ ਬਿੱਟਾਂ ਨੂੰ ਚੁੱਪਚਾਪ ਬਦਲ ਸਕਦਾ ਹੈ।
* ਟ੍ਰਾਂਸਿਟ ਗਲਤੀਆਂ: ਹਾਲਾਂਕਿ TCP ਵਿੱਚ ਚੈੱਕਸਮ ਹੁੰਦੇ ਹਨ, ਉਹ ਕਮਜ਼ੋਰ (16-bit) ਹੁੰਦੇ ਹਨ। ਉੱਚ-ਥ੍ਰੂਪੁੱਟ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਵਾਇਰ ਉੱਤੇ ਅਜਿਹੀ ਡੇਟਾ ਖਰਾਬੀ ਹੋ ਸਕਦੀ ਹੈ ਜੋ TCP ਫੜਨ ਵਿੱਚ ਅਸਫਲ ਰਹਿੰਦਾ ਹੈ।
* ਸਟੋਰੇਜ ਕੰਟਰੋਲਰ ਨੁਕਸ: RAID ਕੰਟਰੋਲਰਾਂ ਜਾਂ SAN ਫੈਬਰਿਕਸ ਵਿੱਚ ਹਾਰਡਵੇਅਰ ਬੱਗ OS ਨੂੰ ਸਫਲਤਾ ਦੀ ਰਿਪੋਰਟ ਦਿੰਦੇ ਹੋਏ ਗਲਤ ਡੇਟਾ ਲਿਖ ਸਕਦੇ ਹਨ।

ਤਰਕਪੂਰਨ ਖਰਾਬੀ (Logical Corruption)

ਤਰਕਪੂਰਨ ਖਰਾਬੀ ਵਧੇਰੇ ਖਤਰਨਾਕ ਹੈ ਕਿਉਂਕਿ ਬੈਕਅੱਪ ਫਾਈਲ ਖੁਦ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਹੀ ਹੁੰਦੀ ਹੈ, ਪਰ ਇਸਦੇ ਅੰਦਰਲਾ ਡੇਟਾ ਟੁੱਟਿਆ ਹੁੰਦਾ ਹੈ।
* ਗਾਰਬੇਜ ਇਨ, ਗਾਰਬੇਜ ਆਊਟ (GIGO): ਜੇਕਰ ਤੁਹਾਡੇ ਲਾਈਵ ਡੇਟਾਬੇਸ ਵਿੱਚ ਕੋਈ ਖਰਾਬ ਇੰਡੈਕਸ ਜਾਂ ਟੁੱਟਿਆ ਪੇਜ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ ਬੈਕਅੱਪ ਟੂਲ ਉਸ ਖਰਾਬ ਪੇਜ ਨੂੰ ਵਫ਼ਾਦਾਰੀ ਨਾਲ ਕਾਪੀ ਕਰ ਸਕਦਾ ਹੈ। ਬੈਕਅੱਪ ਜੌਬ ਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਪਰ ਰੀਸਟੋਰ ਫੇਲ ਹੋ ਜਾਵੇਗਾ ਜਾਂ ਇੱਕ ਟੁੱਟਿਆ ਡੇਟਾਬੇਸ ਮਿਲੇਗਾ।
* ਅਧੂਰੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ: ਡੇਟਾਬੇਸ I/O ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਫ੍ਰੀਜ਼ ਕੀਤੇ ਬਿਨਾਂ (ਉਦਾਹਰਨ ਲਈ, MySQL ਵਿੱਚ FLUSH TABLES WITH READ LOCK ਦੀ ਵਰਤੋਂ ਨਾ ਕਰਨਾ) ਲਏ ਗਏ ਫਾਈਲ-ਸਿਸਟਮ ਪੱਧਰ ਦੇ ਸਨੈਪਸ਼ਾਟ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਟੁੱਟੇ ਪੇਜ ਅਤੇ ਨਾ-ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਯੋਗ ਸਥਿਤੀਆਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ।

ਸਰਗਰਮ ਖੋਜ: ਚੈੱਕਸਮ ਅਤੇ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਹੈਸ਼ਿੰਗ

ਭੌਤਿਕ ਖਰਾਬੀ ਦੇ ਵਿਰੁੱਧ ਬਚਾਅ ਦੀ ਪਹਿਲੀ ਲਾਈਨ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਪ੍ਰਮਾਣਿਕਤਾ ਹੈ। ਫਾਈਲ ਦੇ ਆਕਾਰ ਜਾਂ ਸੋਧ ਦੀਆਂ ਤਾਰੀਖਾਂ ‘ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਨਾਕਾਫੀ ਹੈ।

ਡੇਟਾਬੇਸ-ਪੱਧਰ ਦੇ ਚੈੱਕਸਮ ਨੂੰ ਸਮਰੱਥ ਕਰਨਾ

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

PostgreSQL ਲਈ, ਤੁਸੀਂ ਕਲੱਸਟਰ ਸ਼ੁਰੂਆਤ ਦੌਰਾਨ ਡੇਟਾ ਚੈੱਕਸਮ ਨੂੰ ਸਮਰੱਥ ਕਰ ਸਕਦੇ ਹੋ:

# ਚੈੱਕਸਮ ਸਮਰੱਥ ਨਾਲ ਇੱਕ ਨਵਾਂ PostgreSQL ਕਲੱਸਟਰ ਸ਼ੁਰੂ ਕਰੋ
initdb --data-checksums -D /var/lib/postgresql/data

ਨੋਟ: ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ PostgreSQL ਕਲੱਸਟਰ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਆਫਲਾਈਨ ਸਮਰੱਥ ਕਰਨ ਲਈ pg_checksums ਉਪਯੋਗਤਾ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ।

Microsoft SQL Server ਲਈ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ PAGE_VERIFY ਨੂੰ CHECKSUM ‘ਤੇ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ (ਆਧੁਨਿਕ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਡਿਫੌਲਟ, ਪਰ ਪੁਰਾਣੇ ਸਿਸਟਮਾਂ ‘ਤੇ ਜਾਂਚ ਕਰਨਾ ਲਾਭਦਾਇਕ ਹੈ):

ALTER DATABASE [ProductionDB] SET PAGE_VERIFY CHECKSUM;
GO

ਸਟੋਰੇਜ ‘ਤੇ ਬੈਕਅੱਪ ਦੀ ਪੁਸ਼ਟੀ

ਇੱਕ ਵਾਰ ਜਦੋਂ ਬੈਕਅੱਪ ਤੁਹਾਡੇ ਸਟੋਰੇਜ ਟਾਰਗੇਟ ‘ਤੇ ਪਹੁੰਚ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸਦੀ ਇਕਸਾਰਤਾ ਦੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਤੌਰ ‘ਤੇ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। CloudSave ਵਰਗੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਬੈਕਅੱਪ ਪਲੇਟਫਾਰਮ ਟ੍ਰਾਂਸਿਟ ਅਤੇ ਸਟੋਰੇਜ ਦੌਰਾਨ ਬੈਕਅੱਪ ਬਲਾਕਾਂ ਦੇ SHA-256 ਹੈਸ਼ ਦੀ ਸਵੈਚਲਿਤ ਤੌਰ ‘ਤੇ ਗਣਨਾ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਕਸਟਮ ਸਕ੍ਰਿਪਟਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਹੱਥੀਂ ਲਾਗੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:

# ਬੈਕਅੱਪ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ SHA-256 ਹੈਸ਼ ਤਿਆਰ ਕਰੋ
sha256sum prod_db_backup.tar.gz > prod_db_backup.tar.gz.sha256

# ਸਟੋਰੇਜ ਸਰਵਰ 'ਤੇ ਹੈਸ਼ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ
sha256sum -c prod_db_backup.tar.gz.sha256

ਡੇਟਾਬੇਸ-ਵਿਸ਼ੇਸ਼ ਪ੍ਰਮਾਣਿਕਤਾ ਤਕਨੀਕਾਂ

ਵੱਖ-ਵੱਖ ਡੇਟਾਬੇਸ ਇੰਜਣ ਆਪਣੇ ਬੈਕਅੱਪ ਆਰਟੀਫੈਕਟਸ ਦੀ ਇਕਸਾਰਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਨੇਟਿਵ ਟੂਲ ਪੇਸ਼ ਕਰਦੇ ਹਨ।

PostgreSQL: pg_verifybackup

PostgreSQL 13 ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ, pg_verifybackup pg_basebackup ਨਾਲ ਲਏ ਗਏ ਭੌਤਿਕ ਬੈਕਅੱਪ ਲਈ ਇੱਕ ਗੇਮ-ਚੇਂਜਰ ਹੈ। ਇਹ ਬੈਕਅੱਪ ਦੌਰਾਨ ਤਿਆਰ ਕੀਤੀ ਗਈ backup_manifest ਫਾਈਲ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਮੌਜੂਦ ਹਨ ਅਤੇ ਉਹਨਾਂ ਦੇ ਚੈੱਕਸਮ ਮੇਲ ਖਾਂਦੇ ਹਨ।

# ਇੱਕ ਭੌਤਿਕ ਬੇਸ ਬੈਕਅੱਪ ਡਾਇਰੈਕਟਰੀ ਦੇ ਵਿਰੁੱਧ ਤਸਦੀਕ ਚਲਾਓ
pg_verifybackup /mnt/backups/postgres/base_backup_20231025/

ਜੇਕਰ ਕਿਸੇ ਵੀ ਡੇਟਾ ਫਾਈਲ ਵਿੱਚ ਇੱਕ ਵੀ ਬਿੱਟ ਬਦਲਿਆ ਹੈ, ਤਾਂ pg_verifybackup ਇੱਕ ਘਾਤਕ ਗਲਤੀ ਸੁੱਟੇਗਾ, ਜਿਸ ਨਾਲ ਤੁਹਾਡੇ ਨਿਗਰਾਨੀ ਸਿਸਟਮ ਤੁਰੰਤ DBA ਟੀਮ ਨੂੰ ਸੁਚੇਤ ਕਰ ਸਕਣਗੇ।

Microsoft SQL Server: RESTORE VERIFYONLY

SQL Server ਬੈਕਅੱਪ ਫਾਈਲ ਨੂੰ ਅਸਲ ਵਿੱਚ ਰੀਸਟੋਰ ਕੀਤੇ ਬਿਨਾਂ ਉਸਦੀ ਭੌਤਿਕ ਇਕਸਾਰਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਇੱਕ ਨੇਟਿਵ ਕਮਾਂਡ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹ ਬੈਕਅੱਪ ਹੈਡਰਾਂ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ ਅਤੇ ਪੇਜ ਚੈੱਕਸਮ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ (ਜੇਕਰ ਉਹ ਬੈਕਅੱਪ ਦੌਰਾਨ ਸਮਰੱਥ ਸਨ)।

RESTORE VERIFYONLY 
FROM DISK = 'Z:BackupsProdDB_Full.bak' 
WITH CHECKSUM;

ਚੇਤਾਵਨੀ: RESTORE VERIFYONLY ਸਿਰਫ ਇਹ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਬੈਕਅੱਪ ਫਾਈਲ ਪੜ੍ਹਨਯੋਗ ਹੈ ਅਤੇ ਭੌਤਿਕ ਚੈੱਕਸਮ ਮੇਲ ਖਾਂਦੇ ਹਨ। ਇਹ ਤਰਕਪੂਰਨ ਇਕਸਾਰਤਾ ਦੀ ਗਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ। ਤਰਕਪੂਰਨ ਇਕਸਾਰਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ, ਤੁਹਾਨੂੰ ਪੂਰਾ ਰੀਸਟੋਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ DBCC CHECKDB ਚਲਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।

MySQL / InnoDB: Percona XtraBackup

MySQL ਵਾਤਾਵਰਣ ਲਈ, ਭੌਤਿਕ ਬੈਕਅੱਪ ਅਕਸਰ Percona XtraBackup ਦੁਆਰਾ ਸੰਭਾਲੇ ਜਾਂਦੇ ਹਨ। ਬੈਕਅੱਪ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਫਾਈਲਾਂ ਨੂੰ ਕਾਪੀ ਕਰਨਾ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ, ਪਰ ਬੈਕਅੱਪ ਉਦੋਂ ਤੱਕ ਇਕਸਾਰ ਨਹੀਂ ਹੁੰਦਾ ਜਦੋਂ ਤੱਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ (redo logs) ਲਾਗੂ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ। --prepare ਪੜਾਅ ਇੱਕ ਬਿਲਟ-ਇਨ ਇਕਸਾਰਤਾ ਜਾਂਚ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ।

# ਬੈਕਅੱਪ ਤਿਆਰ ਕਰਨਾ redo logs ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ। 
# ਜੇਕਰ ਬੈਕਅੱਪ ਖਰਾਬ ਹੈ, ਤਾਂ ਇਹ ਪੜਾਅ ਫੇਲ ਹੋ ਜਾਵੇਗਾ।
xtrabackup --prepare --target-dir=/data/backups/mysql/

ਗੋਲਡ ਸਟੈਂਡਰਡ: ਸਵੈਚਲਿਤ ਰੀਸਟੋਰ ਟੈਸਟਿੰਗ

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

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

ਸਵੈਚਲਿਤ ਰੀਸਟੋਰ ਪਾਈਪਲਾਈਨ ਬਣਾਉਣਾ

ਹੇਠਾਂ ਇੱਕ Bash ਸਕ੍ਰਿਪਟ ਦੀ ਉਦਾਹਰਣ ਹੈ ਜੋ PostgreSQL ਲੌਜੀਕਲ ਡੰਪ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਰੋਜ਼ਾਨਾ ਇੱਕ cron job ਜਾਂ CI ਰਨਰ (ਜਿਵੇਂ ਕਿ GitLab CI ਜਾਂ GitHub Actions) ਦੁਆਰਾ ਚਲਾਈ ਜਾ ਸਕਦੀ ਹੈ।

#!/bin/bash
set -e

BACKUP_FILE="/mnt/storage/prod_db_latest.dump"
DB_NAME="prod_db"
CONTAINER_NAME="pg_restore_test"

echo "[INFO] ਸਵੈਚਲਿਤ ਰੀਸਟੋਰ ਟੈਸਟ ਸ਼ੁਰੂ ਹੋ ਰਿਹਾ ਹੈ..."

# 1. ਇੱਕ ਅਸਥਾਈ PostgreSQL ਕੰਟੇਨਰ ਚਲਾਓ
docker run --name $CONTAINER_NAME 
  -e POSTGRES_PASSWORD=testpass 
  -d postgres:15

# PostgreSQL ਦੇ ਤਿਆਰ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰੋ
echo "[INFO] ਡੇਟਾਬੇਸ ਦੇ ਸ਼ੁਰੂ ਹੋਣ ਦੀ ਉਡੀਕ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ..."
until docker exec $CONTAINER_NAME pg_isready -U postgres; do
  sleep 2
done

# 2. ਟਾਰਗੇਟ ਡੇਟਾਬੇਸ ਬਣਾਓ
docker exec $CONTAINER_NAME psql -U postgres -c "CREATE DATABASE $DB_NAME;"

# 3. ਰੀਸਟੋਰ ਚਲਾਓ
echo "[INFO] ਬੈਕਅੱਪ ਰੀਸਟੋਰ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ..."
docker cp $BACKUP_FILE $CONTAINER_NAME:/tmp/backup.dump
docker exec $CONTAINER_NAME pg_restore -U postgres -d $DB_NAME -1 /tmp/backup.dump

# 4. ਲੌਜੀਕਲ ਪ੍ਰਮਾਣਿਕਤਾ ਕੁਐਰੀਆਂ ਚਲਾਓ
echo "[INFO] ਪ੍ਰਮਾਣਿਕਤਾ ਕੁਐਰੀਆਂ ਚਲਾਈਆਂ ਜਾ ਰਹੀਆਂ ਹਨ..."
# ਜਾਂਚ ਕਰੋ ਕਿ ਕੀ ਉਪਭੋਗਤਾ ਟੇਬਲ ਵਿੱਚ 10,000 ਤੋਂ ਵੱਧ ਰਿਕਾਰਡ ਹਨ
USER_COUNT=$(docker exec $CONTAINER_NAME psql -U postgres -d $DB_NAME -t -c "SELECT COUNT(*) FROM users;")

if [ "$USER_COUNT" -lt 10000 ]; then
    echo "[ERROR] ਲੌਜੀਕਲ ਪ੍ਰਮਾਣਿਕਤਾ ਫੇਲ ਹੋ ਗਈ। 10000 ਤੋਂ ਵੱਧ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਉਮੀਦ ਸੀ, $USER_COUNT ਮਿਲੇ"
    # ਇੱਥੇ PagerDuty / Slack ਅਲਰਟ ਚਲਾਓ
    exit 1
else
    echo "[SUCCESS] ਲੌਜੀਕਲ ਪ੍ਰਮਾਣਿਕਤਾ ਸਫਲ। ਉਪਭੋਗਤਾ ਗਿਣਤੀ: $USER_COUNT"
fi

# 5. ਅਸਥਾਈ ਵਾਤਾਵਰਣ ਨੂੰ ਹਟਾਓ
echo "[INFO] ਸਫਾਈ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ..."
docker rm -f $CONTAINER_NAME

echo "[INFO] ਸਵੈਚਲਿਤ ਰੀਸਟੋਰ ਟੈਸਟ ਸਫਲਤਾਪੂਰਵਕ ਪੂਰਾ ਹੋਇਆ।"

ਤੁਹਾਨੂੰ ਕੀ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

ਸਵੈਚਲਿਤ ਰੀਸਟੋਰ ਟੈਸਟਿੰਗ ਕਰਦੇ ਸਮੇਂ, ਸਿਰਫ ਇਹ ਨਾ ਦੇਖੋ ਕਿ ਡੇਟਾਬੇਸ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਐਪਲੀਕੇਸ਼ਨ-ਵਿਸ਼ੇਸ਼ ਪ੍ਰਮਾਣਿਕਤਾ ਕੁਐਰੀਆਂ ਚਲਾਓ:
1. ਰੋਅ ਕਾਉਂਟਸ (Row Counts): ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਮੁੱਖ ਟੇਬਲਾਂ ਵਿੱਚ ਉਮੀਦ ਅਨੁਸਾਰ ਰੋਅ ਗਿਣਤੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ, users ਟੇਬਲ ਖਾਲੀ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ)।
2. ਹਾਲੀਆ ਡੇਟਾ: ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਬੈਕਅੱਪ ਪੁਰਾਣਾ ਨਹੀਂ ਹੈ, ਪਿਛਲੇ 24 ਘੰਟਿਆਂ ਵਿੱਚ ਬਣਾਏ ਗਏ ਰਿਕਾਰਡਾਂ ਲਈ ਕੁਐਰੀ ਕਰੋ।
3. ਰੈਫਰੈਂਸ਼ੀਅਲ ਇੰਟੈਗ੍ਰਿਟੀ: ਅਨਾਥ ਫੌਰਨ ਕੀਜ਼ (orphaned foreign keys) ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਸਕ੍ਰਿਪਟਾਂ ਚਲਾਓ, ਜੋ ਲੌਜੀਕਲ ਖਰਾਬੀ ਦਾ ਸੰਕੇਤ ਦਿੰਦੀਆਂ ਹਨ।

ਬੈਕਅੱਪ ਵਿਗਾੜਾਂ ਲਈ ਨਿਗਰਾਨੀ ਅਤੇ ਅਲਰਟਿੰਗ

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

ਹੂਰੀਸਟਿਕ ਨਿਗਰਾਨੀ (Heuristic Monitoring)

ਆਪਣੇ ਬੈਕਅੱਪ ਮੈਟਾਡੇਟਾ ਨੂੰ Prometheus ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਕਰੋ ਅਤੇ Grafana ਨਾਲ ਇਸਨੂੰ ਵਿਜ਼ੂਅਲਾਈਜ਼ ਕਰੋ। ਹੇਠਾਂ ਦਿੱਤੇ ਹੂਰੀਸਟਿਕਸ ਲਈ ਅਲਰਟ ਸੈੱਟ ਕਰੋ:
* ਅਚਾਨਕ ਆਕਾਰ ਵਿੱਚ ਕਮੀ: ਜੇਕਰ ਤੁਹਾਡਾ ਰੋਜ਼ਾਨਾ ਬੈਕਅੱਪ ਲਗਾਤਾਰ 500GB ਹੈ, ਅਤੇ ਅੱਜ ਦਾ ਬੈਕਅੱਪ 50MB ਹੈ, ਤਾਂ ਜੌਬ ਸਫਲਤਾਪੂਰਵਕ ਪੂਰੀ ਹੋ ਸਕਦੀ ਹੈ (Exit Code 0), ਪਰ ਸੰਭਾਵਤ ਤੌਰ ‘ਤੇ ਇਸਨੇ ਇੱਕ ਖਾਲੀ ਸਕੀਮਾ ਦਾ ਬੈਕਅੱਪ ਲਿਆ ਹੈ।
* ਅਵਧੀ ਵਿੱਚ ਵਿਗਾੜ: ਜੇਕਰ ਕੋਈ ਬੈਕਅੱਪ ਜੋ ਆਮ ਤੌਰ ‘ਤੇ 2 ਘੰਟੇ ਲੈਂਦਾ ਹੈ, 5 ਮਿੰਟਾਂ ਵਿੱਚ ਪੂਰਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕੁਝ ਛੱਡ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਇਸਦੇ ਉਲਟ, ਜੇਕਰ ਇਹ 10 ਘੰਟੇ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਡਿਸਕ I/O ਡਿਗਰੇਡੇਸ਼ਨ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਖਰਾਬੀ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀ ਹੈ।
* WAL/ਆਰਕਾਈਵ ਲੌਗ ਇਕੱਠਾ ਹੋਣਾ: ਜੇਕਰ ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ Write-Ahead Logs (WAL) ਤਿਆਰ ਕਰ ਰਿਹਾ ਹੈ ਪਰ ਬੈਕਅੱਪ ਸਿਸਟਮ ਉਹਨਾਂ ਨੂੰ ਕਾਫ਼ੀ ਤੇਜ਼ੀ ਨਾਲ ਆਰਕਾਈਵ ਨਹੀਂ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਆਪਣੀ Point-in-Time Recovery (PITR) ਚੇਨ ਵਿੱਚ ਇੱਕ ਅੰਤਰ ਪੈਦਾ ਹੋਣ ਦਾ ਜੋਖਮ ਲੈਂਦੇ ਹੋ।

ਇਕਸਾਰਤਾ ਜਾਂਚਾਂ ਦੇ ਨਾਲ 3-2-1 ਨਿਯਮ ਨੂੰ ਲਾਗੂ ਕਰਨਾ

ਉਦਯੋਗ-ਮਿਆਰੀ 3-2-1 ਬੈਕਅੱਪ ਨਿਯਮ (ਡੇਟਾ ਦੀਆਂ 3 ਕਾਪੀਆਂ, 2 ਵੱਖ-ਵੱਖ ਮੀਡੀਆ, 1 ਆਫਸਾਈਟ) ਤਾਂ ਹੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ ਜੇਕਰ ਸਾਰੀਆਂ ਕਾਪੀਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਗਈ ਹੋਵੇ।

ਇੱਥੇ CloudSave ਵਰਗੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਹੱਲ ਦਾ ਲਾਭ ਉਠਾਉਣਾ ਸੰਚਾਲਨ ਦੇ ਬੋਝ ਨੂੰ ਕਾਫ਼ੀ ਘਟਾਉਂਦਾ ਹੈ। ਹਰੇਕ ਡੇਟਾਬੇਸ ਨੋਡ ਲਈ ਗੁੰਝਲਦਾਰ bash ਸਕ੍ਰਿਪਟਾਂ ਲਿਖਣ ਅਤੇ ਬਣਾਈ ਰੱਖਣ ਦੀ ਬਜਾਏ, CloudSave 3-2-1 ਜੀਵਨ ਚੱਕਰ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਨ ਲਈ ਸਿੱਧੇ ਤੁਹਾਡੇ ਇਨਫ੍ਰਾਸਟ੍ਰਕਚਰ ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਹੁੰਦਾ ਹੈ। ਇਹ ਇਮਿਊਟੇਬਲ ਸਟੋਰੇਜ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ—ਰੈਨਸਮਵੇਅਰ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ—ਅਤੇ ਬਿਲਟ-ਇਨ, ਸਵੈਚਲਿਤ ਰੀਸਟੋਰ ਤਸਦੀਕ ਸਮਾਂ-ਸਾਰਣੀ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਰੱਖਦਾ ਹੈ। CloudSave ਸਵੈਚਲਿਤ ਤੌਰ ‘ਤੇ ਅਲੱਗ-ਥਲੱਗ ਸੈਂਡਬੌਕਸ ਵਾਤਾਵਰਣ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ, ਬੈਕਅੱਪ ਮਾਊਂਟ ਕਰ ਸਕਦਾ ਹੈ, ਤੁਹਾਡੀਆਂ ਕਸਟਮ SQL ਪ੍ਰਮਾਣਿਕਤਾ ਸਕ੍ਰਿਪਟਾਂ ਚਲਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਿਹਤ ਸਥਿਤੀ ਨੂੰ ਤੁਹਾਡੇ ਕੇਂਦਰੀ ਡੈਸ਼ਬੋਰਡ ‘ਤੇ ਵਾਪਸ ਰਿਪੋਰਟ ਕਰ ਸਕਦਾ ਹੈ।

ਸਿੱਟਾ

ਖਰਾਬ ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਇੱਕ ਚੁੱਪ ਕਾਤਲ ਹਨ ਜੋ ਕਾਰੋਬਾਰਾਂ ਨੂੰ ਤਬਾਹ ਕਰ ਸਕਦੇ ਹਨ। ਸਿਰਫ ਇੱਕ ਬੈਕਅੱਪ ਸਕ੍ਰਿਪਟ ਦੇ Exit Code 0 ‘ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਇੱਕ ਖਤਰਨਾਕ ਜੂਆ ਹੈ।

ਆਪਣੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਤਾਵਰਣ ਨੂੰ ਸੱਚਮੁੱਚ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਡਿਫੈਂਸ-ਇਨ-ਡੈਪਥ ਰਣਨੀਤੀ ਅਪਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ:
1. ਆਪਣੇ ਡੇਟਾਬੇਸ ਇੰਜਣ ਦੇ ਅੰਦਰ ਪੇਜ-ਪੱਧਰ ਦੇ ਚੈੱਕਸਮ ਨੂੰ ਸਮਰੱਥ ਕਰੋ।
2. ਬੈਕਅੱਪ ਬਣਾਉਣ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਨੇਟਿਵ ਤਸਦੀਕ ਟੂਲ (pg_verifybackup, RESTORE VERIFYONLY) ਦੀ ਵਰਤੋਂ ਕਰੋ।
3. ਹੂਰੀਸਟਿਕ ਵਿਗਾੜਾਂ ਲਈ ਬੈਕਅੱਪ ਮੈਟਾਡੇਟਾ (ਆਕਾਰ, ਅਵਧੀ) ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ।
4. ਆਪਣੀ ਰੋਜ਼ਾਨਾ ਸੰਚਾਲਨ ਪਾਈਪਲਾਈਨ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਸਵੈਚਲਿਤ, ਅਸਥਾਈ ਰੀਸਟੋਰ ਟੈਸਟਿੰਗ ਲਾਗੂ ਕਰੋ।

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

Categories