Rezerves kopija 7. daļa: Secinājumi

Rezerves kopija 7. daļa: Secinājumi

Å Ä« piezÄ«me pabeidz dublÄ“Å”anas ciklu. Tajā tiks apspriesta speciālā servera (vai VPS) loÄ£iskā organizācija, kas ir ērta dublÄ“Å”anai, kā arÄ« tiks piedāvāta iespēja ātri atjaunot serveri no dublējuma bez lielas dÄ«kstāves katastrofas gadÄ«jumā.

Neapstrādāti dati

ÄŖpaÅ”am serverim visbiežāk ir vismaz divi cietie diski, kas kalpo pirmā lÄ«meņa RAID masÄ«va (spoguļa) organizÄ“Å”anai. Tas ir nepiecieÅ”ams, lai varētu turpināt darbināt serveri, ja viens disks neizdodas. Ja tas ir parasts veltÄ«ts serveris, SSD var bÅ«t atseviŔķs aparatÅ«ras RAID kontrolieris ar aktÄ«vās keÅ”atmiņas tehnoloÄ£iju, lai papildus parastajiem cietajiem diskiem varētu pievienot vienu vai vairākus SSD. Dažkārt tiek piedāvāti specializēti serveri, kuros vienÄ«gie lokālie diski ir SATADOM (mazie diski, strukturāli SATA portam pieslēgts zibatmiņas disks) vai pat parasts mazs (8-16GB) zibatmiņas disks, kas pieslēgts speciālam iekŔējam portam, un dati tiek ņemti no uzglabāŔanas sistēmas, savienoti, izmantojot speciālu uzglabāŔanas tÄ«klu (Ethernet 10G, FC utt.), un ir Ä«paÅ”i serveri, kas tiek ielādēti tieÅ”i no uzglabāŔanas sistēmas. Es neapsvērÅ”u Ŕādas iespējas, jo Ŕādos gadÄ«jumos servera dublÄ“Å”anas uzdevums vienmērÄ«gi pāriet uz krātuves sistēmu apkalpojoÅ”o speciālistu; parasti ir dažādas patentētas tehnoloÄ£ijas momentuzņēmumu veidoÅ”anai, iebÅ«vētai dublÄ“Å”anai un citiem sistēmas administratora priekiem. , kas tika apspriests Ŕīs sērijas iepriekŔējās daļās. IzdalÄ«tā servera disku masÄ«va apjoms var sasniegt vairākus desmitus terabaitu atkarÄ«bā no serverim pievienoto disku skaita un lieluma. VPS gadÄ«jumā apjomi ir pieticÄ«gāki: parasti ne vairāk kā 100 GB (bet ir arÄ« vairāk), un Ŕāda VPS tarifi var viegli bÅ«t dārgāki nekā lētākie specializētie serveri no tā paÅ”a hostera. VPS visbiežāk ir viens disks, jo zem tā bÅ«s uzglabāŔanas sistēma (vai kaut kas hiperkonverģēts). Dažreiz VPS ir vairāki diski ar dažādām Ä«paŔībām dažādiem mērÄ·iem:

  • maza sistēma - operētājsistēmas instalÄ“Å”anai;
  • liels - lietotāja datu glabāŔana.

Pārinstalējot sistēmu, izmantojot vadÄ«bas paneli, disks ar lietotāja datiem netiek pārrakstÄ«ts, bet sistēmas disks tiek pilnÄ«bā uzpildÄ«ts. Tāpat VPS gadÄ«jumā mitinātājs var piedāvāt pogu, kas uzņem VPS (vai diska) stāvokļa momentuzņēmumu, taču, ja instalējat savu operētājsistēmu vai aizmirstat aktivizēt vēlamo pakalpojumu VPS iekÅ”ienē, daži dati joprojām var tikt zaudēti. Papildus pogai parasti tiek piedāvāts datu uzglabāŔanas pakalpojums, visbiežāk ļoti ierobežots. Parasti tas ir konts ar piekļuvi, izmantojot FTP vai SFTP, dažreiz kopā ar SSH, ar noņemtu čaulu (piemēram, rbash) vai komandu palaiÅ”anas ierobežojumu, izmantojot Authoricity_keys (izmantojot ForcedCommand).

Izdalītais serveris ir savienots ar tīklu ar diviem portiem ar ātrumu 1 Gbps, dažreiz tās var būt kartes ar ātrumu 10 Gbps. VPS visbiežāk ir viens tīkla interfeiss. Visbiežāk datu centri neierobežo tīkla ātrumu datu centra ietvaros, bet gan ierobežo interneta piekļuves ātrumu.

Tipiska Ŕāda veltÄ«ta servera vai VPS slodze ir tÄ«mekļa serveris, datubāze un lietojumprogrammu serveris. Dažreiz var tikt instalēti dažādi papildu palÄ«gpakalpojumi, tostarp tÄ«mekļa serverim vai datubāzei: meklētājprogramma, pasta sistēma utt.

Speciāli sagatavots serveris darbojas kā vieta rezerves kopiju glabāŔanai, par to sÄ«kāk rakstÄ«sim vēlāk.

Diska sistēmas loģiskā organizācija

Ja jums ir RAID kontrolleris vai VPS ar vienu disku un diska apakÅ”sistēmas darbÄ«bai nav Ä«paÅ”u preferenču (piemēram, atseviŔķs ātrais disks datu bāzei), visa brÄ«vā vieta tiek sadalÄ«ta Ŕādi: viens nodalÄ«jums. tiek izveidota, un tai virsÅ« tiek izveidota LVM sējumu grupa , tajā tiek izveidoti vairāki sējumi: 2 mazi tāda paÅ”a izmēra sējumi, kas tiek izmantoti kā saknes failu sistēma (atjaunināŔanas laikā tiek mainÄ«ti pa vienam, lai nodroÅ”inātu ātru atcelÅ”anu, ideja tika paņemta no Calculate Linux izplatÄ«Å”anas), vēl viens ir paredzēts mijmaiņas nodalÄ«jumam, pārējā brÄ«vā vieta ir sadalÄ«ta mazos apjomos, tiek izmantota kā saknes failu sistēma pilnvērtÄ«giem konteineriem, diskiem virtuālajām maŔīnām, failam sistēmas /home kontiem (katram kontam ir sava failu sistēma), failu sistēmas lietojumprogrammu konteineriem.

SvarÄ«ga piezÄ«me: sējumiem jābÅ«t pilnÄ«bā autonomiem, t.i. nedrÄ«kst bÅ«t atkarÄ«gi viens no otra vai saknes failu sistēmas. Virtuālo maŔīnu vai konteineru gadÄ«jumā Å”is punkts tiek novērots automātiski. Ja tie ir lietojumprogrammu konteineri vai mājas direktoriji, jums vajadzētu padomāt par tÄ«mekļa servera un citu pakalpojumu konfigurācijas failu atdalÄ«Å”anu tā, lai pēc iespējas vairāk novērstu sējumu atkarÄ«bas. Piemēram, katra vietne darbojas no sava lietotāja, vietnes konfigurācijas faili atrodas lietotāja mājas direktorijā, tÄ«mekļa servera iestatÄ«jumos vietnes konfigurācijas faili nav iekļauti, izmantojot /etc/nginx/conf.d/.conf un, piemēram, /home//configs/nginx/*.conf

Ja ir vairāki diski, varat izveidot programmatÅ«ras RAID masÄ«vu (un konfigurēt tā keÅ”atmiņu SSD diskā, ja ir nepiecieÅ”amÄ«ba un iespēja), kuram virsÅ« var uzbÅ«vēt LVM saskaņā ar iepriekÅ” piedāvātajiem noteikumiem. ArÄ« Å”ajā gadÄ«jumā jÅ«s varat izmantot ZFS vai BtrFS, taču par to vajadzētu padomāt divreiz: abiem ir nepiecieÅ”ama daudz nopietnāka pieeja resursiem, turklāt ZFS nav iekļauts Linux kodolā.

NeatkarÄ«gi no izmantotās shēmas vienmēr ir vērts iepriekÅ” novērtēt aptuveno izmaiņu ierakstÄ«Å”anas ātrumu diskos un pēc tam aprēķināt brÄ«vās vietas daudzumu, kas tiks rezervēts momentuzņēmumu izveidei. Piemēram, ja mÅ«su serveris raksta datus ar ātrumu 10 megabaiti sekundē un visa datu masÄ«va izmērs ir 10 terabaiti - sinhronizācijas laiks var sasniegt dienu (22 stundas - tik daudz tiks pārsÅ«tÄ«ts Ŕāds apjoms tÄ«klā 1 Gbps) - ir vērts rezervēt aptuveni 800 GB . PatiesÄ«bā skaitlis bÅ«s mazāks, to var droÅ”i dalÄ«t ar loÄ£isko sējumu skaitu.

Rezerves krātuves servera ierīce

Galvenā atŔķirÄ«ba starp serveri rezerves kopiju glabāŔanai ir tā lielie, lētie un salÄ«dzinoÅ”i lēnie diski. Tā kā mÅ«sdienu cietie diski vienā diskā jau ir pārkāpuÅ”i 10TB joslu, ir jāizmanto failu sistēmas jeb RAID ar kontrolsummām, jo ā€‹ā€‹masÄ«va pārbÅ«ves vai failu sistēmas atjaunoÅ”anas laikā (vairākas dienas!) var neizdoties arÄ« otrais disks. uz palielinātu slodzi. Diskos ar ietilpÄ«bu lÄ«dz 1 TB tas nebija tik jutÄ«gs. Apraksta vienkārŔības labad pieņemu, ka diska vieta ir sadalÄ«ta divās aptuveni vienāda izmēra daļās (atkal, piemēram, izmantojot LVM):

  • apjomi, kas atbilst serveriem, kas tiek izmantoti lietotāju datu glabāŔanai (tajos verifikācijai tiks izvietota pēdējā izveidotā dublÄ“Å”ana);
  • sējumi, kas tiek izmantoti kā BorgBackup krātuves (dati dublÄ“Å”anai nonāks tieÅ”i Å”eit).

DarbÄ«bas princips ir tāds, ka katram serverim tiek izveidoti atseviŔķi sējumi BorgBackup krātuvēm, kur nonāks dati no kaujas serveriem. Krātuves darbojas tikai pievienoÅ”anas režīmā, kas izslēdz iespēju tÄ«Å”i dzēst datus, kā arÄ« sakarā ar repozitoriju dedublikāciju un periodisku tÄ«rÄ«Å”anu no vecajām dublējumkopijām (ikgadējās kopijas paliek, katru mēnesi par pēdējo gadu, katru nedēļu par pēdējo mēnesi, katru dienu pagājuÅ”ajā nedēļā, iespējams, Ä«paÅ”os gadÄ«jumos - katru stundu pēdējo dienu: kopā 24 + 7 + 4 + 12 + gadā - aptuveni 50 eksemplāri katram serverim).
BorgBackup krātuves neiespējo tikai pievienoÅ”anas režīmu; tā vietā tiek izmantota ForcedCommand failā .ssh/authorized_keys:

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.......

NorādÄ«tais ceļŔ satur iesaiņojuma skriptu virs borg, kas papildus bināra palaiÅ”anai ar parametriem papildus sāk dublējuma atjaunoÅ”anas procesu pēc datu noņemÅ”anas. Lai to izdarÄ«tu, iesaiņojuma skripts izveido tagu failu blakus attiecÄ«gajam repozitorijam. Pēdējais dublējums tiek automātiski atjaunots attiecÄ«gajā loÄ£iskajā sējumā pēc datu aizpildÄ«Å”anas procesa pabeigÅ”anas.

Šis dizains ļauj periodiski tīrīt nevajadzīgās dublējumkopijas, kā arī neļauj kaujas serveriem dzēst neko no rezerves krātuves servera.

DublēŔanas process

DublÄ“Å”anas iniciators ir izdalÄ«tais serveris vai VPS, jo Ŕī shēma nodroÅ”ina lielāku kontroli pār dublÄ“Å”anas procesu no Ŕī servera puses. Vispirms tiek uzņemts aktÄ«vās saknes failu sistēmas stāvokļa momentuzņēmums, kas tiek uzstādÄ«ts un augÅ”upielādēts rezerves krātuves serverÄ«, izmantojot BorgBackup. Kad datu tverÅ”ana ir pabeigta, momentuzņēmums tiek noņemts un izdzēsts.

Ja ir neliela datu bāze (lÄ«dz 1 GB katrai vietnei), tiek veikta datu bāzes izgāztuve, kas tiek saglabāta atbilstoŔā loÄ£iskā sējumā, kur atrodas pārējie dati par to paÅ”u vietni, bet tā, lai izgāztuve tiktu saglabāta. nav pieejams caur tÄ«mekļa serveri. Ja datu bāzes ir lielas, jums vajadzētu konfigurēt ā€œkarstoā€ datu noņemÅ”anu, piemēram, izmantojot xtrabackup for MySQL, vai strādāt ar WAL ar archive_command programmā PostgreSQL. Å ajā gadÄ«jumā datu bāze tiks atjaunota atseviŔķi no vietnes datiem.

Ja tiek izmantoti konteineri vai virtuālās maŔīnas, jums jākonfigurē qemu-guest-agent, CRIU vai citas nepiecieÅ”amās tehnoloÄ£ijas. Citos gadÄ«jumos papildu iestatÄ«jumi visbiežāk nav nepiecieÅ”ami - mēs vienkārÅ”i izveidojam loÄ£isko sējumu momentuzņēmumus, kas pēc tam tiek apstrādāti tāpat kā saknes failu sistēmas stāvokļa momentuzņēmums. Pēc datu uzņemÅ”anas attēli tiek izdzēsti.

Papildu darbs tiek veikts rezerves krātuves serverī:

  • tiek pārbaudÄ«ta pēdējā katrā repozitorijā izveidotā dublējumkopija,
  • tiek pārbaudÄ«ta atzÄ«mes faila esamÄ«ba, kas norāda, ka datu vākÅ”anas process ir pabeigts,
  • dati tiek paplaÅ”ināti lÄ«dz atbilstoÅ”ajam lokālajam apjomam,
  • tagu fails tiek izdzēsts

Servera atkopŔanas process

Ja galvenais serveris nomirst, tiek palaists lÄ«dzÄ«gs speciālais serveris, kas tiek palaists no kāda standarta attēla. Visticamāk, lejupielāde notiks tÄ«klā, taču datu centra tehniÄ·is, kas uzstāda serveri, var nekavējoties iekopēt Å”o standarta attēlu vienā no diskiem. Lejupielāde notiek RAM, pēc tam sākas atkopÅ”anas process:

  • tiek izteikts pieprasÄ«jums pievienot blokierÄ«ci, izmantojot iscsinbd vai citu lÄ«dzÄ«gu protokolu loÄ£iskam sējumam, kurā ir miruŔā servera saknes failu sistēma; Tā kā saknes failu sistēmai ir jābÅ«t mazai, Ŕī darbÄ«ba jāpabeidz dažu minÅ«Å”u laikā. Tiek atjaunots arÄ« sāknÄ“Å”anas ielādētājs;
  • tiek atjaunota vietējo loÄ£isko sējumu struktÅ«ra, loÄ£iskie sējumi tiek pievienoti no rezerves servera, izmantojot kodola moduli dm_clone: ā€‹ā€‹sākas datu atkopÅ”ana, un izmaiņas tiek nekavējoties ierakstÄ«tas lokālajos diskos
  • tiek palaists konteiners ar visiem pieejamajiem fiziskajiem diskiem - servera funkcionalitāte ir pilnÄ«bā atjaunota, bet ar samazinātu veiktspēju;
  • pēc datu sinhronizācijas pabeigÅ”anas loÄ£iskie sējumi no rezerves servera tiek atvienoti, konteiners tiek izslēgts un serveris tiek restartēts;

Pēc atsāknÄ“Å”anas serverÄ« bÅ«s visi dati, kas tur bija dublējuma izveides laikā, kā arÄ« tiks iekļautas visas atjaunoÅ”anas procesa laikā veiktās izmaiņas.

Citi sērijas raksti

DublÄ“Å”ana, 1. daļa: Kāpēc nepiecieÅ”ama dublÄ“Å”ana, metožu, tehnoloÄ£iju pārskats
DublÄ“Å”ana 2. daļa: Uz rsync balstÄ«tu dublÄ“Å”anas rÄ«ku pārskatÄ«Å”ana un testÄ“Å”ana
Dublējuma 3. daļa: Dublitātes pārbaude un pārbaude, dublikāti
DublÄ“Å”ana 4. daļa: zbackup, restic, borgbackup pārskatÄ«Å”ana un testÄ“Å”ana
Dublējuma 5. daļa: Bacula un Veeam dublējuma testÄ“Å”ana operētājsistēmai Linux
DublÄ“Å”ana: daļa pēc lasÄ«tāju pieprasÄ«juma: AMANDA, UrBackup, BackupPC apskats
DublÄ“Å”ana 6. daļa: DublÄ“Å”anas rÄ«ku salÄ«dzināŔana
Rezerves kopija 7. daļa: Secinājumi

Aicinu komentāros apspriest piedāvāto variantu, paldies par uzmanību!

Avots: www.habr.com

Pievieno komentāru