Kinukumpleto ng talang ito ang cycle tungkol sa backup. Tatalakayin nito ang lohikal na organisasyon ng isang dedikadong server (o VPS), na maginhawa para sa pag-backup, at mag-aalok din ng isang opsyon para sa mabilis na pagpapanumbalik ng isang server mula sa isang backup nang walang masyadong downtime sa kaganapan ng isang kalamidad.
Raw data
Ang isang dedikadong server ay kadalasang mayroong hindi bababa sa dalawang hard drive na nagsisilbi upang ayusin ang isang first-level na RAID array (mirror). Ito ay kinakailangan upang maipagpatuloy ang pagpapatakbo ng server kung nabigo ang isang disk. Kung ito ay isang regular na dedikadong server, maaaring mayroong isang hiwalay na hardware RAID controller na may aktibong teknolohiya sa pag-cache sa SSD, upang bilang karagdagan sa mga regular na hard drive, isa o higit pang mga SSD ay maaaring konektado. Minsan ang mga dedikadong server ay inaalok, kung saan ang tanging mga lokal na disk ay SATADOM (maliit na disk, structurally isang flash drive na konektado sa isang SATA port), o kahit isang ordinaryong maliit (8-16GB) flash drive na konektado sa isang espesyal na panloob na port, at ang kinukuha ang data mula sa sistema ng imbakan , na konektado sa pamamagitan ng isang nakalaang network ng imbakan (Ethernet 10G, FC, atbp.), at may mga nakalaang server na direktang ni-load mula sa sistema ng imbakan. Hindi ko isasaalang-alang ang mga ganoong opsyon, dahil sa mga ganitong kaso ang gawain ng pag-back up ng server ay maayos na ipinapasa sa espesyalista na nagpapanatili ng sistema ng imbakan; kadalasan mayroong iba't ibang mga teknolohiyang pagmamay-ari para sa paglikha ng mga snapshot, built-in na deduplication at iba pang kagalakan ng system administrator , na tinalakay sa mga nakaraang bahagi ng seryeng ito. Ang dami ng disk array ng isang dedikadong server ay maaaring umabot ng ilang sampu-sampung terabytes, depende sa bilang at laki ng mga disk na konektado sa server. Sa kaso ng VPS, ang mga volume ay mas katamtaman: karaniwang hindi hihigit sa 100GB (ngunit mayroon ding higit pa), at ang mga taripa para sa naturang VPS ay madaling mas mahal kaysa sa pinakamurang mga dedikadong server mula sa parehong hoster. Ang VPS ay kadalasang may isang disk, dahil magkakaroon ng storage system (o isang bagay na hyperconverged) sa ilalim nito. Minsan ang isang VPS ay may ilang mga disk na may iba't ibang katangian, para sa iba't ibang layunin:
- maliit na sistema - para sa pag-install ng operating system;
- malaki - nag-iimbak ng data ng gumagamit.
Kapag muling na-install ang system gamit ang control panel, ang disk na may data ng user ay hindi ma-overwrite, ngunit ang system disk ay ganap na na-refill. Gayundin, sa kaso ng isang VPS, ang hoster ay maaaring mag-alok ng isang pindutan na kumukuha ng isang snapshot ng estado ng VPS (o disk), ngunit kung nag-install ka ng iyong sariling operating system o nakalimutan mong i-activate ang nais na serbisyo sa loob ng VPS, ang ilan ng data ay maaaring mawala pa rin. Bilang karagdagan sa pindutan, ang isang serbisyo sa pag-iimbak ng data ay karaniwang inaalok, kadalasan ay limitado. Kadalasan ito ay isang account na may access sa pamamagitan ng FTP o SFTP, minsan kasama ng SSH, na may isang stripped-down na shell (halimbawa, rbash), o isang paghihigpit sa pagpapatakbo ng mga command sa pamamagitan ng authorized_keys (sa pamamagitan ng ForcedCommand).
Ang isang dedikadong server ay konektado sa network sa pamamagitan ng dalawang port na may bilis na 1 Gbps, kung minsan ang mga ito ay maaaring mga card na may bilis na 10 Gbps. Ang VPS ay kadalasang may isang interface ng network. Kadalasan, hindi nililimitahan ng mga data center ang bilis ng network sa loob ng data center, ngunit nililimitahan nila ang bilis ng pag-access sa Internet.
Ang karaniwang load ng naturang dedikadong server o VPS ay isang web server, isang database, at isang application server. Minsan maaaring mag-install ng iba't ibang karagdagang serbisyong pantulong, kabilang ang para sa isang web server o database: search engine, mail system, atbp.
Ang isang espesyal na inihandang server ay gumaganap bilang isang puwang para sa pag-iimbak ng mga backup na kopya; isusulat namin ang tungkol dito nang mas detalyado sa ibang pagkakataon.
Lohikal na organisasyon ng disk system
Kung mayroon kang RAID controller, o isang VPS na may isang disk, at walang mga espesyal na kagustuhan para sa pagpapatakbo ng disk subsystem (halimbawa, isang hiwalay na fast disk para sa database), ang lahat ng libreng espasyo ay nahahati tulad ng sumusunod: isang partition ay nilikha, at isang pangkat ng dami ng LVM ay nilikha sa ibabaw nito, maraming mga volume ang nilikha sa loob nito: 2 maliit na magkapareho ang laki, na ginamit bilang root file system (nagbago nang paisa-isa sa panahon ng mga pag-update para sa posibilidad ng mabilis na pag-rollback, ang ideya ay kinuha mula sa Calculate Linux distribution), ang isa pa ay para sa swap partition, ang natitirang bahagi ng libreng espasyo ay nahahati sa maliliit na volume , ginamit bilang root file system para sa mga ganap na lalagyan, mga disk para sa mga virtual machine, file. system para sa mga account sa /home (bawat account ay may sariling file system), mga file system para sa mga lalagyan ng aplikasyon.
Mahalagang tala: ang mga volume ay dapat na ganap na nakapag-iisa, i.e. hindi dapat umasa sa isa't isa o sa root file system. Sa kaso ng mga virtual machine o lalagyan, ang puntong ito ay awtomatikong sinusunod. Kung ito ay mga lalagyan ng application o mga direktoryo ng bahay, dapat mong isipin ang tungkol sa paghihiwalay ng mga configuration file ng web server at iba pang mga serbisyo sa paraang maalis ang mga dependency sa pagitan ng mga volume hangga't maaari. Halimbawa, ang bawat site ay tumatakbo mula sa sarili nitong user, ang mga file ng configuration ng site ay nasa home directory ng user, sa mga setting ng web server, ang mga file ng configuration ng site ay hindi kasama sa pamamagitan ng /etc/nginx/conf.d/.conf, at, halimbawa, /home//configs/nginx/*.conf
Kung mayroong ilang mga disk, maaari kang lumikha ng isang software RAID array (at i-configure ang pag-cache nito sa isang SSD, kung may pangangailangan at pagkakataon), sa ibabaw nito maaari kang bumuo ng LVM ayon sa mga panuntunang iminungkahi sa itaas. Gayundin sa kasong ito, maaari mong gamitin ang ZFS o BtrFS, ngunit dapat kang mag-isip nang dalawang beses tungkol dito: parehong nangangailangan ng mas seryosong diskarte sa mga mapagkukunan, at bukod pa, ang ZFS ay hindi kasama sa Linux kernel.
Anuman ang scheme na ginamit, palaging nagkakahalaga ng pagtatantya nang maaga ang tinatayang bilis ng pagsulat ng mga pagbabago sa mga disk, at pagkatapos ay kalkulahin ang dami ng libreng espasyo na nakalaan para sa paglikha ng mga snapshot. Halimbawa, kung ang aming server ay nagsusulat ng data sa bilis na 10 megabytes bawat segundo, at ang laki ng buong hanay ng data ay 10 terabytes - ang oras ng pag-synchronize ay maaaring umabot sa isang araw (22 oras - ito ay kung magkano ang naturang volume na ililipat sa network 1 Gbps) - ito ay nagkakahalaga ng pagpapareserba ng tungkol sa 800 GB . Sa katotohanan, ang figure ay magiging mas maliit; maaari mong ligtas na hatiin ito sa bilang ng mga lohikal na volume.
Backup na storage server device
Ang pangunahing pagkakaiba sa pagitan ng isang server para sa pag-iimbak ng mga backup na kopya ay ang malaki, mura at medyo mabagal na mga disk nito. Dahil ang mga modernong HDD ay tumawid na sa 10TB bar sa isang disk, kinakailangan na gumamit ng mga file system o RAID na may mga checksum, dahil sa panahon ng muling pagtatayo ng array o pagpapanumbalik ng file system (ilang araw!) ang pangalawang disk ay maaaring mabigo dahil sa tumaas na load. Sa mga disk na may kapasidad na hanggang 1TB hindi ito masyadong sensitibo. Para sa pagiging simple ng paglalarawan, ipinapalagay ko na ang puwang ng disk ay nahahati sa dalawang bahagi ng humigit-kumulang pantay na laki (muli, halimbawa, gamit ang LVM):
- mga volume na naaayon sa mga server na ginamit upang mag-imbak ng data ng user (ang huling backup na ginawa ay i-deploy sa kanila para sa pag-verify);
- mga volume na ginamit bilang BorgBackup repository (ang data para sa mga backup ay direktang mapupunta rito).
Ang prinsipyo ng pagpapatakbo ay ang mga hiwalay na volume ay nilikha para sa bawat server para sa mga imbakan ng BorgBackup, kung saan mapupunta ang data mula sa mga server ng labanan. Gumagana ang mga repository sa append-only mode, na nag-aalis ng posibilidad ng sadyang pagtanggal ng data, at dahil sa deduplikasyon at pana-panahong paglilinis ng mga repository mula sa mga lumang backup (nananatili ang mga taunang kopya, buwanan para sa nakaraang taon, lingguhan para sa nakaraang buwan, araw-araw para sa noong nakaraang linggo, posibleng sa mga espesyal na kaso - oras-oras para sa huling araw: kabuuang 24 + 7 + 4 + 12 + taunang - humigit-kumulang 50 kopya para sa bawat server).
Hindi pinapagana ng mga repositoryo ng BorgBackup ang append-only mode; sa halip, ang isang ForcedCommand sa .ssh/authorized_keys ay ginagamit tulad nito:
from="Π°Π΄ΡΠ΅Ρ ΡΠ΅ΡΠ²Π΅ΡΠ°",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......Ang tinukoy na path ay naglalaman ng isang wrapper script sa ibabaw ng borg, na, bilang karagdagan sa paglulunsad ng binary na may mga parameter, ay magsisimula din sa proseso ng pagpapanumbalik ng backup na kopya pagkatapos maalis ang data. Para magawa ito, ang script ng wrapper ay gagawa ng tag file sa tabi ng kaukulang repositoryo. Ang huling backup na ginawa ay awtomatikong maibabalik sa kaukulang lohikal na dami pagkatapos makumpleto ang proseso ng pagpuno ng data.
Binibigyang-daan ka ng disenyong ito na pana-panahong linisin ang mga hindi kinakailangang backup, at pinipigilan din ang mga server ng labanan mula sa pagtanggal ng anuman sa server ng backup na imbakan.
Proseso ng Pag-backup
Ang nagpasimula ng backup ay ang dedikadong server o VPS mismo, dahil ang scheme na ito ay nagbibigay ng higit na kontrol sa proseso ng backup sa bahagi ng server na ito. Una, kumuha ng snapshot ng estado ng aktibong root file system, na naka-mount at na-upload gamit ang BorgBackup sa backup na storage server. Pagkatapos makumpleto ang pagkuha ng data, ang snapshot ay i-unmount at tatanggalin.
Kung mayroong isang maliit na database (hanggang sa 1 GB para sa bawat site), isang database dump ay ginawa, na kung saan ay nai-save sa naaangkop na lohikal na dami, kung saan ang natitirang bahagi ng data para sa parehong site ay matatagpuan, ngunit upang ang dump ay hindi naa-access sa pamamagitan ng web server. Kung ang mga database ay malaki, dapat mong i-configure ang "mainit" na pag-alis ng data, halimbawa, gamit ang xtrabackup para sa MySQL, o magtrabaho kasama ang WAL gamit ang archive_command sa PostgreSQL. Sa kasong ito, ang database ay ibabalik nang hiwalay sa data ng site.
Kung ginagamit ang mga lalagyan o virtual machine, dapat mong i-configure ang qemu-guest-agent, CRIU o iba pang mga kinakailangang teknolohiya. Sa ibang mga kaso, ang mga karagdagang setting ay kadalasang hindi kailangan - gumagawa lang kami ng mga snapshot ng mga lohikal na volume, na pagkatapos ay pinoproseso sa parehong paraan bilang isang snapshot ng estado ng root file system. Matapos makuha ang data, ang mga larawan ay tatanggalin.
Ang karagdagang trabaho ay isinasagawa sa backup na server ng imbakan:
- ang huling backup na ginawa sa bawat repository ay nasuri,
- ang pagkakaroon ng isang mark file ay nasuri, na nagpapahiwatig na ang proseso ng pagkolekta ng data ay nakumpleto,
- ang data ay pinalawak sa kaukulang lokal na dami,
- ang tag file ay tinanggal
Proseso ng pagbawi ng server
Kung namatay ang pangunahing server, ilulunsad ang isang katulad na dedikadong server, na nag-boot mula sa ilang karaniwang imahe. Malamang na ang pag-download ay magaganap sa network, ngunit ang data center technician na nagse-set up ng server ay maaaring agad na kopyahin ang karaniwang imaheng ito sa isa sa mga disk. Ang pag-download ay nangyayari sa RAM, pagkatapos ay magsisimula ang proseso ng pagbawi:
- ang isang kahilingan ay ginawa upang ilakip ang isang block device sa pamamagitan ng iscsinbd o isa pang katulad na protocol sa isang lohikal na dami na naglalaman ng root file system ng namatay na server; Dahil ang root file system ay dapat maliit, ang hakbang na ito ay dapat makumpleto sa loob ng ilang minuto. Ang bootloader ay naibalik din;
- ang istraktura ng mga lokal na lohikal na volume ay muling nilikha, ang mga lohikal na volume ay nakalakip mula sa backup server gamit ang dm_clone kernel module: ang pagbawi ng data ay magsisimula, at ang mga pagbabago ay isinusulat kaagad sa mga lokal na disk
- ang isang lalagyan ay inilunsad kasama ang lahat ng magagamit na mga pisikal na disk - ang pag-andar ng server ay ganap na naibalik, ngunit may pinababang pagganap;
- pagkatapos makumpleto ang pag-synchronize ng data, ang mga lohikal na volume mula sa backup server ay hindi nakakonekta, ang lalagyan ay naka-off, at ang server ay reboot;
Pagkatapos ng pag-reboot, ang server ay magkakaroon ng lahat ng data na naroroon sa oras na ginawa ang backup, at isasama rin ang lahat ng mga pagbabagong ginawa sa panahon ng proseso ng pag-restore.
Iba pang mga artikulo sa serye
Backup Part 7: Mga Konklusyon
Inaanyayahan kita na talakayin ang iminungkahing opsyon sa mga komento, salamat sa iyong pansin!
Pinagmulan: www.habr.com