आपके VPS के लिए बैकअप रणनीति

एक अच्छी VPS बैकअप रणनीति की तीन परतें होती हैं: पूरे सर्वर को जल्दी रीस्टोर करने के लिए अपने-आप चलने वाले सर्वर बैकअप, डेटाबेस के लिए ऐप्लिकेशन-लेवल डंप, और किसी दूसरी लोकेशन पर एक एन्क्रिप्टेड ऑफ़साइट कॉपी। हर जोखिम भरे बदलाव से पहले एक स्नैपशॉट लें और नियमित रूप से रीस्टोर टेस्ट करें, क्योंकि बिना टेस्ट किया बैकअप सिर्फ़ एक उम्मीद है।

यह गाइड हर परत को समझाती है, Ubuntu 24.04 और Debian 12 के कमांड के साथ।

3-2-1 नियम से शुरुआत करें

पुराना नियम आज भी सही है:

• आपके डेटा की 3 कॉपी (लाइव डेटा और दो बैकअप),
• 2 अलग-अलग तरह के स्टोरेज या सिस्टम पर,
• इनमें से 1 ऑफ़साइट, किसी दूसरी लोकेशन या प्रोवाइडर पर।

VPS पर इसका मतलब आम तौर पर होता है: खुद सर्वर, प्रोवाइडर के बैकअप, और कहीं और रखी एक एन्क्रिप्टेड कॉपी।

जानें कि आप किससे बचाव कर रहे हैं

अलग-अलग जोखिमों के लिए अलग-अलग परतें चाहिए। इसीलिए ज़रूरी डेटा के लिए एक तरीका कभी काफ़ी नहीं होता।

परत 1: प्रोवाइडर के बैकअप और स्नैपशॉट

अपने-आप चलने वाले बैकअप

Wolkra पर आप हर सर्वर के लिए रोज़ाना ऑटोमैटिक बैकअप चालू कर सकते हैं। इनकी कीमत सर्वर की कीमत का 20% है और ये 7 रीस्टोर पॉइंट रखते हैं। बैकअप पूरे सर्वर को कैप्चर करता है, इसलिए रीस्टोर करने पर OS, कॉन्फ़िगरेशन और डेटा एक साथ वापस आते हैं। किसी बड़ी गलती के बाद वापस पटरी पर आने का यही सबसे तेज़ तरीका है।

स्नैपशॉट

स्नैपशॉट ज़रूरत पड़ने पर लिए जाते हैं और इनका बिल प्रति GB बनता है। इनका इस्तेमाल करें:

• OS, डेटाबेस या किसी बड़े ऐप वर्ज़न को अपग्रेड करने से पहले;
• फ़ायरवॉल या नेटवर्क सेटिंग्स के साथ प्रयोग करने से पहले;
• टेम्पलेट के रूप में: आप किसी स्नैपशॉट से नए सर्वर बना सकते हैं।

चरणों के लिए देखें बैकअप और स्नैपशॉट और डॉक्स।

डिस्क-लेवल कॉपी को सुसंगत रखें

चलते हुए सर्वर का बैकअप कुछ ऐसा है जैसे बिजली का प्लग खींच देना: फ़ाइल सिस्टम के स्तर पर फ़ाइलें सुसंगत रहती हैं, लेकिन जो डेटाबेस उस समय लिख रहा था उसे रिकवरी की ज़रूरत पड़ सकती है। डेटाबेस इसे संभालने के लिए बने हैं, फिर भी एक साफ़ डंप (परत 2) हर शक दूर कर देता है।

परत 2: ऐप्लिकेशन-लेवल डंप

PostgreSQL

sudo mkdir -p /var/backups/db && sudo chown postgres: /var/backups/db
sudo -u postgres sh -c 'pg_dump -Fc mydb > /var/backups/db/mydb-$(date +%F-%H%M).dump'

-Fc कंप्रेस्ड कस्टम फ़ॉर्मेट है; इसे pg_restore से रीस्टोर करें।

MariaDB या MySQL

sudo sh -c 'mariadb-dump --single-transaction --routines --all-databases | gzip > /var/backups/db/all-$(date +%F-%H%M).sql.gz'

--single-transaction InnoDB टेबल को लॉक किए बिना उनका सुसंगत डंप देता है।

Docker में

docker compose exec -T db pg_dump -U app app | gzip > ~/backups/app-$(date +%F).sql.gz

शेड्यूल करें और पुरानी फ़ाइलें हटाएं

डंप को एक स्क्रिप्ट में डालें और उसे systemd टाइमर या cron से चलाएं, फिर पुरानी फ़ाइलें हटाएं:

find /var/backups/db -type f -mtime +14 -delete

परत 3: restic से एन्क्रिप्टेड ऑफ़साइट कॉपी

restic बैकअप को एन्क्रिप्ट और डीडुप्लिकेट करता है और उन्हें कई तरह के टारगेट पर भेजता है: SFTP के ज़रिए किसी दूसरे सर्वर पर, या किसी भी S3-कम्पैटिबल ऑब्जेक्ट स्टोरेज पर।

इंस्टॉल करें

sudo apt install -y restic

रिपॉज़िटरी चुनें

उदाहरण आपके नियंत्रण वाले एक बैकअप सर्वर पर SFTP का इस्तेमाल करते हैं। S3-कम्पैटिबल बकेट भी इसी तरह काम करता है, s3: रिपॉज़िटरी URL और एनवायरनमेंट वेरिएबल में क्रेडेंशियल के साथ।

sudo mkdir -p /etc/restic && sudo chmod 700 /etc/restic
openssl rand -base64 32 | sudo tee /etc/restic/password >/dev/null
sudo chmod 600 /etc/restic/password

sudo tee /etc/restic/env >/dev/null <<'EOF'
RESTIC_REPOSITORY=sftp:[email protected]:/srv/restic/web-1
RESTIC_PASSWORD_FILE=/etc/restic/password
EOF
sudo chmod 600 /etc/restic/env

root को एक ऐसी SSH की चाहिए जिससे वह backup.example.com में लॉग इन कर सके (देखें SSH कीज़)। restic पासवर्ड को सर्वर के बाहर भी कहीं सुरक्षित रखें। इसके बिना बैकअप कोई नहीं पढ़ सकता, आप भी नहीं।

इनिशियलाइज़ करें और चलाएं

sudo bash -c 'set -a; . /etc/restic/env; restic init'
sudo bash -c 'set -a; . /etc/restic/env; restic backup /etc /var/www /var/backups/db /home --exclude-caches'
sudo bash -c 'set -a; . /etc/restic/env; restic snapshots'

रिटेंशन

sudo bash -c 'set -a; . /etc/restic/env; restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune'

इससे एक हफ़्ते के रोज़ाना, एक महीने के साप्ताहिक और छह महीने के मासिक बैकअप रहते हैं।

systemd टाइमर से ऑटोमेट करें

/etc/systemd/system/restic-backup.service:

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
ExecStart=/usr/bin/restic backup /etc /var/www /var/backups/db /home --exclude-caches
ExecStartPost=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

/etc/systemd/system/restic-backup.timer:

[Unit]
Description=Nightly restic backup

[Timer]
OnCalendar=*-*-* 03:30
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

डेटाबेस डंप को restic से पहले चलाएं, जैसे एक ExecStartPre= लाइन से जो आपकी डंप स्क्रिप्ट को कॉल करे।

हैक हुए सर्वर से बचाव

अगर किसी हमलावर को root मिल जाए, तो वह वे सारे बैकअप डिलीट कर सकता है जिन तक सर्वर पहुंच सकता है। यह जोखिम कम करें:

• जहां टूल सपोर्ट करे, टारगेट पर बैकअप यूज़र को append-only एक्सेस दें (restic के REST सर्वर में --append-only मोड है);
• पुराने बैकअप हटाने (pruning) का काम किसी दूसरी मशीन से चलाएं;
• कम से कम एक कॉपी ऐसी जगह रखें जिसके क्रेडेंशियल सर्वर के पास न हों।

किसका बैकअप लें

• कॉन्फ़िगरेशन के लिए /etc।
• ऐप्लिकेशन कोड और अपलोड: /var/www, /srv, /opt या आपकी ऐप डायरेक्टरी।
• डेटाबेस डंप, कच्ची डेटाबेस फ़ाइलें नहीं।
• स्टेटफ़ुल कंटेनरों के Docker वॉल्यूम, या उनके डंप।
• TLS और ऐप सीक्रेट, एन्क्रिप्टेड रूप में।
• एक छोटी README जो बताए कि सर्वर को दोबारा कैसे बनाना है।

आम तौर पर आपको /var/cache, /tmp, पैकेज कैश या उन Docker इमेज लेयर की ज़रूरत नहीं होती जिन्हें फिर से pull किया जा सकता है।

ब्लॉक स्टोरेज वॉल्यूम

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

रीस्टोर टेस्ट करें

एक शेड्यूल चुनें, जैसे हर महीने, और इनमें से कोई एक करें:

1. पूरा सर्वर: किसी बैकअप या स्नैपशॉट से नया सर्वर बनाएं, उसे किसी टेस्ट नाम पर शुरू करें और जांचें कि ऐप काम करता है।
2. फ़ाइलें: किसी अस्थायी डायरेक्टरी में रीस्टोर करें और तुलना करें।

sudo bash -c 'set -a; . /etc/restic/env; restic restore latest --target /tmp/restore-test --include /etc/caddy'
sudo bash -c 'set -a; . /etc/restic/env; restic check'

3. डेटाबेस: एक डंप को नए डेटाबेस में लोड करें और कुछ क्वेरी चलाएं।

प्रति घंटा बिलिंग के साथ, एक घंटे के लिए रीस्टोर टेस्ट सर्वर बहुत सस्ता पड़ता है। रीस्टोर में लगा समय लिख लें; वही आपका असली रिकवरी टाइम है।

कॉपी करने लायक एक आसान योजना

संख्याओं को इस हिसाब से बदलें कि आप कितना डेटा खोना झेल सकते हैं और आपको कितनी जल्दी वापस चालू होना है। बाकी सर्वर सेटअप के लिए देखें नए VPS पर पहले कदम और Ubuntu सर्वर को सुरक्षित कैसे करें।