Právě v cephech u jednoho zákazníka upgradujeme 6TB a 8TB na 18TB disky. Tentokrát popíšeme jak recyklujeme staré disky a jak zálohujeme jednoho specifického zákazníka tak trochu jinak.
Pro jistotu doplníme, že běžné servery tímto způsobem nezálohujeme a toto je jeden velmi specifický případ.
Máme zákazníka, který uchovává celkem zajímavé množství dat - řádově se jedná o vyšší petabajty. Zákazník ale nechce platit za zálohování s tím, že se ztrátou dat počítá. To je nám ale nepříjemné, protože víme, že k incidentům dochází, docházelo a docházet bude. A zároveň se vždy dostaví v nejméně vhodnou chvíli. Servery jsou přecijen technika, která selhává, a software, ve kterém jsou chyby.
Zamysleli jsme se nad tím a definovali vlastnosti, které nám při zálohování velmi pomohou:
Také jsme si u záloh definovali vlastnosti:
Běžně se na dlouhodobý archív používají zálohovací pásky, které mají dobré i špatné vlastnosti. Zálohovací pásky mají sice vysokou kapacitu, ale při zálohování petabajtů už to nějakou nákladovou položku udělá.
Máme ale malé tisíce pevných disků různých velikostí z vyřazených serverů. Ano, také nás napadla otázka, jak to bude s obnovou dat po několika letech, kdy disk leží vypnutý. Nenašli jsem ale žádný článek, který by se tomuto podrobně věnoval. Řekli jsme si, že v rámci udržení nákladů na minimu je zkusíme pro toto offline zálohování použít.
Ve skladu, kde se pohybujeme velmi často, máme server. Do něj vložíme prázdné disky různé kapacity. Disky se naformátují, zabezpečí a připraví pro zálohování. Na jednotlivé disky se pak stahují soubory z fronty, dokud se plně nezaplní. S daty se zároveň zapíší metadata pro kontrolu konzistence. Po zaplnění disků se disky uloží do regálu, popíše se datum zálohy a velikostí disků.
Fronta se plní periodickým, rekurzivním procházení zdrojové storage, kdy se porovnává zdroj proti lokální databázi. Pokud soubor v zálohách ještě není, tak se přidá do fronty.
Nyní z trochu zajímavějšího soudku. K zálohování souborů používáme i disky, na kterých se vyskytují vadné bloky, které disk už nedokáže realokovat do svých rezerv. Vybíráme jen disky, které mají malé množství vadných bloků. Orientačně řekněme do 20, ale je to vždy individuální podle konkrétního disku. V tomto případě filesystému dáme seznam vadných bloků a počítáme s tím, že na ně nebude zapisovat.
Filesystém s kontrolou vadných bloků lze vytvořit třeba takto: mkfx.ext4 -cc /dev/sdX
.
V databázi najdeme všechny soubory, které potřebujeme obnovit. Podle data zálohy pak nalezneme potřebné disky, vložíme je do serveru a data z nich postupně obnovujeme.
Praktické zkušenosti s obnovou
Data obnovujeme velmi zřídka, ale už se nám několikrát stalo, že to bylo potřeba. Vždy jsme byli schopni obnovit okolo 95% souborů, zbylé soubory ještě zazálohované nebyly. Jen v minimálním množství nešlo soubor přečíst.
Konkrétní čísla a chybovost
Protože z datacentra nyní vyřazujeme 6TB a 8TB disky, tak i ze zálohování vyřazujeme 2TB disky. Při přesunu dat z 2TB disků na větší jsme se připravili malou statistiku.
Mile nás překvapila velmi malá chybovost čtení. Pro rekapitulaci:
Musíme ale přiznat, že 35 souborů bylo z disků s vadnými bloky, takže zde nějaká souvislost určitě je.
Kdybychom ale implementovali erasure code v aplikační části a zálohy rozkládali např. v režimu 3+1 na 4 disky, tak věříme, že čitelnost záloh bude 100% i za použití disků s vadnými bloky. To by ale zase vyžadovalo lepší organizaci disků a investici do vývoje takového řešení.
Vezmeme-li v potaz, že pro zákazníka je to v tomto případě služba navíc, která je hlavně pro náš vnitřní klid, tak řešení funguje naprosto skvěle a daleko nad naše původní očekávání.