ਹਰ ਡੇਟਾਬੇਸ ਐਡਮਿਨਿਸਟ੍ਰੇਟਰ (DBA) ਅਤੇ ਸਿਸਟਮ ਇੰਜੀਨੀਅਰ ਨੇ, ਆਪਣੇ ਕਰੀਅਰ ਵਿੱਚ ਕਿਸੇ ਨਾ ਕਿਸੇ ਮੋੜ ‘ਤੇ, ਡੇਟਾਬੇਸ ਦਾ ਬੈਕਅੱਪ ਲੈਣ ਲਈ ਇੱਕ ਕਸਟਮ ਸ਼ੈੱਲ ਸਕ੍ਰਿਪਟ ਲਿਖੀ ਹੈ। ਇਹ ਅਮਲੀ ਤੌਰ ‘ਤੇ ਇੱਕ ਰਸਮ ਵਾਂਗ ਹੈ। ਕਿਸੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਵਾਂ ਵਿੱਚ, mysqldump ਜਾਂ pg_dump ਨੂੰ gzip ਵਿੱਚ ਪਾਈਪ ਕਰਕੇ ਚਲਾਉਣ ਵਾਲੀ ਇੱਕ ਸਧਾਰਨ cron job ਇੱਕ ਸ਼ਾਨਦਾਰ, ਹਲਕਾ ਅਤੇ ਕਿਫਾਇਤੀ ਹੱਲ ਜਾਪਦਾ ਹੈ।
ਹਾਲਾਂਕਿ, ਜਿਵੇਂ-ਜਿਵੇਂ ਬੁਨਿਆਦੀ ਢਾਂਚਾ (infrastructure) ਵੱਡਾ ਹੁੰਦਾ ਹੈ, ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਵਧਦੀ ਹੈ, ਅਤੇ ਅਪਟਾਈਮ SLAs ਸਖ਼ਤ ਹੁੰਦੇ ਜਾਂਦੇ ਹਨ, ਉਹ 10-ਲਾਈਨਾਂ ਦੀ Bash ਸਕ੍ਰਿਪਟ ਚੁੱਪਚਾਪ ਇੱਕ ਟਿਕ-ਟਿਕ ਕਰਦੇ ਟਾਈਮ ਬੰਬ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ। ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਤਾਵਰਣਾਂ ਨੂੰ ਉੱਚ ਉਪਲਬਧਤਾ (high availability), ਸਖ਼ਤ ਰਿਕਵਰੀ ਪੁਆਇੰਟ ਓਬਜੈਕਟਿਵਜ਼ (RPO), ਅਤੇ ਤੇਜ਼ ਰਿਕਵਰੀ ਟਾਈਮ ਓਬਜੈਕਟਿਵਜ਼ (RTO) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹਨਾਂ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ DIY ਬੈਕਅੱਪ ਸਕ੍ਰਿਪਟਾਂ ‘ਤੇ ਨਿਰਭਰ ਕਰਨਾ ਡੇਟਾ ਦੀ ਇਕਸਾਰਤਾ, ਚੁੱਪ-ਚਾਪ ਅਸਫਲਤਾਵਾਂ, ਸੁਰੱਖਿਆ ਕਮਜ਼ੋਰੀਆਂ, ਅਤੇ ਅਪ੍ਰਬੰਧਿਤ ਰਿਕਵਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨਾਲ ਸਬੰਧਤ ਗੰਭੀਰ ਜੋਖਮ ਪੈਦਾ ਕਰਦਾ ਹੈ।
ਇਸ ਲੇਖ ਵਿੱਚ, ਅਸੀਂ DIY ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਸਕ੍ਰਿਪਟਾਂ ਦੀਆਂ ਆਰਕੀਟੈਕਚਰਲ ਖਾਮੀਆਂ ਅਤੇ ਲੁਕਵੇਂ ਖ਼ਤਰਿਆਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਾਂਗੇ, ਲਾਜ਼ੀਕਲ ਬਨਾਮ ਭੌਤਿਕ ਬੈਕਅੱਪਾਂ ਦੀਆਂ ਤਕਨੀਕੀ ਮੁਸ਼ਕਲਾਂ ਦੀ ਪੜਚੋਲ ਕਰਾਂਗੇ, ਅਤੇ ਚਰਚਾ ਕਰਾਂਗੇ ਕਿ ਤੁਹਾਡੇ ਮਿਸ਼ਨ-ਕ੍ਰਿਟੀਕਲ ਡੇਟਾ ਦੀ ਸੁਰੱਖਿਆ ਲਈ CloudSave ਵਰਗੇ ਐਂਟਰਪ੍ਰਾਈਜ਼-ਗ੍ਰੇਡ ਹੱਲਾਂ ਵੱਲ ਕਿਵੇਂ ਵਧਣਾ ਹੈ।
ਸਾਦਗੀ ਦਾ ਭਰਮ: ਕਲਾਸਿਕ DIY ਸਕ੍ਰਿਪਟ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ
ਖ਼ਤਰੇ ਨੂੰ ਸਮਝਣ ਲਈ, ਸਾਨੂੰ ਪਹਿਲਾਂ ਇੱਕ ਆਮ DIY ਬੈਕਅੱਪ ਸਕ੍ਰਿਪਟ ਦੀ ਬਣਤਰ ਨੂੰ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ। MySQL ਡੇਟਾਬੇਸ ਲਈ ਇੱਕ ਮਿਆਰੀ ਪਹੁੰਚ ਅਕਸਰ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:
#!/bin/bash
# ਸਧਾਰਨ DIY MySQL ਬੈਕਅੱਪ ਸਕ੍ਰਿਪਟ
BACKUP_DIR="/mnt/backups"
DATE=$(date +%F)
DB_USER="admin"
DB_PASS="SuperSecret123!"
mysqldump -u $DB_USER -p$DB_PASS my_database | gzip > $BACKUP_DIR/mydb_$DATE.sql.gz
# 30 ਦਿਨਾਂ ਤੋਂ ਪੁਰਾਣੇ ਬੈਕਅੱਪ ਮਿਟਾਓ
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;
ਪਹਿਲੀ ਨਜ਼ਰੇ, ਇਹ ਸਕ੍ਰਿਪਟ ਟੀਚਾ ਪੂਰਾ ਕਰਦੀ ਹੈ: ਇਹ ਡੇਟਾ ਨੂੰ ਐਕਸਟਰੈਕਟ ਕਰਦੀ ਹੈ, ਇਸਨੂੰ ਕੰਪ੍ਰੈਸ ਕਰਦੀ ਹੈ, ਅਤੇ ਰਿਟੈਨਸ਼ਨ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੀ ਹੈ। ਪਰ ਸਤ੍ਹਾ ਦੇ ਹੇਠਾਂ, ਇਹ ਗੰਭੀਰ ਖਾਮੀਆਂ ਨਾਲ ਭਰੀ ਹੋਈ ਹੈ ਜੋ ਅੰਤ ਵਿੱਚ ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਤਾਵਰਣ ਵਿੱਚ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਦਾ ਕਾਰਨ ਬਣੇਗੀ।
ਖ਼ਤਰਾ 1: ਚੁੱਪ-ਚਾਪ ਅਸਫਲਤਾਵਾਂ ਅਤੇ ਪਾਈਪ ਟ੍ਰੈਪ
DIY ਸਕ੍ਰਿਪਟਾਂ ਦੇ ਸਭ ਤੋਂ ਖਤਰਨਾਕ ਖ਼ਤਰਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਚੁੱਪ-ਚਾਪ ਅਸਫਲਤਾ। ਉਪਰੋਕਤ ਸਕ੍ਰਿਪਟ ਵਿੱਚ, mysqldump ਕਮਾਂਡ ਨੂੰ ਸਿੱਧੇ gzip ਵਿੱਚ ਪਾਈਪ (|) ਕੀਤਾ ਗਿਆ ਹੈ।
Bash ਵਿੱਚ, ਇੱਕ ਪਾਈਪਲਾਈਨ ਦਾ ਐਗਜ਼ਿਟ ਸਟੇਟਸ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਆਖਰੀ ਕਮਾਂਡ ਦਾ ਐਗਜ਼ਿਟ ਸਟੇਟਸ ਹੁੰਦਾ ਹੈ। ਜੇਕਰ ਡੇਟਾਬੇਸ ਸਰਵਰ ਦੀ ਮੈਮੋਰੀ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ, ਕਨੈਕਸ਼ਨ ਡ੍ਰੌਪ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਡੰਪ ਦੇ ਅੱਧ ਵਿਚਕਾਰ ਕੋਈ ਲੌਕਡ ਟੇਬਲ ਮਿਲ ਜਾਂਦਾ ਹੈ, ਤਾਂ mysqldump ਅਸਫਲ ਹੋ ਜਾਵੇਗਾ ਅਤੇ ਇੱਕ ਗਲਤੀ ਸੁੱਟੇਗਾ। ਹਾਲਾਂਕਿ, gzip ਉਸ ਅਧੂਰੇ ਆਉਟਪੁੱਟ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਕੰਪ੍ਰੈਸ ਕਰ ਦੇਵੇਗਾ ਜੋ ਉਸਨੂੰ ਪ੍ਰਾਪਤ ਹੋਇਆ ਸੀ ਅਤੇ 0 (ਸਫਲਤਾ) ਦੇ ਸਟੇਟਸ ਕੋਡ ਨਾਲ ਬਾਹਰ ਨਿਕਲ ਜਾਵੇਗਾ।
ਤੁਹਾਡਾ ਨਿਗਰਾਨੀ ਸਿਸਟਮ, ਜੋ cron job ਦੇ ਐਗਜ਼ਿਟ ਕੋਡ ਦੀ ਜਾਂਚ ਕਰ ਰਿਹਾ ਹੈ, ਇੱਕ ਸਫਲ ਬੈਕਅੱਪ ਦੀ ਰਿਪੋਰਟ ਕਰੇਗਾ। ਤੁਹਾਡੇ ਕੋਲ ਡਿਸਕ ‘ਤੇ ਇੱਕ ਵੈਧ .gz ਫਾਈਲ ਹੋਵੇਗੀ, ਪਰ ਅੰਦਰ ਇੱਕ ਅਧੂਰੀ, ਬੇਕਾਰ SQL ਫਾਈਲ ਹੋਵੇਗੀ। ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਉਦੋਂ ਤੱਕ ਪਤਾ ਨਹੀਂ ਲੱਗੇਗਾ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਰੀਸਟੋਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਦੇ।
ਸੁਧਾਰ (ਅਤੇ ਇਸ ਦੀਆਂ ਸੀਮਾਵਾਂ)
ਇੰਜੀਨੀਅਰ ਅਕਸਰ Bash ਵਿੱਚ ਸਖ਼ਤ ਗਲਤੀ ਹੈਂਡਲਿੰਗ ਨੂੰ ਸਮਰੱਥ ਕਰਕੇ ਇਸਨੂੰ ਪੈਚ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ:
set -e
set -o pipefail
ਹਾਲਾਂਕਿ set -o pipefail ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਜੇਕਰ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਕੋਈ ਵੀ ਕਮਾਂਡ ਅਸਫਲ ਹੁੰਦੀ ਹੈ ਤਾਂ ਸਕ੍ਰਿਪਟ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਫਿਰ ਵੀ ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਸਕ੍ਰਿਪਟ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਮਜ਼ਬੂਤ ਅਲਰਟਿੰਗ, ਲੌਗਿੰਗ, ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਵਾਲੇ ਤੰਤਰ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਕੋਈ ਅਸਥਾਈ ਨੈੱਟਵਰਕ ਗਲਤੀ ਸਵੇਰੇ 2:00 ਵਜੇ ਅਸਫਲਤਾ ਦਾ ਕਾਰਨ ਬਣਦੀ ਹੈ, ਤਾਂ ਇੱਕ DIY ਸਕ੍ਰਿਪਟ ਬਸ ਰੁਕ ਜਾਂਦੀ ਹੈ। ਐਂਟਰਪ੍ਰਾਈਜ਼ ਪਲੇਟਫਾਰਮ ਇਹਨਾਂ ਅਸਥਾਈ ਗਲਤੀਆਂ ਨੂੰ ਬੁੱਧੀਮਾਨ, ਐਕਸਪੋਨੈਂਸ਼ੀਅਲ ਬੈਕਆਫ ਰੀਟ੍ਰਾਈਜ਼ ਨਾਲ ਸੰਭਾਲਦੇ ਹਨ।
ਖ਼ਤਰਾ 2: ਡੇਟਾ ਦੀ ਇਕਸਾਰਤਾ ਅਤੇ ਲੌਕਿੰਗ ਦੇ ਸੁਪਨੇ
DIY ਸਕ੍ਰਿਪਟਾਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪ (mysqldump, pg_dump) ‘ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ। ਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪ ਸਾਰੀਆਂ ਟੇਬਲਾਂ ਵਿੱਚ SELECT ਸਟੇਟਮੈਂਟਾਂ ਚਲਾ ਕੇ ਡੇਟਾ ਕੱਢਦੇ ਹਨ। ਇੱਕ ਉੱਚ ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾਬੇਸ ਵਿੱਚ, ਡੇਟਾ ਲਗਾਤਾਰ ਬਦਲ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਜੇਕਰ ਇੱਕ ਸਕ੍ਰਿਪਟ ਨੂੰ 100GB ਡੇਟਾਬੇਸ ਨੂੰ ਡੰਪ ਕਰਨ ਵਿੱਚ 45 ਮਿੰਟ ਲੱਗਦੇ ਹਨ, ਤਾਂ ਡੰਪ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਡੇਟਾ ਅੰਤ ਵਾਲੇ ਡੇਟਾ ਨਾਲੋਂ 45 ਮਿੰਟ ਪੁਰਾਣਾ ਹੋਵੇਗਾ, ਜੋ ACID ਪਾਲਣਾ ਦੀ ਉਲੰਘਣਾ ਕਰਦਾ ਹੈ।
MySQL ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਇਕਸਾਰਤਾ
InnoDB ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ MySQL ਵਿੱਚ ਇੱਕ ਇਕਸਾਰ ਸਨੈਪਸ਼ਾਟ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਖਾਸ ਫਲੈਗ ਪਾਸ ਕਰਨੇ ਪੈਣਗੇ:
mysqldump --single-transaction --quick --routines --events -u user -p db > dump.sql
--single-transaction ਫਲੈਗ ਆਈਸੋਲੇਸ਼ਨ ਪੱਧਰ ਨੂੰ REPEATABLE READ ‘ਤੇ ਸੈੱਟ ਕਰਦਾ ਹੈ ਅਤੇ ਡੰਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਜੇਕਰ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਅਜੇ ਵੀ ਪੁਰਾਣੀਆਂ MyISAM ਟੇਬਲਾਂ ਹਨ, ਤਾਂ ਇਹ ਫਲੈਗ ਉਹਨਾਂ ਨੂੰ ਲੌਕ ਹੋਣ ਤੋਂ ਨਹੀਂ ਰੋਕੇਗਾ, ਜਿਸ ਨਾਲ ਬੈਕਅੱਪ ਚੱਲਣ ਦੌਰਾਨ ਪ੍ਰੋਡਕਸ਼ਨ ਰੀਡ/ਰਾਈਟ ਟ੍ਰੈਫਿਕ ਰੁਕ ਸਕਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਬੈਕਅੱਪ ਦੌਰਾਨ ਡਿਵੈਲਪਰਾਂ ਦੁਆਰਾ ਚਲਾਈ ਗਈ ਕੋਈ ਵੀ ALTER TABLE, DROP TABLE, ਜਾਂ RENAME TABLE ਸਟੇਟਮੈਂਟ REPEATABLE READ ਸਨੈਪਸ਼ਾਟ ਨੂੰ ਤੋੜ ਦੇਵੇਗੀ, ਜਿਸ ਨਾਲ ਡੰਪ ਅਸਫਲ ਹੋ ਜਾਵੇਗਾ।
PostgreSQL ਅਤੇ WAL ਆਰਕਾਈਵਿੰਗ
PostgreSQL ਲਈ, pg_dump ਇਕਸਾਰ ਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਪਰ ਸਿਰਫ਼ ਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ (PITR) ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਜੇਕਰ ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਸ਼ਾਮ 4:00 ਵਜੇ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਆਖਰੀ cron ਸਕ੍ਰਿਪਟ ਅੱਧੀ ਰਾਤ ਨੂੰ ਚੱਲੀ ਸੀ, ਤਾਂ ਤੁਸੀਂ 16 ਘੰਟਿਆਂ ਦਾ ਡੇਟਾ ਗੁਆ ਦਿੰਦੇ ਹੋ।
PITR ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ Write-Ahead Logs (WAL) ਦੀ ਨਿਰੰਤਰ ਆਰਕਾਈਵਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। archive_command ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸੰਭਾਲਣ ਲਈ ਇੱਕ DIY ਸਕ੍ਰਿਪਟ ਲਿਖਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ।
# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /mnt/wal_archive/%f && cp %p /mnt/wal_archive/%f'
ਜੇਕਰ ਮੰਜ਼ਿਲ ਸਟੋਰੇਜ (/mnt/wal_archive/) ਭਰ ਜਾਂਦੀ ਹੈ ਜਾਂ ਉਪਲਬਧ ਨਹੀਂ ਹੁੰਦੀ ਹੈ, ਤਾਂ archive_command ਅਸਫਲ ਹੋ ਜਾਵੇਗਾ। PostgreSQL ਫਿਰ WAL ਫਾਈਲਾਂ ਨੂੰ ਸਥਾਨਕ ਤੌਰ ‘ਤੇ ਇਕੱਠਾ ਕਰੇਗਾ ਜਦੋਂ ਤੱਕ ਪ੍ਰਾਇਮਰੀ ਡਿਸਕ ਭਰ ਨਹੀਂ ਜਾਂਦੀ, ਜਿਸ ਨਾਲ ਡੇਟਾਬੇਸ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਹੋ ਜਾਵੇਗਾ। DIY ਸਕ੍ਰਿਪਟਾਂ ਕੋਲ ਸ਼ਾਇਦ ਹੀ ਉਹ ਟੈਲੀਮੈਟਰੀ ਹੁੰਦੀ ਹੈ ਜੋ WAL ਇਕੱਤਰਤਾ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਅਤੇ ਆਊਟੇਜ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਸ਼ਾਸਕਾਂ ਨੂੰ ਚੇਤਾਵਨੀ ਦੇਣ ਲਈ ਲੋੜੀਂਦੀ ਹੁੰਦੀ ਹੈ।
ਖ਼ਤਰਾ 3: ਰਿਟੈਨਸ਼ਨ ਰੂਲੇਟ
ਸਾਡੀ ਸ਼ੁਰੂਆਤੀ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਰਿਟੈਨਸ਼ਨ ਕਮਾਂਡ ਨੂੰ ਵਾਪਸ ਦੇਖੋ:
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;
ਇਹ ਇੱਕ ਭਿਆਨਕ ਡੇਟਾ ਨੁਕਸਾਨ ਦੀ ਘਟਨਾ ਹੈ ਜੋ ਵਾਪਰਨ ਦੀ ਉਡੀਕ ਕਰ ਰਹੀ ਹੈ। ਇੱਕ ਅਜਿਹਾ ਦ੍ਰਿਸ਼ ਕਲਪਨਾ ਕਰੋ ਜਿੱਥੇ ਇੱਕ ਕੌਂਫਿਗਰੇਸ਼ਨ ਬਦਲਾਅ mysqldump ਪ੍ਰਮਾਣੀਕਰਨ ਨੂੰ ਤੋੜ ਦਿੰਦਾ ਹੈ। ਸਕ੍ਰਿਪਟ ਨਵੇਂ ਬੈਕਅੱਪ ਬਣਾਉਣ ਵਿੱਚ ਅਸਫਲ ਰਹਿੰਦੀ ਹੈ, ਪਰ find ਕਮਾਂਡ ਹਰ ਰਾਤ ਚੱਲਦੀ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ 30 ਦਿਨਾਂ ਤੋਂ ਪੁਰਾਣੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਮਿਟਾਉਂਦੀ ਰਹਿੰਦੀ ਹੈ।
30 ਦਿਨਾਂ ਦੀਆਂ ਚੁੱਪ-ਚਾਪ ਬੈਕਅੱਪ ਅਸਫਲਤਾਵਾਂ ਤੋਂ ਬਾਅਦ, find ਕਮਾਂਡ ਤੁਹਾਡਾ ਆਖਰੀ ਬਚਿਆ ਹੋਇਆ ਚੰਗਾ ਬੈਕਅੱਪ ਮਿਟਾ ਦੇਵੇਗੀ। ਹੁਣ ਤੁਹਾਡੇ ਕੋਲ ਜ਼ੀਰੋ ਬੈਕਅੱਪ ਬਚੇ ਹਨ।
CloudSave ਵਰਗਾ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਬੈਕਅੱਪ ਸੌਫਟਵੇਅਰ ਸਟੇਟਫੁੱਲ ਰਿਟੈਨਸ਼ਨ ਨੀਤੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇਹ “30 ਦਿਨਾਂ ਤੋਂ ਪੁਰਾਣੇ ਬੈਕਅੱਪ ਮਿਟਾਓ” ਅਤੇ “ਪੁਰਾਣੇ ਡੇਟਾ ਨੂੰ ਹਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਘੱਟੋ-ਘੱਟ 30 ਸਫਲ ਰਿਕਵਰੀ ਪੁਆਇੰਟ ਮੌਜੂਦ ਹਨ” ਵਿਚਕਾਰ ਅੰਤਰ ਨੂੰ ਸਮਝਦਾ ਹੈ।
ਖ਼ਤਰਾ 4: ਸੁਰੱਖਿਆ, ਐਨਕ੍ਰਿਪਸ਼ਨ, ਅਤੇ ਪਾਲਣਾ ਦੇ ਅੰਨ੍ਹੇ ਸਥਾਨ
ਰੈਨਸਮਵੇਅਰ ਅਤੇ ਸਖ਼ਤ ਪਾਲਣਾ ਫਰੇਮਵਰਕ (GDPR, HIPAA, SOC 2) ਦੇ ਯੁੱਗ ਵਿੱਚ, ਬੈਕਅੱਪ ਇੱਕ ਮੁੱਖ ਨਿਸ਼ਾਨਾ ਹਨ। DIY ਸਕ੍ਰਿਪਟਾਂ ਅਕਸਰ ਸੁਰੱਖਿਆ ਦੇ ਵਧੀਆ ਅਭਿਆਸਾਂ ਦੀ ਉਲੰਘਣਾ ਕਰਦੀਆਂ ਹਨ:
- ਹਾਰਡਕੋਡ ਕੀਤੇ ਪ੍ਰਮਾਣ ਪੱਤਰ: ਡੇਟਾਬੇਸ ਪਾਸਵਰਡਾਂ ਨੂੰ ਪਲੇਨਟੈਕਸਟ ਸਕ੍ਰਿਪਟਾਂ ਜਾਂ cron ਪਰਿਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਸਟੋਰ ਕਰਨਾ ਇੱਕ ਵੱਡਾ ਸੁਰੱਖਿਆ ਜੋਖਮ ਹੈ। ਹਾਲਾਂਕਿ MySQL ਦੇ
mysql_config_editorਜਾਂ PostgreSQL ਦੀ.pgpassਫਾਈਲ ਵਰਗੇ ਟੂਲ ਇਸ ਨੂੰ ਘੱਟ ਕਰਦੇ ਹਨ, ਫਿਰ ਵੀ ਉਹਨਾਂ ਨੂੰ ਸਰਵਰ ‘ਤੇ ਸਥਾਨਕ ਕੁੰਜੀ ਫਾਈਲਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। - ਰੈਸਟ ‘ਤੇ ਐਨਕ੍ਰਿਪਸ਼ਨ ਦੀ ਘਾਟ: ਡਿਸਕ ‘ਤੇ ਕੱਚਾ SQL ਡੰਪ ਕਰਨਾ ਸੰਵੇਦਨਸ਼ੀਲ PII/PHI ਨੂੰ ਖੁੱਲ੍ਹਾ ਛੱਡ ਦਿੰਦਾ ਹੈ।
- ਗੁੰਝਲਦਾਰ ਐਨਕ੍ਰਿਪਸ਼ਨ ਪਾਈਪਲਾਈਨਾਂ: GPG ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬੈਕਅੱਪ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਗੰਭੀਰ CPU ਓਵਰਹੈੱਡ ਅਤੇ ਕੁੰਜੀ ਪ੍ਰਬੰਧਨ ਦੀਆਂ ਗੁੰਝਲਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ।
# ਇੱਕ DIY ਐਨਕ੍ਰਿਪਟਡ ਬੈਕਅੱਪ ਪਾਈਪਲਾਈਨ
pg_dump mydb | gzip | gpg --symmetric --cipher-algo AES256 --passphrase-file /etc/keys/backup.key > backup.sql.gz.gpg
ਜੇਕਰ ਸਰਵਰ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਹਮਲਾਵਰ ਕੋਲ ਐਨਕ੍ਰਿਪਟਡ ਬੈਕਅੱਪ ਅਤੇ /etc/keys/backup.key ਫਾਈਲ ਦੋਵਾਂ ਤੱਕ ਪਹੁੰਚ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਐਨਕ੍ਰਿਪਸ਼ਨ ਬੇਕਾਰ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜੇਕਰ ਉਹ DBA ਜਿਸਨੇ GPG ਕੁੰਜੀ ਤਿਆਰ ਕੀਤੀ ਸੀ, ਕੰਪਨੀ ਛੱਡ ਦਿੰਦਾ ਹੈ ਅਤੇ ਕੁੰਜੀ ਗੁੰਮ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਬੈਕਅੱਪ ਰਿਕਵਰ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ।
ਖ਼ਤਰਾ 5: RTO ਰਿਐਲਿਟੀ ਚੈੱਕ (ਰੀਸਟੋਰ ਕਰਨਾ ਬੈਕਅੱਪ ਲੈਣ ਨਾਲੋਂ ਔਖਾ ਹੈ)
ਬੈਕਅੱਪ ਦੀ ਅੰਤਮ ਪ੍ਰੀਖਿਆ ਰੀਸਟੋਰ ਹੈ। DIY ਸਕ੍ਰਿਪਟਾਂ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਗਏ ਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪ ਰੀਸਟੋਰ ਕਰਨ ਲਈ ਬਹੁਤ ਹੌਲੀ ਹੁੰਦੇ ਹਨ। ਇੱਕ 500GB SQL ਡੰਪ ਬਣਾਉਣ ਵਿੱਚ 15 ਮਿੰਟ ਲੱਗ ਸਕਦੇ ਹਨ, ਪਰ ਇਸਨੂੰ ਰੀਸਟੋਰ ਕਰਨ ਲਈ ਡੇਟਾਬੇਸ ਇੰਜਣ ਨੂੰ SQL ਨੂੰ ਪਾਰਸ ਕਰਨ, ਇੰਡੈਕਸਾਂ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ, ਅਤੇ ਕੰਸਟ੍ਰੇਂਟਸ ਦੀ ਮੁੜ ਗਣਨਾ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਘੰਟੇ ਜਾਂ ਦਿਨ ਵੀ ਲੱਗ ਸਕਦੇ ਹਨ, ਜੋ ਤੁਹਾਡੇ RTO ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ।
ਵੱਡੇ ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾਬੇਸ ਲਈ, ਭੌਤਿਕ ਬੈਕਅੱਪ (ਅਸਲ ਡੇਟਾ ਫਾਈਲਾਂ ਨੂੰ ਕਾਪੀ ਕਰਨਾ) ਲਾਜ਼ਮੀ ਹਨ। ਹਾਲਾਂਕਿ Percona XtraBackup ਜਾਂ pg_basebackup ਵਰਗੇ ਟੂਲ ਮੌਜੂਦ ਹਨ, ਉਹਨਾਂ ਨੂੰ DIY Bash ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ ਲਪੇਟਣਾ ਬਹੁਤ ਗੁੰਝਲਦਾਰ ਹੈ। ਤੁਹਾਨੂੰ LVM ਸਨੈਪਸ਼ਾਟ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਫਾਈਲ ਸਿਸਟਮ ਕੁਇਜ਼ਿੰਗ ਨੂੰ ਸੰਭਾਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਬੈਕਅੱਪ ਨੈੱਟਵਰਕ ਇੰਟਰਫੇਸ ਨੂੰ ਸੰਤ੍ਰਿਪਤ ਕੀਤੇ ਬਿਨਾਂ ਆਫਸਾਈਟ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਗਿਆ ਹੈ।
LVM ਸਨੈਪਸ਼ਾਟ ਟ੍ਰੈਪ
ਬਹੁਤ ਸਾਰੇ ਇੰਜੀਨੀਅਰ LVM ਸਨੈਪਸ਼ਾਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ “ਜ਼ੀਰੋ ਡਾਊਨਟਾਈਮ” ਭੌਤਿਕ ਬੈਕਅੱਪ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ:
# ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਬਣਾਓ
lvcreate --size 20G --snapshot --name db_snap /dev/vg0/db_vol
# ਮਾਊਂਟ ਅਤੇ ਕਾਪੀ ਕਰੋ
mount /dev/vg0/db_snap /mnt/snap
tar -czf /backups/db_physical.tar.gz /mnt/snap/mysql
ਜੇਕਰ ਡੇਟਾਬੇਸ ਰਾਈਟ I/O ਵਿੱਚ ਅਚਾਨਕ ਵਾਧਾ ਅਨੁਭਵ ਕਰਦਾ ਹੈ, ਤਾਂ 20G LVM ਸਨੈਪਸ਼ਾਟ ਤੁਰੰਤ ਭਰ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ LVM ਸਨੈਪਸ਼ਾਟ ਭਰ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਅਵੈਧ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਬੈਕਅੱਪ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸ ਤੋਂ ਵੀ ਮਾੜੀ ਗੱਲ ਇਹ ਹੈ ਕਿ, ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਰਤੇ ਗਏ LVM ਸਨੈਪਸ਼ਾਟ ਪ੍ਰਾਇਮਰੀ ਡੇਟਾਬੇਸ ਵਾਲੀਅਮ ਦੀ I/O ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਘਟਾ ਸਕਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨ ਲੈਟੈਂਸੀ ਵਿੱਚ ਵਾਧਾ ਹੁੰਦਾ ਹੈ।
ਐਂਟਰਪ੍ਰਾਈਜ਼-ਗ੍ਰੇਡ ਸੁਰੱਖਿਆ ਵੱਲ ਵਧਣਾ
DIY ਸਕ੍ਰਿਪਟਾਂ ਤੋਂ ਇੱਕ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਪਲੇਟਫਾਰਮ ਵੱਲ ਤਬਦੀਲੀ ਕਿਸੇ ਵੀ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਟੀਮ ਲਈ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਪਰਿਪੱਕਤਾ ਮੀਲ ਪੱਥਰ ਹੈ। ਟੀਚਾ “ਉਮੀਦ ਹੈ ਕਿ ਸਕ੍ਰਿਪਟ ਚੱਲੀ” ਤੋਂ ਲੈ ਕੇ ਰਿਕਵਰੇਬਿਲਟੀ ਦੇ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਸਬੂਤ ਹੋਣ ਤੱਕ ਵਧਣਾ ਹੈ।
CloudSave ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਖਾਸ ਤੌਰ ‘ਤੇ DIY ਸਕ੍ਰਿਪਟਿੰਗ ਦੇ ਅੰਨ੍ਹੇ ਸਥਾਨਾਂ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹਨ। ਐਪਲੀਕੇਸ਼ਨ-ਜਾਗਰੂਕ ਏਜੰਟਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਕੇ, CloudSave ਟੇਬਲਾਂ ਨੂੰ ਲੌਕ ਕੀਤੇ ਜਾਂ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਘਟਾਏ ਬਿਨਾਂ ਇਕਸਾਰ ਭੌਤਿਕ ਅਤੇ ਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪਾਂ ਨੂੰ ਆਰਕੇਸਟ੍ਰੇਟ ਕਰਨ ਲਈ ਸਿੱਧੇ ਡੇਟਾਬੇਸ API (MySQL, PostgreSQL, MS SQL, Oracle) ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦਾ ਹੈ।
ਸਕ੍ਰਿਪਟਾਂ ਤੋਂ ਦੂਰ ਜਾਣ ਦੇ ਮੁੱਖ ਫਾਇਦੇ:
- ਆਟੋਮੇਟਿਡ ਵੈਰੀਫਿਕੇਸ਼ਨ: ਆਧੁਨਿਕ ਪਲੇਟਫਾਰਮ ਸਿਰਫ਼ ਬੈਕਅੱਪ ਨਹੀਂ ਲੈਂਦੇ; ਉਹ ਉਹਨਾਂ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ। CloudSave ਆਪਣੇ ਆਪ ਇੱਕ ਅਸਥਾਈ ਡੇਟਾਬੇਸ ਇੰਸਟੈਂਸ ਨੂੰ ਸਪਿਨ ਅੱਪ ਕਰ ਸਕਦਾ ਹੈ, ਬੈਕਅੱਪ ਨੂੰ ਰੀਸਟੋਰ ਕਰ ਸਕਦਾ ਹੈ, ਇਕਸਾਰਤਾ ਜਾਂਚਾਂ (ਜਿਵੇਂ ਕਿ
DBCC CHECKDB) ਚਲਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਤੋੜ ਸਕਦਾ ਹੈ, ਇੱਕ ਪ੍ਰਮਾਣਿਤ ਰਿਪੋਰਟ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਕਿ ਬੈਕਅੱਪ ਅਸਲ ਵਿੱਚ ਵਰਤੋਂ ਯੋਗ ਹੈ। - ਇਮਿਊਟੇਬਲ ਸਟੋਰੇਜ: ਰੈਨਸਮਵੇਅਰ ਨਾਲ ਲੜਨ ਲਈ, ਬੈਕਅੱਪ ਇਮਿਊਟੇਬਲ (ਅਟੱਲ) ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। DIY ਸਕ੍ਰਿਪਟਾਂ WORM (Write Once, Read Many) ਸਟੋਰੇਜ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਨਹੀਂ ਲਿਖ ਸਕਦੀਆਂ। ਐਂਟਰਪ੍ਰਾਈਜ਼ ਹੱਲ S3 ਆਬਜੈਕਟ ਲੌਕ ਅਤੇ ਇਮਿਊਟੇਬਲ ਕਲਾਉਡ ਸਟੋਰੇਜ ਨਾਲ ਸਵਦੇਸ਼ੀ ਤੌਰ ‘ਤੇ ਏਕੀਕ੍ਰਿਤ ਹੁੰਦੇ ਹਨ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹੋਏ ਕਿ ਭਾਵੇਂ ਕੋਈ ਸਰਵਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤਾ ਗਿਆ ਹੋਵੇ, ਬੈਕਅੱਪ ਨੂੰ ਕਿਸੇ ਹਮਲਾਵਰ ਦੁਆਰਾ ਮਿਟਾਇਆ ਜਾਂ ਐਨਕ੍ਰਿਪਟ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।
- ਸਰਲੀਕ੍ਰਿਤ PITR: ਗੁੰਝਲਦਾਰ
recovery.confਜਾਂpostgresql.auto.confਪੈਰਾਮੀਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਬੇਸ ਬੈਕਅੱਪ ਅਤੇ ਸੈਂਕੜੇ WAL ਫਾਈਲਾਂ ਨੂੰ ਹੱਥੀਂ ਜੋੜਨ ਦੀ ਬਜਾਏ, ਪਲੇਟਫਾਰਮ ਇੱਕ ਵਿਜ਼ੂਅਲ ਟਾਈਮਲਾਈਨ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਤੁਸੀਂ ਬਸ ਉਹ ਸਹੀ ਮਿੰਟ ਚੁਣਦੇ ਹੋ ਜਿਸ ‘ਤੇ ਤੁਸੀਂ ਰੀਸਟੋਰ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਸੌਫਟਵੇਅਰ ਲੌਗ ਰੀਪਲੇਅ ਨੂੰ ਆਪਣੇ ਆਪ ਸੰਭਾਲ ਲੈਂਦਾ ਹੈ। - ਡੀਡੁਪਲੀਕੇਸ਼ਨ ਅਤੇ ਕੰਪ੍ਰੈਸ਼ਨ: DIY ਸਕ੍ਰਿਪਟਾਂ
gzip‘ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ, ਜੋ ਹਰੇਕ ਫਾਈਲ ਨੂੰ ਵੱਖਰੇ ਤੌਰ ‘ਤੇ ਕੰਪ੍ਰੈਸ ਕਰਦੀ ਹੈ। ਐਂਟਰਪ੍ਰਾਈਜ਼ ਬੈਕਅੱਪ ਸੌਫਟਵੇਅਰ ਗਲੋਬਲ ਬਲਾਕ-ਪੱਧਰ ਦੀ ਡੀਡੁਪਲੀਕੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜੋ ਬੈਕਅੱਪ ਨੂੰ ਆਫਸਾਈਟ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਵੇਲੇ ਸਟੋਰੇਜ ਲਾਗਤਾਂ ਅਤੇ ਨੈੱਟਵਰਕ ਬੈਂਡਵਿਡਥ ਨੂੰ ਕਾਫ਼ੀ ਘਟਾਉਂਦਾ ਹੈ।
ਸਿੱਟਾ
ਡੇਟਾਬੇਸ ਦਾ ਬੈਕਅੱਪ ਲੈਣ ਲਈ ਇੱਕ ਕਸਟਮ Bash ਸਕ੍ਰਿਪਟ ਲਿਖਣਾ ਆਸਾਨ ਹੈ। ਇੱਕ ਅਜਿਹੀ ਸਕ੍ਰਿਪਟ ਲਿਖਣਾ ਜੋ ਚੁੱਪ-ਚਾਪ ਪਾਈਪਲਾਈਨ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਸੰਭਾਲਦੀ ਹੈ, ACID ਇਕਸਾਰਤਾ ਦੀ ਗਰੰਟੀ ਦਿੰਦੀ ਹੈ, ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਕੁੰਜੀਆਂ ਦਾ ਸੁਰੱਖਿਅਤ ਪ੍ਰਬੰਧਨ ਕਰਦੀ ਹੈ, ਰਿਟੈਨਸ਼ਨ-ਅਧਾਰਿਤ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਨੂੰ ਰੋਕਦੀ ਹੈ, ਅਤੇ ਸਖ਼ਤ RTO/RPO SLAs ਦੀ ਗਰੰਟੀ ਦਿੰਦੀ ਹੈ, ਲਗਭਗ ਅਸੰਭਵ ਹੈ।
ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ, ਡੇਟਾਬੇਸ ਕਾਰੋਬਾਰ ਦੀ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਸੰਪਤੀ ਹੈ। ਇਸਦੀ ਸੁਰੱਖਿਆ ਨੂੰ ਸ਼ੈੱਲ ਸਕ੍ਰਿਪਟ ਦੀਆਂ ਕੁਝ ਸੌ ਲਾਈਨਾਂ ਦੁਆਰਾ ਸੰਭਾਲੇ ਗਏ ਇੱਕ ਸਾਈਡ-ਪ੍ਰੋਜੈਕਟ ਵਜੋਂ ਮੰਨਣਾ ਇੱਕ ਅਜਿਹਾ ਜੋਖਮ ਹੈ ਜੋ ਕੋਈ ਵੀ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਨਹੀਂ ਉਠਾ ਸਕਦਾ। ਆਪਣੀਆਂ ਮੌਜੂਦਾ ਬੈਕਅੱਪ ਰਣਨੀਤੀਆਂ ਦਾ ਆਡਿਟ ਕਰਕੇ, ਲਾਜ਼ੀਕਲ ਡੰਪਾਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਸਮਝ ਕੇ, ਅਤੇ CloudSave ਵਰਗੇ ਮਜ਼ਬੂਤ, ਆਟੋਮੇਟਿਡ ਪਲੇਟਫਾਰਮਾਂ ਵੱਲ ਮਾਈਗ੍ਰੇਟ ਕਰਕੇ, DevOps ਅਤੇ DBA ਟੀਮਾਂ ਕਸਟਮ ਸਕ੍ਰਿਪਟਾਂ ਦੇ “ਬੱਸ ਫੈਕਟਰ” ਨੂੰ ਖਤਮ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾ ਸਕਦੀਆਂ ਹਨ ਕਿ ਉਹਨਾਂ ਦਾ ਡੇਟਾ ਸੱਚਮੁੱਚ ਲਚਕੀਲਾ ਹੈ।
