ugrás a tartalomhoz

A RAID mennyire véd data corruption ellen?

inf · 2017. Júl. 10. (H), 05.14
Olvastam pár cikket arról, hogy a hibás szektorok okozta data corruption ellen a RAID egyáltalán nem véd (leszámítva a ZFS-t), pl: raid-5-with-bad-fixed-sectors/. Ennek az az oka, hogy a HDD-be van építve a checksum készítő és ellenőrző kód, ami általában elég gyors, de emiatt nem feltétlen a legmegbízhatóbb. A cikkek, amiket olvastam viszont 3-4 évesek. Az érdekelne, hogy azóta változott e a helyzet, illetve, hogy van e olyan RAID verzió, amiben az ilyesmit már megoldották? Én leginkább azért szórnék be az itthoni szerverbe RAID-et, hogy védjen az ilyen jellegű adat sérüléstől is, nem pedig az üzemszünet megakadályozására. Nekem nem szempont, ha elszáll egy meghajtó, várnom kell pár napot és backup-ról kell visszaállítanom mindent. Max annyi számítana, hogy 1-2 hét esetleg kiesne, ha nem gyakran backupolok. Az sem tetszene, hogyha egy hibás szektor miatt tönkremenne az adatbázis, és emiatt kéne backupolni. Nagyjából ilyen elvek mentén van valami megoldás a problémára? Esetleg nincs értelme foglalkozni vele, mert annyira ritka az ilyen egy mai meghajtón?
‹ WAMP szerver Van valakinek headless server? ›
 ■
1

Semennyire

janoszen · 2017. Júl. 10. (H), 12.18
Attol fugg hogy mit ertesz corruption alatt. Ha arrol beszelunk, hogy a disk meghibasodik es megvaltoznak a bitek, az ellen ved. Ha az oprendszer megkergul es hulyeseget ir a fajlokba, vagy egy hirtelen aramszunet miatt leirta a torlest, de az adatokat mar nem (unordered mode) az ellen nem ved. Eppen ezert szoktak a RAID controllerekbe BBU-t tenni.

Persze ha ordered data mode-ban mountolod a filerendszert (pl. ext3, ext4) akkor viszonylag kicsi a riziko. Azt talan nem is kell mondanom, hogy a RAID nem mentesit a backupok elvegzese alol.
2

Nyilván sok más fajtája is

inf · 2017. Júl. 10. (H), 13.22
Nyilván sok más fajtája is van a corruption-nek, de én most elsősorban a HDD-vel, SSD-vel kapcsolatos hardver hibákra gondoltam, amik miatt hibás szektorok keletkeznek és sérülhetnek az adatok. Nekem az eddigiek alapján úgy tűnik, hogy a RAID régebbi verziói nem nyújtanak semmilyen extra védelmet azon felül, amit a HDD-be beletettek a gyártók. Ezt írják több helyen is, itt egy további link. Nem tudom RAID6 esetében mi a helyzet, egyedül ZFS-re mondják, hogy véd az ilyen hibák ellen is. Persze, egyértelmű, hogy backup-olni kell, csak ha már hibás szektor keletkezett és sérült egy fájl, akkor a hibás fájlt fogod backupolni, pl: link. Nekem elsősorban az lenne a fontos az itthoni szerverre, hogy az adat integritása ne sérüljön hosszú távon ilyen, vagy olyan hardver (HDD, SSD, memória, stb.) hibák miatt. Arra ebben az esetben sokkal kisebb az esély, hogy szoftveres hibából adódóan történjen valami az adatokkal.
3

Backup

janoszen · 2017. Júl. 10. (H), 14.42
Desktop kornyezetben az ember tipikusan akkor hasznal RAID-et ha read teljesitmenyt akar, a mai diskek az esetek tulnyomo tobbsegeben azert kihuznak 3+ evet problema nelkul. Szever kornyezetben meg a heti backup az esetek 99%-aban nem elegendo.
4

Nálam elég, amire most

inf · 2017. Júl. 10. (H), 15.50
Nálam elég, amire most elsősorban nekem kell a cucc, annál nem számít, ha egy hét elveszik, mert az még nagyjából fejben van, meg még ott lehet a másolata a kliens gépeken, úgyhogy nem nehéz újra összerakni. Olyan 15-20 év anyagát fogom tárolni rajta, az lenne az igazi probléma, ha az egész elveszne. Ezek szerint nem feltétlen kell nekem RAID, vagy ha mégis, akkor egyedül a ZFS ami az én céljaimnak megfelel.
5

Jellemzoen

janoszen · 2017. Júl. 10. (H), 17.36
Ha azt akarod hogy ne vesszen el, akkor tarold tobb mint egy helyen, lehetoleg tobb folrajzi helyszinen.
6

A probléma nem az, hogy

inf · 2017. Júl. 10. (H), 20.07
A probléma nem az, hogy elveszne az adat, mert azt egy vagy több backup megoldja, meg azt azért észreveszem. A probléma az, hogy tárolás közben károsodhat a meghajtó és így az adat is, és a backupra észrevétlenül a károsodott adat kerül fel a régit felülírva. Így amikor hozzá akarok férni, csak akkor derül ki, hogy hibás a fájl és nincs róla olyan backup, ami nem hibás. Ezt szeretném elkerülni. Az ECC az egyik lépés a memória oldaláról, a RAID6 lenne a másik, ha védene az ilyen jellegű hibáktól. Nyilván szoftver oldalról is lesznek lépések az adat integritás fenntartása felé, de ez most nem arról szól.
7

Meghibasodas

janoszen · 2017. Júl. 11. (K), 09.38
A meghibasodas tobbnyire nem olyan mint a memorianal hogy meghamisodnak a bitek, hanem inkabb olyan hogy nem tudod elolvasni. Az pedig kiderul a backup soran. Ezen felul vannak olyan filerendszerek amikben van integrity check.
8

Van olyan ezek közül a

inf · 2017. Júl. 11. (K), 16.18
Van olyan ezek közül a fájlrendszerek közül, ami kompatibilis Ubuntu-val? A zfs-ről tudom, hogy igen, kíváncsi vagyok lenne e más is, amit hagyományos RAID-el erre tudnék használni.

Az jó, ha tényleg olyan, hogy nem tudom olvasni ahelyett, hogy meghamisítódna. Ettől függetlenül érdekel a fenti kérdésre a válasz.
9

ext4

janoszen · 2017. Júl. 11. (K), 16.51
Elvileg az ext4-ben van metadata checksumming, de meg nem mondom neked hogy ez mennyire hasznalhato. File tartalomra tudtommal csak a ZFS es a btrfs ad checksumot.
10

Köszi! Akkor körülnézek ennek

inf · 2017. Júl. 11. (K), 17.16
Köszi! Akkor körülnézek ennek a kettőnek a háza táján. A btrfs-t is dícsérték sokan, nem csak a zfs-t. Lehet, hogy kipróbálom raid6+btrfs-t és zfs-t is, aztán sebesség, cpu terhelés, stb. alapján döntök.
11

És amikor kész,

Pepita · 2017. Júl. 11. (K), 21.37
írsz egy cikket vagy egy blogot róla. :-D

(Nem kérdeztem, hanem mondtam... :))
12

Majd egyszer. :D Hardverben

inf · 2017. Júl. 12. (Sze), 01.06
Majd egyszer. :D Hardverben meg üzemeltetésben nem vagyok azon a szinten, hogy cikkezzek.
13

Nagyjából az a konklúzió,

inf · 2017. Júl. 31. (H), 01.21
Nagyjából az a konklúzió, hogy btrfs vagy zfs fog kelleni fájlrendszernek, amit snapshotokkal backupolok. Az előbbi felé húzok. Egyelőre csak egy hdd-re teszem fel a btrfs-t, aztán ha sok checksum error-ba futok bele, akkor csinálok egy raid1-et vagy egy raid5-öt, hogy hiba esetén a clone-ból vagy parity-ből automatikusan javítsa magát, egyébként meg ha ritka az ilyesmi, akkor backup-ról állítom vissza a hibás fájlt. Ez a 2014-es cikk elég jól összefoglalja a témának azt a részét, ami nekem kell. link

A héten megjönnek a hiányzó alkatrészek, és végre összeszórom a gépet. Menet közben vettem már laptop szereléshez ESD kesztyűt, csuklópántot, úgyhogy végre felkészülten állok neki a gép szerelésnek.
14

nem tudom mennyi meg milyen

MadBence · 2017. Júl. 31. (H), 22.22
nem tudom mennyi meg milyen adatod van, de érdemes lehet megnézni, hogy felhőben mennyibe kerülne tárolni őket. fotókat/videókat én pl. google photos-on tárolom, ami tök ingyen van.
15

Nem akarom felhőbe kitenni

inf · 2017. Aug. 1. (K), 08.46
Nem akarom felhőbe kitenni, van közte olyan, ami nem publikus. Valszeg ingyen le tudnám tárolni én is, most olyan 500-1000GB közötti mennyiségről van szó. Elvileg ma érkeznek meg az alkatrészek nem sokára. :-)
16

nem tudom pontosan mit értesz

MadBence · 2017. Aug. 1. (K), 15.05
nem tudom pontosan mit értesz az alatt, hogy "nem publikus", a hozzáférést nyilván szabályozni tudod ezekhez. ha valami törvényi szabályozás miatt nem teheted fel külső szerverre az adatokat (pl. bankkártyaadatok), akkor érthető, egyébként szerintem alaptalan paranoia. az más kérdés, ha szeretnél bütykölni, és diy megoldást építeni (ahogy látom nálad ez a helyzet :) ).
17

Jaja, már megvan a gép hozzá,

inf · 2017. Aug. 1. (K), 16.11
Jaja, már megvan a gép hozzá, ma fogom összerakni, tesztelni egy kicsit. Egyelőre még azon vacillálok, hogy a PC-ből átrakjam e a rendszer SSD-jét (120GB) vagy vegyek e neki újat. A PC-ben van még egy SSD (500GB), amin a tárhely nagy része felszabadul azzal, hogy átkerül a szerver HDD-jére, azért gondoltam, hogy inkább arra klónozom át az oprendszert a kisebbről, a kisebb meg megy rendszernek a szerverbe, meg persze azon fogom tárolni az adatbázisokat, kesselni a gyakori fájlokat, hogy ne kelljen mindig a HDD-t felpörgetni miatta, stb.

Persze, paranoia is van, az ilyen ingyenes felhő alapú tárhelyeknél nem látok semmi garanciát arra, hogy ne veszne el vagy károsodna idővel, amit felteszek, esetleg ne kerülne illetéktelenek kezébe. Semmit nem lehet tudni arról, hogy a háttérben milyen megoldás van. Részben ezért döntöttem a DIY mellett. A másik ok, hogy úgy érzem a feature-ök, amikre szükségem van indokolják, hogy egyedi alkalmazást írjak rá.