VPS snapshot, backup, clone మధ్య తేడా ఏమిటి?

Snapshot, backup, clone అంటే వాస్తవంగా ఏమిటి

VPS snapshot అనేది మీ server యొక్క disk image. ఇది మీ provider యొక్క infrastructureలో, మీ accountలో, మీ provider వద్ద నిల్వ ఉంటుంది. Backup అనేది మీ data యొక్క స్వతంత్ర copy. దీన్ని original copyని ఉంచిన provider సహాయం లేకుండానే వేరే చోట restore చేయవచ్చు. Clone అనేది snapshot నుంచి deploy చేసిన కొత్త instance. అందువల్ల ఇది identityతో సహా original instance యొక్క ఖచ్చితమైన copyగా ప్రారంభమవుతుంది.

ఇవి వేర్వేరు సమస్యలను పరిష్కరిస్తాయి. Snapshot విఫలమైన upgradeను నిమిషాల్లో వెనక్కి తిప్పుతుంది. అయితే account మూసివేయబడితే snapshot ఉపయోగపడదు. Provider అందుబాటులో లేకపోయినా backup పనిచేస్తుంది. కానీ ముందుగా machineను మళ్లీ నిర్మించాలి కాబట్టి restore చేయడానికి ఎక్కువ సమయం పడుతుంది. Clone ఒకే దశలో రెండవ running serverను అందిస్తుంది. అయితే ఒకే machine అని భావించే రెండు machines కూడా మీకు ఏర్పడతాయి.

VPS snapshot బ్యాకప్ ఎందుకు కాదు

సమస్య image నాణ్యతలో లేదు; failure domain లో ఉంది. Snapshot మీ provider storage platformలో ఉంటుంది. సాధారణంగా అది ఆ server ఉన్న regionలోనే ఉంటుంది. అది ఎల్లప్పుడూ అదే account పరిధిలో ఉంటుంది. ఒకే సంఘటన server మరియు దాని snapshot రెండింటినీ ప్రభావితం చేయవచ్చు.

• Account suspend కావచ్చు, payment విఫలం కావచ్చు లేదా ఎవరైనా login‌ను దొంగిలించవచ్చు.
• API access ఉన్న వ్యక్తి లేదా script instance‌ను delete చేయవచ్చు. అనేక providersలో instance‌ను delete చేస్తే దానికి సంబంధించిన snapshots కూడా delete అవుతాయి. వేరుగా ఉందని అనుకునే ముందు మీ provider documentationలోని ప్రవర్తనను పరిశీలించండి.
• Regionలో సమస్య ఏర్పడి, అందులోని ప్రతిదీ ఒకేసారి unreachable కావచ్చు.
• Serverపై rootగా నడుస్తున్న ఏదైనా process /rootలో మీరు ఉంచిన provider API tokenను కనుగొని, diskను తాకే ముందు snapshotsను తొలగించవచ్చు.

ఈ నాలుగు పరిస్థితులన్నింటినీ తట్టుకుని మిగిలే copyనే backup అంటాం. పరీక్షకు ఒకే ప్రశ్న ఉంది: ఈ మధ్యాహ్నం మీ 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 లో ఇంకా ఉన్న data ను కూడా అది చూడలేదు. అందువల్ల ఆ 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 lines ను ముద్రిస్తుంది. ఈ recovery database రూపొందించిన విధంగానే పనిచేస్తోంది. అందువల్ల quiet PostgreSQL లేదా MySQL యొక్క single-volume snapshot సాధారణంగా సరిగ్గా restore అవుతుంది.

Crash-consistent స్థితి సరిపోని సందర్భాలు నిజమైనవే. సమస్యలు కలిగించేవి కూడా అవే. మీ data రెండు volumes లో ఉంటే, root disk మరియు ప్రత్యేక data disk వేర్వేరు క్షణాల్లో snapshot చేయబడతాయి. అందువల్ల data files మరియు log directory పరస్పరం సరిపోకపోవచ్చు. Recovery కి replay చేయడానికి సరైన data ఉండదు. fsync ను call చేయకుండా application రాసే ఏ file అయినా, ఉదాహరణకు పూర్తిగా అందని upload లేదా queue file, తిరిగి వచ్చినప్పుడు truncated అయి ఉండవచ్చు. Application memory లో ఉంచి timer ఆధారంగా flush చేసే data image లో ఉండదు.

కాబట్టి snapshot తీసుకునే ముందు disk కు dump రాయండి. అప్పుడు live data files ఏ స్థితిలో ఉన్నా, image లో అంతర్గతంగా consistent అని మీకు తెలిసిన ఒక file ఉంటుంది.

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 లేదా stopped server అవసరం. Dump పై నమ్మకం ఉంచే ముందు అది empty గా లేదని, truncated కాలేదని తనిఖీ చేయండి: complete 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 ఆ machine లోని ప్రతి write ను block చేస్తుంది. Unfreeze command టైప్ చేయడానికి మీరు ఉపయోగించే shell కూడా దీనిలో ఉంటుంది. అందువల్ల మీరే system నుంచి lock out అవుతారు. Hard reset కోసం వేచి ఉండాల్సి వస్తుంది.

ఆఫ్‌సైట్ భాగం: restic లేదా Borg

Snapshot వేగవంతమైన భాగం. Offsite copy అనేది మీ provider వైఫల్యాన్ని తట్టుకునే భాగం. restic సాధారణంగా మంచి ఎంపిక. ఇది 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 లోకి కాపీ చేయండి. ఆ password manager ఈ server లో ఉండకూడదు. passphrase లేకుండా restic repository ను తెరవలేరు. దాన్ని తిరిగి పొందడానికి recovery మార్గం లేదు. మీరు ఇప్పుడే కోల్పోయిన server లో మాత్రమే password యొక్క ఏకైక copy ఉంటే, 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 లభిస్తుంది. అప్పుడు repository location specified కాలేదని restic చూపిస్తుంది. restic snapshots మీరు ఇప్పుడే చేసిన run ను, దాని host మరియు paths తో చూపించాలి. నిర్ణీత schedule ప్రకారం repository ను కూడా verify చేయండి. 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 ఎలాంటి హెచ్చరిక ఇవ్వదు, ఎందుకంటే 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 కు భిన్నంగా ఉండాలి. ప్రస్తుత session కొనసాగుతుంది, ఎందుకంటే sshd ను restart చేయడం ద్వారా ఇప్పటికే ఏర్పడిన connections మూసివేయబడవు. ఎవరైనా క్లోన్‌కు connect అవ్వకముందే దీన్ని చేయండి. ఆలస్యం చేస్తే, వారసత్వంగా వచ్చిన key ను ఇప్పటికే నమ్మిన ప్రతి client కు WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! వస్తుంది, మరియు ముందుగా ssh-keygen -R <host> ను అమలు చేయాలి.

machine ID ను reset చేయండి. /etc/machine-id అనేది systemd మొదటి boot సమయంలో ఒకసారి రూపొందించే unique 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, తదుపరి boot సమయంలో systemd కొత్త value రూపొందించమని సూచిస్తుంది. అందుకే ఆ file ను delete చేయకుండా truncate చేస్తారు. అది duplicate గా ఉంటే రెండు సమస్యలు ఏర్పడతాయి. DHCP ద్వారా address పొందే images లో, systemd-networkd సాధారణంగా 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 ను పరిశీలించండి. వీటిలో ఎక్కువ భాగాన్ని ఇది కనుగొంటుంది:

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 అందించకపోతే rotate చేయకుండా revoke చేయండి. Live production API token ఉన్న staging box, patching మరింత బలహీనంగా ఉన్న production box లాంటిదే.

ఇప్పుడు రెండుసార్లు నడిచే jobs ను ఆపండి. ఒకే crontab తో నడిచే రెండు servers, అదే నిమిషంలో అదే external systems ను access చేస్తాయి.

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

restic సందర్భాన్ని ప్రత్యేకంగా వివరించాలి. ఇది కేవలం స్పష్టంగా విఫలమవడం కాదు; మీ retention ను కూడా పాడుచేస్తుంది. restic ప్రతి snapshot కు host name ను tag గా జతచేస్తుంది, మరియు restic forget --keep-daily 7 దాని policy ను ప్రతి host కు విడిగా వర్తింపజేస్తుంది. ఒకే host name తో report చేసే రెండు machines ను ఒకే host గా పరిగణిస్తారు. అందువల్ల ఏడు "daily" snapshots అన్నీ క్లోన్ నుంచి రావచ్చు, అదే సమయంలో అసలు సర్వర్ snapshots prune అయిపోవచ్చు. మొదటి backup run కు ముందే hostname ను సరిచేయండి, లేదా క్లోన్‌లో timer ను ఆపండి. certbot సందర్భం సరళమైనది: ఒకే names ను renew చేయడానికి రెండు servers certificate authority యొక్క duplicate certificate rate limit ను తాకుతాయి. ఎక్కువ certificates ఇప్పటికే ఆ exact names సమూహానికి issue అయ్యాయని error తో ఒక run విఫలమవుతుంది. క్లోన్ యొక్క domain ఇప్పటికీ అసలు సర్వర్ వైపు point చేస్తుంటే, అది HTTP challenge ను ఎలాగూ pass చేయలేదు. కాబట్టి అక్కడ renewal ను disable చేయండి.

monitoring agent ను నిర్వహించండి. చాలా agents hostname లేదా install సమయంలో రాసిన ID file ఆధారంగా identify అవుతాయి. అందువల్ల ఒకే host గా report చేసే రెండు agents తమ metrics ను ఒకే series లో కలిపేస్తాయి. అప్పుడు CPU graphs ఏ ఒక్క machine ఉత్పత్తి చేయని values ను చూపిస్తాయి, మరియు alerts మారుమోగుతాయి. క్లోన్‌లో agent ను stop చేసి remove చేయండి, లేదా vendor documentation లోని విధానాన్ని ఉపయోగించి కొత్త hostname కింద మళ్లీ enrol చేయండి.

అసలు సర్వర్ address కోసం network configuration ను పరిశీలించండి. image లో netplan ద్వారా static address ఉంటే, క్లోన్ మరొక machine కు చెందిన IP ను claim చేస్తుంది.

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

ఈ క్లోన్ template గా మారితే cloud-init state ను clear చేయండి.

sudo cloud-init clean --logs

ఇది /var/lib/cloud కింద ఉన్న cloud-init state ను తొలగిస్తుంది. అందువల్ల తదుపరి boot సమయంలో first-boot modules మళ్లీ నడుస్తాయి. వాటిలో SSH host keys లేనప్పుడు వాటిని రూపొందించే module కూడా ఉంటుంది. కొన్ని versions machine ID ను reset చేయడానికి flag ను కూడా అందిస్తాయి. ఇతర చోట్ల ఉన్న flag list ను నమ్మకుండా, మీ image ఏ flags కు support ఇస్తుందో చూడటానికి cloud-init clean --help ను అమలు చేయండి.

ఏ సందర్భంలో ఏదిని ఉపయోగించాలి

ప్రమాదకరమైన upgrade ను rollback చేయాలి: snapshot తీసుకోండి. మార్పు చేయడానికి కొన్ని నిమిషాల ముందు snapshot తీసుకోండి. Upgrade అమలు చేయండి. సమస్య వస్తే image ను restore చేయండి. Restore చేసినప్పుడు snapshot తర్వాత జరిగిన అన్ని writes తొలగిపోతాయి. అందువల్ల live traffic స్వీకరించే server లో ముందుగా database dump తీసుకోండి. మీరు కోల్పోయే data window ఎంత ఉంటుందో ఖచ్చితంగా తెలుసుకోండి. పది నిమిషాల పాటు offline చేయగలిగే box పై do-release-upgrade కోసం snapshot ఒక్కటే సరిపోతుంది.

పెద్ద plan కు migrate చేయాలి: clone ను deploy చేయండి. Snapshot నుంచి పెద్ద plan పై clone ను నిర్మించండి. పై identity జాబితాలోని అంశాలను ఒక్కొక్కటిగా పరిశీలించండి. Traffic ను మార్చే ముందు clone ను దాని స్వంత IP పై test చేయండి. Cutover త్వరగా పూర్తయ్యేలా ఒక రోజు ముందుగానే DNS TTL ను తగ్గించండి. కొత్త box నిజమైన traffic ను నిర్వహించే వరకు పాతదాన్ని నడుస్తూనే ఉంచండి. మీ workload కు పెద్ద plan వాస్తవంగా వేగంగా పనిచేస్తుందో ముందుగా నిర్ధారించండి. దీని కోసం రెండు serverలపై ఒకే benchmark పద్ధతిని ఉపయోగించండి. ఎందుకంటే ఎక్కువ busy hardware పై ఎక్కువ vCPUs ఉండటం ఎల్లప్పుడూ upgrade అని అర్థం కాదు.

Template నిర్మించాలి: శుభ్రం చేసిన machine యొక్క snapshot తీసుకోండి. ఒక server ను install చేసి harden చేయండి. తరువాత image తీసే ముందు దానికి ప్రత్యేకమైన ప్రతిదాన్ని తొలగించండి. Host keys ఉండకూడదు. Machine ID ఖాళీగా ఉండాలి. వ్యక్తిగత authorized_keys ఉండకూడదు. Credentials తొలగించాలి. cloud-init కూడా clean చేయాలి. ఆ తర్వాత snapshot తీసుకోండి. దాని నుంచి deploy చేసిన ప్రతి instance మొదటి boot సమయంలో తన స్వంత identity ను సృష్టిస్తుంది. అందువల్ల పై checklist ను ప్రతి సారి మళ్లీ అనుసరించాల్సిన అవసరం ఉండదు. దీనిని కొత్త VPS పై మొదటి పది నిమిషాల ప్రామాణిక విధానంతో కలిపి ఉపయోగించండి. అప్పుడు మీరు సాధారణంగా మళ్లీ చేయాల్సిన పని template లోనే ఉంటుంది.

FAQ

VPS snapshot ఒక backupనా?

కాదు. అది ఏర్పడిన server తోనే ఒకే failure domain ను పంచుకుంటుంది. Snapshot మీ provider storage లో, మీ account లో, సాధారణంగా అదే region లో ఉంటుంది. Account suspension, దొంగిలించబడిన API key లేదా పొరపాటున instance deletion వల్ల server మరియు దాని snapshots రెండూ ఒకే చర్యతో తొలగిపోవచ్చు. అనేక providers వద్ద instance ను తొలగించడం వల్ల దాని snapshots కూడా ఉద్దేశపూర్వకంగానే తొలగిపోతాయి. Snapshot మీ వద్ద ఉన్న అత్యంత వేగమైన rollback విధానం. కాబట్టి snapshots తీసుకుంటూ ఉండండి. అలాగే provider నియంత్రించని infrastructure పై రెండవ encrypted copy ఉంచండి.

Snapshot తీసుకునే ముందు database ను ఆపాలా?

ఎల్లప్పుడూ అవసరం లేదు. అయితే snapshot లో లభించే స్థితిని మీరు అంగీకరించాలి. Provider snapshot crash-consistent గా ఉంటుంది. అంటే power cut తర్వాత disk ఎలా కనిపిస్తుందో image కూడా అలాగే ఉంటుంది. PostgreSQL మరియు InnoDB ప్రారంభమైనప్పుడు ఆ స్థితి నుంచి recover అవుతాయి. PostgreSQL ఆ సమయంలో database system was not properly shut down; automatic recovery in progress logs లో నమోదు చేస్తుంది. వేర్వేరు సమయాల్లో snapshot తీసిన రెండు volumes మధ్య data విభజించబడి ఉంటే recovery కు హామీ ఉండదు. అలాగే application fsync లేకుండా రాస్తే కూడా recovery హామీ ఉండదు. ముందుగా pg_dumpall లేదా mysqldump --single-transaction ను disk పై రాయండి. అప్పుడు image లో consistency ఉన్నదని మీకు తెలిసిన ఒక file ఉంటుంది.

రెండు cloned servers ఒకే IP address కోసం ఎందుకు పోటీ పడతాయి?

అవి /etc/machine-id ను పంచుకోవడం వల్ల. DHCP ఉపయోగించే images లో systemd-networkd default గా machine ID ఆధారంగా DHCP client identifier ను రూపొందిస్తుంది. అందువల్ల రెండు clones ఒకే client గా lease కోరుతాయి. DHCP server రెండింటికీ ఒకే address ను అందిస్తుంది. /etc/machine-id ను zero bytes కు truncate చేయండి. /var/lib/dbus/machine-id ను తొలగించండి. దాన్ని తిరిగి /etc/machine-id కు symlink చేయండి. తరువాత 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 timers ను ఆపండి. ఆ job ను ఏ machine నిర్వహించాలో నిర్ణయించే వరకు వాటిని నిలిపి ఉంచండి.