Disky jsou mechanické výrobky a ty prostě občas odcházejí. Běžná věc. Pro snížení rizika ztráty dat se vymyslel systém pojmenovaný zkratkou RAID (Redundant Array of Inexpensive/Independent Disks — Pole nadbytečných levných / nezávislých disků). RAID není záloha, to se často opakuje a laici to nechtějí slyšet.
Asi před 14 dny mi odešel jeden disk. Výrobce v tomto článku nebudu uvádět, abych nezavdával příčinu zbytečnému flame. Disk měl naběháno přes 2.3 roku (smart údaj power_on_hours něco přes 20’000). To je celkem dost na odchod do křemíkového nebe. Disk jsem vyměnil apole sesynchronizoval. Data zůstala neohrožena.
Dnes mi raid monitoring zahlásil, že se loučí s dalším diskem (má 13 vadných sektorů) a to ve stejném poli (mirroru). Tento disk (jiného výrobce, než předchozí) má odpracováno pouze 9’000 hodin, což je málo, půjde na reklamaci. Kdyby si ovšem s touto závadou pospíšil o 14 dnů (oba disky by selhaly současně), data by již nebyla.
Na tomto chci ilustrovat jeden z důvodů, proč RAID není záloha. Při poruše jednoho disku může totiž dojít i k poruše toho druhého. Není to jev častý, ale má nenulovou pravděpodobnost. Porucha je také „podpořena“ synchronizací pole, kdy oba disky jedou několik hodin na 100%.
Stále tedy platí, zálohovat, zálohovat, zálohovat.
To se má TSB na co těšit, oba disky jsou v záruce.
jak dlouho presne trvalo, nez jsi vymenil ten prvni vadny disk? Jsem laik a stale mi mirror prijde dostatecne spolehlivy :-), kdysi jsem to myslim jaksi pocital, zkusim pohledat.
V podstatě dva dny. Je třeba koupit nový, připojit do pole a nechat sesynchronizovat (synchronizace samotná potom trvá cca 5 hodin).
Co se týče té spolehlivosti, nějaké statistické vzorečky jsou wiki (http://en.wikipedia.org/wiki/RAID_1#RAID_1).
Mirror spolehlivý je, ale chtělo by to mít nachystaný spare disk (ideálně připojený v serveru), aby se začalo synchronizovat co nejdříve. Takhle jsou pár dnů ohrožena všechna data (mám 3 mirrory spojené do velkého LVM oddílu, kdybych přišel o jeden mirror, přijdu o všechna data). Také třeba i z tohoto důvodu je stále nutné zálohovat. :-)
No, ono je jednak otazka, za jak dlouho se to pole spravi, kdyz umre disk – da se to urychlit spare diskem, tak, aby obnova zacala hned, jak se zjisti problem, ale porad zustavaji varianty, jak o data prijit. No a nejednou jsem se setkal s tim, ze to, ze spare disk nefunguje se zjistilo prave ve chvili, kdy ho to chtelo pouzit – radice spare disk sice obcas testuji a mely by chybu odhalit, ale ne vzdy to funguje dokonale.
Jedna z moznosti je chyba uzivatele, ktera je castejsi nez chyba hardwaru – proste neco nechte smazu – pokud nemam zalohu, tak me RAID nezachrani.
Co jsem ale uz parkrat taky potkal byla zavada zdroje, pri ktere odeslo nekolik komponent z pocitace. Treba vsechny disky najednou – ani tady sebelepsi RAID nepomuze.
Pěkné. Měl jsi štěstí. Já tohle obvykle demonstruji takto:
[lzap@lzapx important_folder_on_the_raid]# pwd
/mnt/raid/important_folder_on_the_raid
[lzap@lzapx important_folder_on_the_raid]# rm -rf .
[lzap@lzapx important_folder_on_the_raid]#
Oops. Data jsou pryč. Konec. Finito. Hotovo. Bez zálohy ani ránu. A není záloha jako záloha. Musí mít nějakou tu historii, aby se mohly obnovit omylem smazané soubory.
Zrovna tento víkend jsem přeinstalovával svůj domácí Ubuntu Server na RHEL6. Kromě jiného se mi přihodilo toto při použití jednoho staršího disku z hw RAID pole: http://www.abclinuxu.cz/poradna/linux/show/333133
To ale není to důležité. RAID jsem zrušil, v tohle případě nemá smysl. Měl jsem tam RAID5 a nakonec jsem se rozhdl to zrušit a udělat si tam jen LVM s dvěma volume grupami. Jedna „safe“ a druhá „unsafe“. Důležité je, aby safe a unsafe nebyly na stejných fyzických discích. Musí to být rozděleno (já mám např. 1 + 2).
No a v rc.local skriptu pak dělám inkrementální „snapshoty“ pomocí hardlinků a rsyncu (popsáno např. http://www.mikerubel.org/computers/rsync_snapshots/#Incremental). Ačkoli mám na „safe“ několik set giga, trvá to pár vteřin (vytvoří se jen adresářová struktura hardlinků a pak se findem smaže vše starší 60 dní).
Výhoda je jasné. 1) žádný RAID (vždy je lepší mít jednodušší konfiguraci); 2) záloha vyřešena (stejnak bych ji potřeboval); 3) operativnější využití prostoru (RAID5 prostě ukrojí 30 % místa bez diskuze – v mém případě mám jakýs takýs prostor pro manipulaci).
Co se tím snažím říct? Že ne vždy je RAID pole ideální. Do produkčních serverů ano, na domácí „servřík“ s databází fotek a nějakýma těma HD nahrávkama nikoliv.
Jo abych nezapomněl – dělám to v rc.local skriptu páč si servřík jen pustím, když potřebuju. Samozřejmě by se to mohlo dělat z cronu, nebo i jinak.
K té inkrementální záloze, dost mi to připomíná hotový balíček rsnapshot (používám jej na zálohy) a dělá to, co jsi popsal (odkazovný návod jsem nestudoval).
Ještě k tomu tvému řešení, chápu to dobře, že ono safe a unsafe (tedy pracovní prostor a safe) máš na jednom HW (jeden PC)? Potom může ale nastat situace, kterou popsal Petr. Tedy, že odejdou všechny disky. Potom nepomůže ani RAID, ani tohle inkrementální řešení. Shodou okolností jsem teď v pátek vyměňoval jeden shořelý zdroj, zbytek PC zůstal nepoškozen.
Takže, já osobně hledám řešení jak ochrany dat před výpadkem HW (což je pro mě mirror – RAID1, RAID5 je nechutně pomalý pro práce s DB) a zároveň bezpečnou zálohu pro případ smazání ale i výpadku HW. Tedy pracovní data mám na serveru s mirrorovanými disky, s výhodou též používám verzovací systém (na všechny dokumenty, chtěl bych to i na fotky, ale to zatím dost dobře nejde) i jako ochranu proti náhodnému smazání a tato data ještě občas (po přidání významných dat) odzálohovávám na externí disk.
Ono samozřejmě žádné řešení není ideální a pro každé použití se hodí něco jiného. Já takto de facto přicházím o 50% kapacity disku (3x mirror nad 2xHDD = 6HDD ale „jen“ 3HDD místa), ale toto jsem ochoten akceptovat pro ochranu těch dat. Mimo to ještě používám zálohovací disk, takže reálně využití místa je ještě menší než těch 50%.
Osobně se velmi těším na nové systémy souborů jako je ZFS (v linuxu nejspíše nikdy nebude) a hlavně BTRFS. Jednak na úložiště nad mnoha disky (i když, co jsem si zkoušel v Debianu, tak se to chová trochu jinak, než jsem si vysnil) a nové typy softwarových raidů, ale také na snapshoty FS, pro vybrané „adresáře“ (subvolumes) transparentí kompresi, časem deduplikaci bloků apod.
Zejména ty snapshoty by se mi velmi hodily, dnes tuto funkcionalitu supluji pomocí gitu (případně pomocí rsnapshot), ale to nad adresářem, který má pár desítek GB není to pravé ořechové.
Ani tento nový úžasný FS nás nezbaví nutnosti zálohy na externí úložiště, ale určitě spříjemní práci s daty a efektivní rozložení dat na discích.