टेस्ट रिस्टोर: अपने बैकअप पहले से जाँचें

जिस बैकअप से आपने कभी रीस्टोर नहीं किया, वह बैकअप नहीं है — वह सिर्फ़ एक उम्मीद है। हर तीन महीने में एक बार अभ्यास रीस्टोर में एक घंटा लगता है और यह उम्मीद को सत्यापित तथ्य में बदल देता है।

क्या जाँचें

किसी घटना से पहले तीन सवालों के जवाब आपके पास होने चाहिए:

1. पूर्णता। क्या बैकअप में शुरू करने के लिए ज़रूरी सब कुछ है: डेटा, सेटिंग्स, की, सर्टिफ़िकेट, शेड्यूल।
2. पठनीयता। क्या आर्काइव खुलता है, क्या डेटाबेस डंप बिना एरर के रीस्टोर होता है।
3. समय। पूरा रीस्टोर होने में कितने घंटे लगेंगे। यह संख्या आपको पहले से पता होनी चाहिए, दबाव में पता नहीं चलनी चाहिए।

ड्रिल कैसे करें

सबसे ईमानदार तरीका है अलग मशीन पर, प्रोडक्शन वाली पर नहीं। एक महीने के लिए VDS-1 लें, उस पर शुरू से रीस्टोर करें और समय नापें।

export RESTIC_REPOSITORY="sftp:backup@backup.example.com:/srv/restic"
export RESTIC_PASSWORD_FILE=/root/.restic-pass

restic snapshots
restic restore latest --target /restore
ls -la /restore

डेटाबेस रीस्टोर करें:

docker compose up -d db
gunzip -c /restore/var/backups/db.sql.gz | docker compose exec -T db psql -U postgres app
docker compose exec -T db psql -U postgres app -c "select count(*) from users;"

एप्लिकेशन चालू करें और ब्राउज़र में खोलें — यह आख़िरी कदम है। जब तक पेज नहीं खुलता, रीस्टोर नहीं हुआ।

एक हल्का विकल्प जो काम का है: उसी मशीन पर अलग कंटेनर में सिर्फ़ डेटाबेस रीस्टोर करें और देखें कि डेटा मौजूद और ताज़ा है।

सिर्फ़ यह न देखें कि अनपैकिंग हो गई, बल्कि डेटा की तारीख़ भी देखें। जो बैकअप भरोसे से बनता रहता है लेकिन एक महीने पहले ज़रूरी डायरेक्टरी शामिल करना बंद कर चुका है, वह स्नैपशॉट लिस्ट में बिल्कुल सामान्य दिखता है। टेबल में रिकॉर्ड की संख्या और नई फ़ाइलों के टाइमस्टैम्प की तुलना करें।

आमतौर पर क्या सामने आता है

• .env फ़ाइल भूल जाती है। डेटा मौजूद है, लेकिन उसके पासवर्ड नहीं।
• सर्टिफ़िकेट भूल जाते हैं। साइट चालू होती है लेकिन HTTPS पर जवाब नहीं देती।
• शेड्यूल भूल जाता है। सब कुछ चलता है, लेकिन बैकअप बनना बंद हो जाता है — और पता एक महीने बाद चलता है।
• स्टार्टअप क्रम लिखा ही नहीं जाता। एप्लिकेशन डेटाबेस से पहले शुरू होता है और क्रैश हो जाता है।
• रिपॉज़िटरी का पासवर्ड सिर्फ़ खोई हुई मशीन पर था। बैकअप मौजूद हैं, लेकिन उन तक पहुँच नहीं।
• रीस्टोर दो नहीं, दस घंटे लेता है। रिसीवर बैंडविड्थ या डिस्क शेल्फ, देखें डिस्क स्पीड।

क्रम लिखकर रखें

ड्रिल के आधार पर एक छोटी इंस्ट्रक्शन लिखें और उसे मशीन से बाहर रखें:

1. उसी या बड़े टियर की मशीन ऑर्डर करें — प्रोविज़निंग में लगभग एक मिनट लगता है।
2. Docker इंस्टॉल करें और बैकअप से /opt/myapp रीस्टोर करें।
3. डेटाबेस डंप रीस्टोर करें, रिकॉर्ड की संख्या जाँचें।
4. /etc/nginx और सर्टिफ़िकेट रीस्टोर करें, वेब सर्वर चालू करें।
5. डोमेन को नए पते पर पॉइंट करें।
6. crontab.txt से शेड्यूल रीस्टोर करें।
7. जाँचें: साइट खुलती है, लॉगिन चलता है, बैकअप फिर से बन रहे हैं।

आइटम 5 सबसे ज़्यादा कम आँका जाता है। DNS रिकॉर्ड तुरंत अपडेट नहीं होते, और अगर आप माइग्रेशन की गुंजाइश रखते हैं तो रिकॉर्ड का TTL पहले से 300 सेकंड कर दें।

कितनी बार

प्रोडक्शन सर्विस के लिए हर तीन महीने में एक बार, बाक़ी सब के लिए हर छह महीने में एक बार। साथ ही किसी भी बड़े बदलाव के बाद हमेशा: नया डेटाबेस, नई सर्विस, डायरेक्टरी की शिफ़्टिंग। ड्रिल को कैलेंडर पर डालें, वरना वह कभी नहीं होगी।

बैकअप में क्या होना चाहिए — ठीक क्या बैकअप करें। कहाँ रखें — ऑफ़साइट बैकअप। अगर घटना पहले ही हो चुकी है — डेटा खो गया।