VPS बैकअप और स्नैपशॉट गाइड

खराब अपडेट, गलती, मैलवेयर या हार्डवेयर की समस्या से सर्वर खराब हो सकता है। एक अच्छी योजना में स्नैपशॉट, बैकअप और परखा हुआ रिस्टोर शामिल होता है। ONIE पर होची मिन्ह सिटी के Cloud Servers स्नैपशॉट और बैकअप सपोर्ट करते हैं, और डेटा के लिए आप अतिरिक्त Block Storage जोड़ सकते हैं।

स्नैपशॉट बनाम बैकअप

दोनों का उपयोग करें: जोखिम भरे बदलावों से पहले स्नैपशॉट लें, और बाकी सब के लिए तय समय पर बैकअप।

3-2-1 नियम

महत्वपूर्ण डेटा की 3 कॉपी रखें, 2 अलग-अलग प्रकार के स्टोरेज पर, और 1 कॉपी किसी दूसरी जगह। अकेला स्नैपशॉट उसी सर्वर पर पर्याप्त नहीं है।

फ़ाइलों का बैकअप

rsync केवल वही कॉपी करता है जो बदला है:

rsync -aH --delete /var/www/ backup@backup-host:/srv/backups/www/

restic कई लक्ष्यों पर एन्क्रिप्टेड और डीडुप्लीकेटेड बैकअप बनाता है:

sudo apt install -y restic
restic -r sftp:backup@backup-host:/srv/restic init
restic -r sftp:backup@backup-host:/srv/restic backup /var/www /etc
restic -r sftp:backup@backup-host:/srv/restic forget --keep-daily 7 --keep-weekly 4 --prune

डेटाबेस का बैकअप

चल रही डेटा फ़ाइलों को सीधे कॉपी करने के बजाय डंप से डेटाबेस कॉपी करें:

mysqldump --single-transaction --routines -u root wordpress | gzip > /var/backups/wordpress-$(date +%F).sql.gz

PostgreSQL के लिए pg_dump का उपयोग करें।

स्वचालित बैकअप

बैकअप को cron या systemd timer से चलाएँ, और रिटेंशन नीति रखें ताकि पुरानी कॉपियाँ हटती रहें:

sudo crontab -e
# every day at 02:30
30 2 * * * /usr/local/bin/backup.sh

रिस्टोर की जाँच करें

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

बड़े बदलावों से पहले

स्नैपशॉट लें, बदलाव करें, परखें, और पूरी तरह निश्चित होने पर स्नैपशॉट हटा दें। यह सुरक्षित SSH सेटअप के साथ अच्छी तरह जाता है, और WordPress साइट अपग्रेड करते समय भी यही आदत काम आती है।