Domaci NAS v2

4.9.2015 15:23 | Přečteno: 1705× | poslední úprava: 4.9.2015 15:23

Dozrela doba na upgrade mojho domaceho NAS.

Momentalne bezim na D-Link DNS320, co je dvojslotovy domaci NAS postaveny nad (dost osekanym) linuxom. Prevazne skladuje fotky, backupy prace z PC a bezi len "on request", tzn. zapnem ho ked potrebujem. Su v tom 2x2TB disky, pricom ich nepouzivam ako RAID-1, ale jeden disk je "produkcny" a druhy zalozny, na ktory (obcas) prelievam zalohy. Primarnym dovodom, preco to pouzivam prave v tomto rezime je to, ze raid mi nevyriesi chyby uzivatela (nahodne zmazanie suborov). Prakticky od zaciatku ale bojujem s roznymi limitaciami - najprv som chcel pouzivat u suborov xattr - kernel nema modul. Casom objem dat nabobtnal tak, ze som musel z rdiff-backup, ktoreho zaloha z disku na disk trvala 4+ dni, prejst na link-backup (kde to trva len ~noc). Plus rychlost samotneho NAS-u - nic moc, na 1gpbs sieti zapis ~20MBps. O tom, ze potrebujem upgrade, proste viem uz davno, len sa mi do doho nechcelo sypat prachy.

Az ked doslo na to, ze zena dostala stres, ze jej zmizla kopa archivovanych veci (primarne fotky, nakoniec sa nasli len presunute v inych adresaroch, ale boh ma ochranuj z tych diskov nieco v pripade pruseru fakt lovit), pochopil som, ze:

- potrebujem snapshoty

- potrebujem to cele zalohovat este niekde inde (externy disk v trezore napr.)

Po stranke HW to teda vidim na nejake usporne x86 v rozumnej krabici, zatial mam vybrane tieto komponenty, k tomu este 1 externy disk na zalohy do trezoru.

Po stranke SW tapam. Skusal som pod virtualboxom ako FreeNAS/ZFS tak Debian/BTRFS, oboje ma svoje vyhody aj nevyhody a oboje ma spolocne koncepty.

Pocitam, ze v oboch pripadoch budem robit automaticke snapshoty, ktore budem potom z casu na cas pomocou z[btr]fs send/receive prenasat na externy disk (do trezoru), pripadne pokial nepouzijem RAID-1, identicky na dennej bazi z disku na disk. Finalne sa ale rozhodnut neviem - co sa tyka btrfs, moje teoreticke znalosti jeho stavu za zasekli na "btrfs is experimental, raid-5 is experimental under experimental btrfs". Vzhladom na to, ze casom pocitam s rozsirenim pola o dalsie disky, je predpoklad, ze pojdem smerom k raid-5(10) - a tu su argumenty ako pre tak aj proti obom fs.

U BTRFS ma laka jeho lahucke rozsirovanie o dalsie disky, konverzia z raid1 na 5, odradza udajny stav raid5 (nedetekuje odpojenie/pripojenie disku, nemoznost vykopnutia failed disku zaziva, nachylnost na stratu dat, ...). U ZFS je to zas presne naopak - podstatne nepraktickejsie rozsirovanie o dalsie disky, zato bezproblemovy management a vymena diskov v pripade poruchy. Takisto uvazujem o deduplikacii, pretoze u tej hromady fotiek a jej x-rocneho presuvania a prekopirovavania hore-dole medzi adresarmi k nejakym duplicitam urcite doslo - hlas proti btrfs a (maly hlas) pre zfs.

Riesil niekto nieco podobne a ktorou cestou ste sa pripadne vydali?        

Anketa

Anketa

Komentáře

[Dirka]

Nebylo by lepsi mit uz od zacatku slusnou strukturu a nemuset presouvat neco kdovikam a pak hledat duplikaty? Aspon me se teda osvedcilo, proste stahnu novy fotky do adresare YYYYMMDD_becka_5D a je jasny o co se jedna ... jinak teda osobne mam cerstvy data na ntb + NASu + k tomu rotuju dva externi disky (kazdej v jine geograficke lokaci) na kterych je vzdy snapshot live dat + kompletni archivy (ty jsou i na NASu). No a pak jsou jeste offline zalohy na DVD, ale kazdej at si zalohuje jak chce :)

[R]

Ked ma v tom clovek bordel, tak to staci raz upratat s pomocou nejakeho skriptu (pred casom sa to tu riesilo).

Deduplikacia sa pouziva na trochu ine veci - napr. ked treba ulozit 100 obrazov HDD s Windows.

[msk]

Vzhladom na to, ze ta deduplikacia je na urovni blokov, je imho uplne jedno cielove pouzitie. Mne osobne staci deduplikacia na urovni celych suborov, tak uvidim, mozno to poriesim nejak 'offline'.

[R]

Samozrejme, ze sa da deduplikacia pouzit aj na toto. Lenze ono to nie je zadarmo - potrebuje to dost vela RAM.

[msk]

RAM by mala stacit, aspon zatial s 2 diskami. Dalej sa uvidi. A mozno ju fakt nebudem potrebovat, alebo pouzijem btrfs a offline dedup, alebo vlastny script.

[msk]

Jedna sa o historicke presuny a kopie, ku ktorym doslo pred x rokmi a zatial som to nekvantifikoval. Script si na to samozrejme napisat dokazem, takisto to ale dokazem riesit nad zfs nativnou deduplikaciou bez prace, alebo nad btrfs nejakym scriptom ktory urobi rm & cp --reflink podla potreby. A celkovo - nejedna sa len o fotky, mam na pracovnom pc kopu dat, ktore potrebujem odzalohovat (sample, midi, projekty, kdejaky bordel) a u ktorych viem ze nejake duplikaty su na 100%, akurat neviem, kolko toho je. Proste sa o to idealne nechcem starat a nechce sa mi v tom vrtat, takze pokial existuje riesenie bez prace, sem s nim ...

[Josef Kufner]

Já tenhle bordel řeším tak, že mám ~/tmp, který se sám uklízí (podle měsíců). Fotky dávám do ~/fortky/raw/%Y%m%d a ty zajímavé zatřídím s přidáním názvu za datum. Bordel se mi nijak zvlášť nekupí, archiv ~/tmp má pár set MB za rok (ty velké věci promažu, zbytek se občas hodí a je malý).

Ono vůbec adresáře pojmenované podle data jsou celkem užitečná věc, neboť místo ~/starý/starší/old2/backup je pár adresářů ~/old/2014-03-02, ~/old/2011-02-03, ~/old/1991-02-03, a celé to je mnohem přehlednější.

[R]

BTW. Na DNS-320 sa da dat Debian, pripadne nieco ine podla potreby (ak mas malo miesta vo flash, mozes pouzit disk). Dokonca aj ku kernelu su zdrojaky, takze modul sa da dokompilovat.

[msk]

Ano, viem ze sa to da, nemal som chut sa do toho pustat, lebo tie data nemam odliate nikde inde. Kazdopadne pocitam, ze sa casom rozrastiem nad 2 disky, takze to aj tak nebude stacit.

[tom62]

Já provozoval delší dobu Debian na ZyXEL NSA325v2. Bylo to v mnohém lepší než originální software, nikoliv však v rychlosti (NFS, Samba). Pokud vám na rychlosti příliš nezáleží, podobnou kombinaci určitě doporučuji (kdyby měl někdo zájem, ten ZyXEL mi tu leží nevyužitý). S HP Microserver G8 (CPU G2020T), který mám teď, se to ale výkonem nemůže zdaleka rovnat, znatelné je to třeba při použití šifrování (zálohy přes rsync přes SSH se mi teď kopírují více než desetkrát rychleji).

[Pavel Píša]

Bedna ze seznamu vypadá zajímavě. Měl bych ale trochu obavu ze svislého umístění disků (tedy pokud správně chápu orientace obrázků). Minimálně dříve některé disky uváděly ve specifikaci nejlepší životnost vodorovně, trochu horší svisle a pro obecnou orientaci se sklonem nad pár stupňů nejhorší.

Jinak sám již několik let používám Debian, BTRFS a LXC na hardware Supermicro X9SPV-M4. Je to sice již starší a není nejlevnější, ale jsem s ní spokojený. Měřil jsem i spotřebu celého systému a také se mi líbila. Teď si to již nepamatuji, ale bylo to určitě pod 30W. Dnes má Supermicro malé desky in na novějších architekturách a s slabšími CPU dokonce od 6W (seznam).

Jinak u BTRFS bych v žádném případě nepoužíval jádro starší než 3.16 s aktuálními opravami. I tak ze seznamu oprav pro novější jádra se mi zdá, že i 3.16 může mít pár ještě neopravených chyb, které v okrajových podmínkách mohou být fatální. Problémy jsem sám s 3.16 neměl, ale raději jsem stejně přešel na 4.1.2 a budu 4.1 nebo 4.2 stable sledovat.

Jeden z disků v BTRFS RAID1 mám již starší odložený ST3500320NS (nyní Reallocated_Sector_Ct = 6) a rád bych ho nahradil něčím spolehlivým a tichým okolo 4 GB. Ale neumím se v aktuální nabídce moc rozhodnout. U většiny Seagate disků se hovoří o rušivém seeku. K WD a tím i k RED nemám až takovou důvěru. Rád si přečtu názory na disky v této kategorii, pokud se v diskuzi k blogu objeví.

[drunkezz]

.....hm...strasne vela hign-end poli ci uz block device ci NAS ma disky v policiach zvislo....to iste plati pre servery...tak neviem

D.

[Hulk]

4GB seagate uz nekupis