Ši pastaba užbaigia atsarginės kopijos kūrimo ciklą. Jame bus aptartas logiškas dedikuoto serverio (arba VPS), patogus atsarginiam kopijavimui, organizavimas, taip pat bus pasiūlyta galimybė greitai atkurti serverį iš atsarginės kopijos be didelių prastovų įvykus nelaimei.
Neapdoroti duomenys
Dedikuotas serveris dažniausiai turi bent du standžiuosius diskus, kurie padeda organizuoti pirmojo lygio RAID masyvą (veidrodį). Tai būtina norint toliau valdyti serverį, jei vienas diskas sugenda. Jei tai įprastas dedikuotas serveris, SSD gali būti atskiras aparatinės įrangos RAID valdiklis su aktyvios talpyklos technologija, kad būtų galima prijungti ne tik įprastus standžiuosius diskus, bet ir vieną ar daugiau SSD. Kartais siūlomi dedikuoti serveriai, kuriuose vieninteliai vietiniai diskai yra SATADOM (maži diskai, struktūriškai „flash drive“, prijungtas prie SATA prievado), ar net paprastas mažas (8–16 GB) „flash drive“, prijungtas prie specialaus vidinio prievado, ir duomenys paimami iš saugojimo sistemos, prijungti per tam skirtą saugojimo tinklą (Ethernet 10G, FC ir kt.), ir yra dedikuoti serveriai, kurie įkeliami tiesiai iš saugojimo sistemos. Tokių variantų nesvarstysiu, nes tokiais atvejais serverio atsarginių kopijų kūrimo užduotis sklandžiai pereina saugojimo sistemą prižiūrinčiam specialistui, dažniausiai yra įvairių patentuotų momentinių nuotraukų kūrimo, įmontuoto dubliavimo ir kitų sistemos administratoriaus džiaugsmų technologijos. , aptartas ankstesnėse šios serijos dalyse. Dedikuoto serverio diskų masyvo tūris gali siekti kelias dešimtis terabaitų, priklausomai nuo prie serverio prijungtų diskų skaičiaus ir dydžio. VPS atveju apimtys kuklesnės: dažniausiai ne daugiau 100GB (bet būna ir daugiau), o tokių VPS tarifai nesunkiai gali būti brangesni nei pigiausių dedikuotų serverių iš to paties prieglobos. VPS dažniausiai turi vieną diską, nes po juo bus saugojimo sistema (arba kažkas hiperkonverguoto). Kartais VPS turi keletą skirtingų charakteristikų diskų, skirtų skirtingiems tikslams:
- maža sistema - operacinei sistemai įdiegti;
- didelis – talpinanti vartotojo duomenis.
Kai iš naujo įdiegiate sistemą naudodami valdymo skydelį, diskas su vartotojo duomenimis neperrašomas, tačiau sistemos diskas visiškai užpildomas. Taip pat VPS atveju prieglobos serveris gali pasiūlyti mygtuką, kuris nufotografuoja VPS (arba disko) būseną, tačiau jei įdiegiate savo operacinę sistemą arba pamiršote aktyvuoti norimą paslaugą VPS viduje, kai kurie duomenų vis tiek gali būti prarasta. Be mygtuko dažniausiai siūloma duomenų saugojimo paslauga, dažniausiai labai ribota. Paprastai tai yra paskyra su prieiga per FTP arba SFTP, kartais kartu su SSH, su pašalintu apvalkalu (pavyzdžiui, rbash) arba apribojus komandų vykdymą naudojant įgaliotus_raktus (per ForcedCommand).
Dedikuotas serveris yra prijungtas prie tinklo dviem prievadais, kurių greitis yra 1 Gbps, kartais tai gali būti kortelės, kurių greitis yra 10 Gbps. VPS dažniausiai turi vieną tinklo sąsają. Dažniausiai duomenų centrai neriboja tinklo greičio duomenų centre, tačiau riboja interneto prieigos greitį.
Įprasta tokio dedikuoto serverio arba VPS apkrova yra žiniatinklio serveris, duomenų bazė ir programų serveris. Kartais gali būti įdiegtos įvairios papildomos pagalbinės paslaugos, įskaitant žiniatinklio serveriui ar duomenų bazei: paieškos sistema, pašto sistema ir kt.
Specialiai paruoštas serveris veikia kaip erdvė atsarginėms kopijoms saugoti, apie tai plačiau parašysime vėliau.
Loginis disko sistemos organizavimas
Jei turite RAID valdiklį arba VPS su vienu disku, o disko posistemio veikimui nėra specialių nuostatų (pavyzdžiui, atskiras greitas diskas duomenų bazei), visa laisva vieta padalijama taip: vienas skaidinys yra sukurtas, o ant jos sukuriama LVM tomų grupė , joje sukuriami keli tomai: 2 maži tokio pat dydžio, naudojami kaip šakninė failų sistema (atnaujinant keičiami po vieną, kad būtų galima greitai atkurti, idėja buvo paimta iš „Calculate Linux“ platinimo), kitas skirtas apsikeitimo skaidiniui, likusi laisvos vietos dalis yra padalinta į mažus tūrius, naudojama kaip šakninė failų sistema pilnaverčiams konteineriams, diskams virtualioms mašinoms, failams /home paskyrų sistemos (kiekviena paskyra turi savo failų sistemą), programų konteinerių failų sistemos.
Svarbi pastaba: tūriai turi būti visiškai savarankiški, t.y. neturėtų priklausyti vienas nuo kito arba nuo šakninės failų sistemos. Virtualiose mašinose ar konteineriuose šis taškas stebimas automatiškai. Jei tai yra programų konteineriai arba namų katalogai, turėtumėte pagalvoti apie žiniatinklio serverio ir kitų paslaugų konfigūracijos failų atskyrimą taip, kad būtų kuo labiau pašalintos priklausomybės tarp tomų. Pavyzdžiui, kiekviena svetainė veikia nuo savo vartotojo, svetainės konfigūracijos failai yra vartotojo namų kataloge, žiniatinklio serverio nustatymuose, svetainės konfigūracijos failai neįtraukti per /etc/nginx/conf.d/.conf ir, pavyzdžiui, /home//configs/nginx/*.conf
Jei yra keli diskai, galite sukurti programinės įrangos RAID masyvą (ir sukonfigūruoti jo talpyklą SSD diske, jei yra poreikis ir galimybė), ant kurio galite sukurti LVM pagal aukščiau pasiūlytas taisykles. Taip pat šiuo atveju galite naudoti ZFS arba BtrFS, tačiau apie tai turėtumėte gerai pagalvoti: abiem reikia daug rimtesnio požiūrio į išteklius, be to, ZFS nėra įtrauktas į Linux branduolį.
Nepriklausomai nuo naudojamos schemos, visada verta iš anksto įvertinti apytikslį pakeitimų įrašymo į diską greitį, o tada apskaičiuoti laisvos vietos kiekį, kuris bus rezervuotas momentinėms nuotraukoms kurti. Pavyzdžiui, jei mūsų serveris duomenis rašo 10 megabaitų per sekundę greičiu, o viso duomenų masyvo dydis yra 10 terabaitų - sinchronizavimo laikas gali siekti parą (22 val. - tiek bus perduota tokia apimtis per tinklą 1 Gbps) – verta rezervuoti apie 800 GB . Tiesą sakant, šis skaičius bus mažesnis, galite saugiai padalyti jį iš loginių tūrių skaičiaus.
Atsarginės kopijos saugojimo serverio įrenginys
Pagrindinis skirtumas tarp serverio, kuriame saugomos atsarginės kopijos, yra dideli, pigūs ir santykinai lėti diskai. Kadangi šiuolaikiniai HDD jau peržengė 10 TB juostą viename diske, būtina naudoti failų sistemas arba RAID su kontroliinėmis sumomis, nes masyvo atkūrimo ar failų sistemos atkūrimo metu (kelias dienas!) antrasis diskas gali sugesti. prie padidėjusios apkrovos. Diskuose, kurių talpa iki 1 TB, tai nebuvo taip jautru. Kad būtų lengviau aprašyti, darau prielaidą, kad vieta diske yra padalinta į dvi maždaug vienodo dydžio dalis (vėlgi, pavyzdžiui, naudojant LVM):
- tomai, atitinkantys serverius, naudojamus vartotojo duomenims saugoti (paskutinė sukurta atsarginė kopija bus įdiegta juose patikrinti);
- tomai, naudojami kaip „BorgBackup“ saugyklos (atsarginių kopijų duomenys pateks tiesiai čia).
Veikimo principas yra toks, kad kiekvienam serveriui BorgBackup saugykloms sukuriami atskiri tomai, į kuriuos pateks duomenys iš kovinių serverių. Saugyklos veikia tik papildymo režimu, kuris pašalina galimybę tyčia ištrinti duomenis ir dėl saugyklų dubliavimo ir periodinio valymo iš senų atsarginių kopijų (lieka metinės kopijos, kas mėnesį už paskutinius metus, kas savaitę už paskutinį mėnesį, kasdien praėjusią savaitę, galbūt ypatingais atvejais - kas valandą paskutinę dieną: iš viso 24 + 7 + 4 + 12 + per metus - maždaug 50 egzempliorių kiekvienam serveriui).
„BorgBackup“ saugyklos neįjungia tik pridėjimo režimo; vietoj to naudojama „ForcedCommand“ .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.......Nurodytame kelyje borg viršuje yra įvyniojimo scenarijus, kuris, be dvejetainio su parametrais paleidimo, papildomai pradeda atsarginės kopijos atkūrimo procesą pašalinus duomenis. Norėdami tai padaryti, įpakavimo scenarijus sukuria žymos failą šalia atitinkamos saugyklos. Paskutinė atsarginė kopija automatiškai atkuriama į atitinkamą loginį tūrį, kai baigiamas duomenų pildymo procesas.
Ši konstrukcija leidžia periodiškai išvalyti nereikalingas atsargines kopijas, be to, kovos serveriai neleidžia nieko ištrinti atsarginės kopijos saugojimo serveryje.
Atsarginės kopijos kūrimo procesas
Atsarginės kopijos kūrimo iniciatorius yra dedikuotas serveris arba pats VPS, nes ši schema suteikia daugiau galimybių valdyti atsarginės kopijos kūrimo procesą iš šio serverio pusės. Pirmiausia padaroma aktyvios šakninės failų sistemos būsenos momentinė nuotrauka, kuri sumontuojama ir įkeliama naudojant BorgBackup į atsarginės kopijos saugojimo serverį. Užbaigus duomenų fiksavimą, momentinė nuotrauka pašalinama ir ištrinama.
Jei yra nedidelė duomenų bazė (iki 1 GB kiekvienai svetainei), sukuriamas duomenų bazės iškrovimas, kuris išsaugomas atitinkamame loginiame tūryje, kuriame yra likę tos pačios svetainės duomenys, bet taip, kad išrašas būtų nepasiekiamas per žiniatinklio serverį. Jei duomenų bazės yra didelės, turėtumėte sukonfigūruoti „karštų“ duomenų pašalinimą, pavyzdžiui, naudodami „xtrabackup“, skirtą „MySQL“, arba dirbti su WAL su „archive_command“ sistemoje „PostgreSQL“. Tokiu atveju duomenų bazė bus atkurta atskirai nuo svetainės duomenų.
Jei naudojami konteineriai ar virtualios mašinos, turėtumėte sukonfigūruoti qemu-guest-agent, CRIU ar kitas reikalingas technologijas. Kitais atvejais papildomų nustatymų dažniausiai nereikia – tiesiog sukuriame loginių tomų momentines nuotraukas, kurios vėliau apdorojamos taip pat, kaip ir pagrindinės failų sistemos būsenos momentinė nuotrauka. Paėmus duomenis nuotraukos ištrinamos.
Tolesnis darbas atliekamas atsarginės kopijos saugojimo serveryje:
- patikrinama paskutinė atsarginė kopija, padaryta kiekvienoje saugykloje,
- patikrinama, ar yra žymų failas, nurodantis, kad duomenų rinkimo procesas baigtas,
- duomenys išplečiami iki atitinkamo vietinio tomo,
- žymos failas ištrintas
Serverio atkūrimo procesas
Jei pagrindinis serveris miršta, paleidžiamas panašus dedikuotas serveris, kuris paleidžiamas iš standartinio vaizdo. Labiausiai tikėtina, kad atsisiuntimas vyks per tinklą, tačiau duomenų centro technikas, nustatantis serverį, gali iš karto nukopijuoti šį standartinį vaizdą į vieną iš diskų. Atsisiuntimas vyksta į RAM, po kurio prasideda atkūrimo procesas:
- pateikiamas prašymas prijungti blokinį įrenginį per iscsinbd ar kitą panašų protokolą prie loginio tomo, kuriame yra mirusio serverio šakninių failų sistema; Kadangi šakninių failų sistema turi būti maža, šis veiksmas turėtų būti atliktas per kelias minutes. Taip pat atkurta įkrovos programa;
- atkuriama vietinių loginių tomų struktūra, loginiai tomai prijungiami iš atsarginio serverio naudojant branduolio modulį dm_clone: prasideda duomenų atkūrimas, o pakeitimai iškart įrašomi į vietinius diskus
- paleidžiamas konteineris su visais turimais fiziniais diskais - serverio funkcionalumas visiškai atkurtas, tačiau sumažėjęs našumas;
- užbaigus duomenų sinchronizavimą, loginiai tomai nuo atsarginio serverio atjungiami, konteineris išjungiamas ir serveris paleidžiamas iš naujo;
Po perkrovimo serveris turės visus duomenis, kurie buvo atsarginės kopijos kūrimo metu, taip pat visus pakeitimus, kurie buvo atlikti atkūrimo proceso metu.
Kiti serijos straipsniai
Atsarginė kopija 7 dalis: Išvados
Kviečiu komentaruose aptarti siūlomą variantą, ačiū už dėmesį!
Šaltinis: www.habr.com