ਉਤਪਾਦਨ ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਰਣਨੀਤੀਆਂ ਜੋ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਦੀਆਂ ਹਨ: MySQL ਅਤੇ PostgreSQL
ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ MySQL ਅਤੇ PostgreSQL ਲਈ ਸਾਬਤ ਬੈਕਅੱਪ ਅਤੇ ਰਿਕਵਰੀ ਰਣਨੀਤੀਆਂ
Balinder Walia12 ਅਪ੍ਰੈਲ 202632 min readਉਤਪਾਦਨ ਡੇਟਾ ਨੂੰ ਗੁਆਉਣਾ ਇੱਕ ਅਜਿਹੀ ਘਟਨਾ ਹੈ ਜੋ ਕਰੀਅਰ ਨੂੰ ਖਤਮ ਕਰਦੀ ਹੈ, ਕੰਪਨੀਆਂ ਨੂੰ ਬੰਦ ਕਰਦੀ ਹੈ, ਅਤੇ ਸਾਰੇ ਗਲਤ ਕਾਰਨਾਂ ਕਰਕੇ ਹੈਕਰ ਨਿਊਜ਼ ਦਾ ਪਹਿਲਾ ਪੰਨਾ ਬਣਾਉਂਦੀ ਹੈ। ਫਿਰ ਵੀ ਬਹੁਤੀਆਂ ਟੀਮਾਂ ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਨੂੰ ਇੱਕ ਵਿਚਾਰ ਵਜੋਂ ਮੰਨਦੀਆਂ ਹਨ - ਇੱਕ ਕ੍ਰੋਨ ਨੌਕਰੀ ਜੋ ਕਿਸੇ ਨੇ ਦੋ ਸਾਲ ਪਹਿਲਾਂ ਸਥਾਪਤ ਕੀਤੀ ਸੀ ਜਿਸਦੀ ਕਿਸੇ ਨੇ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕੀਤੀ ਹੈ। ਇਹ ਲੇਖ MySQL ਅਤੇ PostgreSQL ਲਈ ਲੜਾਈ-ਜਾਂਚ ਕੀਤੀਆਂ ਬੈਕਅੱਪ ਰਣਨੀਤੀਆਂ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਜੋ ਕਿ ਸਿੰਗਲ-ਨੋਡ k3s ਕਲੱਸਟਰਾਂ ਤੋਂ ਲੈ ਕੇ ਰੋਜ਼ਾਨਾ ਲੱਖਾਂ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਦੀ ਪ੍ਰੋਸੈਸਿੰਗ ਕਰਨ ਵਾਲੇ ਬਹੁ-ਖੇਤਰ ਕਲਾਉਡ ਤੈਨਾਤੀਆਂ ਤੱਕ ਦੇ ਉਤਪਾਦਨ ਵਾਤਾਵਰਨ ਵਿੱਚ ਸਾਬਤ ਹੋਏ ਹਨ।
ਅਸੀਂ ਪੂਰੇ ਸਪੈਕਟ੍ਰਮ ਨੂੰ ਕਵਰ ਕਰਾਂਗੇ: ਲਾਜ਼ੀਕਲ ਅਤੇ ਭੌਤਿਕ ਬੈਕਅੱਪ ਵਿਧੀਆਂ, ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ, ਸਵੈਚਲਿਤ ਸਮਾਂ-ਸਾਰਣੀ, ਕਲਾਉਡ ਸਟੋਰੇਜ ਟੀਚੇ, ਏਨਕ੍ਰਿਪਸ਼ਨ, ਤਸਦੀਕ, Kubernetes-ਨੇਟਿਵ ਪਹੁੰਚ, ਅਤੇ ਤਬਾਹੀ ਰਿਕਵਰੀ ਯੋਜਨਾ ਜੋ ਇਸ ਸਭ ਨੂੰ ਜੋੜਦੀ ਹੈ। ਹਰ ਸਿਫ਼ਾਰਸ਼ ਠੋਸ ਸੰਰਚਨਾ ਅਤੇ ਕੋਡ ਦੇ ਨਾਲ ਆਉਂਦੀ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਆਪਣੇ ਵਾਤਾਵਰਨ ਦੇ ਅਨੁਕੂਲ ਬਣਾ ਸਕਦੇ ਹੋ।
ਬੈਕਅੱਪ ਕਿਸਮਾਂ ਨੂੰ ਸਮਝਣਾ
ਖਾਸ ਟੂਲਸ ਵਿੱਚ ਗੋਤਾਖੋਰੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਚਾਰ ਬੁਨਿਆਦੀ ਬੈਕਅੱਪ ਰਣਨੀਤੀਆਂ ਦੇ ਇੱਕ ਸਪੱਸ਼ਟ ਮਾਨਸਿਕ ਮਾਡਲ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਉਹ ਰਿਕਵਰੀ ਉਦੇਸ਼ਾਂ ਨਾਲ ਕਿਵੇਂ ਗੱਲਬਾਤ ਕਰਦੇ ਹਨ. ਹਰੇਕ ਰਣਨੀਤੀ ਬੈਕਅੱਪ ਸਪੀਡ, ਸਟੋਰੇਜ ਦੀ ਖਪਤ, ਅਤੇ ਰਿਕਵਰੀ ਸਮੇਂ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਵੱਖਰਾ ਵਪਾਰ ਬਣਾਉਂਦੀ ਹੈ।
Aਪੂਰਾ ਬੈਕਅੱਪਸਮੁੱਚੀ ਡਾਟਾਬੇਸ ਨੂੰ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਕੈਪਚਰ ਕਰਦਾ ਹੈ। ਇਹ ਤਰਕ ਕਰਨਾ ਸਭ ਤੋਂ ਸਰਲ ਹੈ ਅਤੇ ਰੀਸਟੋਰ ਕਰਨਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਹੈ, ਪਰ ਸਟੋਰੇਜ ਵਿੱਚ ਸਭ ਤੋਂ ਮਹਿੰਗਾ ਅਤੇ ਬਣਾਉਣ ਲਈ ਸਭ ਤੋਂ ਹੌਲੀ ਹੈ। ਇੱਕਵਾਧੇ ਵਾਲਾ ਬੈਕਅੱਪਸਿਰਫ਼ ਉਸ ਡੇਟਾ ਨੂੰ ਕੈਪਚਰ ਕਰਦਾ ਹੈ ਜੋ ਕਿਸੇ ਵੀ ਕਿਸਮ ਦੇ ਪਿਛਲੇ ਬੈਕਅੱਪ ਤੋਂ ਬਾਅਦ ਬਦਲਿਆ ਹੈ। ਸਟੋਰੇਜ ਵਿੱਚ ਬਣਾਉਣਾ ਅਤੇ ਸੰਕੁਚਿਤ ਕਰਨਾ ਤੇਜ਼ ਹੈ, ਪਰ ਬਹਾਲੀ ਲਈ ਪੂਰੀ ਚੇਨ ਨੂੰ ਮੁੜ ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਆਖਰੀ ਪੂਰਾ ਬੈਕਅੱਪ ਅਤੇ ਹਰ ਬਾਅਦ ਵਿੱਚ ਵਾਧਾ। ਇੱਕਡਿਫਰੈਂਸ਼ੀਅਲ ਬੈਕਅੱਪਉਹ ਸਭ ਕੁਝ ਕੈਪਚਰ ਕਰਦਾ ਹੈ ਜੋ ਪਿਛਲੇ ਪੂਰੇ ਬੈਕਅੱਪ ਤੋਂ ਬਾਅਦ ਬਦਲਿਆ ਹੈ। ਇਹ ਇੱਕ ਮੱਧ ਭੂਮੀ 'ਤੇ ਕਬਜ਼ਾ ਕਰਦਾ ਹੈ — ਇੱਕ ਵਾਧੇ ਵਾਲੇ ਤੋਂ ਵੱਡਾ ਪਰ ਬਹਾਲ ਕਰਨਾ ਸੌਖਾ ਹੈ ਕਿਉਂਕਿ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਆਖਰੀ ਪੂਰੇ ਅਤੇ ਨਵੀਨਤਮ ਅੰਤਰ ਦੀ ਲੋੜ ਹੈ। ਅੰਤ ਵਿੱਚ,ਨਿਰੰਤਰ ਪੁਰਾਲੇਖ(PostgreSQL ਵਿੱਚ WAL ਪੁਰਾਲੇਖ, MySQL ਵਿੱਚ ਬਾਈਨਰੀ ਲੌਗ ਸਟ੍ਰੀਮਿੰਗ) ਹਰੇਕ ਵਿਅਕਤੀਗਤ ਲੈਣ-ਦੇਣ ਨੂੰ ਕੈਪਚਰ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਇਹ ਵਾਪਰਦਾ ਹੈ, ਬੈਕਅੱਪ ਦੇ ਵਿਚਕਾਰ ਕਿਸੇ ਵੀ ਪਲ ਲਈ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਉਤਪਾਦਨ ਪ੍ਰਣਾਲੀਆਂ ਲਈ ਅਨੁਕੂਲ ਰਣਨੀਤੀ ਇੱਕ ਸੁਮੇਲ ਹੈ: ਹਫਤਾਵਾਰੀ ਪੂਰੇ ਬੈਕਅੱਪ, ਰੋਜ਼ਾਨਾ ਵਾਧੇ ਜਾਂ ਅੰਤਰ, ਅਤੇ ਲਗਾਤਾਰ WAL/binlog ਪੁਰਾਲੇਖ। ਇਹ ਤੁਹਾਨੂੰ ਹਾਲ ਹੀ ਦੇ ਪੂਰੇ ਬੈਕਅੱਪਾਂ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਰਿਕਵਰੀ ਅਤੇ ਲੋੜ ਪੈਣ 'ਤੇ ਕਿਸੇ ਵੀ ਸਮੇਂ ਤੱਕ ਰਿਕਵਰੀ ਕਰਨ ਦੀ ਯੋਗਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
MySQL ਬੈਕਅੱਪ ਵਿਧੀਆਂ
MySQL ਕਈ ਬੈਕਅੱਪ ਟੂਲ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਹਰੇਕ ਵੱਖ-ਵੱਖ ਡਾਟਾਬੇਸ ਆਕਾਰਾਂ ਅਤੇ ਰਿਕਵਰੀ ਲੋੜਾਂ ਲਈ ਅਨੁਕੂਲ ਹੈ। ਸਹੀ ਚੋਣ ਤੁਹਾਡੇ ਡੇਟਾ ਵਾਲੀਅਮ, ਸਵੀਕਾਰਯੋਗ ਬੈਕਅੱਪ ਵਿੰਡੋ, ਅਤੇ RTO/RPO ਟੀਚਿਆਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।
mysqldump — ਯੂਨੀਵਰਸਲ ਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪ
mysqldumpSQL ਸਟੇਟਮੈਂਟਾਂ ਦਾ ਉਤਪਾਦਨ ਕਰਦਾ ਹੈ ਜੋ ਸਕੀਮਾ ਅਤੇ ਡੇਟਾ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਹਰ MySQL ਸੰਸਕਰਣ ਅਤੇ ਸਟੋਰੇਜ਼ ਇੰਜਣ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸ ਨੂੰ ਯੂਨੀਵਰਸਲ ਫਾਲਬੈਕ ਬਣਾਉਂਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇਹ ਡੰਪ ਦੇ ਦੌਰਾਨ ਟੇਬਲਾਂ ਨੂੰ ਤਾਲਾਬੰਦ ਕਰਦਾ ਹੈ (ਜਦੋਂ ਤੱਕ ਕਿ InnoDB ਨਾਲ--single-transactionਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ), ਅਤੇ ਬਹਾਲੀ ਦੀ ਗਤੀ 50-100 GB ਤੋਂ ਵੱਧ ਡਾਟਾਬੇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਘਟ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਵਿਅਕਤੀਗਤ INSERT ਸਟੇਟਮੈਂਟਾਂ ਨੂੰ ਮੁੜ-ਪਲੇਅ ਕਰਦਾ ਹੈ।
# Full logical backup with consistent snapshot for InnoDB
mysqldump --single-transaction --routines --triggers --events \
--set-gtid-purged=ON --all-databases \
| gzip > /backups/mysql-full-$(date +%Y%m%d-%H%M%S).sql.gz
# Single database backup with compression
mysqldump --single-transaction --routines --triggers \
--databases production_db \
| pigz -p4 > /backups/production_db-$(date +%Y%m%d).sql.gz
# Schema-only backup for migration planning
mysqldump --no-data --routines --triggers --events \
--all-databases > /backups/schema-only-$(date +%Y%m%d).sqlmysqlpump — ਸਮਾਨਾਂਤਰ ਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪ
mysqlpumpਪੈਰਲਲ ਟੇਬਲ ਡੰਪਿੰਗ ਅਤੇ ਬਿਲਟ-ਇਨ ਕੰਪਰੈਸ਼ਨ ਦੇ ਨਾਲmysqldump'ਤੇ ਸੁਧਾਰ ਕਰਦਾ ਹੈ। ਇਹ ਬਹੁਤ ਸਾਰੇ ਸੁਤੰਤਰ ਟੇਬਲਾਂ ਵਾਲੇ ਡੇਟਾਬੇਸ ਲਈ ਬੈਕਅਪ ਸਮੇਂ ਨੂੰ ਕਾਫ਼ੀ ਘਟਾ ਸਕਦਾ ਹੈ।
# Parallel logical backup with 4 threads and zstd compression
mysqlpump --default-parallelism=4 --compress-output=ZSTD \
--include-databases=production_db,analytics_db \
--set-gtid-purged=ON \
> /backups/mysql-pump-$(date +%Y%m%d).sql.zstPercona XtraBackup — InnoDB
ਲਈ ਭੌਤਿਕ ਬੈਕਅੱਪ50 GB ਤੋਂ ਵੱਡੇ ਡੇਟਾਬੇਸ ਲਈ, ਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪ ਅਵਿਵਹਾਰਕ ਹੋ ਜਾਂਦੇ ਹਨ — ਬੈਕਅੱਪ ਵਿੰਡੋ ਅਤੇ ਰੀਸਟੋਰ ਸਮਾਂ ਦੋਵੇਂ ਡਾਟਾ ਆਕਾਰ ਦੇ ਨਾਲ ਰੇਖਿਕ ਤੌਰ 'ਤੇ ਵਧਦੇ ਹਨ। Percona XtraBackup ਡਾਟਾਬੇਸ ਨੂੰ ਲਾਕ ਕੀਤੇ ਬਿਨਾਂ InnoDB ਡਾਟਾ ਫਾਈਲਾਂ ਦੀਆਂ ਭੌਤਿਕ-ਪੱਧਰ ਦੀਆਂ ਕਾਪੀਆਂ ਲੈਂਦਾ ਹੈ, ਇਸ ਨੂੰ ਮਲਟੀ-ਟੇਰਾਬਾਈਟ ਤੈਨਾਤੀਆਂ ਲਈ ਢੁਕਵਾਂ ਬਣਾਉਂਦਾ ਹੈ।
# Full physical backup with streaming to compressed archive
xtrabackup --backup --target-dir=/backups/full-$(date +%Y%m%d) \
--user=backup_user --password=secure_pass \
--parallel=4 --compress --compress-threads=4
# Incremental backup based on last full
xtrabackup --backup --target-dir=/backups/incr-$(date +%Y%m%d) \
--incremental-basedir=/backups/full-20260412 \
--user=backup_user --password=secure_pass \
--parallel=4
# Stream full backup directly to S3 via xbstream
xtrabackup --backup --stream=xbstream --compress \
--user=backup_user --password=secure_pass | \
aws s3 cp - s3://db-backups/mysql/full-$(date +%Y%m%d).xbstream
# Prepare for restore (apply redo log)
xtrabackup --prepare --target-dir=/backups/full-20260412
# Prepare incremental on top of full
xtrabackup --prepare --apply-log-only --target-dir=/backups/full-20260412
xtrabackup --prepare --target-dir=/backups/full-20260412 \
--incremental-dir=/backups/incr-20260412
# Restore
systemctl stop mysqld
xtrabackup --copy-back --target-dir=/backups/full-20260412
chown -R mysql:mysql /var/lib/mysql
systemctl start mysqldMySQL ਬਾਈਨਰੀ ਲੌਗ — ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ
MySQL ਬਾਈਨਰੀ ਲੌਗ ਹਰ ਡਾਟਾ-ਸੋਧਣ ਵਾਲੀ ਸਟੇਟਮੈਂਟ ਜਾਂ ਕਤਾਰ ਤਬਦੀਲੀ ਨੂੰ ਰਿਕਾਰਡ ਕਰਦੇ ਹਨ। ਜਦੋਂ ਇੱਕ ਪੂਰੇ ਜਾਂ ਭੌਤਿਕ ਬੈਕਅੱਪ ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਬੈਕਅੱਪ ਲੈਣ ਤੋਂ ਬਾਅਦ ਕਿਸੇ ਵੀ ਪਲ ਲਈ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦੇ ਹਨ।
# Enable binary logging in my.cnf
[mysqld]
server-id = 1
log-bin = /var/log/mysql/mysql-bin
binlog_format = ROW
binlog_expire_logs_seconds = 604800 # 7 days
sync_binlog = 1
gtid_mode = ON
enforce_gtid_consistency = ON
# Flush and archive binary logs
mysqladmin flush-logs
mysqlbinlog --read-from-remote-server --host=db-primary \
--raw --stop-never --result-file=/backup/binlogs/ \
mysql-bin.000042
# Point-in-time recovery: replay binlog up to specific timestamp
mysqlbinlog --stop-datetime="2026-04-12 14:30:00" \
/backup/binlogs/mysql-bin.000042 \
/backup/binlogs/mysql-bin.000043 | mysql -u rootPostgreSQL ਬੈਕਅੱਪ ਢੰਗ
PostgreSQL ਦਾ ਬੈਕਅੱਪ ਈਕੋਸਿਸਟਮ MySQL ਦੇ ਮੁਕਾਬਲੇ ਜ਼ਿਆਦਾ ਅਮੀਰ ਹੈ, ਪਹਿਲੀ-ਪਾਰਟੀ ਟੂਲਸ ਅਤੇ ਵੱਡੇ ਪੈਮਾਨੇ ਦੇ ਉਤਪਾਦਨ ਵਾਤਾਵਰਣਾਂ ਲਈ ਬਣਾਏ ਗਏ ਕਮਿਊਨਿਟੀ ਹੱਲਾਂ ਦੇ ਇੱਕ ਪਰਿਪੱਕ ਸੈੱਟ ਦੇ ਨਾਲ।
pg_dump ਅਤੇ pg_dumpall — ਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪ
mysqldumpਵਾਂਗ,pg_dumpਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਕਸਟਮ ਫਾਰਮੈਟ (-Fc) ਸਿਫ਼ਾਰਸ਼ ਕੀਤਾ ਡਿਫੌਲਟ ਹੈ ਕਿਉਂਕਿ ਇਹ ਪੈਰਲਲ ਰੀਸਟੋਰ, ਚੋਣਵੇਂ ਟੇਬਲ ਰੀਸਟੋਰੇਸ਼ਨ, ਅਤੇ ਬਿਲਟ-ਇਨ ਕੰਪਰੈਸ਼ਨ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।
# Custom format with parallel dump (4 worker jobs)
pg_dump -Fc -j4 -f /backups/production-$(date +%Y%m%d).dump production_db
# Directory format for maximum parallelism on large databases
pg_dump -Fd -j8 -f /backups/production-$(date +%Y%m%d)/ production_db
# All databases including globals (roles, tablespaces)
pg_dumpall > /backups/pg-all-$(date +%Y%m%d).sql
# Parallel restore from custom format
pg_restore -j4 -d production_db_restored /backups/production-20260412.dump
# Selective restore: single table
pg_restore -j4 -d production_db -t orders /backups/production-20260412.dumppg_basebackup — ਫਿਜ਼ੀਕਲ ਬੈਕਅੱਪ ਫਾਊਂਡੇਸ਼ਨ
pg_basebackupਪੂਰੀ PostgreSQL ਡਾਟਾ ਡਾਇਰੈਕਟਰੀ ਦੀ ਇੱਕ ਭੌਤਿਕ ਕਾਪੀ ਲੈਂਦਾ ਹੈ। ਇਹ ਸਟੈਂਡਅਲੋਨ ਰਿਕਵਰੀ ਅਤੇ ਸਟ੍ਰੀਮਿੰਗ ਰੀਪਲੀਕੇਸ਼ਨ ਸੈਟਅਪ ਦੋਵਾਂ ਲਈ ਬੁਨਿਆਦ ਹੈ। WAL ਪੁਰਾਲੇਖ ਦੇ ਨਾਲ ਮਿਲਾ ਕੇ, ਇਹ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ।
# Physical backup with WAL files included
pg_basebackup -D /backups/base-$(date +%Y%m%d) \
-Ft -z -Xs -P -c fast \
-U replication_user -h db-primary
# Stream backup directly to a tar archive with checksums
pg_basebackup -D - -Ft -Xs -c fast \
-U replication_user -h db-primary | \
gzip > /backups/pg-base-$(date +%Y%m%d).tar.gzpgBackRest — ਐਂਟਰਪ੍ਰਾਈਜ਼-ਗ੍ਰੇਡ ਬੈਕਅੱਪ ਪ੍ਰਬੰਧਨ
pgBackRest PostgreSQL ਬੈਕਅੱਪ ਪ੍ਰਬੰਧਨ ਲਈ ਗੋਲਡ ਸਟੈਂਡਰਡ ਹੈ। ਇਹ ਪੂਰੇ, ਵਾਧੇ ਵਾਲੇ, ਅਤੇ ਡਿਫਰੈਂਸ਼ੀਅਲ ਬੈਕਅਪ, ਸਮਾਨਾਂਤਰ ਬੈਕਅੱਪ ਅਤੇ ਰੀਸਟੋਰ, ਏਨਕ੍ਰਿਪਸ਼ਨ, ਮਲਟੀ-ਰਿਪੋਜ਼ਟਰੀ ਟਾਰਗਿਟ (ਸਥਾਨਕ ਡਿਸਕ, S3, GCS, Azure ਬਲੌਬ), ਅਤੇ ਸਵੈਚਲਿਤ WAL ਆਰਕਾਈਵਿੰਗ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ - ਸਭ ਇੱਕ ਸਿੰਗਲ, ਇਕਸੁਰ ਸੰਰਚਨਾ ਦੁਆਰਾ।
# /etc/pgbackrest/pgbackrest.conf
[global]
repo1-type=s3
repo1-s3-bucket=pg-backups-production
repo1-s3-endpoint=s3.eu-west-1.amazonaws.com
repo1-s3-region=eu-west-1
repo1-s3-key=AKIAIOSFODNN7EXAMPLE
repo1-s3-key-secret=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
repo1-path=/pgbackrest
repo1-retention-full=4
repo1-retention-diff=14
repo1-cipher-type=aes-256-cbc
repo1-cipher-pass=a_very_secure_encryption_passphrase
# Second repository for geographic redundancy
repo2-type=azure
repo2-azure-container=pg-backups-dr
repo2-azure-account=prodbackupstorage
repo2-azure-key=base64encodedkeyhere
repo2-path=/pgbackrest
repo2-retention-full=2
process-max=4
compress-type=zst
compress-level=6
log-level-console=info
log-level-file=detail
start-fast=y
[production]
pg1-path=/var/lib/postgresql/16/main
pg1-port=5432
# PostgreSQL WAL archive configuration (postgresql.conf)
# archive_mode = on
# archive_command = 'pgbackrest --stanza=production archive-push %p'
# Create the stanza
pgbackrest --stanza=production stanza-create
# Verify the stanza configuration
pgbackrest --stanza=production check
# Full backup
pgbackrest --stanza=production --type=full backup
# Differential backup
pgbackrest --stanza=production --type=diff backup
# Incremental backup
pgbackrest --stanza=production --type=incr backup
# List backups
pgbackrest --stanza=production infoWAL-G — ਕਲਾਉਡ ਸਟੋਰੇਜ
ਲਈ ਲਾਈਟਵੇਟ WAL ਆਰਕਾਈਵਿੰਗWAL-G pgBackRest ਦਾ ਇੱਕ ਸਰਲ ਵਿਕਲਪ ਹੈ ਜੋ ਕਿ ਕਲਾਉਡ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਲਈ WAL ਸੈਗਮੈਂਟਾਂ ਅਤੇ ਬੇਸ ਬੈਕਅੱਪਾਂ ਨੂੰ ਸਟ੍ਰੀਮ ਕਰਨ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੈ। ਇਹ ਕੰਟੇਨਰਾਈਜ਼ਡ ਵਾਤਾਵਰਨ ਵਿੱਚ ਪ੍ਰਸਿੱਧ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਘੱਟੋ-ਘੱਟ ਸੰਰਚਨਾ ਦੇ ਨਾਲ ਇੱਕ ਸਿੰਗਲ ਬਾਈਨਰੀ ਚਾਹੁੰਦੇ ਹੋ।
# Environment variables for WAL-G with S3
export WALG_S3_PREFIX=s3://pg-wal-archive/production
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_REGION=eu-west-1
export WALG_COMPRESSION_METHOD=lz4
export PGHOST=/var/run/postgresql
# Configure WAL archiving in postgresql.conf
# archive_mode = on
# archive_command = 'wal-g wal-push %p'
# restore_command = 'wal-g wal-fetch %f %p'
# Take a base backup
wal-g backup-push /var/lib/postgresql/16/main
# List backups
wal-g backup-list
# Restore from latest backup
wal-g backup-fetch /var/lib/postgresql/16/main LATEST
# Delete old backups (retain last 4)
wal-g delete retain FULL 4 --confirmਬਰਮਨ — ਕੇਂਦਰੀਕ੍ਰਿਤ ਬੈਕਅੱਪ ਸਰਵਰ
ਬਰਮਨ (ਬੈਕਅੱਪ ਅਤੇ ਰਿਕਵਰੀ ਮੈਨੇਜਰ) ਨੂੰ ਅਜਿਹੇ ਵਾਤਾਵਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ ਜਿੱਥੇ ਇੱਕ ਸਮਰਪਿਤ ਬੈਕਅੱਪ ਸਰਵਰ ਕਈ PostgreSQL ਮੌਕਿਆਂ ਲਈ ਬੈਕਅੱਪ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ। ਇਹ ਬੈਕਅੱਪ ਟ੍ਰਾਂਸਪੋਰਟ ਲਈ rsync/SSH ਅਤੇ ਸਟ੍ਰੀਮਿੰਗ ਰੀਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਟੋਕੋਲ ਦੋਵਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।
# /etc/barman.d/production.conf
[production]
description = "Production PostgreSQL 16"
ssh_command = ssh postgres@db-primary
conninfo = host=db-primary user=barman dbname=postgres
streaming_conninfo = host=db-primary user=streaming_barman
backup_method = postgres
streaming_archiver = on
slot_name = barman
retention_policy = RECOVERY WINDOW OF 14 DAYS
# Create replication slot and start streaming
barman receive-wal --create-slot production
barman switch-wal --force --archive production
# Take a backup
barman backup production
# List backups
barman list-backup production
# Restore to point in time
barman recover --target-time "2026-04-12 14:30:00" \
production 20260412T120000 /var/lib/postgresql/16/mainਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ (PITR)
ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਤੁਹਾਡੀ ਬੈਕਅੱਪ ਟੂਲਕਿੱਟ ਵਿੱਚ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਸਮਰੱਥਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਇੱਕ ਡੇਟਾਬੇਸ ਨੂੰ ਸਹੀ ਸਥਿਤੀ ਵਿੱਚ ਮੁੜ ਸਥਾਪਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਇਹ ਕਿਸੇ ਵੀ ਖਾਸ ਪਲ ਵਿੱਚ ਸੀ — ਨਾ ਸਿਰਫ਼ ਉਦੋਂ ਜਦੋਂ ਬੈਕਅੱਪ ਲਏ ਗਏ ਸਨ, ਪਰ ਬੈਕਅੱਪ ਦੇ ਵਿਚਕਾਰ ਕੋਈ ਵੀ ਸਕਿੰਟ। ਇਹ ਦੁਰਘਟਨਾਤਮਕ ਡੇਟਾ ਮਿਟਾਉਣ, ਐਪਲੀਕੇਸ਼ਨ ਬੱਗ ਜੋ ਡੇਟਾ ਨੂੰ ਖਰਾਬ ਕਰਦੇ ਹਨ, ਅਤੇ ਸੁਰੱਖਿਆ ਘਟਨਾਵਾਂ ਤੋਂ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਿੱਥੇ ਤੁਹਾਨੂੰ ਸਮਝੌਤਾ ਦੇ ਸਹੀ ਪਲ ਦੀ ਪਛਾਣ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ।
PostgreSQLਲਈPITR
PostgreSQL PITR ਇੱਕ ਬੇਸ ਬੈਕਅਪ ਨੂੰ ਬਹਾਲ ਕਰਕੇ ਅਤੇ WAL ਖੰਡਾਂ ਨੂੰ ਟਾਰਗੇਟ ਟਾਈਮਸਟੈਂਪ ਤੱਕ ਰੀਪਲੇਅ ਕਰਕੇ ਕੰਮ ਕਰਦਾ ਹੈ। pgBackRest ਦੇ ਨਾਲ, ਪੂਰੀ ਪ੍ਰਕਿਰਿਆ ਇੱਕ ਸਿੰਗਲ ਕਮਾਂਡ ਹੈ।
# Restore to specific point in time with pgBackRest
pgbackrest --stanza=production \
--type=time --target="2026-04-12 16:42:30" \
--target-action=promote \
restore
# Manual PITR using pg_basebackup + WAL archive
# 1. Stop PostgreSQL
systemctl stop postgresql
# 2. Clear the data directory and restore base backup
rm -rf /var/lib/postgresql/16/main/*
tar xzf /backups/pg-base-20260412.tar.gz -C /var/lib/postgresql/16/main/
# 3. Create recovery signal and configure restore
cat > /var/lib/postgresql/16/main/postgresql.auto.conf << 'CONF'
restore_command = 'cp /backup/wal_archive/%f %p'
recovery_target_time = '2026-04-12 16:42:30'
recovery_target_action = 'promote'
CONF
touch /var/lib/postgresql/16/main/recovery.signal
# 4. Start PostgreSQL — it will replay WAL and stop at target
systemctl start postgresqlPITR
MySQL PITR ਇੱਕ XtraBackup ਭੌਤਿਕ ਰੀਸਟੋਰ ਨੂੰ ਬਾਈਨਰੀ ਲੌਗ ਰੀਪਲੇਅ ਨਾਲ ਜੋੜਦਾ ਹੈ।
# 1. Restore the XtraBackup
systemctl stop mysqld
rm -rf /var/lib/mysql/*
xtrabackup --prepare --target-dir=/backups/full-20260412
xtrabackup --copy-back --target-dir=/backups/full-20260412
chown -R mysql:mysql /var/lib/mysql
systemctl start mysqld
# 2. Identify the binlog position from XtraBackup metadata
cat /backups/full-20260412/xtrabackup_binlog_info
# Output: mysql-bin.000042 154 3E11FA47-1111-1111-1111-AAAAAAAAAAAA:1-1234
# 3. Replay binlogs up to target time
mysqlbinlog --start-position=154 \
--stop-datetime="2026-04-12 16:42:30" \
/backup/binlogs/mysql-bin.000042 \
/backup/binlogs/mysql-bin.000043 | mysql -u rootਮਲਟੀ-ਕਲਾਊਡ ਬੈਕਅੱਪ ਆਰਕੀਟੈਕਚਰ
ਉਤਪਾਦਨ ਬੈਕਅੱਪ ਰਣਨੀਤੀਆਂ ਨੂੰ ਕਿਸੇ ਵੀ ਇੱਕਲੇ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ਜਾਂ ਖੇਤਰ ਦੀ ਅਸਫਲਤਾ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਬੈਕਅੱਪਾਂ ਨੂੰ ਸਿਰਫ਼ ਉਸੇ ਕਲਾਊਡ ਖਾਤੇ ਅਤੇ ਖੇਤਰ ਵਿੱਚ ਸਟੋਰ ਕਰਨਾ ਜਿਸ ਵਿੱਚ ਤੁਹਾਡੇ ਉਤਪਾਦਨ ਡੇਟਾਬੇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਖਾਤਾ ਸਮਝੌਤਾ, ਬਿਲਿੰਗ ਸਮੱਸਿਆ, ਜਾਂ ਖੇਤਰੀ ਆਊਟੇਜ ਤੁਹਾਡੇ ਡੇਟਾ ਅਤੇ ਤੁਹਾਡੇ ਬੈਕਅੱਪ ਦੋਵਾਂ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਲੈ ਸਕਦਾ ਹੈ। ਇੱਕ ਮਜਬੂਤ ਆਰਕੀਟੈਕਚਰ ਅੰਤਰ-ਖੇਤਰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਨਾਲ ਘੱਟੋ-ਘੱਟ ਦੋ ਸੁਤੰਤਰ ਸਟੋਰੇਜ ਟੀਚਿਆਂ ਲਈ ਬੈਕਅੱਪ ਭੇਜਦਾ ਹੈ।
ਲਾਈਫਸਾਈਕਲ ਨੀਤੀਆਂ ਦੇ ਨਾਲਕਲਾਉਡ ਸਟੋਰੇਜ ਕੌਂਫਿਗਰੇਸ਼ਨ
# AWS S3 lifecycle policy (Terraform)
resource "aws_s3_bucket_lifecycle_configuration" "backup_lifecycle" {
bucket = aws_s3_bucket.db_backups.id
rule {
id = "backup-tiering"
status = "Enabled"
transition {
days = 30
storage_class = "STANDARD_IA"
}
transition {
days = 90
storage_class = "GLACIER"
}
transition {
days = 365
storage_class = "DEEP_ARCHIVE"
}
expiration {
days = 2555 # 7 years for compliance
}
}
rule {
id = "wal-segments"
status = "Enabled"
filter {
prefix = "wal-archive/"
}
expiration {
days = 30
}
}
}
# Enable cross-region replication
resource "aws_s3_bucket_replication_configuration" "backup_replication" {
bucket = aws_s3_bucket.db_backups.id
role = aws_iam_role.replication.arn
rule {
id = "cross-region-dr"
status = "Enabled"
destination {
bucket = aws_s3_bucket.db_backups_dr.arn
storage_class = "STANDARD_IA"
encryption_configuration {
replica_kms_key_id = aws_kms_key.dr_key.arn
}
}
source_selection_criteria {
sse_kms_encrypted_objects {
status = "Enabled"
}
}
}
}# Azure Blob immutability policy (Azure CLI)
az storage container immutability-policy create \
--account-name prodbackupstorage \
--container-name pg-backups \
--period 365 \
--allow-protected-append-writes true
# GCS lifecycle with nearline transition
gsutil lifecycle set /dev/stdin gs://pg-backups-production << 'JSON'
{
"rule": [
{"action": {"type": "SetStorageClass", "storageClass": "NEARLINE"}, "condition": {"age": 30}},
{"action": {"type": "SetStorageClass", "storageClass": "COLDLINE"}, "condition": {"age": 90}},
{"action": {"type": "Delete"}, "condition": {"age": 2555}}
]
}
JSONਬੈਕਅੱਪ ਐਨਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਸੁਰੱਖਿਆ
ਬੈਕਅੱਪ ਹਮਲਾਵਰਾਂ ਲਈ ਉੱਚ-ਮੁੱਲ ਵਾਲੇ ਟੀਚੇ ਹਨ। ਇੱਕ ਚੋਰੀ ਹੋਇਆ ਅਨਇਨਕ੍ਰਿਪਟਡ ਬੈਕਅੱਪ ਹਮਲਾਵਰ ਨੂੰ ਤੁਹਾਡੇ ਚੱਲ ਰਹੇ ਸਿਸਟਮਾਂ ਦੀ ਉਲੰਘਣਾ ਕੀਤੇ ਬਿਨਾਂ ਤੁਹਾਡੇ ਉਤਪਾਦਨ ਡੇਟਾ ਦੀ ਇੱਕ ਪੂਰੀ ਕਾਪੀ ਦਿੰਦਾ ਹੈ। ਹਰ ਬੈਕਅੱਪ, ਆਵਾਜਾਈ ਵਿੱਚ ਅਤੇ ਆਰਾਮ ਵਿੱਚ, ਇਨਕ੍ਰਿਪਟਡ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਟ੍ਰਾਂਜ਼ਿਟ ਵਿੱਚ ਐਨਕ੍ਰਿਪਸ਼ਨਦਾ ਮਤਲਬ ਹੈ ਡੇਟਾਬੇਸ ਸਰਵਰ ਅਤੇ ਬੈਕਅੱਪ ਮੰਜ਼ਿਲ ਦੇ ਵਿਚਕਾਰ ਸਾਰੇ ਕਨੈਕਸ਼ਨਾਂ ਲਈ TLS ਦੀ ਵਰਤੋਂ ਕਰਨਾ। TLS ਨਾਲ ਕੌਂਫਿਗਰ ਕੀਤੇ ਜਾਣ 'ਤੇ ਦੋਵੇਂ pgBackRest ਅਤੇ XtraBackup ਸਟ੍ਰੀਮ ਨੂੰ ਏਨਕ੍ਰਿਪਟ ਕੀਤੇ ਚੈਨਲਾਂ ਉੱਤੇ। S3, Azure Blob, ਜਾਂ GCS 'ਤੇ ਸ਼ਿਪਿੰਗ ਕਰਦੇ ਸਮੇਂ, ਕਲਾਇੰਟ SDK ਮੂਲ ਰੂਪ ਵਿੱਚ HTTPS ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।
ਬਾਕੀਇਨਕ੍ਰਿਪਸ਼ਨ ਦੀਆਂ ਦੋ ਪਰਤਾਂ ਹਨ। ਸਰਵਰ-ਸਾਈਡ ਇਨਕ੍ਰਿਪਸ਼ਨ (SSE) ਸਟੋਰੇਜ ਟੀਚੇ 'ਤੇ ਪਹੁੰਚਣ ਤੋਂ ਬਾਅਦ ਡੇਟਾ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ — S3 SSE-KMS, Azure ਸਟੋਰੇਜ ਸਰਵਿਸ ਇਨਕ੍ਰਿਪਸ਼ਨ, ਜਾਂ GCS ਡਿਫੌਲਟ ਐਨਕ੍ਰਿਪਸ਼ਨ। ਕਲਾਇੰਟ-ਸਾਈਡ ਇਨਕ੍ਰਿਪਸ਼ਨ ਡੇਟਾਬੇਸ ਸਰਵਰ ਨੂੰ ਛੱਡਣ ਤੋਂ ਪਹਿਲਾਂ ਡੇਟਾ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ਕਦੇ ਵੀ ਪਲੇਨ ਟੈਕਸਟ ਡੇਟਾ ਨੂੰ ਨਹੀਂ ਦੇਖਦਾ। pgBackRest ਅਤੇ WAL-G ਦੋਵੇਂ ਮੂਲ ਰੂਪ ਵਿੱਚ ਕਲਾਇੰਟ-ਸਾਈਡ ਇਨਕ੍ਰਿਪਸ਼ਨ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ।
# pgBackRest client-side encryption config
repo1-cipher-type=aes-256-cbc
repo1-cipher-pass=long_random_passphrase_stored_in_vault
# WAL-G client-side encryption
export WALG_LIBSODIUM_KEY=$(cat /etc/wal-g/encryption.key)
# Or GPG-based
export WALG_GPG_KEY_ID=backup@example.com
# MySQL XtraBackup with encryption
xtrabackup --backup --encrypt=AES256 \
--encrypt-key-file=/etc/mysql/backup-encryption.key \
--target-dir=/backups/full-encrypted-$(date +%Y%m%d)ਇਨਕ੍ਰਿਪਸ਼ਨ ਕੁੰਜੀਆਂ ਨੂੰ ਖੁਦ ਬੈਕਅੱਪ ਤੋਂ ਵੱਖ ਸਟੋਰ ਕਰੋ। HashiCorp ਵਾਲਟ, AWS ਸੀਕਰੇਟਸ ਮੈਨੇਜਰ, ਜਾਂ Azure ਕੀ ਵਾਲਟ ਵਰਗੇ ਇੱਕ ਸੀਕਰੇਟਸ ਮੈਨੇਜਰ ਦੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਪਹੁੰਚ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਬੈਕਅੱਪ ਦੇ ਨਾਲ ਕੁੰਜੀ ਸਟੋਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਹਮਲਾਵਰ ਜੋ ਤੁਹਾਡੀ ਬੈਕਅੱਪ ਸਟੋਰੇਜ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਉਸ ਕੋਲ ਉਹ ਸਭ ਕੁਝ ਹੁੰਦਾ ਹੈ ਜਿਸਦੀ ਉਹਨਾਂ ਨੂੰ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਆਟੋਮੇਟਿਡ ਬੈਕਅੱਪ ਸਮਾਂ-ਸਾਰਣੀ
ਮੈਨੁਅਲ ਬੈਕਅੱਪ ਬੈਕਅੱਪ ਨਹੀਂ ਹਨ — ਉਹ ਇੱਛਾਵਾਂ ਹਨ। ਬੈਕਅੱਪ ਸਮਾਂ-ਸਾਰਣੀ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਸਵੈਚਲਿਤ, ਨਿਗਰਾਨੀ, ਅਤੇ ਅਸਫਲਤਾ 'ਤੇ ਚੇਤਾਵਨੀ ਦਿੱਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।
ਬੇਅਰ ਮੈਟਲ ਅਤੇ VMsਲਈਸਿਸਟਮ ਕਰੋਨ# /etc/cron.d/database-backups
# PostgreSQL — pgBackRest
# Full backup every Sunday at 01:00
0 1 * * 0 postgres pgbackrest --stanza=production --type=full backup 2>&1 | logger -t pgbackrest-full
# Differential backup every day at 01:00 (except Sunday)
0 1 * * 1-6 postgres pgbackrest --stanza=production --type=diff backup 2>&1 | logger -t pgbackrest-diff
# MySQL — XtraBackup
# Full backup every Sunday at 02:00
0 2 * * 0 root /usr/local/bin/mysql-backup.sh full 2>&1 | logger -t xtrabackup-full
# Incremental backup every day at 02:00 (except Sunday)
0 2 * * 1-6 root /usr/local/bin/mysql-backup.sh incremental 2>&1 | logger -t xtrabackup-incr
# Backup verification — restore test every Wednesday at 04:00
0 4 * * 3 root /usr/local/bin/verify-backup.sh 2>&1 | logger -t backup-verify
Kubernetes CronJobs
# /etc/cron.d/database-backups
# PostgreSQL — pgBackRest
# Full backup every Sunday at 01:00
0 1 * * 0 postgres pgbackrest --stanza=production --type=full backup 2>&1 | logger -t pgbackrest-full
# Differential backup every day at 01:00 (except Sunday)
0 1 * * 1-6 postgres pgbackrest --stanza=production --type=diff backup 2>&1 | logger -t pgbackrest-diff
# MySQL — XtraBackup
# Full backup every Sunday at 02:00
0 2 * * 0 root /usr/local/bin/mysql-backup.sh full 2>&1 | logger -t xtrabackup-full
# Incremental backup every day at 02:00 (except Sunday)
0 2 * * 1-6 root /usr/local/bin/mysql-backup.sh incremental 2>&1 | logger -t xtrabackup-incr
# Backup verification — restore test every Wednesday at 04:00
0 4 * * 3 root /usr/local/bin/verify-backup.sh 2>&1 | logger -t backup-verifyKubernetes ਵਾਤਾਵਰਨ ਵਿੱਚ, CronJobs ਸਿਸਟਮ ਕ੍ਰੋਨ ਨੂੰ ਬਦਲਦਾ ਹੈ। ਉਹ ਕਲੱਸਟਰ ਦੇ RBAC ਅਤੇ ਗੁਪਤ ਪ੍ਰਬੰਧਨ ਦੇ ਨਾਲ ਬਿਲਟ-ਇਨ ਰੀਟ੍ਰੀ ਤਰਕ, ਸਮਕਾਲੀ ਨਿਯੰਤਰਣ, ਅਤੇ ਏਕੀਕਰਣ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੇ ਹਨ।
apiVersion: batch/v1
kind: CronJob
metadata:
name: pg-backup-full
namespace: database
spec:
schedule: "0 1 * * 0" # Sunday 01:00 UTC
concurrencyPolicy: Forbid
successfulJobsHistoryLimit: 4
failedJobsHistoryLimit: 3
jobTemplate:
spec:
backoffLimit: 2
activeDeadlineSeconds: 7200 # 2 hour timeout
template:
spec:
serviceAccountName: db-backup
restartPolicy: OnFailure
containers:
- name: pgbackrest
image: pgbackrest/pgbackrest:2.50
command:
- /bin/bash
- -c
- |
pgbackrest --stanza=production --type=full backup
RESULT=$?
if [ $RESULT -eq 0 ]; then
curl -s -X POST "$SLACK_WEBHOOK" \
-d '{"text":"PostgreSQL full backup completed successfully"}'
else
curl -s -X POST "$SLACK_WEBHOOK" \
-d '{"text":"ALERT: PostgreSQL full backup FAILED"}'
fi
exit $RESULT
envFrom:
- secretRef:
name: pgbackrest-credentials
- secretRef:
name: slack-webhook
resources:
requests:
memory: 512Mi
cpu: 500m
limits:
memory: 2Gi
cpu: "2"
volumeMounts:
- name: pgbackrest-config
mountPath: /etc/pgbackrest
volumes:
- name: pgbackrest-config
configMap:
name: pgbackrest-conf
---
apiVersion: batch/v1
kind: CronJob
metadata:
name: pg-backup-diff
namespace: database
spec:
schedule: "0 1 * * 1-6" # Mon-Sat 01:00 UTC
concurrencyPolicy: Forbid
successfulJobsHistoryLimit: 7
failedJobsHistoryLimit: 3
jobTemplate:
spec:
backoffLimit: 2
activeDeadlineSeconds: 3600
template:
spec:
serviceAccountName: db-backup
restartPolicy: OnFailure
containers:
- name: pgbackrest
image: pgbackrest/pgbackrest:2.50
command:
- /bin/bash
- -c
- |
pgbackrest --stanza=production --type=diff backup
envFrom:
- secretRef:
name: pgbackrest-credentials
resources:
requests:
memory: 256Mi
cpu: 250m
limits:
memory: 1Gi
cpu: "1"
volumeMounts:
- name: pgbackrest-config
mountPath: /etc/pgbackrest
volumes:
- name: pgbackrest-config
configMap:
name: pgbackrest-conf
---
apiVersion: batch/v1
kind: CronJob
metadata:
name: mysql-backup-full
namespace: database
spec:
schedule: "0 2 * * 0"
concurrencyPolicy: Forbid
jobTemplate:
spec:
backoffLimit: 2
activeDeadlineSeconds: 7200
template:
spec:
serviceAccountName: db-backup
restartPolicy: OnFailure
containers:
- name: xtrabackup
image: percona/percona-xtrabackup:8.0
command:
- /bin/bash
- -c
- |
xtrabackup --backup --stream=xbstream --compress \
--user=$MYSQL_BACKUP_USER \
--password=$MYSQL_BACKUP_PASS \
--host=mysql-primary.database.svc | \
aws s3 cp - s3://$S3_BUCKET/mysql/full-$(date +%Y%m%d).xbstream
envFrom:
- secretRef:
name: mysql-backup-credentials
- secretRef:
name: aws-credentials
resources:
requests:
memory: 512Mi
cpu: 500m
limits:
memory: 2Gi
cpu: "2"Kubernetes-ਨੇਟਿਵ ਬੈਕਅੱਪ ਪਹੁੰਚ
Kubernetes ਵਿੱਚ ਚੱਲ ਰਹੇ ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਰਣਨੀਤੀ ਲਈ ਇੱਕ ਨਵਾਂ ਮਾਪ ਪੇਸ਼ ਕਰਦੇ ਹਨ। ਐਪਲੀਕੇਸ਼ਨ-ਪੱਧਰ ਦੇ ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਤੋਂ ਇਲਾਵਾ, ਤੁਹਾਨੂੰ ਕਲੱਸਟਰ-ਪੱਧਰ ਦੇ ਬੈਕਅੱਪ (etcd), ਨਿਰੰਤਰ ਵਾਲੀਅਮ ਸਨੈਪਸ਼ਾਟ, ਅਤੇ ਆਪਰੇਟਰ-ਪ੍ਰਬੰਧਿਤ ਬੈਕਅੱਪ 'ਤੇ ਵਿਚਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
ਕਲੱਸਟਰ-ਪੱਧਰ ਬੈਕਅੱਪਲਈਵੇਲੇਰੋ
ਵੇਲੇਰੋ Kubernetes ਸਰੋਤਾਂ (ਤੈਨਾਤੀ, ਸੇਵਾਵਾਂ, ਸੰਰਚਨਾ, ਭੇਦ) ਅਤੇ ਨਿਰੰਤਰ ਵਾਲੀਅਮ ਦਾ ਬੈਕਅੱਪ ਲੈਂਦਾ ਹੈ। ਇਹ ਐਪਲੀਕੇਸ਼ਨ-ਪੱਧਰ ਦੇ ਡੇਟਾਬੇਸ ਬੈਕਅਪ ਲਈ ਬਦਲ ਨਹੀਂ ਹੈ - ਇਹ PVs ਦਾ ਇੱਕ ਕਰੈਸ਼-ਇਕਸਾਰ ਸਨੈਪਸ਼ਾਟ ਕੈਪਚਰ ਕਰਦਾ ਹੈ, ਜੋ ਡੇਟਾਬੇਸ ਲਈ ਲੈਣ-ਦੇਣ ਅਨੁਸਾਰ ਇਕਸਾਰ ਨਹੀਂ ਹੋ ਸਕਦਾ ਹੈ। ਡਾਟਾਬੇਸ ਰਿਕਵਰੀ ਲਈ ਕਲੱਸਟਰ ਰਿਕਵਰੀ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ-ਲੈਵਲ ਟੂਲਸ (pgBackRest, XtraBackup) ਲਈ ਵੇਲੇਰੋ ਦੀ ਵਰਤੋਂ ਕਰੋ।
# Install Velero with S3 backend
velero install \
--provider aws \
--bucket velero-backups \
--secret-file ./credentials-velero \
--backup-location-config region=eu-west-1 \
--snapshot-location-config region=eu-west-1 \
--use-volume-snapshots=true \
--plugins velero/velero-plugin-for-aws:v1.9.0
# Create a scheduled backup of the database namespace
velero schedule create db-namespace-backup \
--schedule="0 3 * * *" \
--include-namespaces database \
--ttl 720h \
--storage-location default \
--volume-snapshot-locations default
# On-demand backup before maintenance
velero backup create pre-maintenance-$(date +%Y%m%d) \
--include-namespaces database,monitoring \
--wait
# Restore a namespace from backup
velero restore create --from-backup pre-maintenance-20260412 \
--include-namespaces databaseਲੋਂਗਹੋਰਨ ਸਨੈਪਸ਼ਾਟ
k3s ਤੈਨਾਤੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਲੋਂਗਹੋਰਨ ਨੂੰ ਆਪਣੇ CSI ਸਟੋਰੇਜ ਪ੍ਰਦਾਤਾ ਵਜੋਂ ਵਰਤਦੀਆਂ ਹਨ। ਲੋਂਗਹੋਰਨ ਵਾਲੀਅਮ-ਪੱਧਰ ਦੇ ਸਨੈਪਸ਼ਾਟ ਅਤੇ S3-ਅਨੁਕੂਲ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਲਈ ਸਨੈਪਸ਼ਾਟ ਦੀ ਨਕਲ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਡੇਟਾਬੇਸ ਲਈ, ਡੂੰਘਾਈ ਵਿੱਚ ਰੱਖਿਆ ਲਈ ਐਪਲੀਕੇਸ਼ਨ-ਪੱਧਰ ਦੇ ਬੈਕਅੱਪ ਦੇ ਨਾਲ ਲੋਂਗਹੋਰਨ ਸਨੈਪਸ਼ਾਟ ਨੂੰ ਜੋੜੋ।
# Longhorn recurring snapshot job via CRD
apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
name: pg-data-snapshot
namespace: longhorn-system
spec:
cron: "0 */4 * * *" # every 4 hours
task: snapshot
retain: 6
concurrency: 1
groups:
- pg-data
labels:
app: postgresql
---
# Longhorn recurring backup to S3
apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
name: pg-data-s3-backup
namespace: longhorn-system
spec:
cron: "0 2 * * *" # daily at 02:00
task: backup
retain: 14
concurrency: 1
groups:
- pg-data
labels:
app: postgresql
---
# VolumeSnapshot using Longhorn CSI
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: pg-data-snap-$(date +%Y%m%d)
namespace: database
spec:
volumeSnapshotClassName: longhorn-snapshot-vsc
source:
persistentVolumeClaimName: pg-data-postgresql-0ਆਪਰੇਟਰ-ਪ੍ਰਬੰਧਿਤ ਬੈਕਅੱਪ
CloudNativePG (PostgreSQL ਲਈ) ਅਤੇ Percona ਆਪਰੇਟਰ (MySQL ਲਈ) ਵਰਗੇਡਾਟਾਬੇਸ ਆਪਰੇਟਰ ਬੈਕਅੱਪ ਪ੍ਰਬੰਧਨ ਨੂੰ ਸਿੱਧੇ ਡਾਟਾਬੇਸ ਜੀਵਨ ਚੱਕਰ ਵਿੱਚ ਜੋੜਦੇ ਹਨ। ਆਪਰੇਟਰ ਕਸਟਮ ਸਰੋਤਾਂ ਦੁਆਰਾ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਸਮਾਂ-ਸਾਰਣੀ, WAL ਪੁਰਾਲੇਖ, ਅਤੇ ਧਾਰਨ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ।
# CloudNativePG cluster with integrated backup
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: production-pg
namespace: database
spec:
instances: 3
storage:
size: 100Gi
storageClass: longhorn
backup:
barmanObjectStore:
destinationPath: s3://pg-backups/cnpg/
endpointURL: https://s3.eu-west-1.amazonaws.com
s3Credentials:
accessKeyId:
name: aws-creds
key: ACCESS_KEY_ID
secretAccessKey:
name: aws-creds
key: SECRET_ACCESS_KEY
wal:
compression: gzip
maxParallel: 4
data:
compression: gzip
retentionPolicy: "30d"
---
apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
name: production-pg-weekly
namespace: database
spec:
schedule: "0 1 * * 0"
backupOwnerReference: self
cluster:
name: production-pgਕਲਾਉਡ ਪ੍ਰਦਾਤਾ-ਵਿਸ਼ੇਸ਼ ਰਣਨੀਤੀਆਂ
AWS — RDS ਅਤੇ Aurora
AWS RDS ਸੰਰਚਨਾਯੋਗ ਧਾਰਨਾ (35 ਦਿਨਾਂ ਤੱਕ) ਅਤੇ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਲਈ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਆਰਕਾਈਵਿੰਗ ਦੁਆਰਾ ਨਿਰੰਤਰ ਬੈਕਅੱਪ ਦੇ ਨਾਲ ਸਵੈਚਲਿਤ ਰੋਜ਼ਾਨਾ ਸਨੈਪਸ਼ਾਟ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਔਰੋਰਾ ਬੈਕਟਰੈਕ ਨੂੰ ਜੋੜਦਾ ਹੈ, ਜੋ ਕਿ ਕਲੱਸਟਰ ਨੂੰ ਬੈਕਟਰੈਕ ਵਿੰਡੋ ਦੇ ਅੰਦਰ ਕਿਸੇ ਵੀ ਬਿੰਦੂ ਤੇ ਰੀਸਟੋਰ ਕੀਤੇ ਬਿਨਾਂ ਰੀਸਟੋਰ ਕਰ ਸਕਦਾ ਹੈ — ਇਹ ਸਿਰਫ਼ ਡਾਟਾਬੇਸ ਦੀ ਅੰਦਰੂਨੀ ਸਥਿਤੀ ਨੂੰ ਉਲਟਾ ਦਿੰਦਾ ਹੈ।
# Enable automated backups with maximum retention (Terraform)
resource "aws_db_instance" "production" {
identifier = "production-pg"
engine = "postgres"
engine_version = "16.2"
instance_class = "db.r6g.xlarge"
allocated_storage = 500
backup_retention_period = 35 # maximum
backup_window = "03:00-04:00"
copy_tags_to_snapshot = true
deletion_protection = true
storage_encrypted = true
kms_key_id = aws_kms_key.rds.arn
# Enable PITR
enabled_cloudwatch_logs_exports = ["postgresql", "upgrade"]
}
# Cross-region automated backup replication
resource "aws_db_instance_automated_backups_replication" "dr" {
source_db_instance_arn = aws_db_instance.production.arn
kms_key_id = aws_kms_key.dr_rds.arn
retention_period = 14
}
# Aurora Backtrack (MySQL-compatible Aurora only)
resource "aws_rds_cluster" "aurora_production" {
cluster_identifier = "aurora-production"
engine = "aurora-mysql"
engine_version = "8.0.mysql_aurora.3.05.2"
backtrack_window = 86400 # 24 hours of backtrack
backup_retention_period = 35
preferred_backup_window = "03:00-04:00"
storage_encrypted = true
}
# Manual snapshot with cross-region copy
aws rds create-db-snapshot \
--db-instance-identifier production-pg \
--db-snapshot-identifier pre-migration-$(date +%Y%m%d)
aws rds copy-db-snapshot \
--source-db-snapshot-identifier arn:aws:rds:eu-west-1:123456789:snapshot:pre-migration-20260412 \
--target-db-snapshot-identifier pre-migration-20260412-dr \
--source-region eu-west-1 \
--region us-east-1 \
--kms-key-id arn:aws:kms:us-east-1:123456789:key/dr-key-idAzure — ਲਚਕਦਾਰ ਸਰਵਰ
PostgreSQL ਅਤੇ MySQL ਫਲੈਕਸੀਬਲ ਸਰਵਰ ਲਈAzure ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਬੇਲੋੜੇ ਜਾਂ ਭੂ-ਰਿਡੰਡੈਂਟ ਸਟੋਰੇਜ ਦੇ ਨਾਲ ਆਟੋਮੈਟਿਕ ਬੈਕਅੱਪ ਸ਼ਾਮਲ ਹਨ। ਜੀਓ-ਰਿਡੰਡੈਂਟ ਬੈਕਅੱਪ ਆਫ਼ਤ ਰਿਕਵਰੀ ਲਈ ਅੰਤਰ-ਖੇਤਰ ਰੀਸਟੋਰ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।
# Azure Flexible Server with geo-redundant backup (Terraform)
resource "azurerm_postgresql_flexible_server" "production" {
name = "production-pg"
location = "westeurope"
resource_group_name = azurerm_resource_group.db.name
sku_name = "GP_Standard_D4s_v3"
version = "16"
storage_mb = 524288 # 512 GB
backup_retention_days = 35
geo_redundant_backup_enabled = true
authentication {
active_directory_auth_enabled = true
password_auth_enabled = false
}
}
# Azure Blob immutability for self-managed backups
resource "azurerm_storage_management_policy" "backup_lifecycle" {
storage_account_id = azurerm_storage_account.backups.id
rule {
name = "backup-tiering"
enabled = true
filters {
blob_types = ["blockBlob"]
prefix_match = ["pg-backups/"]
}
actions {
base_blob {
tier_to_cool_after_days_since_modification_greater_than = 30
tier_to_archive_after_days_since_modification_greater_than = 90
delete_after_days_since_modification_greater_than = 2555
}
}
}
}GCP — ਕਲਾਊਡ SQL
ਕਲਾਊਡ SQL ਬਾਕਸ ਦੇ ਬਾਹਰ ਆਟੋਮੇਟਿਡ ਬੈਕਅੱਪ ਅਤੇ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। GCE ਜਾਂ GKE 'ਤੇ ਸਵੈ-ਪ੍ਰਬੰਧਿਤ ਡੇਟਾਬੇਸ ਲਈ, ਨਿਅਰਲਾਈਨ ਅਤੇ ਕੋਲਡਲਾਈਨ ਸਟੋਰੇਜ ਕਲਾਸਾਂ ਵਾਲਾ GCS ਲਾਗਤ-ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲੰਬੀ-ਅਵਧੀ ਬੈਕਅੱਪ ਸਟੋਰੇਜ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
# Cloud SQL with automated backups and PITR (Terraform)
resource "google_sql_database_instance" "production" {
name = "production-pg"
database_version = "POSTGRES_16"
region = "europe-west1"
settings {
tier = "db-custom-4-16384"
backup_configuration {
enabled = true
start_time = "03:00"
point_in_time_recovery_enabled = true
transaction_log_retention_days = 7
backup_retention_settings {
retained_backups = 30
retention_unit = "COUNT"
}
}
ip_configuration {
ssl_mode = "ENCRYPTED_ONLY"
}
}
}
# Export to GCS for long-term retention
gcloud sql export sql production-pg \
gs://pg-backups-longterm/export-$(date +%Y%m%d).sql.gz \
--database=production_db \
--offloadਬੈਕਅੱਪ ਵੈਰੀਫਿਕੇਸ਼ਨ ਅਤੇ ਰੀਸਟੋਰ ਟੈਸਟਿੰਗ
ਇੱਕ ਬੈਕਅੱਪ ਜਿਸਦੀ ਕਦੇ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਗਈ, ਇੱਕ ਬੈਕਅੱਪ ਨਹੀਂ ਹੈ — ਇਹ ਇੱਕ ਉਮੀਦ ਹੈ। ਆਟੋਮੇਟਿਡ ਰੀਸਟੋਰ ਟੈਸਟਿੰਗ ਨੂੰ ਇੱਕ ਨਿਯਮਤ ਸਮਾਂ-ਸਾਰਣੀ 'ਤੇ, ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ ਹਫ਼ਤਾਵਾਰੀ, ਇੱਕ ਅਲੱਗ-ਥਲੱਗ ਵਾਤਾਵਰਣ ਵਿੱਚ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਟੈਸਟ ਨੂੰ ਸਿਰਫ਼ ਇਹ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਰੀਸਟੋਰ ਬਿਨਾਂ ਕਿਸੇ ਤਰੁੱਟੀ ਦੇ ਪੂਰਾ ਹੁੰਦਾ ਹੈ, ਪਰ ਇਹ ਕਿ ਰੀਸਟੋਰ ਕੀਤਾ ਡੇਟਾ ਇਕਸਾਰ ਹੈ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਇਸ ਨੂੰ ਕਨੈਕਟ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਪੁੱਛਗਿੱਛ ਕਰ ਸਕਦੀ ਹੈ।
#!/bin/bash
# verify-backup.sh — Automated backup verification script
set -euo pipefail
RESTORE_DIR="/tmp/backup-verify-$(date +%Y%m%d-%H%M%S)"
LOG_FILE="/var/log/backup-verify.log"
SLACK_WEBHOOK="${SLACK_WEBHOOK_URL}"
DB_TYPE="${1:-postgresql}" # postgresql or mysql
log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" | tee -a "$LOG_FILE"; }
alert() {
log "ALERT: $*"
curl -s -X POST "$SLACK_WEBHOOK" \
-H 'Content-Type: application/json' \
-d "{\"text\":\"BACKUP VERIFY FAILED: $*\"}"
}
cleanup() {
log "Cleaning up $RESTORE_DIR"
rm -rf "$RESTORE_DIR"
if [ "$DB_TYPE" = "postgresql" ]; then
pg_ctlcluster 16 verify stop 2>/dev/null || true
else
mysqladmin -S /tmp/mysql-verify.sock shutdown 2>/dev/null || true
fi
}
trap cleanup EXIT
mkdir -p "$RESTORE_DIR"
if [ "$DB_TYPE" = "postgresql" ]; then
log "Starting PostgreSQL backup verification"
# Restore latest pgBackRest backup to temporary directory
pgbackrest --stanza=production \
--pg1-path="$RESTORE_DIR/pgdata" \
--type=immediate \
--target-action=promote \
restore 2>&1 | tee -a "$LOG_FILE"
if [ ${PIPESTATUS[0]} -ne 0 ]; then
alert "pgBackRest restore failed"
exit 1
fi
# Start PostgreSQL on a different port
pg_ctlcluster 16 verify start -- \
-D "$RESTORE_DIR/pgdata" \
-o "-p 5433" \
-o "-c listen_addresses=127.0.0.1"
sleep 5
# Verify data integrity
TABLES=$(psql -p 5433 -d production_db -t -c \
"SELECT count(*) FROM information_schema.tables WHERE table_schema='public';")
log "Verified $TABLES tables exist"
ROW_CHECK=$(psql -p 5433 -d production_db -t -c \
"SELECT count(*) FROM orders WHERE created_at > now() - interval '7 days';")
log "Recent orders count: $ROW_CHECK"
if [ "$ROW_CHECK" -lt 1 ]; then
alert "PostgreSQL restore has no recent data — possible stale backup"
exit 1
fi
# Run pg_amcheck for corruption detection (PostgreSQL 14+)
pg_amcheck -p 5433 -d production_db --heapallindexed 2>&1 | tee -a "$LOG_FILE"
log "PostgreSQL backup verification PASSED"
else
log "Starting MySQL backup verification"
# Prepare and restore latest XtraBackup
LATEST_FULL=$(ls -td /backups/full-* | head -1)
cp -r "$LATEST_FULL" "$RESTORE_DIR/mysql-data"
xtrabackup --prepare --target-dir="$RESTORE_DIR/mysql-data"
# Start MySQL on a different socket and port
mysqld --datadir="$RESTORE_DIR/mysql-data" \
--socket=/tmp/mysql-verify.sock \
--port=3307 \
--skip-networking=0 \
--bind-address=127.0.0.1 &
sleep 10
# Verify data
TABLES=$(mysql -S /tmp/mysql-verify.sock -e \
"SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='production_db';" -sN)
log "Verified $TABLES tables exist"
mysqlcheck -S /tmp/mysql-verify.sock --all-databases --check 2>&1 | tee -a "$LOG_FILE"
log "MySQL backup verification PASSED"
fi
curl -s -X POST "$SLACK_WEBHOOK" \
-H 'Content-Type: application/json' \
-d "{\"text\":\"Backup verification PASSED for $DB_TYPE at $(date)\"}"
log "Verification complete"ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ ਪਲੈਨਿੰਗ: RTO ਅਤੇ RPO
ਹਰ ਬੈਕਅੱਪ ਰਣਨੀਤੀ ਦੋ ਮੈਟ੍ਰਿਕਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਤਿਆਰ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ:ਰਿਕਵਰੀ ਟਾਈਮ ਉਦੇਸ਼ (RTO)— ਤੁਸੀਂ ਕਿੰਨੀ ਦੇਰ ਤੱਕ ਹੇਠਾਂ ਰਹਿਣਾ ਬਰਦਾਸ਼ਤ ਕਰ ਸਕਦੇ ਹੋ — ਅਤੇਰਿਕਵਰੀ ਪੁਆਇੰਟ ਉਦੇਸ਼ (RPO)— ਤੁਸੀਂ ਕਿੰਨਾ ਡਾਟਾ ਗੁਆ ਸਕਦੇ ਹੋ। ਇਹ ਨੰਬਰ ਬੈਕਅੱਪ ਬਾਰੰਬਾਰਤਾ, ਵਿਧੀ ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਬਾਰੇ ਹਰੇਕ ਫੈਸਲੇ ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ।
| ਦ੍ਰਿਸ਼ | RTO | RPO | ਰਣਨੀਤੀ |
|---|---|---|---|
| ਈ-ਕਾਮਰਸ ਚੈੱਕਆਉਟ | < 5 ਮਿੰਟ | 0 (ਜ਼ੀਰੋ ਡਾਟਾ ਨੁਕਸਾਨ) | ਸਮਕਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ + ਨਿਰੰਤਰ WAL ਆਰਕਾਈਵਿੰਗ + ਹੌਟ ਸਟੈਂਡਬਾਏ ਫੇਲਓਵਰ |
| SaaS ਐਪਲੀਕੇਸ਼ਨ | < 30 ਮਿੰਟ | < 1 ਮਿੰਟ | ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ + WAL-G ਨਿਰੰਤਰ ਪੁਰਾਲੇਖ + ਸਵੈਚਲਿਤ ਫੇਲਓਵਰ |
| ਅੰਦਰੂਨੀ ਟੂਲ | < 4 ਘੰਟੇ | < 1 ਘੰਟਾ | ਰੋਜ਼ਾਨਾ ਅੰਤਰ + ਘੰਟਾ ਵਾਧਾ + WAL ਪੁਰਾਲੇਖ |
| ਵਿਸ਼ਲੇਸ਼ਣ / ਡਾਟਾ ਵੇਅਰਹਾਊਸ | < 24 ਘੰਟੇ | < 24 ਘੰਟੇ | ਕਲਾਉਡ ਸਟੋਰੇਜ ਲਈ ਰੋਜ਼ਾਨਾ ਪੂਰਾ ਬੈਕਅੱਪ |
| ਦੇਵ / ਸਟੇਜਿੰਗ | < 48 ਘੰਟੇ | < 1 ਹਫ਼ਤਾ | ਹਫ਼ਤਾਵਾਰ ਪੂਰਾ ਬੈਕਅੱਪ |
ਜ਼ੀਰੋ RPO ਲਈ, ਤੁਹਾਨੂੰ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਸਟੈਂਡਬਾਏ ਲਈ ਸਮਕਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੀ ਲੋੜ ਹੈ। ਇਹ ਹਰੇਕ ਲਿਖਤੀ ਲੈਣ-ਦੇਣ ਲਈ ਲੇਟੈਂਸੀ ਨੂੰ ਜੋੜਦਾ ਹੈ ਪਰ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ ਕਿ ਕੋਈ ਵਚਨਬੱਧ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਖਤਮ ਨਹੀਂ ਹੁੰਦਾ। ਬਹੁਤੇ ਉਤਪਾਦਨ ਸਿਸਟਮ ਲਗਾਤਾਰ WAL/binlog ਪੁਰਾਲੇਖ ਦੇ ਨਾਲ ਅਸਿੰਕ੍ਰੋਨਸ ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਨੇੜੇ-ਜ਼ੀਰੋ RPO (ਸੰਭਾਵੀ ਨੁਕਸਾਨ ਦੇ ਸਕਿੰਟ) ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ, ਜੋ ਲਿਖਣ-ਲੇਟੈਂਸੀ ਜੁਰਮਾਨੇ ਤੋਂ ਬਚਦਾ ਹੈ।
ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ ਰਨਬੁੱਕ ਟੈਮਪਲੇਟ
# DR Runbook: Database Recovery
## Severity Levels
- P1: Complete data loss / corruption — all hands, CEO notified
- P2: Partial data loss / single region down — on-call team + escalation
- P3: Replica failure / backup failure — on-call investigation
## Recovery Procedures
### Scenario A: Primary DB failure, replicas healthy
1. Promote replica to primary (automated via Patroni / orchestrator)
2. Verify application connectivity
3. Re-establish replication from new primary
4. Investigate root cause
### Scenario B: Complete cluster failure, backups intact
1. Provision new database infrastructure
2. Restore latest full backup
3. Apply WAL/binlog to reach latest consistent point
4. Verify data integrity with checksums
5. Update DNS / connection strings
6. Resume application traffic
7. Re-establish backup schedule immediately
### Scenario C: Data corruption (bad migration / SQL injection)
1. Identify exact timestamp of corruption
2. Restore to point-in-time just before corruption
3. Export affected tables from restored copy
4. Merge clean data into production
5. OR: full PITR restore if corruption is widespread
## Contacts
- DBA on-call: [PagerDuty rotation]
- Infrastructure: [PagerDuty rotation]
- VP Engineering: [phone number]
## Validation Checklist
- [ ] Application health checks pass
- [ ] Row counts match expected ranges
- [ ] Recent transactions are present
- [ ] Replication re-established
- [ ] Backup schedule resumed
- [ ] Post-incident review scheduledਬੈਕਅੱਪ ਨਿਗਰਾਨੀ ਅਤੇ ਚੇਤਾਵਨੀ
ਬੈਕਅੱਪ ਸਿਸਟਮ ਚੁੱਪਚਾਪ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ। ਡੇਟਾਬੇਸ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ, ਐਪਲੀਕੇਸ਼ਨ ਟ੍ਰੈਫਿਕ ਪ੍ਰਦਾਨ ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਇਹ ਨਹੀਂ ਦੇਖਦਾ ਹੈ ਕਿ ਬੈਕਅੱਪ ਨੇ ਤਿੰਨ ਹਫ਼ਤੇ ਪਹਿਲਾਂ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ ਸੀ - ਜਦੋਂ ਤੱਕ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਕਿਰਿਆਸ਼ੀਲ ਨਿਗਰਾਨੀ ਜ਼ਰੂਰੀ ਹੈ।
# Prometheus alerting rules for backup monitoring
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: backup-alerts
namespace: monitoring
spec:
groups:
- name: database-backups
rules:
- alert: BackupTooOld
expr: |
(time() - backup_last_successful_timestamp_seconds) > 90000
for: 10m
labels:
severity: critical
annotations:
summary: "Database backup is older than 25 hours"
description: "Last successful backup for {{ $labels.database }} was {{ $value | humanizeDuration }} ago"
- alert: BackupJobFailed
expr: |
kube_job_status_failed{job_name=~".*backup.*"} > 0
for: 5m
labels:
severity: critical
annotations:
summary: "Backup CronJob failed: {{ $labels.job_name }}"
- alert: WALArchivingLagging
expr: |
pg_stat_archiver_failed_count > 0
for: 5m
labels:
severity: warning
annotations:
summary: "PostgreSQL WAL archiving has failures"
- alert: BackupStorageQuotaNearing
expr: |
(backup_storage_used_bytes / backup_storage_quota_bytes) > 0.85
for: 30m
labels:
severity: warning
annotations:
summary: "Backup storage at {{ $value | humanizePercentage }} capacity"
- alert: BinlogSpaceCritical
expr: |
mysql_binlog_size_bytes > 53687091200
for: 10m
labels:
severity: warning
annotations:
summary: "MySQL binlog space exceeds 50GB — check archiving"# Custom Prometheus exporter for pgBackRest metrics
#!/usr/bin/env python3
"""pgBackRest Prometheus exporter — exposes backup age and size metrics."""
import json
import subprocess
import time
from prometheus_client import start_http_server, Gauge
BACKUP_AGE = Gauge('pgbackrest_last_backup_age_seconds', 'Seconds since last backup', ['stanza', 'type'])
BACKUP_SIZE = Gauge('pgbackrest_last_backup_size_bytes', 'Size of last backup', ['stanza', 'type'])
BACKUP_REPO_SIZE = Gauge('pgbackrest_repo_size_bytes', 'Total repository size', ['stanza'])
def collect():
result = subprocess.run(
['pgbackrest', '--output=json', 'info'],
capture_output=True, text=True
)
info = json.loads(result.stdout)
for stanza_info in info:
stanza = stanza_info['name']
for backup in stanza_info.get('backup', []):
backup_type = backup['type']
stop_time = backup['timestamp']['stop']
age = time.time() - stop_time
BACKUP_AGE.labels(stanza=stanza, type=backup_type).set(age)
size = backup['info']['size']
BACKUP_SIZE.labels(stanza=stanza, type=backup_type).set(size)
if __name__ == '__main__':
start_http_server(9854)
while True:
collect()
time.sleep(300)ਆਮ ਗਲਤੀਆਂ ਅਤੇ ਐਂਟੀ-ਪੈਟਰਨ
ਦਰਜਨਾਂ ਉਤਪਾਦਨ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਡੇਟਾਬੇਸ ਬੈਕਅਪ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਇਹ ਉਹ ਗਲਤੀਆਂ ਹਨ ਜੋ ਸਭ ਤੋਂ ਵੱਧ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੀਆਂ ਹਨ।
1. ਡਾਟਾਬੇਸ ਦੇ ਰੂਪ ਵਿੱਚ ਉਸੇ ਡਿਸਕ 'ਤੇ ਬੈਕਅੱਪ ਲਿਆ ਜਾ ਰਿਹਾ ਹੈ।ਜੇਕਰ ਡਿਸਕ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਅਤੇ ਬੈਕਅੱਪ ਦੋਵੇਂ ਗੁਆ ਦਿੰਦੇ ਹੋ। ਹਮੇਸ਼ਾ ਇੱਕ ਵੱਖਰੇ ਸਟੋਰੇਜ਼ ਟੀਚੇ ਲਈ ਬੈਕਅੱਪ ਲਿਖੋ — ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ ਆਫ-ਹੋਸਟ ਅਤੇ ਆਫ-ਰੀਜਨ।
2. ਕਦੇ ਵੀ ਰੀਸਟੋਰ ਦੀ ਜਾਂਚ ਨਾ ਕਰੋ।ਇੱਕ ਬੈਕਅੱਪ ਜੋ ਰੀਸਟੋਰ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਇੱਕ ਬੈਕਅੱਪ ਨਹੀਂ ਹੈ। ਸਵੈਚਲਿਤ ਰੀਸਟੋਰ ਟੈਸਟਾਂ ਨੂੰ ਹਫਤਾਵਾਰੀ ਤਹਿ ਕਰੋ ਅਤੇ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਤਿਮਾਹੀ ਤੌਰ 'ਤੇ ਮੈਨੂਅਲ ਰੀਸਟੋਰ ਡ੍ਰਿਲਸ ਕਰਨ ਲਈ ਕਹੋ।
3. ਬੈਕਅੱਪ ਦੇ ਤੌਰ 'ਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ 'ਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਭਰੋਸਾ ਕਰਨਾ।ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਬੈਕਅੱਪ ਨਹੀਂ ਹੈ। ਪ੍ਰਾਇਮਰੀ 'ਤੇ ਇੱਕDROP TABLEਨੂੰ ਤੁਰੰਤ ਸਾਰੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਲਈ ਨਕਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਹਾਰਡਵੇਅਰ ਅਸਫਲਤਾ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ, ਨਾ ਕਿ ਲਾਜ਼ੀਕਲ ਗਲਤੀਆਂ ਤੋਂ।
4. ਬੈਕਅੱਪ ਨੌਕਰੀਆਂ ਦੀ ਨਿਗਰਾਨੀ ਨਹੀਂ ਕਰ ਰਿਹਾ।ਕਰੋਨ ਨੌਕਰੀਆਂ ਚੁੱਪਚਾਪ ਅਸਫਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। Kubernetes CronJobs ਮੁਅੱਤਲ ਹੋ ਗਏ ਹਨ। S3 ਕ੍ਰੀਡੈਂਸ਼ੀਅਲ ਦੀ ਮਿਆਦ ਸਮਾਪਤ ਹੋ ਗਈ ਹੈ। ਹਰੇਕ ਬੈਕਅੱਪ ਨੌਕਰੀ ਲਈ ਇੱਕ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਨੂੰ ਸਫਲਤਾ ਜਾਂ ਅਸਫਲਤਾ ਦੀ ਰਿਪੋਰਟ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਜੇਕਰ ਸਭ ਤੋਂ ਤਾਜ਼ਾ ਸਫਲ ਬੈਕਅੱਪ ਤੁਹਾਡੇ RPO ਤੋਂ ਪੁਰਾਣਾ ਹੈ ਤਾਂ ਚੇਤਾਵਨੀ ਦਿਓ।
5. ਬੈਕਅੱਪ ਦੇ ਨਾਲ-ਨਾਲ ਇਨਕ੍ਰਿਪਸ਼ਨ ਕੁੰਜੀਆਂ ਨੂੰ ਸਟੋਰ ਕਰਨਾ।ਜੇਕਰ ਕੋਈ ਹਮਲਾਵਰ ਤੁਹਾਡੀ ਬੈਕਅੱਪ ਸਟੋਰੇਜ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਕੋਲ ਡੀਕ੍ਰਿਪਸ਼ਨ ਕੁੰਜੀ ਵੀ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। ਇੱਕ ਸਮਰਪਿਤ ਭੇਦ ਪ੍ਰਬੰਧਕ ਵਿੱਚ ਕੁੰਜੀਆਂ ਸਟੋਰ ਕਰੋ।
6. ਕੋਈ ਧਾਰਨ ਨੀਤੀ ਨਹੀਂ।ਜੀਵਨ ਚੱਕਰ ਨੀਤੀਆਂ ਤੋਂ ਬਿਨਾਂ, ਬੈਕਅੱਪ ਸਟੋਰੇਜ ਬੇਅੰਤ ਵਧਦੀ ਹੈ। ਸਪਸ਼ਟ ਧਾਰਨਾ ਵਿੰਡੋਜ਼ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: WAL ਭਾਗਾਂ ਲਈ 7 ਦਿਨ, ਰੋਜ਼ਾਨਾ ਬੈਕਅਪ ਲਈ 30 ਦਿਨ, ਮਾਸਿਕ ਬੈਕਅਪ ਲਈ 12 ਮਹੀਨੇ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਮਿਟਾਉਣਾ ਸਵੈਚਲਿਤ ਕਰੋ।
7. ਬੈਕਅੱਪ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਭਾਵ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ।ਪੀਕ ਘੰਟਿਆਂ ਦੌਰਾਨ ਪ੍ਰਾਇਮਰੀ ਡਾਟਾਬੇਸ 'ਤੇ ਪੂਰਾ ਬੈਕਅੱਪ ਚਲਾਉਣਾ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਘੱਟ-ਟ੍ਰੈਫਿਕ ਵਿੰਡੋਜ਼ ਦੇ ਦੌਰਾਨ ਬੈਕਅੱਪ ਨੂੰ ਤਹਿ ਕਰੋ, ਜਾਂ ਸਮਰਪਿਤ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਤੋਂ ਬੈਕਅੱਪ ਕਰੋ।
8.--single-transactionਤੋਂ ਬਿਨਾਂ ਵੱਡੇ ਡੇਟਾਬੇਸ ਲਈmysqldumpਦੀ ਵਰਤੋਂ ਕਰਨਾ।ਇਸ ਫਲੈਗ ਤੋਂ ਬਿਨਾਂ,mysqldumpਟੇਬਲਾਂ ਨੂੰ ਲਾਕ ਕਰਦਾ ਹੈ, ਡੰਪ ਦੀ ਮਿਆਦ ਲਈ ਬਲਾਕਿੰਗ ਰਾਈਟਸ। ਵੱਡੇ ਡੇਟਾਬੇਸ ਲਈ ਇਸਦਾ ਮਤਲਬ ਮਿੰਟਾਂ ਜਾਂ ਘੰਟਿਆਂ ਦਾ ਡਾਊਨਟਾਈਮ ਹੋ ਸਕਦਾ ਹੈ।
9. ਡਾਟਾਬੇਸ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦਾ ਬੈਕਅੱਪ ਲੈਣਾ ਭੁੱਲਣਾ।ਡਾਟਾ ਰੀਸਟੋਰ ਕਰਨਾ ਸਿਰਫ ਅੱਧੀ ਲੜਾਈ ਹੈ। ਜੇਕਰ ਤੁਸੀਂpostgresql.conf,pg_hba.conf,my.cnf, ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈਟਿੰਗਾਂ, ਅਤੇ ਉਪਭੋਗਤਾ ਅਨੁਦਾਨ ਗੁਆ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਨੂੰ ਵਰਤੋਂ ਯੋਗ ਸਥਿਤੀ ਵਿੱਚ ਵਾਪਸ ਨਹੀਂ ਲਿਆ ਸਕਦੇ ਹੋ। ਆਪਣੀ ਬੈਕਅੱਪ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸੰਰਚਨਾ ਫਾਈਲਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ।
10. ਰੀਸਟੋਰ ਪ੍ਰਕਿਰਿਆ ਦਾ ਦਸਤਾਵੇਜ਼ ਨਹੀਂ ਹੈ।ਇੱਕ ਆਊਟੇਜ ਦੇ ਦੌਰਾਨ, ਡੇਟਾਬੇਸ ਨੂੰ ਰੀਸਟੋਰ ਕਰਨ ਵਾਲਾ ਵਿਅਕਤੀ ਬੈਕਅੱਪ ਸੈਟ ਅਪ ਕਰਨ ਵਾਲਾ ਵਿਅਕਤੀ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਇੱਕ ਲਿਖਤੀ, ਟੈਸਟ ਕੀਤੀ ਰਨਬੁੱਕ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਬੈਕਅੱਪ ਸਟੋਰੇਜਲਈਲਾਗਤ ਅਨੁਕੂਲਨ
ਬੈਕਅੱਪ ਸਟੋਰੇਜ ਦੀਆਂ ਲਾਗਤਾਂ ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਸਕਦੀਆਂ ਹਨ, ਖਾਸ ਕਰਕੇ ਵੱਡੇ ਡੇਟਾਬੇਸ ਦੇ ਲਗਾਤਾਰ ਪੂਰੇ ਬੈਕਅੱਪ ਦੇ ਨਾਲ। ਇਹ ਰਣਨੀਤੀਆਂ ਰਿਕਵਰੀਯੋਗਤਾ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤੇ ਬਿਨਾਂ ਲਾਗਤਾਂ ਨੂੰ ਕੰਟਰੋਲ ਵਿੱਚ ਰੱਖਦੀਆਂ ਹਨ।
ਇਨਕਰੀਮੈਂਟਲ/ਡਿਫਰੈਂਸ਼ੀਅਲ ਬੈਕਅੱਪ ਦੀ ਵਰਤੋਂ ਕਰੋ।ਇੱਕ ਹਫਤਾਵਾਰੀ ਫੁੱਲ ਪਲੱਸ ਰੋਜ਼ਾਨਾ ਫਰਕ ਰੋਜ਼ਾਨਾ ਪੂਰੇ ਬੈਕਅੱਪ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਸਟੋਰੇਜ ਦੇ ਇੱਕ ਹਿੱਸੇ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। pgBackRest ਦੀ ਡੈਲਟਾ ਰੀਸਟੋਰ ਸਮਰੱਥਾ ਦਾ ਅਰਥ ਹੈ ਵਾਧੇ ਵਾਲੇ ਬੈਕਅਪ ਲਗਭਗ ਪੂਰੇ ਬੈਕਅਪ ਵਾਂਗ ਤੇਜ਼ੀ ਨਾਲ ਰੀਸਟੋਰ ਕਰਦੇ ਹਨ।
ਕੰਪਰੈਸ਼ਨ ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ।ਆਧੁਨਿਕ ਕੰਪਰੈਸ਼ਨ ਐਲਗੋਰਿਦਮ ਜਿਵੇਂ ਕਿ zstd ਘੱਟੋ-ਘੱਟ CPU ਓਵਰਹੈੱਡ ਦੇ ਨਾਲ ਸ਼ਾਨਦਾਰ ਕੰਪਰੈਸ਼ਨ ਅਨੁਪਾਤ (ਆਮ ਡੇਟਾਬੇਸ ਡੇਟਾ ਲਈ 5:1 ਤੋਂ 10:1) ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੇ ਹਨ। pgBackRest ਅਤੇ XtraBackup ਦੋਵੇਂ ਨੇਟਿਵ ਤੌਰ 'ਤੇ zstd ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ।
ਸਟੋਰੇਜ ਟਾਇਰਿੰਗ ਲਾਗੂ ਕਰੋ।ਬੈਕਅੱਪ ਨੂੰ ਉਮਰ ਦੇ ਨਾਲ-ਨਾਲ ਸਸਤੀਆਂ ਸਟੋਰੇਜ ਟੀਅਰਾਂ 'ਤੇ ਲੈ ਜਾਓ। ਪਹਿਲਾਂ ਦਿਖਾਈਆਂ ਗਈਆਂ ਜੀਵਨ-ਚੱਕਰ ਨੀਤੀਆਂ (S3 ਸਟੈਂਡਰਡ → IA → ਗਲੇਸ਼ੀਅਰ, GCS ਸਟੈਂਡਰਡ → ਨਿਅਰਲਾਈਨ → ਕੋਲਡਲਾਈਨ) ਲੰਬੇ ਸਮੇਂ ਦੀ ਸਟੋਰੇਜ ਲਾਗਤਾਂ ਨੂੰ 70-90% ਤੱਕ ਘਟਾ ਸਕਦੀਆਂ ਹਨ।
ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇਡੁਪਲੀਕੇਟ।pgBackRest ਆਪਣੀ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਬਲਾਕ-ਪੱਧਰ ਦੀ ਡੁਪਲੀਕੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਸਿਰਫ ਬਦਲੇ ਹੋਏ ਬਲਾਕਾਂ ਨੂੰ ਬੈਕਅੱਪਾਂ ਵਿੱਚ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਇਹ ਨਾਟਕੀ ਢੰਗ ਨਾਲ ਡੇਟਾਬੇਸ ਲਈ ਸਟੋਰੇਜ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਜ਼ਿਆਦਾਤਰ ਡੇਟਾ ਸਥਿਰ ਹੁੰਦਾ ਹੈ।
ਸੱਜਾ-ਆਕਾਰ ਧਾਰਨ ਵਿੰਡੋਜ਼।ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਸਾਵਧਾਨੀ ਤੋਂ ਹਮੇਸ਼ਾ ਲਈ ਬੈਕਅੱਪ ਰੱਖਣ ਲਈ ਡਿਫੌਲਟ ਹੁੰਦੀਆਂ ਹਨ। ਆਪਣੇ ਅਸਲ ਰਿਕਵਰੀ ਪੈਟਰਨਾਂ ਅਤੇ ਪਾਲਣਾ ਦੀਆਂ ਲੋੜਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੋ, ਫਿਰ ਮੇਲ ਖਾਂਦੀ ਧਾਰਨਾ ਸੈੱਟ ਕਰੋ। 7-ਸਾਲ ਦੀ ਧਾਰਨ ਦੀ ਲੋੜ ਜ਼ਿਆਦਾਤਰ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾਵਾਂ 'ਤੇ $1/TB/ਮਹੀਨੇ ਤੋਂ ਘੱਟ ਦੀ ਡੂੰਘੀ ਪੁਰਾਲੇਖ ਸਟੋਰੇਜ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੀ ਹੈ।
# Cost comparison: Full vs Incremental backup storage
# Assuming 500 GB database, 5% daily change rate, 30-day retention
# Strategy A: Daily full backups
# 500 GB × 30 days = 15,000 GB = 15 TB
# S3 Standard: 15 TB × $0.023/GB = $345/month
# Strategy B: Weekly full + daily incremental
# 4 full × 500 GB = 2,000 GB
# 26 incremental × 25 GB = 650 GB
# Total: 2,650 GB ≈ 2.6 TB
# S3 Standard: 2.6 TB × $0.023/GB = $59.80/month
# Strategy C: Strategy B + lifecycle tiering
# Current week: 525 GB Standard = $12.08
# Weeks 2-4: 2,125 GB Standard-IA = $26.56
# Total: $38.64/month
# Savings: Strategy C is 89% cheaper than Strategy Aਇਸ ਸਭ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ: ਇੱਕ ਸੰਪੂਰਨ ਬੈਕਅੱਪ ਆਰਕੀਟੈਕਚਰ
MySQL ਅਤੇ PostgreSQL ਦੋਨਾਂ ਨੂੰ ਚਲਾਉਣ ਵਾਲੇ ਉਤਪਾਦਨ ਵਾਤਾਵਰਨ ਲਈ ਇੱਥੇ ਸਿਫ਼ਾਰਿਸ਼ ਕੀਤਾ ਗਿਆ ਬੈਕਅੱਪ ਆਰਕੀਟੈਕਚਰ ਹੈ, ਜੋ ਕਿ ਮਲਟੀ-ਕਲਾਊਡ ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ ਦੇ ਨਾਲ Kubernetes 'ਤੇ ਤੈਨਾਤ ਹੈ।
PostgreSQL ਲਈ:
- ਦੋ ਰਿਪੋਜ਼ਟਰੀਆਂ (S3 + Azure ਬਲੌਬ)ਦੇ ਨਾਲ ਪ੍ਰਾਇਮਰੀ ਬੈਕਅੱਪ ਟੂਲ ਵਜੋਂ
- pgBackRest
- ਦੋਵਾਂ ਰਿਪੋਜ਼ਟਰੀਆਂ ਲਈ ਲਗਾਤਾਰ WAL ਪੁਰਾਲੇਖ
- ਹਫਤਾਵਾਰੀ ਪੂਰਾ ਬੈਕਅੱਪ + ਰੋਜ਼ਾਨਾ ਅੰਤਰ (K8s CronJob ਰਾਹੀਂ) ਤੇਜ਼ ਰੋਲਬੈਕਲਈ ਹਰ 4 ਘੰਟਿਆਂ ਬਾਅਦ
- ਲੋਂਗਹੋਰਨ ਵਾਲੀਅਮ ਸਨੈਪਸ਼ਾਟ
- ਹਰ ਬੁੱਧਵਾਰ ਸਵੈਚਲਿਤ ਰੀਸਟੋਰ ਪੁਸ਼ਟੀਕਰਨ
- Prometheus ਬੈਕਅੱਪ ਉਮਰ, ਅਸਫਲਤਾ ਅਤੇ ਸਟੋਰੇਜ 'ਤੇ ਚੇਤਾਵਨੀਆਂ ਦੇ ਨਾਲ ਨਿਗਰਾਨੀ
:
- ਸਰੀਰਕ ਬੈਕਅੱਪ ਲਈ
- Percona XtraBackup S3 'ਤੇ ਸਟ੍ਰੀਮ ਕੀਤਾ ਗਿਆ
- ਵੱਖਰੀ ਸਟੋਰੇਜ ਲਈ ਨਿਰੰਤਰ ਬਾਈਨਰੀ ਲੌਗ ਸ਼ਿਪਿੰਗ
- ਹਫ਼ਤਾਵਾਰ ਪੂਰਾ + ਰੋਜ਼ਾਨਾ ਵਾਧਾ (K8s CronJob ਦੁਆਰਾ)
- ਪੋਰਟੇਬਲ ਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪ ਲਈ ਨਾਜ਼ੁਕ ਸਕੀਮਾਂ ਦਾ ਰੋਜ਼ਾਨਾ
mysqldump - ਲੌਂਗਹੋਰਨ ਵਾਲੀਅਮ ਸਨੈਪਸ਼ਾਟ ਹਰ 4 ਘੰਟੇ
- ਹਰ ਵੀਰਵਾਰ ਸਵੈਚਲਿਤ ਰੀਸਟੋਰ ਪੁਸ਼ਟੀਕਰਨ
Kubernetes ਕਲੱਸਟਰ ਲਈ:
- ਵੇਲੇਰੋ ਪੀਵੀ ਸਨੈਪਸ਼ਾਟ ਨਾਲ ਡੇਟਾਬੇਸ ਨੇਮਸਪੇਸ ਦਾ ਰੋਜ਼ਾਨਾ ਬੈਕਅੱਪ
- RKE2/k3s etcd ਸਨੈਪਸ਼ਾਟ ਹਰ 6 ਘੰਟਿਆਂ ਬਾਅਦ ਆਫ-ਕਲੱਸਟਰ ਸਟੋਰੇਜ ਲਈ
- GitOps ਰਿਪੋਜ਼ਟਰੀ ਸਾਰੇ ਪ੍ਰਗਟਾਵੇ ਲਈ ਸੱਚ ਦੇ ਸਰੋਤ ਵਜੋਂ
ਆਫ਼ਤ ਰਿਕਵਰੀ ਲਈ:
- DR ਖੇਤਰਲਈ
- S3 ਅੰਤਰ-ਖੇਤਰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਜੀਓ-ਰਿਡੰਡੈਂਟ ਬੈਕਅੱਪ ਕਾਪੀਆਂ ਲਈ
- Azure GRS
- ਮਾਸਿਕ DR ਡ੍ਰਿਲ: DR ਖੇਤਰ ਵਿੱਚ ਬੈਕਅੱਪਾਂ ਤੋਂ ਪੂਰਾ ਕਲੱਸਟਰ ਰੀਬਿਲਡ ਹਰੇਕ ਅਸਫਲਤਾ ਦੇ ਦ੍ਰਿਸ਼ਲਈ ਫੈਸਲੇ ਦੇ ਰੁੱਖ ਦੇ ਨਾਲ
- ਦਸਤਾਵੇਜ਼ੀ ਰਨਬੁੱਕ
ਸਿੱਟਾ
ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਤੁਹਾਡੇ ਕਾਰੋਬਾਰ ਅਤੇ ਘਾਤਕ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਦੇ ਵਿਚਕਾਰ ਬਚਾਅ ਦੀ ਆਖਰੀ ਲਾਈਨ ਹਨ। ਇਸ ਲੇਖ ਵਿੱਚ ਦੱਸੀਆਂ ਗਈਆਂ ਰਣਨੀਤੀਆਂ — ਭੌਤਿਕ ਅਤੇ ਲਾਜ਼ੀਕਲ ਬੈਕਅੱਪ, ਨਿਰੰਤਰ WAL ਅਤੇ ਬਿਨਲੌਗ ਆਰਕਾਈਵਿੰਗ, ਲਾਈਫਸਾਈਕਲ ਨੀਤੀਆਂ ਦੇ ਨਾਲ ਮਲਟੀ-ਕਲਾਊਡ ਸਟੋਰੇਜ, ਹਰ ਲੇਅਰ 'ਤੇ ਐਨਕ੍ਰਿਪਸ਼ਨ, Kubernetes ਕ੍ਰੋਨਜੌਬਜ਼ ਰਾਹੀਂ ਸਵੈਚਲਿਤ ਸਮਾਂ-ਸਾਰਣੀ, ਅਤੇ ਵਿਵਸਥਿਤ ਰੀਸਟੋਰ ਵੈਰੀਫਿਕੇਸ਼ਨ — ਉਤਪਾਦਨ MySQLX ਅਤੇ ਵਾਤਾਵਰਣ ਲਈ ਕਲਾ ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਨੂੰ ਦਰਸਾਉਂਦੀਆਂ ਹਨ।
ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਉਪਾਅ ਇਹ ਹੈ:ਇੱਕ ਬੈਕਅੱਪ ਰਣਨੀਤੀ ਸਿਰਫ ਇਸਦੇ ਆਖਰੀ ਸਫਲ ਰੀਸਟੋਰ ਟੈਸਟਜਿੰਨੀ ਹੀ ਵਧੀਆ ਹੈ। ਇਸ ਲੇਖ ਵਿੱਚ ਹਰ ਟੂਲ, ਸਕ੍ਰਿਪਟ, ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਪੈਟਰਨ ਇੱਕ ਉਦੇਸ਼ ਦੀ ਪੂਰਤੀ ਲਈ ਮੌਜੂਦ ਹੈ — ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਜਦੋਂ ਸਭ ਤੋਂ ਮਾੜਾ ਵਾਪਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਆਪਣੇ ਡੇਟਾ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ, ਆਪਣੀਆਂ RTO ਅਤੇ RPO ਵਚਨਬੱਧਤਾਵਾਂ ਨੂੰ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਆਪਣੇ ਕਾਰੋਬਾਰ ਨੂੰ ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹੋ। ਆਪਣਾ ਬੈਕਅੱਪ ਸਿਸਟਮ ਬਣਾਓ, ਇਸਨੂੰ ਸਵੈਚਲਿਤ ਕਰੋ, ਇਸਦੀ ਨਿਗਰਾਨੀ ਕਰੋ, ਇਸਦੀ ਜਾਂਚ ਕਰੋ, ਅਤੇ ਫਿਰ ਇਸਨੂੰ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰੋ। ਤੁਹਾਡਾ ਭਵਿੱਖ ਆਪ ਤੁਹਾਡਾ ਧੰਨਵਾਦ ਕਰੇਗਾ।