Nejprve poznámka. Budu mluvit o RAID a tedy zapomeňte na nesmyslné RAID0, RAID STRIP, které NEJSOU žádné RAID, ale byly názvoslovně vytvořeny aby jednoduše doplnili výraz pro jednu z možností řadičů. Bohužel princip RAID0(STRIP) odporuje a jde přímo proti významu svého vlastního názvu, tedy Redundantní.Nebudu radit, spíš napíšu jak to řeším já. Vím, že to není 100% řešení, ale myslím, že je zcela postačující.HW RAID typu MIRROR jsem opustil. Místo toho mám vlastnoručně postavený NAS, na který kopíruji vše dle potřeby. Například důležitá data, jako dokumenty či fotografie nebo video z oslavy nakopíruji okamžitě, když si ovšem stáhnu nějakou aplikaci tak ji nejprve odzkouším a teprve až se rozhodnu, tak ji zkopírují či přesunu na NAS...Samotný NAS má pak 3 disky. 1 systémový a 2 datové. Dále pak mám další 2 běžné disky, volně ložené v šuplíku. Datové disky v NASu zrcadlím pomocí software 1 denně. Jako software používám FBackup (Free Backup) nebo se dá použí i Cobian Backup (se mi zdá pomalejší, ale žádné měření jsem nedělal). Jednou za 1/4 roku udělám kopii datového disku na ony dva, volně ložené disky.Některá data mám tedy na 4 discích (někdy i na 5, když je mám ještě v PC), z toho na 2 aktuální (PC a 1. datový v NAS), na druhém(2. v NAS) s max. denním zpožděním a na dalších dvou (volně ložených) 1/4 letní zálohu.Mé důvody, proč to řeším takto. HW RAID zabrání ztrátě jen v případě, kdy pevný disk odejde do věčných lovišť po stránce HW. I když to není nic neobvyklého, nestává se to až zas tak často. Obvykle lze na problémy s HW u HDD přijít s předstihem díky SMART, ale ani to není všemohoucí. Někdy HDD prostě umře bez varování. HW RAID tedy řeší tyto případy. Co se ovšem stane, když něco (vir, nenadálý výpadek el. proudu, ...) pokazí souborový systém a/nebo soubory jako takové? HW RAID zapíše otrocky nesmysly na oba disky, tedy redundance pomocí druhého disku je pro takový případ k ničemu.… Proto dělám zrcadlení pomocí aplikace. Ano, je tu pravděpodobnost, že zrovna mezi jednotlivými zrcadleními odejde disk (nebo i při samotném zrcadlení), ale případná ztráta je pouze ve změnách a tedy záleží na tom, jak často spouštím zrcadlení. Chybu zahlašuje samotný OS, který zobrazí hlášku o nemožnosti zkopírovat daný soubor. To znamená, že i poškozený disk se nechá dále číst a cílový disk je přenosu chyby ušetřen (to ovšem v případě, že chyba souhrou okolností není takového rázu, že kontrolní kód souboru sedí i přes chybu...). Denní přírůstky/změny nebývají takového rozsahu, že by samotné zrcadlení muselo trvat dlouho. Nestalo se mi, že by bylo delší jak 5 minut na 3TB disku (kdy aplikace zjišťuje změny a tedy prochází všechny soubory na disku a přenáší jen změny). Nakonec, každý disk je sám sebou a tedy se s ním dá pracovat všude tam, kde přečtou konkrétní souborový systém a je na vás, zda budete pracovat na Windows, Linuxu nebo jiném OS...Možná si říkáte, že je to příliš složité a musím mít hodně disků. Na to říkám, že není. Zrcadlení si jednou nastavíte a pak se provádí samo. Při denním (nebo 1/2 denním či kratším, dle vašich potřeb) intervalu máte navíc výhodu v tom, že pokud si něco nechtěně "natvrdo" smažete (a má to už svou kopii), tak to stále existuje v zrcadlu (HW RAID to smaže na obou discích a konec). Proč tolik disků? A je jich vůbec moc? Odpověď je myslím jasná na obě otázky. "Pojistka" na první otázku a "Není" druhou otázku. (Disků není nikdy dost.) Vše min. ve dvou kopiích, a ty 1/4 letní zálohy jsou nezbytné, protože kdyby odešlo v NASu něco co odpálí oba disky (blesk, poškozený napájecí zdroj,...), tak je po zálohách. DVD nebo BlueRay jsou pro uchování dat stejně "kvalitní", ale mnohem méně praktické a drahé (Nepočítám speciality, které mají vydržet 100 let, ale ty nejsou drahé, ale zatraceně drahé.)...Dodatek: Zrovna včera jsem navyšoval kapacitu NASu, kdy jsem měnil disky za 4TB Data jsem ze 3TB zkopírovat na 4TB prostým kopírováním (žádné speciální nástroje). Výměna disků je v tomto případě triviální. Už jste někdo zkoušel měnit v RAIDu disky za větší? Kdo ano, tak uzná, že to není činnosti pro BFU (Běžný Franta Uživatel)... Ukázat celý příspěvek