Tofauti kati ya VPS snapshot, backup, na clone

Snapshot, backup, na clone ni nini hasa

VPS snapshot ni picha ya diski ya seva yako, inayohifadhiwa na mtoa huduma wako, kwenye miundombinu ya mtoa huduma huyo, ndani ya akaunti yako. Backup ni nakala huru ya data yako ambayo unaweza kuirejesha mahali pengine, bila msaada kutoka kwa mtoa huduma aliyeshikilia nakala asilia. Clone ni instance mpya inayotumwa kutoka kwenye snapshot, hivyo huanza kama nakala kamili ya ile asilia, ikijumuisha utambulisho wake.

Hizi hutatua matatizo tofauti. Snapshot hurudisha nyuma upgrade iliyoharibika ndani ya dakika chache, na haisaidii chochote ikiwa akaunti imefungwa. Backup hupona hata kama mtoa huduma ataacha kutoa huduma, na huchukua muda mrefu zaidi kurejesha kwa sababu unajenga upya mashine kwanza. Clone hukupa seva ya pili inayofanya kazi kwa hatua moja, na pia hukupa mashine mbili zinazoamini kuwa ni mashine moja.

Kwa nini snapshot ya VPS si chelezo (backup)

Tatizo ni upeo wa hitilafu (failure domain), si ubora wa picha ya diski. Snapshot hukaa kwenye mfumo wa hifadhi wa mtoa huduma wako, kwa kawaida katika eneo moja na seva iliyotoka, na daima ndani ya akaunti hiyo hiyo. Tukio moja linaweza kufuta seva na snapshot yake kwa pamoja.

• Akaunti inafungiwa, malipo yanashindikana, au mtu anaiba taarifa za kuingia.
• Mtu au script yenye uwezo wa kutumia API inafuta instance. Kwa watoa huduma wengi, kufuta instance hufuta na snapshot zake. Soma nyaraka za mtoa huduma wako kuhusu tabia hii kabla ya kudhani vinginevyo.
• Eneo (region) linapata hitilafu na kila kitu ndani yake kinakuwa hakipatikani kwa wakati mmoja.
• Kitu kinachoendeshwa kama root kwenye seva kinapata token ya API ya mtoa huduma uliyoiacha ndani ya /root, na kufuta snapshot kabla ya kugusa diski.

Chelezo ni nakala inayookoka matatizo hayo yote manne. Jaribio ni swali moja: kama akaunti yako ya mtoa huduma ingekoma kuwepo mchana huu, ni nini ungeweza kurejesha, na ungekirejesha wapi? Kitu chochote kinachoshindwa swali hilo ni zana ya kurudisha hali ya awali (rollback tool). Endelea kuchukua snapshot, kwa sababu hakuna kinachorejesha data haraka zaidi. Kisha weka nakala ya pili kwenye hifadhi ambayo mtoa huduma wako haidhibiti.

Kanuni ya zamani bado inafanya kazi: nakala tatu za data, kwenye aina mbili za hifadhi, moja ikiwa nje ya jukwaa hilo. Snapshot ya mtoa huduma pamoja na restic backup repository kwenye miundombinu tofauti inatimiza hilo kwa kutumia sehemu mbili tofauti.

Kwa nini snapshot ya database inayofanya kazi inaweza kurejesha data iliyoharibika

Snapshot ya mtoa huduma hunakili block device kama ilivyo katika muda huo. Haiwaambii programu zako kusimama kwanza, na haiwezi kuona chochote kilichobaki kwenye page cache. Kwa hiyo, picha hiyo ni crash-consistent kwa bora zaidi. Inaonekana kama diski inavyoonekana mtu akichomoa kebo ya umeme.

Sehemu kubwa ya stack hushughulikia hilo. ext4 na XFS hucheza tena journal yao wakati wa mount, kwa hivyo filesystem inafanya kazi. PostgreSQL hucheza tena write-ahead log yake wakati wa kuanza, na log hiyo inasema hivyo:

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

InnoDB hufanya vivyo hivyo na kuchapisha mistari yake ya crash recovery wakati wa startup. Urejeshaji huo ni database inayofanya kazi kama ilivyokusudiwa, kwa hivyo snapshot ya volume moja ya PostgreSQL au MySQL iliyo tulivu kwa kawaida hurejesha data vizuri.

Kesi ambazo crash-consistent haitoshi ni za kweli, na ndizo zinazoleta madhara. Ikiwa data yako inasambaa kwenye volume mbili, root disk na data disk tofauti hupigwa snapshot kwa nyakati tofauti, kwa hivyo faili za data na saraka ya log zinaweza kutofautiana na urejeshaji hauna kitu sahihi cha kucheza tena. Faili yoyote ambayo programu huandika bila kuita fsync, kama vile upload iliyopokelewa nusu au faili ya queue, inaweza kurudi ikiwa imekatwa. Chochote ambacho programu inashikilia kwenye kumbukumbu na kukitoa kwa timer hakipo kwenye picha hiyo.

Kwa hivyo andika dump kwenye diski kabla ya kuchukua snapshot. Kisha picha hiyo itakuwa na faili moja unayojua kuwa ina uthabiti wa ndani, bila kujali hali ya faili za data zilizo hai.

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 hutoa dump thabiti ya meza za InnoDB bila kuzuia waandishi, kwa sababu dump hiyo inaendeshwa ndani ya transaction moja ya repeatable-read. Haishughulikii meza za MyISAM, ambazo zinahitaji lock au seva iliyosimamishwa. Hakikisha dump si tupu na haijakatwa kabla ya kuiamini: tail -n 1 /var/backups/mysql-$(date +%F).sql kwenye mysqldump kamili huishia na maoni ya Dump completed.

Ikiwa una volume tofauti ya data, unaweza kuigandisha (freeze) kwa sekunde ambazo snapshot inahitaji:

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

Gandisha volume ya data pekee. Usigandishe kamwe /. Root filesystem iliyogandishwa huzuia kila uandishi kwenye seva, ikijumuisha shell unayoweza kutumia kuandika amri ya unfreeze, kwa hivyo utajifungia nje na kusubiri hard reset.

Nusu ya nje ya tovuti: restic au Borg

Snapshot ndiyo nusu ya haraka. Nakala ya nje ya tovuti ndiyo nusu inayookoka iwapo mtoa huduma wako atapata matatizo. restic ni chaguo zuri la msingi kwa sababu hufanya deduplication, husimba data kwa njia fiche (encryption) kwenye upande wa mteja, na huandika kwenye hifadhi ya vitu (object storage) inayooana na S3, SFTP, au saraka ya kawaida. storage VPS kama lengo la nje ya tovuti hufanya kazi vizuri hapa, kwa sababu hazina za chelezo (backup repositories) huhitaji uwezo mkubwa wa kuhifadhi badala ya IOPS.

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

Nakili nenosiri hilo kwenye kidhibiti cha nywila sasa hivi, kwenye kifaa ambacho si seva hii. Hazina ya restic haiwezi kufunguliwa bila nenosiri hilo na hakuna njia ya kurejesha data. Ikiwa nakala pekee ya nenosiri ilikuwa kwenye seva uliyopoteza, chelezo hiyo itakuwa ni data iliyosimbwa isiyoweza kusomeka.

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 huhifadhi vigezo hivyo, kwa sababu bila hivyo root hupata mazingira safi na restic huripoti kuwa hakuna eneo la hazina lililobainishwa. restic snapshots inapaswa kuorodhesha utekelezaji ulioufanya sasa hivi, pamoja na mwenyeji (host) na njia zake. Hakiki hazina yenyewe kulingana na ratiba, na usome baadhi ya data badala ya kukagua muundo pekee:

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

Chelezo ambayo haijajaribiwa ni kubahatisha. Rejesha data kwenye VPS tofauti angalau mara moja, pima muda unaotumika, na uandike muda huo, kwa sababu namba hiyo ndiyo lengo lako halisi la urejeshaji. Borg ni chaguo jingine thabiti na huhifadhi hazina yake kupitia SSH badala ya object storage; tofauti zake zimefafanuliwa katika ulinganisho wa restic na BorgBackup.

Mambo ya kurekebisha kabla ya VPS iliyonakiliwa kuanza kutumika

Nakala ni mfano halisi wa seva asilia. Hiyo ndiyo faida yake, lakini pia ndiyo tatizo lake. Kila kitu kilichofanya seva asilia kuwa ya kipekee kimenakiliwa, na nakala hizi zitagongana.

Tengeneza upya funguo za SSH (SSH host keys). Nakala hiyo inabeba faili za /etc/ssh/ssh_host_* za seva asilia, kwa hivyo seva mbili zinajitambulisha kwa utambulisho mmoja. Mtu yeyote anayeweza kudhibiti seva moja anaweza kujifanya ni seva nyingine kwa mteja yeyote aliyekubali ufunguo huo, na SSH haitoi onyo lolote, kwa sababu ufunguo huo ndio mteja aliotarajia.

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 huandika ufunguo mpya wa kila aina inayotarajiwa na daemon. Fingerprint kutoka kwa amri ya mwisho lazima itofautiane na ile ya seva asilia. Kikao chako cha sasa hakitakatika baada ya kuanzisha upya, kwa sababu kuanzisha upya sshd hakufungi miunganisho iliyopo. Fanya hivi kabla ya mtu yeyote kuunganisha kwenye nakala hiyo. Ukichelewa, kila mteja aliyekuwa ameuamini ufunguo uliorithiwa atapata WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! na atalazimika kutumia ssh-keygen -R <host> kwanza.

Weka upya kitambulisho cha mashine (machine ID). /etc/machine-id ni kitambulisho cha kipekee ambacho systemd hutengeneza mara moja, wakati wa boot ya kwanza, na nakala hiyo hurithi kitambulisho hicho.

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

Faili tupu ya /etc/machine-id huambia systemd itengeneze thamani mpya wakati wa boot inayofuata, ndiyo maana unafuta yaliyomo kwenye faili badala ya kuifuta faili yenyewe. Vitu viwili huharibika wakati kitambulisho hiki kimenakiliwa. Kwenye picha (images) zinazochukua anwani zao kupitia DHCP, systemd-networkd hupata kitambulisho chake cha mteja wa DHCP kutoka kwa machine ID kwa chaguo-msingi, kwa hivyo nakala zote mbili huomba anwani kama mteja yuleyule na seva huwapa anwani moja. Pia, journald huweka mhuri kwenye kila ingizo na machine ID, kwa hivyo mkusanyaji wa logi za kati huweka seva zote mbili chini ya mashine moja. Tekeleza cat /etc/machine-id baada ya kuanzisha upya na uthibitishe kuwa thamani imebadilika.

Badilisha hostname.

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

hostnamectl huandika /etc/hostname na kutumia jina hilo mara moja. Haigusi /etc/hosts, kwa hivyo hariri mstari wa 127.0.1.1 ili uendane na jina jipya. Ukiruka hatua hiyo, jina jipya halitatafsiriwa popote, kwa hivyo kila wito wa sudo utasubiri utafutaji ulioshindwa na kuchapisha sudo: unable to resolve host web-02: Name or service not known.

Badilisha kila kitambulisho (credential) kilichomo ndani ya picha hiyo. Nakala hiyo inashikilia siri za seva asilia, na sasa mashine mbili zinaweza kutenda kama seva asilia. Pitia faili za authorized_keys za SSH, tokeni za API za mtoa huduma na DNS, faili za .env za programu, nywila za database, funguo za siri za TLS, tokeni za kujiunga na ufuatiliaji, na nywila ya hifadhi ya restic. Hii itapata nyingi kati ya hizo:

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

Ikiwa nakala hiyo ni nakala ya majaribio ambayo haitatumika kuhudumia trafiki, batilisha badala ya kubadilisha. Sanduku la majaribio (staging box) linaloshikilia tokeni ya API ya uzalishaji ni sanduku la uzalishaji lenye ulinzi mbaya zaidi.

Zima kazi zinazoendeshwa mara mbili. Seva mbili zinazoendesha crontab ileile hupiga mifumo ileile ya nje kwa dakika ileile.

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

Kisa cha restic kinastahili ufafanuzi, kwa sababu huharibu uhifadhi wako badala ya kushindwa tu kwa kelele. restic huweka lebo kwenye kila snapshot na jina la mwenyeji (host name), na restic forget --keep-daily 7 hutumia sera yake kwa kila mwenyeji. Mashine mbili zinazoripoti jina lilelile la mwenyeji huchukuliwa kama mashine moja, kwa hivyo snapshot saba za "kila siku" zinaweza zote kutoka kwenye nakala hiyo wakati snapshot za seva asilia zikifutwa. Rekebisha hostname kabla ya uendeshaji wa kwanza wa backup, au simamisha kipima muda (timer) kwenye nakala hiyo. Kisa cha certbot ni rahisi zaidi: seva mbili zinazohuisha majina yale yale hupiga kikomo cha cheti cha mamlaka ya cheti (certificate authority), na uendeshaji unaoshindwa hutoa kosa kuhusu vyeti vingi vilivyotolewa kwa seti ileile ya majina. Nakala ambayo kikoa chake bado kinaelekeza kwenye seva asilia haiwezi kupita changamoto ya HTTP hata hivyo, kwa hivyo zima uhuishaji hapo.

Shughulikia wakala wa ufuatiliaji (monitoring agent). Mawakala wengi hutambua kwa hostname au kwa faili ya kitambulisho iliyoandikwa wakati wa usakinishaji, kwa hivyo mawakala wawili wanaoripoti kama mwenyeji mmoja huchanganya vipimo vyao kwenye mfululizo mmoja. Grafu za CPU kisha huonyesha thamani ambazo hakuna mashine moja iliyozalisha, na tahadhari (alerts) huanza kuruka hovyo. Simamisha na uondoe wakala kwenye nakala hiyo, au mwandikishe upya chini ya hostname mpya kwa kutumia utaratibu uliowekwa na muuzaji wako.

Angalia usanidi wa mtandao kwa anwani ya seva asilia. Ikiwa picha hiyo inabeba anwani tuli (static address) katika netplan, nakala hiyo inadai IP ambayo ni ya mashine nyingine.

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

Futa hali ya cloud-init ikiwa nakala hii inakuwa kiolezo (template).

sudo cloud-init clean --logs

Hiyo huondoa hali ya cloud-init chini ya /var/lib/cloud, kwa hivyo boot inayofuata huendesha moduli za boot ya kwanza tena, ambayo inajumuisha kutengeneza funguo za SSH wakati hakuna zilizopo. Matoleo mengine pia hutoa bendera (flag) ya kuweka upya machine ID. Tekeleza cloud-init clean --help kwenye picha yako mwenyewe ili kuona kile ambacho mfumo wako unasaidia badala ya kuamini orodha ya bendera kutoka kwingine.

Wakati wa kutumia njia ipi

Kurejesha toleo la awali baada ya upgrade hatari: chukua snapshot. Chukua snapshot dakika chache kabla ya kufanya mabadiliko, fanya upgrade, na urejeshe picha hiyo ikiwa mambo yataenda vibaya. Kurejesha snapshot hufuta kila data iliyoandikwa tangu snapshot ichukuliwe, kwa hivyo kwenye seva inayohudumia traffic ya moja kwa moja, hifadhi database kwanza na ujue vyema muda wa data utakaopoteza. Kwa do-release-upgrade kwenye seva unayoweza kuizima kwa dakika kumi, snapshot ndiyo mpango mzima.

Kuhama kwenda kwenye plan kubwa zaidi: tumia clone. Jenga clone kutoka kwenye snapshot kwenda kwenye plan kubwa, kamilisha orodha ya utambulisho hapo juu, kisha ifanyie majaribio kwenye IP yake yenyewe kabla ya kuhamisha traffic yoyote. Punguza DNS TTL siku moja kabla ili uhamisho uwe wa haraka, na uache seva ya asili ikiendelea kufanya kazi hadi seva mpya itakapoweza kuhimili traffic halisi. Thibitisha kwanza kama plan kubwa ni ya haraka zaidi kwa kazi yako, kwa kutumia njia ile ile ya benchmark kwenye seva zote mbili, kwa sababu vCPU nyingi kwenye hardware yenye shughuli nyingi si mara zote ni upgrade.

Kutengeneza template: chukua snapshot ya mashine iliyosafishwa. Sakinisha na kuimarisha seva moja, kisha ondoa kila kitu cha kipekee kabla ya kuichukulia picha (image). Hakuna host keys, machine ID tupu, hakuna authorized_keys ya kibinafsi, hakuna credentials, na cloud-init iliyosafishwa. Chukua snapshot ya hali hiyo. Kila instance inayotumwa kutoka kwenye template hiyo hutengeneza utambulisho wake yenyewe wakati wa boot ya kwanza, hivyo orodha ya ukaguzi hapo juu haihitajiki tena. Iunganishe na dakika kumi za kwanza za kawaida kwenye VPS mpya ili template iwe tayari ina kazi ambayo ungeirudia kila mara.

FAQ

Je, snapshot ya VPS ni backup?

Hapana, kwa sababu inashiriki kikoa kimoja cha hitilafu (failure domain) na seva iliyotoka. Snapshot hukaa kwenye hifadhi ya mtoa huduma wako, ndani ya akaunti yako, na kwa kawaida katika eneo moja la kijiografia. Kusimamishwa kwa akaunti, kuibiwa kwa API key, au kufutwa kwa seva kimakosa kunaweza kuondoa seva na snapshot zake kwa wakati mmoja, na kwa watoa huduma wengi, kufuta instance hufuta snapshot zake pia. Snapshot ndiyo njia ya haraka zaidi ya kurudisha hali ya awali, kwa hivyo endelea kuzichukua, na uweke nakala ya pili iliyosimbwa (encrypted) kwenye miundombinu ambayo mtoa huduma wako haidhibiti.

Je, ninahitaji kusimamisha database yangu kabla ya kuchukua snapshot?

Si lazima kila wakati, lakini lazima ukubali matokeo yake. Snapshot ya mtoa huduma ni crash-consistent, ikimaanisha kuwa picha hiyo inafanana na hali ya diski baada ya kukatika kwa umeme. PostgreSQL na InnoDB hujirekebisha kutoka hali hiyo wakati wa kuanza, na PostgreSQL huandika database system was not properly shut down; automatic recovery in progress wakati ikifanya hivyo. Urejeshaji hauhakikishiwi wakati data yako inasambaa kwenye volumes mbili zilizopigwa snapshot kwa nyakati tofauti, au wakati programu inaandika bila fsync. Andika pg_dumpall au mysqldump --single-transaction kwenye diski kwanza, ili picha iwe na faili moja unayojua kuwa ni sahihi.

Kwa nini seva mbili zilizopigwa clone hugombania anwani moja ya IP?

Kwa sababu zinashiriki /etc/machine-id. Kwenye picha zinazotumia DHCP, systemd-networkd hutengeneza DHCP client identifier kutoka kwa machine ID kwa chaguo-msingi, kwa hivyo clones zote mbili huomba lease kama mteja yuleyule na seva ya DHCP huwapa zote anwani ileile. Futa yaliyomo kwenye /etc/machine-id ili iwe na baiti sifuri, ondoa /var/lib/dbus/machine-id, tengeneza symlink kurudi kwenye /etc/machine-id, na uwashe upya seva ili systemd itengeneze thamani mpya. Sababu nyingine ya kawaida ni anwani tuli (static address) iliyoandikwa kwenye /etc/netplan/, ambayo clone ilinakili kama ilivyo; kagua kwa kutumia ip -br addr.

Njia ya haraka zaidi ya kuhakikisha clone iko salama kutumika kwenye production ni ipi?

Linganisha mambo manne dhidi ya seva ya asili. Endesha ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub kwenye zote mbili na uhakikishe kuwa fingerprints ni tofauti. Endesha cat /etc/machine-id kwenye zote mbili na uhakikishe kuwa thamani ni tofauti. Endesha hostnamectl status na uhakikishe kuwa jina ni jipya na linatatuliwa (resolves), ili sudo isitoe onyo. Kisha endesha systemctl list-timers --all na usimamishe kila timer inayowasiliana na mfumo ulioshirikiwa, kama vile backups, usasishaji wa cheti, au wakala wa ufuatiliaji (monitoring agent), hadi uamue ni mashine ipi inayomiliki kazi hiyo.