MySQL Backup और Restore

Command से पहले Recovery Goals तय करें

Database backup तभी उपयोगी है जब वह agreed data-loss और time window में service restore कर सके। Tool चुनने से पहले ये goals तय करें:

Nightly dump अकेला 15-minute RPO पूरा नहीं करता। 2 TB logical dump import में eight hours ले तो one-hour RTO पूरा नहीं होगा। Real backup/restore duration, growth, network throughput और dependencies मापें।

Runbook में owner, target system, recovery point, escalation और decision authority लिखें। Outage के बीच इन्हें न खोजें।

सही Backup Type चुनें

mysqldump logical backup program है। Large database या strict RTO में supported physical backup, MySQL-coordinated snapshot, replica workflow या MySQL Shell dump utilities evaluate करें। Replica अपने आप backup नहीं है; destructive change replicate हो सकता है।

Recovery के लिए क्या-क्या सुरक्षित रखें

Database rows working service का केवल एक भाग हैं। जरूरत के अनुसार ये assets protect करें:

• schemas, tables, views, triggers, routines और scheduled events;
• users, roles और grants; secrets approved vault में;
• MySQL configuration, time zones, character sets, plugins और version;
• PITR के लिए binary logs और replication metadata;
• encryption keys, certificates और key-recovery procedure;
• application migrations, uploaded files, object storage और dependencies;
• manifests, checksums, retention policy और restore instructions.

Copy से पहले data classify करें। Backup में production personal data और credentials हो सकते हैं, इसलिए access, encryption और deletion obligations उस पर भी लागू होते हैं।

service: school-api
mysql_source: mysql-8.4 / InnoDB
backup_utc: 2026-08-15T01:00:00Z
rpo: 15m
rto: 60m
includes: schema,data,views,triggers,routines,events
separate_assets: users-grants,config,binlogs,kms-runbook
restore_test: required

Consistent Logical Backup Lab

Credentials command history से बाहर रखें। Backup host पर administrator encrypted login path interactively बना सकता है:

mysql_config_editor set --login-path=backup \
  --host=db.example.internal --user=backup_operator --password

mysql --login-path=backup -e "SELECT VERSION();"

Selected options के लिए जरूरी minimum privileges वाला account रखें। Production password command/script में न लिखें।

mysqldump --login-path=backup \
  --single-transaction --quick \
  --routines --events --triggers \
  --databases school \
  --result-file=school_full.sql

--single-transaction InnoDB जैसी transactional tables का consistent snapshot देता है। Nontransactional tables consistent नहीं होतीं और dump के समय ALTER, DROP, RENAME या TRUNCATE consistency बिगाड़ सकते हैं। --quick पूरी table buffer करने की बजाय rows stream करता है।

Triggers default में dump होते हैं, पर explicit flag intent बताता है। Routines/events के flags जरूरी हैं। --databases database create/select statements जोड़ता है। Windows PowerShell में --result-file बेहतर है; कुछ redirection versions UTF-16 file बना सकती हैं।

Isolated Target पर Restore और Verify करें

Only production database पर restore test न करें। Compatible isolated server, पर्याप्त disk और blocked application traffic रखें। Dump execute करने से पहले scan करें। Example में --databases school था, इसलिए dump database select करता है:

mysql_config_editor set --login-path=restore \
  --host=restore.example.internal --user=restore_operator --password

mysql --login-path=restore < school_full.sql

Interactive client में SOURCE /approved/path/school_full.sql; use कर सकते हैं। SQL dump executable code है; trusted artifact और least-privileged restore account रखें।

1. Client exit status और full error log देखें।
2. Tables, views, triggers, routines और events check करें।
3. Expected row counts और business totals compare करें।
4. Foreign keys, nullability और migrations verify करें।
5. CHECKSUM TABLE केवल operationally suitable जगह use करें।
6. Email/payment/jobs disabled रखकर read-only app smoke test करें।
7. Actual restore time को RTO से compare करें।

SELECT COUNT(*) AS students FROM school.students;
SHOW TRIGGERS FROM school;
SHOW PROCEDURE STATUS WHERE Db='school';
SELECT EVENT_NAME,STATUS FROM information_schema.EVENTS
WHERE EVENT_SCHEMA='school';

Binary Logs से Point-in-Time Recovery

Full backup अपने snapshot time तक recover करता है। उसके बाद data loss घटाने के लिए required binary logs retain करें और incident से पहले approved time/position तक changes replay करें। यही PITR है।

1. UTC में exact incident timeline पहचानें और unreviewed writes रोकें।
2. Affected server, backup, binlogs और evidence preserve करें।
3. Last valid full backup isolated replacement पर restore करें।
4. Backup के बाद वाली सही binlog sequence चुनें।
5. Approved stop time/position तक reviewed changes replay करें।
6. Cutover से पहले data/application invariants validate करें।

Discovery time सहित RPO cover करने जितनी binlog retention रखें। हर drill में continuity, server identifiers, GTID policy और time zones confirm करें। गलत stop point damaging statement दोबारा चला या legitimate work हटा सकता है।

Backup Security, Retention और Disposal

Practical target 3-2-1-1-0 है: three copies, two storage types, one offsite, one offline/immutable और zero unverified restore errors। इसे regulation और threat model के अनुसार adapt करें।

• Transit/at-rest encryption और separately managed recoverable keys रखें।
• Dedicated identities, least privilege, MFA और audit logs रखें।
• Ransomware/admin compromise से protected immutable copy रखें।
• Production, backup और restore credentials अलग रखें।
• Daily/weekly/monthly retention, legal holds और secure expiry तय करें।
• Missed jobs, abnormal size, checksum failure और aging copies monitor करें।
• Nonproduction use से पहले sensitive data mask करें।

“Just in case” के लिए हमेशा data retain न करें। Documented schedule recovery, legal और privacy needs balance करता है। Retention खत्म होने पर replicated copies भी securely expire करें।

Production Backup और Restore Runbook

1. Design: RPO/RTO, scope, technology, owners और budget approve करें।
2. Prepare: objects, versions, keys, grants और dependencies inventory करें।
3. Back up: consistent copy और immutable metadata बनाएँ।
4. Transfer: encrypt/checksum करके independent failure domains में रखें।
5. Monitor: failure, duration, size, retention और missing logs पर alerts रखें।
6. Restore: documented commands से isolation में rebuild करें।
7. Validate: technical और business acceptance compare करें।
8. Exercise: timed DR drill, gap record और runbook update करें।

Commands के लिए mysqldump पढ़ें। Restored jobs premature न चलें, इसलिए Event Scheduler review करें और identities पर least privilege लगाएँ।

Official संदर्भ

• MySQL 8.4: Backup and Recovery
• MySQL 8.4: Backup Types
• MySQL 8.4: The Binary Log

Backup classification, logical dump limits और recovery में binary log की भूमिका official MySQL manual से verify की गई है। Deployed edition, version और topology पर procedure test करें।