Perbezaan Snapshot, Backup dan Klon VPS

Apakah sebenarnya snapshot, sandaran (backup), dan klon

Snapshot VPS ialah imej cakera pelayan anda yang disimpan oleh penyedia anda, pada infrastruktur penyedia tersebut, di dalam akaun anda. Sandaran ialah salinan data anda yang bebas yang boleh anda pulihkan di tempat lain, tanpa bantuan daripada penyedia yang menyimpan data asal. Klon ialah instans baharu yang digunakan daripada snapshot, jadi ia bermula sebagai salinan tepat bagi yang asal, termasuk identitinya.

Ia menyelesaikan masalah yang berbeza. Snapshot memulihkan naik taraf yang rosak dalam beberapa minit, dan ia tidak berguna jika akaun anda ditutup. Sandaran akan kekal selamat jika penyedia perkhidmatan berhenti beroperasi, dan ia mengambil masa yang lebih lama untuk dipulihkan kerana anda perlu membina semula mesin tersebut terlebih dahulu. Klon memberikan anda pelayan kedua yang sedang berjalan dalam satu langkah, dan ia juga memberikan anda dua mesin yang menganggap diri mereka sebagai mesin yang sama.

Mengapa snapshot VPS bukan sandaran (backup)

Masalahnya terletak pada domain kegagalan, bukan kualiti imej tersebut. Snapshot disimpan pada platform storan pembekal anda, biasanya di rantau yang sama dengan pelayan asalnya, dan sentiasa di dalam akaun yang sama. Satu kejadian boleh melumpuhkan pelayan dan snapshotnya serentak.

• Akaun digantung, pembayaran gagal, atau seseorang mencuri maklumat log masuk.
• Seseorang atau skrip dengan akses API memadamkan instans tersebut. Pada kebanyakan pembekal, memadamkan instans akan memadamkan snapshotnya sekali. Baca dokumentasi tingkah laku pembekal anda sebelum membuat andaian sebaliknya.
• Rantau tersebut mengalami masalah teknikal dan segala-galanya di dalamnya tidak boleh dicapai secara serentak.
• Sesuatu yang berjalan sebagai root pada pelayan menemui token API pembekal yang anda tinggalkan dalam /root, lalu memadamkan snapshot tersebut sebelum ia menyentuh cakera.

Sandaran ialah salinan yang terselamat daripada keempat-empat situasi tersebut. Ujiannya hanya satu soalan: jika akaun pembekal anda tidak lagi wujud petang ini, apakah yang masih boleh anda pulihkan, dan di manakah anda akan memulihkannya? Apa-apa sahaja yang gagal dalam soalan itu hanyalah alat untuk membuat rollback. Teruskan mengambil snapshot, kerana tiada apa yang boleh dipulihkan dengan lebih pantas. Kemudian, simpan salinan kedua pada storan yang tidak dikawal oleh pembekal anda.

Peraturan lama masih terpakai: tiga salinan data, pada dua jenis storan, salah satunya di luar platform. Snapshot pembekal ditambah dengan repositori sandaran restic pada infrastruktur berasingan merangkumi keperluan tersebut dengan dua komponen yang berbeza.

Mengapa snapshot pangkalan data yang sedang berjalan boleh gagal dipulihkan

Snapshot pembekal menyalin peranti blok pada satu ketika. Ia tidak meminta aplikasi anda berhenti terlebih dahulu, dan ia tidak dapat melihat apa-apa yang masih berada dalam cache halaman. Jadi, imej tersebut paling baik hanyalah konsisten sekiranya berlaku kerosakan (crash-consistent). Ia kelihatan tepat seperti keadaan cakera jika seseorang mencabut kabel kuasa.

Kebanyakan tindanan (stack) mengendalikan perkara itu. ext4 dan XFS memainkan semula jurnal mereka semasa mount, jadi sistem fail akan naik. PostgreSQL memainkan semula log tulis-dahulu (write-ahead log) semasa permulaan, dan log tersebut menyatakan perkara itu:

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

InnoDB melakukan perkara yang sama dan mencetak baris pemulihan kerosakan sendiri semasa permulaan. Pemulihan itu adalah pangkalan data yang berfungsi seperti yang direka, jadi snapshot satu volum bagi PostgreSQL atau MySQL yang tidak sibuk biasanya boleh dipulihkan dengan baik.

Kes di mana crash-consistent tidak mencukupi adalah benar, dan ia adalah kes yang mendatangkan masalah. Jika data anda merangkumi dua volum, cakera root dan cakera data berasingan disnapshotted pada saat yang berbeza, jadi fail data dan direktori log boleh menjadi tidak selari dan pemulihan tidak mempunyai apa-apa yang betul untuk dimainkan semula. Mana-mana fail yang ditulis oleh aplikasi tanpa memanggil fsync, seperti muat naik yang separuh diterima atau fail baris gilir, boleh kembali dalam keadaan terpotong (truncated). Apa-apa sahaja yang disimpan oleh aplikasi dalam memori dan dibilas (flush) mengikut pemasa tidak akan ada dalam imej tersebut.

Oleh itu, tulis dump ke cakera sebelum anda mengambil snapshot. Kemudian imej tersebut mengandungi satu fail yang anda tahu konsisten secara dalaman, walau apa pun keadaan fail data langsung tersebut.

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 memberikan dump jadual InnoDB yang konsisten tanpa menyekat penulis, kerana dump berjalan di dalam satu transaksi repeatable-read. Ia tidak meliputi jadual MyISAM, yang memerlukan kunci atau pelayan yang dihentikan. Pastikan dump tidak kosong dan tidak terpotong sebelum anda mempercayainya: tail -n 1 /var/backups/mysql-$(date +%F).sql pada mysqldump yang lengkap berakhir dengan komen Dump completed.

Jika anda mempunyai volum data yang berasingan, anda boleh membekukannya (freeze) untuk beberapa saat yang diperlukan oleh snapshot:

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

Bekukan volum data sahaja. Jangan sekali-kali membekukan /. Sistem fail root yang dibekukan akan menyekat setiap penulisan pada kotak tersebut, termasuk shell yang anda gunakan untuk menaip arahan nyahbeku (unfreeze), jadi anda akan terkunci keluar dan terpaksa menunggu tetapan semula keras (hard reset).

Bahagian luar tapak: restic atau Borg

Snapshot ialah bahagian yang pantas. Salinan luar tapak ialah bahagian yang akan terselamat daripada penyedia anda. restic merupakan pilihan lalai yang baik kerana ia melakukan penyahduplikasian, penyulitan pada bahagian klien, dan menulis ke storan objek yang serasi dengan S3, SFTP, atau direktori biasa. Sebuah VPS storan sebagai sasaran luar tapak berfungsi dengan baik di sini, kerana repositori sandaran lebih memerlukan kapasiti berbanding 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

Salin frasa laluan tersebut ke dalam pengurus kata laluan sekarang, pada peranti yang bukan pelayan ini. Repositori restic tidak boleh dibuka tanpanya dan tiada laluan pemulihan. Jika satu-satunya salinan kata laluan tersebut berada pada kotak yang baru sahaja anda hilang, sandaran tersebut hanyalah data yang disulitkan tanpa makna.

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 mengekalkan pemboleh ubah tersebut, kerana tanpanya root akan mendapat persekitaran yang bersih dan restic akan melaporkan bahawa tiada lokasi repositori dinyatakan. restic snapshots sepatutnya menyenaraikan larian yang baru sahaja anda buat, berserta hos dan laluannya. Sahkan repositori itu sendiri mengikut jadual, dan baca semula sebahagian data tersebut dan bukannya sekadar memeriksa strukturnya:

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

Sandaran yang tidak diuji hanyalah satu andaian. Lakukan pemulihan ke VPS yang berbeza sekurang-kurangnya sekali, catatkan masanya, dan tuliskan masa tersebut, kerana angka itulah sasaran pemulihan sebenar anda. Borg ialah satu lagi pilihan yang mantap dan menyimpan repositorinya melalui SSH dan bukannya storan objek; pertukaran antara kedua-duanya dibincangkan dalam perbandingan restic dan BorgBackup.

Perkara yang perlu dibetulkan sebelum VPS klon digunakan dalam pengeluaran

Klon ialah replika yang tepat. Itulah kelebihan dan juga masalahnya. Segala perkara yang menjadikan pelayan asal unik telah diduplikasi, dan duplikat akan bertembung.

Jana semula kunci hos SSH. Klon membawa fail /etc/ssh/ssh_host_* milik asal, jadi dua pelayan akan membentangkan identiti hos yang sama. Sesiapa yang mengawal salah satu pelayan boleh menyamar sebagai pelayan yang satu lagi kepada setiap klien yang telah menerima kunci tersebut, dan SSH tidak akan mengeluarkan amaran kerana kunci itu adalah kunci yang dijangkakan oleh klien.

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 menulis kunci baharu bagi setiap jenis yang dijangkakan oleh daemon. Fingerprint daripada arahan terakhir mestilah berbeza daripada fingerprint pada pelayan asal. Sesi semasa anda akan kekal selepas but semula, kerana memulakan semula sshd tidak menutup sambungan yang sedia ada. Lakukan ini sebelum sesiapa menyambung ke klon tersebut. Jika anda menangguhkannya, setiap klien yang telah mempercayai kunci yang diwarisi akan mendapat WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! dan perlu menjalankan ssh-keygen -R <host> terlebih dahulu.

Tetapkan semula ID mesin. /etc/machine-id ialah pengecam unik yang dijana oleh systemd sekali sahaja, pada but pertama, dan klon akan mewarisinya.

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

Fail /etc/machine-id yang kosong memberitahu systemd untuk menjana nilai baharu pada but seterusnya, itulah sebabnya anda mengosongkan fail tersebut dan bukannya memadamnya. Dua perkara akan terjejas apabila ia diduplikasi. Pada imej yang mengambil alamat melalui DHCP, systemd-networkd secara lalai memperoleh pengecam klien DHCP daripada ID mesin, jadi kedua-dua klon meminta pajakan sebagai klien yang sama dan pelayan memberikan alamat yang sama kepada kedua-duanya. Selain itu, journald mengecap setiap entri dengan ID mesin, jadi pengumpul log pusat akan memfailkan kedua-dua pelayan di bawah satu mesin. Jalankan cat /etc/machine-id selepas but semula dan sahkan bahawa nilai tersebut telah berubah.

Tukar nama hos.

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

hostnamectl menulis /etc/hostname dan menggunakan nama tersebut serta-merta. Ia tidak menyentuh /etc/hosts, jadi edit baris 127.0.1.1 supaya sepadan. Jika anda melangkau langkah ini, nama baharu tidak akan dapat diselesaikan, jadi setiap panggilan sudo akan menunggu carian yang gagal dan mencetak sudo: unable to resolve host web-02: Name or service not known.

Putarkan setiap kelayakan yang terbina dalam imej. Klon memegang rahsia pelayan asal, dan kini dua mesin boleh bertindak sebagai pelayan asal. Semak fail authorized_keys SSH, token API pembekal dan DNS, fail .env aplikasi, kata laluan pangkalan data, kunci peribadi TLS, token pendaftaran pemantauan, dan kata laluan repositori restic. Ini akan menemui kebanyakan daripadanya:

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

Jika klon tersebut ialah salinan ujian yang tidak akan melayani trafik, batalkan kelayakan tersebut dan bukannya memutarkannya. Kotak staging yang memegang token API pengeluaran yang aktif ialah kotak pengeluaran dengan tampalan yang lebih buruk.

Matikan kerja yang kini berjalan dua kali. Dua pelayan yang menjalankan crontab yang sama akan mencapai sistem luaran yang sama pada minit yang sama.

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

Kes restic perlu diperjelaskan, kerana ia merosakkan pengekalan anda dan bukannya sekadar gagal dengan ketara. restic menandakan setiap snapshot dengan nama hos, dan restic forget --keep-daily 7 menggunakan polisinya mengikut hos. Dua mesin yang melaporkan nama hos yang sama dianggap sebagai satu hos, jadi tujuh snapshot "harian" semuanya boleh datang daripada klon manakala snapshot pelayan asal dipangkas. Betulkan nama hos sebelum proses sandaran pertama berjalan, atau hentikan pemasa pada klon. Kes certbot lebih mudah: dua pelayan yang memperbaharui nama yang sama akan mencapai had kadar sijil duplikat pihak berkuasa sijil, dan proses yang kalah akan gagal dengan ralat tentang terlalu banyak sijil yang telah dikeluarkan untuk set nama yang tepat itu. Klon yang domainnya masih menghala ke pelayan asal tidak boleh melepasi cabaran HTTP, jadi lumpuhkan pembaharuan di sana.

Urus ejen pemantauan. Kebanyakan ejen mengenal pasti diri melalui nama hos atau fail ID yang ditulis semasa pemasangan, jadi dua ejen yang melaporkan sebagai satu hos akan mencampurkan metrik mereka ke dalam satu siri tunggal. Graf CPU kemudiannya akan menunjukkan nilai yang tidak dihasilkan oleh mana-mana mesin tunggal, dan amaran akan menjadi tidak stabil. Hentikan dan alih keluar ejen pada klon, atau daftar semula di bawah nama hos baharu menggunakan prosedur yang didokumenkan oleh vendor anda.

Semak konfigurasi rangkaian untuk alamat pelayan asal. Jika imej membawa alamat statik dalam netplan, klon akan menuntut IP yang dimiliki oleh mesin lain.

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

Kosongkan status cloud-init jika klon ini menjadi templat.

sudo cloud-init clean --logs

Langkah itu membuang status cloud-init di bawah /var/lib/cloud, jadi but seterusnya akan menjalankan modul but pertama sekali lagi, yang termasuk menjana kunci hos SSH apabila tiada kunci ditemui. Sesetengah versi juga menawarkan flag untuk menetapkan semula ID mesin. Jalankan cloud-init clean --help pada imej anda sendiri untuk melihat perkara yang disokong oleh imej anda dan bukannya mempercayai senarai flag daripada sumber lain.

Bilakah perlu menggunakan kaedah tertentu

Melakukan rollback bagi naik taraf yang berisiko: ambil snapshot. Ambil snapshot beberapa minit sebelum perubahan dilakukan, jalankan naik taraf, dan pulihkan imej tersebut jika berlaku kegagalan. Pemulihan akan membuang setiap penulisan yang dilakukan sejak snapshot diambil, jadi bagi pelayan yang menerima trafik langsung, buat dump pangkalan data terlebih dahulu dan ketahui dengan tepat tempoh data yang akan hilang. Bagi do-release-upgrade pada mesin yang boleh anda luar taliankan selama sepuluh minit, snapshot adalah pelan keseluruhan yang diperlukan.

Berhijrah ke pelan yang lebih besar: gunakan clone. Bina clone daripada snapshot pada pelan yang lebih besar, selesaikan senarai identiti di atas, kemudian uji pada IP sendiri sebelum sebarang trafik dialihkan. Rendahkan TTL DNS sehari lebih awal supaya peralihan berlaku dengan pantas, dan kekalkan pelayan asal sehingga mesin baharu stabil menerima trafik sebenar. Pastikan pelan yang lebih besar benar-benar lebih pantas untuk beban kerja anda terlebih dahulu, menggunakan kaedah penanda aras yang sama pada kedua-dua pelayan, kerana lebih banyak vCPU pada perkakasan yang lebih sibuk tidak semestinya merupakan satu naik taraf.

Membina templat: ambil snapshot mesin yang telah dibersihkan. Pasang dan keraskan satu pelayan, kemudian buang semua perkara yang unik sebelum anda mengambil imejnya. Tiada host keys, ID mesin yang kosong, tiada authorized_keys peribadi, tiada kelayakan, dan cloud-init telah dibersihkan. Ambil snapshot tersebut. Setiap instans yang digunakan daripadanya akan menjana identiti sendiri pada but pertama, jadi senarai semak di atas tidak lagi diperlukan. Padankan dengan sepuluh minit pertama yang standard pada VPS baharu supaya templat tersebut sudah mengandungi kerja yang sepatutnya anda ulangi.

FAQ

Adakah snapshot VPS dianggap sebagai sandaran (backup)?

Tidak, kerana ia berkongsi domain kegagalan yang sama dengan pelayan asalnya. Snapshot tersebut disimpan pada storan pembekal anda, di dalam akaun anda, dan biasanya di wilayah yang sama. Penggantungan akaun, kunci API yang dicuri, atau pemadaman instans secara tidak sengaja boleh melenyapkan pelayan serta snapshotnya dalam satu tindakan. Bagi kebanyakan pembekal, memadamkan instans akan memadamkan snapshotnya secara reka bentuk. Snapshot ialah cara pemulihan (rollback) terpantas yang anda miliki, jadi teruskan mengambilnya, tetapi simpan salinan kedua yang disulitkan pada infrastruktur yang tidak dikawal oleh pembekal anda.

Adakah saya perlu menghentikan pangkalan data sebelum mengambil snapshot?

Tidak semestinya, tetapi anda perlu menerima keadaan data tersebut. Snapshot pembekal adalah "crash-consistent", bermakna imej tersebut sepadan dengan keadaan cakera selepas gangguan bekalan elektrik. PostgreSQL dan InnoDB akan pulih daripada keadaan itu semasa but semula, dan PostgreSQL akan mencatatkan database system was not properly shut down; automatic recovery in progress semasa proses tersebut. Pemulihan tidak dijamin apabila data anda merangkumi dua volum yang diambil snapshot pada saat yang berbeza, atau apabila aplikasi menulis tanpa fsync. Tulis pg_dumpall atau mysqldump --single-transaction ke cakera terlebih dahulu, supaya imej tersebut mengandungi satu fail yang anda tahu konsisten.

Mengapa dua pelayan klon berebut alamat IP yang sama?

Kerana mereka berkongsi /etc/machine-id. Pada imej yang menggunakan DHCP, systemd-networkd membina pengecam klien DHCP daripada machine ID secara lalai. Oleh itu, kedua-dua klon meminta pajakan sebagai klien yang sama dan pelayan DHCP menawarkan alamat yang sama kepada kedua-duanya. Kosongkan /etc/machine-id kepada sifar bait, alihkan /var/lib/dbus/machine-id, buat symlink semula ke /etc/machine-id, dan but semula supaya systemd menjana nilai baharu. Punca biasa yang lain ialah alamat statik yang ditulis ke dalam /etc/netplan/, yang disalin secara verbatim oleh klon tersebut; semak dengan ip -br addr.

Apakah cara terpantas untuk memastikan klon selamat digunakan dalam pengeluaran (production)?

Bandingkan empat perkara dengan pelayan asal. Jalankan ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub pada kedua-duanya dan pastikan cap jari (fingerprint) berbeza. Jalankan cat /etc/machine-id pada kedua-duanya dan pastikan nilainya berbeza. Jalankan hostnamectl status dan pastikan namanya baharu serta dapat diselesaikan (resolve), supaya sudo tidak mengeluarkan amaran. Kemudian, jalankan systemctl list-timers --all dan hentikan setiap pemasa (timer) yang berhubung dengan sistem kongsi, seperti sandaran, pembaharuan sijil, atau ejen pemantauan, sehingga anda memutuskan mesin mana yang bertanggungjawab untuk tugasan tersebut.