VPS snapshot, backup आणि clone मधील फरक

स्नॅपशॉट, बॅकअप आणि क्लोन प्रत्यक्षात काय असतात

VPS snapshot म्हणजे तुमच्या server ची disk image. ती तुमचा provider, त्याच्या infrastructure वर आणि तुमच्या account मध्ये ठेवतो. Backup म्हणजे तुमच्या data ची स्वतंत्र copy. Provider ची मदत न घेता ती तुम्ही दुसरीकडे restore करू शकता. Clone म्हणजे snapshot वरून deploy केलेला नवीन instance. त्यामुळे तो सुरुवातीपासूनच मूळ server ची identity सहित तंतोतंत copy असतो.

हे तिन्ही वेगवेगळ्या समस्या सोडवतात. Snapshot मुळे अयशस्वी upgrade काही मिनिटांत मागील स्थितीत आणता येतो. मात्र account बंद झाल्यास त्याचा उपयोग होत नाही. Provider सेवा बंद करून निघून गेला तरी backup उपलब्ध राहतो. Restore करण्यास अधिक वेळ लागतो, कारण आधी machine पुन्हा तयार करावी लागते. Clone मुळे एका चरणात दुसरा चालू server मिळतो. पण त्यामुळे एकाच machine असल्याचा विश्वास असलेले दोन server तयार होतात.

VPS snapshot हा backup का नाही

समस्या image च्या गुणवत्तेची नाही; ती failure domain ची आहे. Snapshot तुमच्या provider च्या storage platform वर असतो. तो सामान्यतः ज्या region मध्ये server आहे त्याच region मध्ये असतो आणि नेहमी त्याच account मध्ये राहतो. एका घटनेमुळे server आणि त्याचा snapshot दोन्ही एकाच वेळी नष्ट होऊ शकतात.

• Account suspend होते, payment fail होते किंवा कोणी login चोरते.
• API access असलेली व्यक्ती किंवा script instance delete करते. अनेक providers मध्ये instance delete केल्यावर त्याचे snapshots देखील delete होतात. याच्या उलट गृहीत धरण्यापूर्वी तुमच्या provider चे documented behaviour वाचा.
• Region मध्ये बिघाड होतो आणि तेथील सर्वकाही एकाच वेळी unreachable होते.
• Server वर root म्हणून चालणाऱ्या एखाद्या प्रक्रियेला तुम्ही /root मध्ये ठेवलेला provider API token सापडतो आणि ती प्रक्रिया disk वर परिणाम करण्यापूर्वी snapshots remove करते.

Backup ही अशी copy असते जी या चारही परिस्थितींनंतर उपलब्ध राहते. चाचणीसाठी एकच प्रश्न विचारा: तुमचे provider account आज दुपारी अस्तित्वातच राहिले नाही, तर तुम्ही काय restore करू शकाल आणि ते कुठे restore कराल? या प्रश्नाचे समाधान न करणारी कोणतीही गोष्ट rollback tool आहे. Snapshots घेत राहा, कारण त्यांच्यापेक्षा जलद restore करणारी गोष्ट नाही. त्यानंतर provider च्या नियंत्रणाबाहेरील storage वर दुसरी copy ठेवा.

जुना नियम अजूनही लागू आहे: data च्या तीन copies, storage चे दोन प्रकार आणि त्यांपैकी एक platform च्या बाहेर. Provider snapshot आणि स्वतंत्र infrastructure वरील restic backup repository यामुळे दोन घटकांसह ही गरज पूर्ण होते.

चालू database चा snapshot restore केल्यावर तो खराब का होऊ शकतो

Provider snapshot एका क्षणी block device ज्या स्थितीत आहे, त्याची प्रत बनवतो. तो आधी तुमच्या applications थांबवत नाही. Page cache मध्ये अजून असलेला कोणताही डेटा त्याला दिसत नाही. त्यामुळे image सर्वोत्तम परिस्थितीत crash-consistent असतो. एखाद्याने power cable ओढून काढल्यावर disk जशी दिसेल, तशीच ती दिसते.

Stack मधील बहुतांश घटक हे हाताळतात. ext4 आणि XFS mount करताना त्यांचा journal replay करतात. त्यामुळे filesystem सुरू होतो. PostgreSQL सुरू होताना त्याचा write-ahead log replay करतो. Log मध्ये हे दिसते:

LOG:  database system was not properly shut down; automatic recovery in progress

InnoDB देखील हेच करते आणि startup दरम्यान crash recovery च्या स्वतःच्या नोंदी दाखवते. ही recovery database च्या अपेक्षित कार्यपद्धतीनुसार होते. त्यामुळे शांत PostgreSQL किंवा MySQL चा single-volume snapshot सहसा योग्यरीत्या restore होतो.

Crash-consistent पुरेसा नसलेल्या परिस्थिती खरोखर घडतात आणि त्यांचा परिणाम गंभीर असतो. तुमचा data दोन volumes मध्ये असल्यास root disk आणि स्वतंत्र data disk वेगवेगळ्या क्षणी snapshot केले जातात. त्यामुळे data files आणि log directory यांच्यात विसंगती येऊ शकते. अशा वेळी recovery कडे replay करण्यासाठी योग्य माहिती उरत नाही. fsync न वापरता application ने लिहिलेली कोणतीही file, जसे अर्धवट प्राप्त झालेली upload किंवा queue file, truncate झालेल्या स्थितीत परत येऊ शकते. Application memory मध्ये ठेवून timer नुसार flush करत असलेला कोणताही data image मध्ये मुळीच नसतो.

म्हणून snapshot घेण्यापूर्वी disk वर dump लिहा. त्यानंतर image मध्ये तुम्हाला अंतर्गतदृष्ट्या consistent असल्याची खात्री असलेली एक file असेल. Live data files कोणत्याही स्थितीत असल्या तरी हे लागू राहते.

sudo -u postgres pg_dumpall --clean --file=/var/backups/pg-$(date +%F).sql
sudo mysqldump --single-transaction --routines --all-databases > /var/backups/mysql-$(date +%F).sql

--single-transaction writers ला block न करता InnoDB tables चा consistent dump देते, कारण dump एका repeatable-read transaction मध्ये चालतो. MyISAM tables यामध्ये समाविष्ट होत नाहीत. त्यांच्यासाठी lock किंवा थांबवलेला server आवश्यक असतो. Dump वर विश्वास ठेवण्यापूर्वी तो रिकामा किंवा truncated नाही याची तपासणी करा: पूर्ण mysqldump चा शेवट tail -n 1 /var/backups/mysql-$(date +%F).sql नंतरच्या Dump completed comment ने होतो.

स्वतंत्र data volume असल्यास snapshot साठी लागणाऱ्या काही seconds साठी ते freeze करू शकता:

sudo fsfreeze -f /srv
# take the snapshot from your provider's panel or API
sudo fsfreeze -u /srv

फक्त data volume freeze करा. / कधीही freeze करू नका. Frozen root filesystem मुळे box वरील प्रत्येक write block होतो. यात unfreeze command टाइप करण्यासाठी वापरण्यात येणारा shell देखील येतो. त्यामुळे तुम्ही स्वतःच system मधून बाहेर पडता आणि hard reset ची वाट पाहावी लागते.

offsite भाग: restic किंवा Borg

Snapshot हा जलद भाग आहे. offsite प्रत तुमच्या provider च्या पलीकडे टिकून राहणारा भाग आहे. restic हा चांगला default पर्याय आहे, कारण तो deduplication करतो, client side encryption करतो आणि S3-compatible object storage, SFTP किंवा साध्या directory मध्ये लिहितो. offsite target म्हणून storage VPS येथे चांगला पर्याय ठरतो, कारण backup repositories ना IOPS पेक्षा capacity अधिक आवश्यक असते.

sudo apt update && sudo apt install -y restic
sudo sh -c 'umask 077; head -c 24 /dev/urandom | base64 > /root/.restic-pass'
sudo chmod 600 /root/.restic-pass
sudo cat /root/.restic-pass

हा passphrase आता password manager मध्ये कॉपी करा. त्यासाठी या server व्यतिरिक्त दुसरे device वापरा. restic repository हा passphrase शिवाय उघडता येत नाही आणि recovery path उपलब्ध नाही. तुम्ही नुकताच गमावलेल्या box वर password ची एकमेव प्रत असल्यास backup encrypted noise ठरतो.

export RESTIC_REPOSITORY="s3:https://s3.example.com/vps-backups"
export RESTIC_PASSWORD_FILE=/root/.restic-pass
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
sudo -E restic init
sudo -E restic backup /etc /srv /var/backups
sudo -E restic snapshots

sudo -E ही variables ठेवतो. ते नसल्यास root ला clean environment मिळते आणि restic repository location निर्दिष्ट केलेली नसल्याचे सांगतो. restic snapshots मध्ये तुम्ही नुकतीच केलेली run, तिचा host आणि paths दिसले पाहिजेत. ठरावीक वेळापत्रकानुसार repository ची स्वतः पडताळणी करा. फक्त तिची structure तपासू नका; काही data परत वाचूनही पाहा:

sudo -E restic check --read-data-subset=5%
sudo -E restic restore latest --target /tmp/restore-check
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

चाचणी न केलेला backup हा केवळ अंदाज असतो. तो वेगळ्या VPS वर किमान एकदा restore करा आणि त्यासाठी लागणारा वेळ मोजा. तो वेळ नोंदवून ठेवा, कारण तोच तुमचा वास्तविक recovery target आहे. Borg हा दुसरा विश्वासार्ह पर्याय आहे. तो object storage ऐवजी SSH द्वारे repository साठवतो. त्यातील trade-offs restic आणि BorgBackup ची तुलना येथे दिले आहेत.

उत्पादनाच्या जवळ नेण्यापूर्वी क्लोन केलेल्या VPS मध्ये दुरुस्ती करावयाच्या गोष्टी

क्लोन ही हुबेहुब प्रतिकृती असते. हेच तिचे महत्त्वाचे वैशिष्ट्य आणि समस्या आहे. मूळ सर्व्हरची ओळख वेगळी करणाऱ्या सर्व गोष्टींच्या प्रतिकृती तयार होतात आणि त्या एकमेकांशी संघर्ष करतात.

SSH host keys पुन्हा निर्माण करा. क्लोनमध्ये मूळ सर्व्हरच्या /etc/ssh/ssh_host_* फाइल्स असतात. त्यामुळे दोन्ही सर्व्हर एकच host identity सादर करतात. एखाद्याचे नियंत्रण मिळवणारी व्यक्ती, ती key स्वीकारलेल्या प्रत्येक client समोर दुसऱ्या सर्व्हरचे अनुकरण करू शकते. SSH कोणतीही warning देत नाही, कारण client ला अपेक्षित असलेली key हीच असते.

sudo rm -f /etc/ssh/ssh_host_*
sudo ssh-keygen -A
sudo systemctl restart ssh
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

ssh-keygen -A daemon ला अपेक्षित असलेल्या प्रत्येक प्रकारची नवीन key लिहिते. शेवटच्या command मधील fingerprint मूळ सर्व्हरवरील fingerprint पेक्षा वेगळी असली पाहिजे. restart केल्यानंतर तुमचे सध्याचे session सुरू राहते, कारण sshd restart केल्याने आधीपासून स्थापित connections बंद होत नाहीत. क्लोनशी कोणीही connect होण्यापूर्वी हे करा. हे नंतरपर्यंत ठेवले, तर inherited key वर आधीच विश्वास ठेवणाऱ्या प्रत्येक client ला WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! मिळते आणि त्यांना आधी ssh-keygen -R <host> चालवावे लागते.

Machine ID reset करा. /etc/machine-id हा systemd पहिल्या boot वेळी एकदाच निर्माण करणारा unique identifier आहे आणि क्लोनमध्ये तोच identifier येतो.

sudo truncate -s 0 /etc/machine-id
sudo rm -f /var/lib/dbus/machine-id
sudo ln -s /etc/machine-id /var/lib/dbus/machine-id
sudo reboot

रिकामी /etc/machine-id systemd ला पुढील boot वेळी नवीन value निर्माण करण्यास सांगते. म्हणून ती file delete करण्याऐवजी truncate करा. ती duplicated असल्यास दोन गोष्टी बिघडतात. DHCP द्वारे address घेणाऱ्या images मध्ये systemd-networkd default नुसार machine ID वरून DHCP client identifier तयार करते. त्यामुळे दोन्ही clones एकाच client प्रमाणे lease मागतात आणि server त्यांना एकच address देतो. तसेच journald प्रत्येक entry वर machine ID लावते. त्यामुळे central log collector दोन्ही servers ची नोंद एकाच machine अंतर्गत करतो. reboot नंतर cat /etc/machine-id चालवून value बदलल्याची खात्री करा.

Hostname बदला.

sudo hostnamectl set-hostname web-02
grep 127.0.1.1 /etc/hosts

hostnamectl /etc/hostname लिहिते आणि name त्वरित लागू करते. ती /etc/hosts बदलत नाही. त्यामुळे 127.0.1.1 मधील line जुळेल अशी edit करा. हे वगळल्यास नवीन name कुठेही resolve होत नाही. परिणामी प्रत्येक sudo call अपयशी lookup वर थांबते आणि sudo: unable to resolve host web-02: Name or service not known छापते.

Image मध्ये आधीपासून असलेले प्रत्येक credential बदला. क्लोनमध्ये मूळ सर्व्हरचे secrets असतात. त्यामुळे आता दोन machines मूळ सर्व्हरप्रमाणे काम करू शकतात. SSH authorized_keys files, provider आणि DNS API tokens, application .env files, database passwords, TLS private keys, monitoring enrolment tokens आणि restic repository password तपासा. यातील बहुतेक credentials पुढील command शोधते:

sudo grep -rIlE 'PASSWORD|SECRET|TOKEN|API_KEY' /etc /srv /opt /home 2>/dev/null
sudo find / -name '.env' -not -path '/proc/*' -not -path '/sys/*' 2>/dev/null

क्लोन ही अशी test copy असेल जी कधीही traffic serve करणार नसेल, तर credentials rotate करण्याऐवजी revoke करा. Live production API token असलेला staging box म्हणजे अधिक खराब patching असलेला production box आहे.

आता दोनदा चालणाऱ्या jobs बंद करा. समान crontab असलेले दोन servers त्याच minute ला त्याच external systems वर request करतात.

systemctl list-timers --all
sudo crontab -l
sudo ls -l /etc/cron.d /etc/cron.daily

restic बाबत अधिक स्पष्टपणे सांगणे आवश्यक आहे, कारण यामुळे फक्त स्पष्ट failure होत नाही; तुमची retention policyच बिघडते. restic प्रत्येक snapshot ला host name लावते आणि restic forget --keep-daily 7 ही policy प्रत्येक host साठी स्वतंत्रपणे लागू करते. समान host name report करणाऱ्या दोन machines ना एकच host मानले जाते. त्यामुळे सात "daily" snapshots सर्व क्लोनमधून येऊ शकतात आणि मूळ server चे snapshots prune होऊ शकतात. पहिला backup run होण्यापूर्वी hostname दुरुस्त करा किंवा क्लोनवरील timer थांबवा. certbot बाबत समस्या सोपी आहे: समान names renew करणारे दोन servers certificate authority च्या duplicate certificate rate limit वर पोहोचतात आणि हरलेला run, त्या exact set of names साठी आधीच खूप certificates issue झाल्याची error देऊन fail होतो. ज्याचा domain अजूनही मूळ server कडे point करतो असा clone HTTP challenge पास करू शकत नाही. त्यामुळे तेथे renewal disable करा.

Monitoring agent ची व्यवस्था करा. बहुतेक agents hostname किंवा install वेळी लिहिलेल्या ID file वरून स्वतःची ओळख करतात. त्यामुळे एकाच host म्हणून report करणारे दोन agents त्यांचे metrics एकाच series मध्ये एकत्र मिसळतात. परिणामी CPU graphs कोणत्याही एका machine ने निर्माण न केलेली values दाखवतात आणि alerts वारंवार flap होतात. क्लोनवरील agent stop करून remove करा किंवा vendor ने documented केलेल्या procedure नुसार नवीन hostname अंतर्गत त्याचे पुन्हा enrolment करा.

मूळ server च्या address साठी network configuration तपासा. netplan मध्ये image सोबत static address असल्यास, क्लोन दुसऱ्या machine च्या मालकीचा IP claim करतो.

ip -br addr
sudo grep -r addresses /etc/netplan/

हा clone template बनणार असल्यास cloud-init state clear करा.

sudo cloud-init clean --logs

यामुळे /var/lib/cloud अंतर्गत cloud-init ची state remove होते. त्यामुळे पुढील boot वेळी first-boot modules पुन्हा चालतात. त्यात SSH host keys उपलब्ध नसल्यास त्या generate करण्याचाही समावेश असतो. काही versions machine ID reset करण्यासाठी flag देखील देतात. इतरत्र दिलेल्या flag list वर विश्वास ठेवण्याऐवजी तुमच्या image वर cloud-init clean --help चालवून त्यामध्ये कोणते पर्याय समर्थित आहेत ते पाहा.

कोणता पर्याय कधी वापरावा

जोखमीचे upgrade पूर्ववत करायचे असल्यास: snapshot घ्या. बदल करण्याच्या काही मिनिटे आधी snapshot घ्या, upgrade चालवा आणि काही बिघडल्यास image restore करा. Snapshot घेतल्यानंतर झालेले सर्व writes restore केल्यावर नष्ट होतात. त्यामुळे live traffic घेणाऱ्या server वर आधी database dump घ्या आणि नेमका कोणता कालावधी गमावला जाईल हे स्पष्टपणे ठरवा. दहा मिनिटांसाठी offline ठेवता येणाऱ्या server वरील do-release-upgrade साठी snapshot हीच संपूर्ण योजना असते.

मोठ्या plan वर migrate करायचे असल्यास: clone deploy करा. Snapshot वरून मोठ्या plan वर clone तयार करा. वर दिलेली identity list तपासा. त्यानंतर traffic हलवण्यापूर्वी clone च्या स्वतंत्र IP वर त्याची चाचणी घ्या. Cutover जलद होण्यासाठी एक दिवस आधी DNS TTL कमी करा. नवीन server ने प्रत्यक्ष traffic यशस्वीपणे हाताळेपर्यंत मूळ server सुरू ठेवा. तुमच्या workload साठी मोठा plan खरोखरच अधिक वेगवान आहे याची आधी खात्री करा. त्यासाठी दोन्ही server वर समान benchmark पद्धत वापरा. अधिक व्यस्त hardware वरील अधिक vCPUs म्हणजे नेहमी upgrade असेलच असे नाही.

Template तयार करायचे असल्यास: स्वच्छ केलेल्या machine चा snapshot घ्या. एक server install आणि harden करा. Image तयार करण्यापूर्वी त्या server शी संबंधित सर्व unique माहिती काढून टाका. Host keys ठेवू नका. Machine ID रिकामा करा. वैयक्तिक authorized_keys आणि credentials काढा. cloud-init साफ करा. त्यानंतर snapshot घ्या. त्यावरून deploy केलेले प्रत्येक instance first boot वेळी स्वतःची identity तयार करते. त्यामुळे वरील checklist पुन्हा checklist राहत नाही. हे नवीन VPS वरील पहिल्या दहा मिनिटांच्या standard प्रक्रियेसोबत वापरा, म्हणजे template मध्ये तुम्ही अन्यथा पुन्हा करणार असलेले काम आधीच समाविष्ट असेल.

FAQ

VPS snapshot हा backup आहे का?

नाही, कारण तो ज्या server वरून तयार झाला त्याच failure domain मध्ये असतो. Snapshot तुमच्या provider च्या storage वर, तुमच्या account मध्ये आणि सामान्यतः त्याच region मध्ये असतो. Account suspension, चोरीला गेलेली API key किंवा चुकून instance delete होणे यामुळे server आणि त्याचे snapshots एकाच कृतीत हटवले जाऊ शकतात. अनेक providers मध्ये instance delete केल्यावर त्याचे snapshots देखील design नुसार delete होतात. Snapshot हा तुमच्याकडील सर्वात जलद rollback पर्याय आहे. त्यामुळे snapshots घेत राहा आणि provider च्या नियंत्रणाबाहेरील infrastructure वर दुसरी encrypted copy ठेवा.

Snapshot घेण्यापूर्वी database थांबवणे आवश्यक आहे का?

नेहमीच नाही. मात्र snapshot मधून नेमके काय मिळेल हे स्वीकारणे आवश्यक आहे. Provider snapshot crash-consistent असतो. म्हणजे power cut झाल्यानंतर disk जशी दिसेल, तशीच image असते. PostgreSQL आणि InnoDB सुरू होताना त्यातून recovery करतात आणि PostgreSQL हे करताना database system was not properly shut down; automatic recovery in progress logs मध्ये नोंद करतो. तुमचा data वेगवेगळ्या वेळी snapshot घेतलेल्या दोन volumes मध्ये पसरलेला असेल किंवा एखादे application fsync शिवाय write करत असेल, तर recovery ची हमी नसते. आधी disk वर pg_dumpall किंवा mysqldump --single-transaction लिहा, जेणेकरून image मध्ये consistency असल्याची खात्री असलेली एक file असेल.

दोन cloned servers एकाच IP address साठी का संघर्ष करतात?

कारण ते /etc/machine-id share करतात. DHCP वापरणाऱ्या images मध्ये systemd-networkd default नुसार machine ID वरून DHCP client identifier तयार करते. त्यामुळे दोन्ही clones समान client म्हणून lease मागतात आणि DHCP server दोघांनाही तोच address देतो. /etc/machine-id शून्य bytes पर्यंत truncate करा, /var/lib/dbus/machine-id काढून टाका, त्याची symlink /etc/machine-id कडे पुन्हा तयार करा आणि reboot करा. त्यामुळे systemd नवीन value तयार करेल. दुसरे सामान्य कारण म्हणजे /etc/netplan/ मध्ये लिहिलेला static address. Clone ने तो जसाच्या तसा copy केलेला असतो. ip -br addr वापरून तपासा.

Clone production मध्ये ठेवणे सुरक्षित आहे का हे तपासण्याचा सर्वात जलद मार्ग कोणता?

Original विरुद्ध चार गोष्टींची तुलना करा. दोन्हीवर ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub चालवा आणि fingerprints वेगवेगळे असल्याची खात्री करा. दोन्हीवर cat /etc/machine-id चालवा आणि values वेगवेगळ्या असल्याची खात्री करा. hostnamectl status चालवा आणि name नवीन असून resolve होत असल्याची खात्री करा, जेणेकरून sudo warning देणार नाही. त्यानंतर systemctl list-timers --all चालवा आणि shared system शी संवाद साधणारे प्रत्येक timer थांबवा. यामध्ये backups, certificate renewal किंवा monitoring agent यांसारख्या कामांचा समावेश होतो. कोणते machine हे काम करणार हे ठरवेपर्यंत ते timers थांबवून ठेवा.