Rūpintis savo duomenų saugumu reikia nuolat ir reikia tai daryti patiems. Atsarginės kopijos turi būti daromos nuolat ar bent jau kai pagalvoji, kad gal reikėtų jas padaryti. :) Tačiau pačios sistemos apsaugojimui nuo netikėto disko gedimo rekomenduojama daryti veidrodinį ar aukštesnio lygio RAID masyvą. Ir, kaip parodė praktika - pageidautina viename diske neturėti keleto masyvų.
Bet, pasirodo yra niuansų, todėl turėdami RAID1 veidrodinį masyvą - dar negalite būti tikri, kad nusprogus vienam iš diskų, jūsų sistema liks veiksni. Jau nė nekalbant apie duomenų teisingumą. Todėl - rezervinės kopijos ir dar kartą rezervinės kopijos. Net ir sisteminiams diskams, kur saugoma sistema ir jos konfigūracija. Nes pačią sistemą įdiegti galima greitai, tačiau prie visų reikiamų programų diegimo ir konfigūravimo kartais galima praleisti ir ne vieną dieną. Blogiau, kai apie tokius niuansus išsiaiškini sugedus būtent rezervines kopijas saugančio serverio diskui. :)
Taigi apie viską iš eilės.
Praėjusio savaitgalio vakare serveris kažkaip atkreipė mano dėmesį, nes buvo neįprastai tylus. Anot Šreko: it's quiet, too quiet... Pabandžius prisijungti nuotoliniu būdu - buvau nudžiugintas pranešimu: "no route to host". Tai rodė, kad serveris yra nugriuvęs pagal pilną programą. Įjungus monitorių, ekrane puikavosi užstrigęs grafinės sąsajos vaizdas (buvo reikalingas Nvidia spartintuvams veikti). Na, nusprendžiau, kaip tik laikas perrinkti serverį ir atskirti serverį nuo GPU skaičiavimo sistemos. Taigi perrinkus server io komponentus į naują korpusą įjungiau ir buvau pasveikintas gausia disko klaidų puokšte. Tapo aišku, kad vienas iš masyvo SSD diskų pasiilgo garantinio serviso.
Klaidų pranešimai gan akivaizdžiai nurodė, kad SATA0 diskui yra šakutės, tad daug nedvejodamas, atjungiau kaupiklį ir įjungęs kompiuterį buvau pasveikintas pranešimu: 'volume group "rootvg" was not found' ir kuklia GRUB įkrovos tvarkyklės komandine eilute. WTF??? Taigi RAID1 masyvas turi veikti ir su vienu disku... Paleidus kompiuterį su SATA0 kaupikliu jis įsikrovė, bet vos tik pradėjus naudoti - ėmė spjaudytis klaidomis. Dar po kelių bandymų įkrauti su abejais kaupikliais pastebėjau, kad kompiuteris gali įsikrauti, jei yra prijungtas SATA0 diskas, bet prasidėjus RAID1 veidrodžio sinchronizavimui, po keleto minučių viskas užstringa, nes vėl pasipila klaidos.
Teko susirasti „Linux Mint“ įdiegimo USB atmintinę ir įkrovus sistemą iš jos, imtis "skrodimo". O skrodimas parodė, kad paciento mirties priežastis buvo skrodimas... Realiai susidarė tokia situacija, kad SATA0 diskas iš tiesų sugedo ir skaitant duomenis iš jo, nuo kažkurio tai sektoriaus pasipila klaidos ir kaupiklis tampa nebepasiekiamas. Bet prie to pačio RAID1 tvarkyklė nusprendė, kad SATA0 diskas turi naujesnę duomenų kopiją ir masyvą reikia sinchronizuoti būtent iš jo. Ir kompiuterio krovimosi metu, kai masyvas yra "surenkamas" SATA0 diskas pridedamas, kaip aktyvus, o fiziškai geras SATA1 diskas, pridedamas, kaip papildomas ("spare"). Ir tuomet pradedama masyvo sinchronizacija, kuri baigiasi tuo, kad SATA0 nustoja reaguoti į komandas.
Kas įdomiausia , tai kad apie jokius gedimus negavau jokios žinios. Abiems diskams buvo aktyvuotas periodinis SMART testavimas, kuris rodė, kad jokių klaidų nėra. Rankiniu būdu paleistas tiek greitas, tiek ilgas SMART testas taip pat sėkmingai baigė savo darbą, neparodydamas jokių klaidų. Taigi teoriškai - naujas diskas (pirktas praėjusių metų gruodžio pabaigoje), praktiškai - neveikia.
Nekrologas, nekrologu, bet labai jau nesinorėjo pripažinti pralaimėjimą ir perinstaliuoti sistemą - visi duomenys yra kitame RAID5 masyve su įprastiniais magnetiniais diskais. Todėl atsiraitojau rankoves ir ėmiausi bandymu įtikinti RAID masyvo tvarkyklę paleisti masyvą su likusiu vienu disku. Geruoju to padaryti nepavyko, nes mdadm užsispyrusiai pridėdavo diską, kaip pakaitinį „Spare“ ir sakydavo, kad nepakanka aktyvių diskų paleisti masyvą.
mdadm --assemble --force /dev/md1 /dev/sda2
Tuomet pasiknaisiojus po internetą radau komandą build, kuri palikta suderinamumui su senesnės kartos mdadm RAID masyvais, nesaugojusiems metaduomenų diske. Internetas sufleravo, kad tokia komanda turėtų leisti sukurti masyvą:
mdadm --build /dev/md1 --force --level=1 --raid-devices=2 /dev/sda2 missing
Ir iš tiesų tai padėjo ir masyvas pasileido. Tačiau tik laikinai, nes nerašius metaduomenų, /dev/sda2 liko pažymėtas, kaip pakaitinis diskas ir perkrovus kompiuterį - gaudavau tik GRUB įkrovos komandinę eilutę. Kaip nurodo LVM HowTo puslapis bei kiti šaltiniai mdadm --create galima naudoti tik jei diskai yra nauji arba jūs tikrai žinote, ką darote. Pasirodo tai buvo būtent šis atvejis ir --create leido atkurti RAID avariniame („degraded“) režime.
mdadm --build /dev/md0 --force --level=1 --raid-devices=2 /dev/sda1 missingmdadm --build /dev/md1 --force --level=1 --raid-devices=2 /dev/sda2 missing
Tačiau tuo nuotykiai dar nesibaigė, nes nepaisant to, kad RAID masyvas pradėjo veikti, sisteminės LVM tomų grupės aktyvuoti nepavyko. Tikėtina, kad iš naujo sukūrus RAID masyvą pasikeitė kokie nors ID ir išsitrynė LVM fizinio tomo žymė. Pasitelkus puslapį pavyko rasti, kaip iš naujo perkurti fizinį LVM tomą (PV), nurodant senojo tomo UUID reikšmę. Tik teko kiek labiau pavargti, nes /etc/lvm turinys buvo būtent toje LVM tomų grupėje, kurią ir ketinau atkurti. Laimei šių duomenų kopija yra sistemos init diske (initrd). Tam tereikėjo prisijungti /dev/md0 kuriame buvo saugoma /boot skirsnio informacija. Tik vėl yra grėblys. Jei naudojate naujus branduolius, tai įprastas initrd archyvo išpakavimas, pasitelkiant cpio nesuveiks, tam reikia naudoti unmkinitramfs, antraip išpakuosite tik nedidelę initrd turinio dalį.
mkdir /tmp-bootmount /dev/md0 /tmp-bootcp /tmp-boot/initrd.img-5.4.0-62-generic /tmp/cd /tmpunmkinitramfs -v initrd.img-5.4.0-26-generic .
Tada visą seną LVM konfigūraciją pavyko rasti /tmp/main/etc/lvm/backup kataloge. Jame buvo rootvg byla, kurioje buvo aprašytas mano fizinis tomas ir jo UUID:
...pv0 { id = "GDoi0z-DkxX-inX4-v24r-HumU-7pU1-oTjve8" device = "/dev/md1" # Hint only...
Ir turėdamas tą UUID jau galėjau paleisti:
pvcreate --uuid "GDoi0z-DkxX-inX4-v24r-HumU-7pU1-oTjve8" \--restore /tmp/main/etc/lvm/backup/rootvg /dev/md1vgcfgrestore rootvg
Tiesa, nors po viso šito sistemą jau buvo galima įkrauti, tačiau ji sėkmingai pakibdavo. To priežastis - dėl nepabaigtos RAID sinchronizacijos sudarkyta failinė sistema. Paprastai fsck turėtų pasileisti automatiškai, jei failinė sistema yra pažymima, kaip „nešvari“, bet dėl kažkokių priežasčių taip nenutikdavo ir sistemos šaknis „/“ tapdavo prieinama tik skaitymui. Dėl šios priežasties nebuvo galima sukurti /forcefsck failo, kuris nurodytų sistemai patikrinti diską, įkrovos metu. Taigi teko imtis gudrybių. Paprastai sistema tikrina failų sistemą, kai yra nustatoma „nešvaros“ žymė arba, kai failų sistema yra prijungiama daugiau nei N-tąjį kartą. Pasitelkus tune2fs priemonę galima pakoreguoti failinės sistemos parametrus, pavyzdžiui, root vartotojui rezervuojamos vietos kiekį. Tačiau galima pakeisti prijungimo skaičių ir padaryti jį didesniu, nei numatytas maksimalus galimas. Tuomet kitos įkrovos metu sistema automatiškai paleis failų sistemos tikrinimo priemonę.
tune2fs -l /dev/rootvg/root | grep -i Mount#Skaičius didesnis, nei Maximum mount counttune2fs -C 34 /dev/rootvg/root
Po viso šito sistema įsikrovė, tačiau Kubernetes aplinką teko diegti iš naujo, nes kai kurie duomenys diske buvo sugadinti ir Etcd duomenų bazė nebepasileido. Taigi reziumuojant rezervinių kopijų serveriui taip pat praverstų padaryti rezervines kopijas, nes atkūrimas iš rezervinės kopijos būtų trukęs greičiau, nei iki 4 ryto. :) Na galbūt šie nuotykiai kažkam pravers.