Tämä huomautus päättää varmuuskopiointisyklin. Siinä käsitellään erillisen palvelimen (tai VPS:n) loogista organisaatiota, joka on kätevä varmuuskopiointiin, ja tarjoaa myös vaihtoehdon palvelimen nopeaan palauttamiseen varmuuskopiosta ilman paljon seisokkeja katastrofin sattuessa.
Raakatiedot
Omassa palvelimessa on useimmiten vähintään kaksi kiintolevyä, jotka järjestävät ensimmäisen tason RAID-ryhmän (peilin). Tämä on tarpeen, jotta palvelimen käyttöä voidaan jatkaa, jos yksi levy epäonnistuu. Jos tämä on tavallinen oma palvelin, SSD:llä voi olla erillinen laitteisto-RAID-ohjain aktiivisella välimuistitekniikalla, jotta tavallisten kiintolevyjen lisäksi voidaan liittää yksi tai useampi SSD-levy. Joskus tarjotaan dedikoituja palvelimia, joissa ainoat paikalliset levyt ovat SATADOM (pienet levyt, rakenteellisesti SATA-porttiin kytketty flash-asema) tai jopa tavallinen pieni (8-16 Gt) flash-asema, joka on kytketty erityiseen sisäiseen porttiin, ja tiedot otetaan tallennusjärjestelmästä, liitetään erillisen tallennusverkon kautta (Ethernet 10G, FC jne.), ja siellä on omistettuja palvelimia, jotka ladataan suoraan tallennusjärjestelmästä. En harkitse tällaisia vaihtoehtoja, koska tällaisissa tapauksissa palvelimen varmuuskopiointi siirtyy sujuvasti tallennusjärjestelmää ylläpitävälle asiantuntijalle; yleensä on olemassa erilaisia omistettuja tekniikoita tilannevedosten luomiseen, sisäänrakennettu duplikointi ja muut järjestelmänvalvojan ilot , jota on käsitelty tämän sarjan aiemmissa osissa. Dedikoidun palvelimen levyryhmän tilavuus voi olla useita kymmeniä teratavuja riippuen palvelimeen kytkettyjen levyjen määrästä ja koosta. VPS:n tapauksessa volyymit ovat vaatimattomampia: yleensä korkeintaan 100 Gt (mutta on myös enemmän), ja tällaisen VPS:n tariffit voivat helposti olla kalliimpia kuin saman isännöitsijän halvimmat omistetut palvelimet. VPS:ssä on useimmiten yksi levy, koska sen alla on tallennusjärjestelmä (tai jotain hyperkonvergoitunutta). Joskus VPS:ssä on useita levyjä, joilla on erilaiset ominaisuudet eri tarkoituksiin:
- pieni järjestelmä - käyttöjärjestelmän asentamiseen;
- suuri - tallentaa käyttäjätietoja.
Kun asennat järjestelmän uudelleen ohjauspaneelin avulla, käyttäjätietoja sisältävää levyä ei kirjoiteta päälle, vaan järjestelmälevy täytetään kokonaan uudelleen. Myös VPS:n tapauksessa isännöitsijä voi tarjota painikkeen, joka ottaa tilannekuvan VPS:n (tai levyn) tilasta, mutta jos asennat oman käyttöjärjestelmän tai unohdat aktivoida halutun palvelun VPS:n sisällä, tiedoista saattaa silti kadota. Painikkeen lisäksi tarjotaan yleensä tiedontallennuspalvelua, useimmiten hyvin rajoitettua. Tyypillisesti tämä on tili, johon pääsee FTP:n tai SFTP:n kautta, joskus yhdessä SSH:n kanssa, ja jossa on poistettu komentotulkki (esimerkiksi rbash) tai rajoitus komentojen suorittamiselle authorised_keys-avaimilla (ForcedCommandin kautta).
Dedikoitu palvelin on kytketty verkkoon kahdella portilla, joiden nopeus on 1 Gbps, joskus nämä voivat olla kortteja, joiden nopeus on 10 Gbps. VPS:llä on useimmiten yksi verkkoliitäntä. Useimmiten palvelinkeskukset eivät rajoita verkon nopeutta datakeskuksen sisällä, mutta ne rajoittavat Internet-yhteyden nopeutta.
Tällaisen erillisen palvelimen tai VPS:n tyypillinen kuormitus on verkkopalvelin, tietokanta ja sovelluspalvelin. Joskus voidaan asentaa erilaisia lisäapupalveluita, mukaan lukien verkkopalvelin tai tietokanta: hakukone, sähköpostijärjestelmä jne.
Varmuuskopioiden säilytystilana toimii erityisesti valmistettu palvelin, josta kirjoitamme myöhemmin tarkemmin.
Levyjärjestelmän looginen organisaatio
Jos sinulla on RAID-ohjain tai VPS yhdellä levyllä, eikä levyalijärjestelmän toiminnalle ole erityisiä asetuksia (esimerkiksi erillinen pikalevy tietokantaa varten), kaikki vapaa tila jaetaan seuraavasti: yksi osio luodaan ja sen päälle luodaan LVM-taltioryhmä , siihen luodaan useita taltioita: 2 pientä samankokoista, käytetään juuritiedostojärjestelmänä (muutettu yksitellen päivitysten aikana nopean palautuksen mahdollistamiseksi, idea poimittiin Calculate Linux -jakelusta), toinen on swap-osio, loput vapaasta tilasta on jaettu pieniin volyymeihin, käytetään juuritiedostojärjestelmänä täysimittaisille konteille, levyille virtuaalikoneen, tiedostolle järjestelmät tileille /home (jokaisella tilillä on oma tiedostojärjestelmä), tiedostojärjestelmät sovellussäiliöille.
Tärkeä huomautus: tilavuuksien on oltava täysin itsenäisiä, ts. eivät saisi riippua toisistaan tai juuritiedostojärjestelmästä. Virtuaalikoneiden tai säilöjen tapauksessa tämä kohta havaitaan automaattisesti. Jos kyseessä ovat sovellussäilöt tai kotihakemistot, kannattaa harkita web-palvelimen ja muiden palveluiden asetustiedostojen erottamista siten, että taltioiden väliset riippuvuudet eliminoidaan mahdollisimman paljon. Esimerkiksi jokainen sivusto toimii omalta käyttäjältään, sivuston määritystiedostot ovat käyttäjän kotihakemistossa, verkkopalvelimen asetuksissa sivuston määritystiedostoja ei sisällytetä /etc/nginx/conf.d/-osoitteen kautta..conf ja esimerkiksi /home//configs/nginx/*.conf
Jos levyjä on useita, voit luoda ohjelmiston RAID-ryhmän (ja määrittää sen välimuistin SSD-levylle, jos on tarvetta ja mahdollisuus), jonka päälle voit rakentaa LVM:n yllä ehdotettujen sääntöjen mukaisesti. Myös tässä tapauksessa voit käyttää ZFS:ää tai BtrFS:ää, mutta sinun kannattaa harkita tätä kahdesti: molemmat vaativat paljon vakavampaa lähestymistapaa resursseihin, ja lisäksi ZFS ei sisälly Linux-ytimeen.
Riippumatta käytetystä kaaviosta kannattaa aina arvioida etukäteen likimääräinen muutosten kirjoittamisen nopeus levyille ja laskea sitten tilannekuvien luomiseen varattavan vapaan tilan määrä. Esimerkiksi jos palvelimemme kirjoittaa dataa nopeudella 10 megatavua sekunnissa ja koko tietojoukon koko on 10 teratavua - synkronointiaika voi olla vuorokausi (22 tuntia - näin paljon tällaista määrää siirretään verkon yli 1 Gbps) - kannattaa varata noin 800 Gt . Todellisuudessa luku on pienempi, voit jakaa sen turvallisesti loogisten tilavuuksien lukumäärällä.
Varmuuskopiointipalvelinlaite
Suurin ero varmuuskopioiden tallentamiseen tarkoitetun palvelimen välillä on sen suuret, halvat ja suhteellisen hitaat levyt. Koska nykyaikaiset kiintolevyt ovat jo ylittäneet 10 Tt:n pylvään yhdellä levyllä, on tarpeen käyttää tiedostojärjestelmiä tai RAIDia tarkistussummien kanssa, koska taulukon uudelleenrakentamisen tai tiedostojärjestelmän palauttamisen aikana (useita päiviä!) toinen levy voi epäonnistua. lisääntyneeseen kuormitukseen. Levyillä, joiden kapasiteetti on enintään 1 Tt, tämä ei ollut niin herkkä. Kuvauksen yksinkertaisuuden vuoksi oletan, että levytila on jaettu kahteen suunnilleen samankokoiseen osaan (jälleen esim. LVM:llä):
- taltiot, jotka vastaavat käyttäjätietojen tallentamiseen käytettyjä palvelimia (viimeisin tehty varmuuskopio otetaan käyttöön niiden varmentamista varten);
- taltiot, joita käytetään BorgBackup-tietovarastoina (varmuuskopioiden tiedot menevät suoraan tänne).
Toimintaperiaate on, että jokaiselle palvelimelle luodaan erilliset taltiot BorgBackup-arkistoja varten, joihin taistelupalvelimien tiedot menevät. Arkistot toimivat vain liite -tilassa, mikä eliminoi mahdollisuuden tietojen tahalliseen poistamiseen sekä arkiston vanhojen varmuuskopioiden duplikoinnin ja säännöllisen puhdistuksen vuoksi (vuosittaiset kopiot säilyvät, kuukausittain viimeiseltä vuodelta, viikoittain viimeiseltä kuukaudelta, päivittäin viime viikolla, mahdollisesti erikoistapauksissa - viimeisenä päivänä tunneittain: yhteensä 24 + 7 + 4 + 12 + vuosittain - noin 50 kopiota jokaista palvelinta kohden).
BorgBackup-varastot eivät ota käyttöön vain liitetilaa, vaan ForcedCommand-komentoa tiedostossa .ssh/authorized_keys käytetään jotakuinkin näin:
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.......Määritetty polku sisältää wrapper-skriptin borgin päällä, joka sen lisäksi, että se käynnistää binaarin parametrien kanssa, käynnistää lisäksi varmuuskopion palautusprosessin tietojen poistamisen jälkeen. Tätä varten wrapper-skripti luo tunnistetiedoston vastaavan arkiston viereen. Viimeinen varmuuskopio palautetaan automaattisesti vastaavaan loogiseen taltioon tietojen täyttöprosessin jälkeen.
Tämän rakenteen avulla voit ajoittain puhdistaa tarpeettomat varmuuskopiot ja estää myös taistelupalvelimia poistamasta mitään varmuuskopion tallennuspalvelimelta.
Varmuuskopiointiprosessi
Varmuuskopioinnin aloittaja on itse omistettu palvelin tai VPS, koska tämä järjestelmä antaa paremman hallinnan tämän palvelimen varmuuskopiointiprosessiin. Ensin otetaan tilannekuva aktiivisen juuritiedostojärjestelmän tilasta, joka liitetään ja ladataan BorgBackupin avulla varmuuskopion tallennuspalvelimelle. Kun tietojen kaappaus on valmis, tilannekuva poistetaan ja poistetaan.
Jos tietokanta on pieni (enintään 1 Gt jokaiselle sivustolle), tehdään tietokantavedos, joka tallennetaan sopivaan loogiseen taltioon, jossa muu saman sivuston data sijaitsee, mutta niin, että vedos on ei ole käytettävissä web-palvelimen kautta. Jos tietokannat ovat suuria, sinun tulee määrittää "kuumien" tietojen poisto, esimerkiksi käyttämällä xtrabackupia MySQL:lle, tai työskennellä WAL:n kanssa PostgreSQL:n archive_command-komennolla. Tässä tapauksessa tietokanta palautetaan erillään sivuston tiedoista.
Jos käytetään säilöjä tai virtuaalikoneita, sinun tulee määrittää qemu-guest-agent, CRIU tai muut tarvittavat tekniikat. Muissa tapauksissa lisäasetuksia ei useimmiten tarvita - luomme yksinkertaisesti tilannekuvia loogisista taltioista, jotka sitten käsitellään samalla tavalla kuin tilannekuva juuritiedostojärjestelmän tilasta. Kun tiedot on otettu, kuvat poistetaan.
Varmuuskopiotallennuspalvelimella tehdään lisätyötä:
- viimeisin kussakin arkistoon tehty varmuuskopio tarkistetaan,
- merkintätiedoston olemassaolo tarkistetaan, mikä osoittaa, että tiedonkeruuprosessi on valmis,
- tiedot laajennetaan vastaavaan paikalliseen volyymiin,
- tunnistetiedosto poistetaan
Palvelimen palautusprosessi
Jos pääpalvelin kuolee, käynnistetään samanlainen oma palvelin, joka käynnistyy jostain tavallisesta näköistiedostosta. Todennäköisesti lataus tapahtuu verkon kautta, mutta palvelinkeskuksen asentaja voi välittömästi kopioida tämän vakiokuvan jollekin levyistä. Lataus tapahtuu RAM-muistiin, jonka jälkeen palautusprosessi alkaa:
- pyydetään liittämään lohkolaite iscsinbd:n tai muun vastaavan protokollan kautta loogiseen taltioon, joka sisältää kuolleen palvelimen juuritiedostojärjestelmän; Koska juuritiedostojärjestelmän on oltava pieni, tämä vaihe on suoritettava muutamassa minuutissa. Myös käynnistyslatain palautetaan;
- paikallisten loogisten taltioiden rakenne luodaan uudelleen, loogiset taltiot liitetään varmuuskopiopalvelimelta dm_clone ydinmoduulin avulla: tietojen palautus alkaa ja muutokset kirjoitetaan välittömästi paikallisille levyille
- kontti käynnistetään kaikilla käytettävissä olevilla fyysisillä levyillä - palvelimen toiminnallisuus palautetaan täysin, mutta suorituskyky on heikentynyt;
- kun tietojen synkronointi on valmis, loogisten taltioiden yhteys varmuuskopiopalvelimelta katkaistaan, säilö sammutetaan ja palvelin käynnistetään uudelleen;
Uudelleenkäynnistyksen jälkeen palvelimella on kaikki tiedot, jotka olivat siellä varmuuskopion luomishetkellä, ja se sisältää myös kaikki palautusprosessin aikana tehdyt muutokset.
Muut artikkelit sarjassa
Varmuuskopio Osa 7: Päätelmät
Kutsun sinut keskustelemaan ehdotetusta vaihtoehdosta kommenteissa, kiitos huomiosta!
Lähde: will.com