VPS snapshot vs backup vs clone: Ano ang pagkakaiba?

Ano talaga ang snapshot, backup, at clone

Ang VPS snapshot ay disk image ng iyong server na nakaimbak ng provider sa infrastructure nito at nasa loob ng account mo. Ang backup ay hiwalay na kopya ng iyong data na maaari mong i-restore sa ibang lugar nang hindi umaasa sa provider na nag-iingat ng orihinal. Ang clone ay bagong instance na dine-deploy mula sa snapshot. Kaya nagsisimula ito bilang eksaktong kopya ng orihinal, kasama ang identity nito.

Magkakaiba ang problemang nilulutas ng mga ito. Maaaring ibalik ng snapshot ang isang sirang upgrade sa loob ng ilang minuto, pero wala itong magagawa kapag naisara ang account. Nakaliligtas ang backup kapag hindi na available ang provider, pero mas matagal itong i-restore dahil kailangan mo munang buuin muli ang machine. Nagbibigay ang clone ng pangalawang tumatakbong server sa isang hakbang, pero nagreresulta rin ito sa dalawang machine na naniniwalang iisang machine sila.

Bakit hindi backup ang VPS snapshot

Ang problema ay nasa failure domain, hindi sa kalidad ng image. Nasa storage platform ng provider ang snapshot, karaniwan sa parehong region ng server na pinagmulan nito, at palaging nasa parehong account. Isang insidente lang ay maaaring parehong maapektuhan ang server at ang snapshot nito.

• Masuspend ang account, mabigo ang payment, o manakaw ang login.
• Burahin ng isang tao o script na may API access ang instance. Sa maraming provider, kapag binura ang instance, kasama nitong nabubura ang mga snapshot nito. Basahin ang dokumentadong behavior ng provider bago ipagpalagay ang iba.
• Magkaroon ng problema ang region at sabay-sabay na hindi ma-access ang lahat ng nasa loob nito.
• Mahanap ng isang prosesong tumatakbo bilang root sa server ang provider API token na iniwan mo sa /root, at burahin ang mga snapshot bago galawin ang disk.

Ang backup ay ang kopyang nakakaligtas sa lahat ng apat na sitwasyon. Isang tanong ang pagsusuri: kung mawala ang provider account mo ngayong hapon, ano pa ang maaari mong i-restore, at saan mo ito ire-restore? Anumang hindi makasagot sa tanong na iyon ay rollback tool. Ipagpatuloy ang paggawa ng snapshots dahil wala nang mas mabilis i-restore. Pagkatapos, magtago ng pangalawang kopya sa storage na hindi kontrolado ng provider.

Nananatili ang dating tuntunin: tatlong kopya ng data, sa dalawang uri ng storage, at ang isa ay nasa labas ng platform. Sapat na rito ang provider snapshot kasama ang restic backup repository sa hiwalay na infrastructure; dalawang moving part lamang ang kailangan.

Bakit maaaring mag-restore ng sirang database ang snapshot ng tumatakbo nang database

Kinokopya ng provider snapshot ang block device ayon sa eksaktong kalagayan nito sa isang partikular na sandali. Hindi nito hinihiling sa mga application na huminto muna, at hindi nito nakikita ang anumang nasa page cache pa. Kaya crash-consistent lamang ang image sa pinakamainam na kalagayan. Eksaktong katulad ito ng magiging laman ng disk kung biglang pinutol ang power.

Nahahawakan ito ng karamihan sa stack. Nire-replay ng ext4 at XFS ang kanilang journal kapag nag-mount, kaya gumagana ang filesystem. Nire-replay ng PostgreSQL ang write-ahead log nito sa pagsisimula, at ganito ang nakasaad sa log:

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

Ganito rin ang ginagawa ng InnoDB at ipinapakita nito ang sarili nitong crash recovery lines habang nagsisimula. Ang recovery na ito ay normal na paggana ng database, kaya karaniwang maayos na nagre-restore ang snapshot ng iisang volume na ginagamit ng tahimik na PostgreSQL o MySQL.

May mga sitwasyon kung saan hindi sapat ang crash-consistent, at ito ang mga sitwasyong nagdudulot ng problema. Kung nasa dalawang volume ang data mo, na-snapshot ang root disk at hiwalay na data disk sa magkaibang sandali. Dahil dito, maaaring hindi magkatugma ang data files at ang log directory, at walang tamang mare-replay ang recovery. Maaaring bumalik na truncated ang anumang file na isinusulat ng application nang hindi tumatawag sa fsync, gaya ng kalahating natanggap na upload o queue file. Anumang hawak ng application sa memory at pana-panahong fina-flush ay wala sa image.

Kaya magsulat muna ng dump sa disk bago kunin ang snapshot. Sa ganitong paraan, may isang file sa image na alam mong internally consistent, anuman ang kalagayan ng 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

Nagbibigay ang --single-transaction ng consistent dump ng mga InnoDB table nang hindi bina-block ang mga writer, dahil tumatakbo ang dump sa loob ng isang repeatable-read transaction. Hindi nito saklaw ang MyISAM tables, na nangangailangan ng lock o nakahintong server. Suriing hindi empty at hindi truncated ang dump bago mo ito pagkatiwalaan: nagtatapos ang tail -n 1 /var/backups/mysql-$(date +%F).sql sa isang Dump completed comment kapag kumpleto ang mysqldump.

Kung mayroon kang hiwalay na data volume, maaari mo itong i-freeze sa loob ng ilang segundo na kailangan ng snapshot:

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

Data volume lamang ang i-freeze. Huwag kailanman i-freeze ang /. Kapag na-freeze ang root filesystem, bina-block nito ang lahat ng write sa server, pati ang shell na gagamitin mo para i-type ang unfreeze command. Dahil dito, mawawalan ka ng access at maghihintay para sa hard reset.

Ang offsite na bahagi: restic o Borg

Ang snapshot ang mabilis na bahagi. Ang offsite copy ang bahaging nakakaligtas kapag nagkaproblema ang provider mo. Magandang default ang restic dahil nagde-deduplicate ito, nag-e-encrypt sa client side, at nagsusulat sa S3-compatible object storage, SFTP, o plain directory. Mainam dito ang isang storage VPS bilang offsite target, dahil mas kailangan ng mga backup repository ang capacity kaysa 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

Kopyahin ngayon ang passphrase sa isang password manager, gamit ang device na hindi ang server na ito. Hindi mabubuksan ang restic repository kung wala ito, at walang recovery path. Kung ang tanging kopya ng password ay nasa box na kakawala mo lang, encrypted noise lamang ang backup.

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 ang nagtatago sa mga variable na iyon, dahil kung wala ito, malinis ang environment na matatanggap ng root at iuulat ng restic na walang tinukoy na repository location. Dapat ilista ng restic snapshots ang run na kakagawa mo lang, kasama ang host at mga path nito. Regular na i-verify ang repository mismo, at magbasa ng ilang data mula rito sa halip na ang structure lamang ang suriin:

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

Haka-haka lamang ang backup na hindi pa nasusubukan. Mag-restore kahit isang beses sa ibang VPS, sukatin ang tagal, at itala ito dahil ang numerong iyon ang tunay mong recovery target. Ang Borg ang isa pang matibay na pagpipilian at ini-store nito ang repository sa SSH sa halip na object storage; tinalakay ang mga trade-off sa paghahambing ng restic at BorgBackup.

Ano ang dapat ayusin bago ilapit sa production ang isang na-clone na VPS

Ang clone ay eksaktong kopya. Iyan ang pakinabang nito at siya ring problema. Nadodoble ang lahat ng nagpaiba sa orihinal, kaya nagkakaroon ng collision ang mga duplicate.

I-regenerate ang SSH host keys. Taglay ng clone ang mga file na /etc/ssh/ssh_host_* ng orihinal, kaya pareho ang host identity na ipinapakita ng dalawang server. Maaaring magpanggap ang sinumang kumokontrol sa isa bilang isa pa sa bawat client na tumanggap sa key na iyon. Walang warning na ibibigay ang SSH dahil ang key ang inaasahan ng client.

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

Gumagawa ang ssh-keygen -A ng bagong key para sa bawat uri na inaasahan ng daemon. Kailangang iba ang fingerprint mula sa huling command kumpara sa fingerprint ng orihinal. Magpapatuloy ang kasalukuyan mong session matapos ang restart dahil hindi isinasara ng pag-restart ng sshd ang mga kasalukuyang koneksyon. Gawin ito bago kumonekta ang sinuman sa clone. Kung ipagpapaliban mo ito, makakatanggap ang bawat client na dati nang nagtiwala sa minanang key ng WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! at kailangang patakbuhin muna ang ssh-keygen -R <host>.

I-reset ang machine ID. Ang /etc/machine-id ay isang natatanging identifier na isang beses lang ginagawa ng systemd sa unang boot, at minamana ito ng clone.

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

Sinasabi ng walang-lamang /etc/machine-id sa systemd na gumawa ng bagong value sa susunod na boot. Iyan ang dahilan kung bakit tina-truncate mo ang file sa halip na burahin ito. Dalawang bagay ang nasisira kapag duplicate ang value. Sa mga image na kumukuha ng address sa pamamagitan ng DHCP, ginagamit bilang default ng systemd-networkd ang machine ID para buuin ang DHCP client identifier. Dahil dito, humihingi ng lease ang dalawang clone bilang iisang client, kaya pareho ang address na ibinibigay ng server. Nilalagyan naman ng journald ang bawat entry ng machine ID, kaya inilalagay ng central log collector ang dalawang server sa ilalim ng iisang machine. Patakbuhin ang cat /etc/machine-id pagkatapos ng reboot at kumpirmahing nagbago ang value.

Palitan ang hostname.

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

Isinusulat ng hostnamectl ang /etc/hostname at agad na ina-apply ang pangalan. Hindi nito binabago ang /etc/hosts, kaya i-edit ang linyang 127.0.1.1 para tumugma rito. Kapag nilaktawan mo iyon, hindi mareresolba saanman ang bagong pangalan, kaya naghihintay ang bawat tawag na sudo sa nabigong lookup at nagpi-print ng sudo: unable to resolve host web-02: Name or service not known.

I-rotate ang bawat credential na nakabaon sa image. Taglay ng clone ang mga secret ng orihinal, kaya maaari nang kumilos ang dalawang machine bilang orihinal. Suriin ang mga SSH authorized_keys file, provider at DNS API token, application .env file, database password, TLS private key, monitoring enrollment token, at password ng restic repository. Karamihan sa mga ito ay matutukoy gamit ito:

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

Kung test copy ang clone at hindi ito kailanman magse-serve ng traffic, i-revoke ang credential sa halip na i-rotate ito. Ang staging box na may live production API token ay production box na mas mahina pa ang patching.

I-off ang mga job na dalawang beses nang tumatakbo. Kapag parehong crontab ang tumatakbo sa dalawang server, sabay nilang naa-access ang parehong external system sa parehong minuto.

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

Mahalagang ipaliwanag ang kaso ng restic dahil sinisira nito ang retention, hindi lamang basta nabibigo. Tinatatakan ng restic ang bawat snapshot gamit ang hostname, at ina-apply ng restic forget --keep-daily 7 ang policy nito batay sa host. Itinuturing na iisang host ang dalawang machine na nag-uulat gamit ang parehong hostname. Dahil dito, maaaring lahat ng pitong “daily” snapshot ay mula sa clone habang napu-prune ang mga snapshot ng orihinal. Ayusin ang hostname bago ang unang backup run, o ihinto ang timer sa clone. Mas simple ang kaso ng certbot: kapag nire-renew ng dalawang server ang parehong pangalan, natatamaan nila ang duplicate certificate rate limit ng certificate authority. Nabibigo ang isang run at naglalabas ng error tungkol sa sobrang dami ng certificate na na-issue na para sa eksaktong set ng mga pangalang iyon. Hindi rin makakapasa sa HTTP challenge ang clone kung nakaturo pa sa orihinal ang domain nito, kaya i-disable ang renewal doon.

Ayusin ang monitoring agent. Karamihan sa agent ay kumikilala gamit ang hostname o ID file na ginagawa sa oras ng installation. Dahil dito, nagsasama ang metrics ng dalawang agent sa iisang series kapag pareho ang host na iniuulat nila. Nagpapakita tuloy ang CPU graph ng mga value na hindi ginawa ng kahit isang machine, at nagfa-flap ang mga alert. Ihinto at alisin ang agent sa clone, o i-re-enrol ito gamit ang bagong hostname ayon sa dokumentadong procedure ng vendor.

Suriin ang network configuration para sa address ng orihinal. Kung may static address ang image sa netplan, aangkinin ng clone ang IP na pagmamay-ari ng ibang machine.

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

I-clear ang cloud-init state kung gagawin mong template ang clone.

sudo cloud-init clean --logs

Inaalis nito ang state ng cloud-init sa ilalim ng /var/lib/cloud, kaya tatakbuhin muli ng susunod na boot ang mga first-boot module. Kasama rito ang paggawa ng SSH host key kapag walang available na key. May mga version din na nag-aalok ng flag para i-reset ang machine ID. Patakbuhin ang cloud-init clean --help sa sarili mong image para makita kung ano ang sinusuportahan nito, sa halip na umasa sa listahan ng flag mula sa ibang source.

Kailan gagamit ng alin

Pagbabalik sa dating estado matapos ang mapanganib na upgrade: gumawa ng snapshot. Gawin ito ilang minuto bago ang pagbabago, patakbuhin ang upgrade, at i-restore ang image kung magkaroon ng problema. Binubura ng pag-restore ang lahat ng write mula nang gawin ang snapshot. Kaya kung tumatanggap ng live traffic ang server, mag-dump muna ng database at tukuyin nang eksakto kung anong window ang mawawala. Para sa isang do-release-upgrade sa machine na maaari mong i-offline nang sampung minuto, sapat na ang snapshot bilang buong plano.

Paglipat sa mas malaking plan: mag-deploy ng clone. Gawin ang clone mula sa snapshot papunta sa mas malaking plan, sundin ang identity list sa itaas, at subukan ito sa sarili nitong IP bago ilipat ang anumang traffic. Ibaba ang DNS TTL isang araw bago ang paglipat para mabilis ang cutover, at panatilihing tumatakbo ang orihinal hanggang makatanggap ng totoong traffic ang bagong machine. Tiyaking mas mabilis nga ang mas malaking plan para sa workload mo. Gamitin ang parehong benchmark method sa dalawang server, dahil hindi palaging upgrade ang mas maraming vCPU sa mas abalang hardware.

Pagbuo ng template: gumawa ng snapshot ng nilinis na machine. Mag-install at mag-harden ng isang server, pagkatapos ay alisin ang lahat ng natatangi rito bago gawin ang image. Walang host keys, walang laman ang machine ID, walang personal na authorized_keys, walang credentials, at nalinis ang cloud-init. I-snapshot ito. Bawat instance na ide-deploy mula rito ay gagawa ng sarili nitong identity sa unang boot. Dahil dito, hindi na kailangang ulitin ang checklist sa itaas. Ipares ito sa standard na unang sampung minuto sa bagong VPS para nasa template na ang mga gawaing karaniwan mong inuulit.

FAQ

Ang snapshot ba ng VPS ay backup?

Hindi, dahil nasa iisang failure domain ito kasama ng server na pinagmulan nito. Nasa storage ng provider ang snapshot, sa account mo, at karaniwan ay nasa parehong region. Maaaring matanggal ang server at ang mga snapshot nito sa isang aksyon lamang dahil sa pagsususpinde ng account, ninakaw na API key, o aksidenteng pag-delete ng instance. Sa maraming provider, awtomatikong nabubura ang mga snapshot kapag dinelete ang instance. Ang snapshot ang pinakamabilis mong rollback, kaya patuloy kang gumawa nito. Magtabi rin ng pangalawang encrypted copy sa infrastructure na hindi kontrolado ng provider mo.

Kailangan ko bang ihinto ang database bago gumawa ng snapshot?

Hindi palagi, pero kailangan mong tanggapin ang magiging resulta. Crash-consistent ang snapshot ng provider. Ibig sabihin, tumutugma ang image sa magiging kalagayan ng disk matapos mawalan ng kuryente. Nakaka-recover dito ang PostgreSQL at InnoDB kapag nagsimula ang mga ito, at nagla-log ang PostgreSQL ng database system was not properly shut down; automatic recovery in progress habang ginagawa iyon. Hindi garantisado ang recovery kapag nasa dalawang volume ang data mo na na-snapshot sa magkaibang oras, o kapag nagsusulat ang application nang walang fsync. Sumulat muna ng pg_dumpall o mysqldump --single-transaction sa disk para maglaman ang image ng isang file na alam mong consistent.

Bakit nagkakaroon ng conflict sa parehong IP address ang dalawang cloned server?

Dahil pareho silang gumagamit ng /etc/machine-id. Sa mga image na gumagamit ng DHCP, binubuo ng systemd-networkd ang DHCP client identifier nito mula sa machine ID bilang default. Dahil dito, humihingi ng lease ang dalawang clone bilang iisang client, kaya parehong address ang iniaalok ng DHCP server sa mga ito. I-truncate ang /etc/machine-id sa zero bytes, alisin ang /var/lib/dbus/machine-id, i-symlink itong muli sa /etc/machine-id, at mag-reboot para makabuo ang systemd ng bagong value. Ang isa pang karaniwang sanhi ay ang static address na nakasulat sa /etc/netplan/ at eksaktong nakopya ng clone. Suriin gamit ang ip -br addr.

Ano ang pinakamabilis na paraan para tiyaking ligtas ilagay sa production ang isang clone?

Ihambing ang apat na bagay nito sa original. Patakbuhin ang ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub sa parehong server at tiyaking magkaiba ang mga fingerprint. Patakbuhin ang cat /etc/machine-id sa parehong server at tiyaking magkaiba ang mga value. Patakbuhin ang hostnamectl status at tiyaking bago ang pangalan at nagre-resolve ito, para hindi magbabala ang sudo. Pagkatapos, patakbuhin ang systemctl list-timers --all at ihinto ang bawat timer na kumokonekta sa isang shared system, gaya ng backups, certificate renewal, o monitoring agent, hanggang sa mapagpasyahan mo kung aling machine ang gagawa ng trabahong iyon.