Elrettentő: így ne csináld!!!
Lássuk, hogyan NE csináld, ha Te fogsz hasonló online titkosítós konverziókba.
Elrettentő példa, bár én eddig jól megúsztam, köszönhetően a ZFS kreativitásának.
RAIDZ1:
- 3 x 8 TB Seagate NAS HDD (Ironwolf)
Megjegyzés: korábban a mirroron azért választottam két külön márkájú HDD-t, hogy ha van szórás köztük, vagy szériahiba, rejtett hiba, akármi az egyiken, akkor az ne két ugyanolyan "mindjárt megdöglő" diszket érintsen. Ez a diverzifikálás ajánlott ZFS és hagyományos RAID-ben is, ha a meghajtók fizikai és főleg logikai paraméterei nagyjából egyeznek. (Itt ez a helyzet, 4K advanced format mindkettő, cache méret, sebesség, minden ugyanolyan és bájtra pontosan akkorák méretben is logikailag, tehát kiváló ilyen célra, de ha egyikük picit kisebb lenne a másiknál, a kicsi méretet használná duplán a ZFS).
Nos, innentől úgy gondoltam, okos vagyok, belevágtam. :)
Teendő: RAIDZ1 pool alól kivenni egy HDD-t, titkosítani, majd visszaadni alá a titkosított kötetet a /dev/mapper-ből, és várni, míg befejezi a resilver-t.
- zpool remove nem működött top level vdev akármi miatt (erről nem szeretnék külön fejezetet nyitni), a lényeg, hogy offline-ba kellett tennem a kiszemelt diszket (ekkor nem ír rá és nem olvas, szigorúan érintetlenül hagyja)
- cryptsetup luksFormat-tal létrehoztam rá titkosított kötetet (--sector-size=4096 AF miatt), header fájlt ilyenkor generál, előtte pedig csináltam neki egy 4096 bájtos key fájlt, ezzel a kulccsal titkosította le a diszket
- ilyenkor még nem írja végig a fizikai lemezt random adattal a rendszer, így tehát köv. lépés:
- cryptsetup Luksopen-nel megnyitni, /dev/mapper-ben megjelent a feloldott titkosított réteg, és ezt dd-vel nullákkal teleírtam, hogy az alatta lévő fizikai meghajtón a LUKS így az egészet csurig írja random adattal
- kapcsolók: --header fájlnév.bin illetve --key-file fájlnév.bin, így a LUKS fejléc (16 MB) és kulcs (4096 bájt) az SSD-n a /root-ban tárolva jelenleg, magyarul a HDD csak és kizárólag avatatlan szem számára ismeretlen random adattal van tele, csurig.
- miután végigment éjjel a virtuális feloldott "lemez" nullával teleírása:
- zpool replace poolnév régidiszk újdiszk
- itt poolnév a pool-om neve, régi diszk /dev/disk/by-id/... (wwn alapján megyek teljes diszk használatakor), új diszk pedig ugyanennek a titkosított-feloldott /dev/mapper -es megfelelője
Mindig kivettem egy diszket offline-ba és cryptsetup inicializálás + /dev/mapper eszköz megnyitás után replace-szel visszaadtam azt a poolnak... igen, a ZFS tud offline eszközt replace-elni, nem igazán esett le neki, hogy amúgy ugyanazt a fizikai eszközt kapja vissza, csak került közbe egy LUKS2-es titkosítás is ... szóval így 3x kockáztattam a teljes pool életét (hiszen csak 1 hibát visel el, és én ezt létre is hoztam neki, még egy nem fért volna bele). RAIDZ2 (RAID6) felállás esetén már simább liba a művelet, én most merész voltam, Ti ne legyetek :)
Az újra ép és ONLINE poolon ezután ugyanezt eljátszottam a többiekkel: mindig a következő vinyót tettem offline-ba, titkosítás, teleírás, majd az így előállt mapper eszközt visszaadtam a poolnak replace-szel.
Azért vannak meglepik, nálam egyből jött is (ezt még a 2-diszkes mirroromon mutatom, egy Seagate és egy WD Purple):
pool: zfsmirror
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Sun Nov 22 07:54:51 2020
2,08T scanned at 248M/s, 748G issued at 87,2M/s, 2,60T total
750G resilvered, 28,15% done, 0 days 06:13:55 to go
config:
NAME STATE READ WRITE CKSUM
zfsmirror DEGRADED 0 0 0
mirror-0 DEGRADED 2 0 0
replacing-0 DEGRADED 18 0 0
ata-ST4000VN000-1H4168_Z301T3M2 OFFLINE 0 0 0
z301t3m2 ONLINE 0 0 18 (resilvering)
wcc4e5ns38e5 DEGRADED 4 0 16 too many errors
errors: 1 data errors, use '-v' for a list
Bizony-bizony. A jó kis WD40PURX és annak 100/100-as mivolta ellenére egy kis bithiba "valahol". Tehát most minden létfontosságú adatom épp ezerrel másolódik vissza a Seagate NAS vinyóra, ők vannak így mirrorban, miközben történt egy kis korrigálhatatlan hiba - hiszen ez most még csak 1-lábú mirror, hibát észlelni tud, de javítani már nem.
Hozzáteszem, megdöglött a tápom ezt követően pár napra rá, de SATA kábeltörésem is volt :D, úgyhogy 99.99% nem a HDD, pláne, hogy Sentinel ultra makura jelentette + írás-olvasás surface teszt, fullfull jó.
-v-vel kérve le a státuszt, megmondta, mi a bibi. Lássuk így a kimenetet.
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Sun Nov 22 07:54:51 2020
2,08T scanned at 240M/s, 778G issued at 87,7M/s, 2,60T total
780G resilvered, 29,28% done, 0 days 06:06:00 to go
config:
NAME STATE READ WRITE CKSUM
zfsmirror DEGRADED 0 0 0
mirror-0 DEGRADED 2 0 0
replacing-0 DEGRADED 18 0 0
ata-ST4000VN000-1H4168_Z301T3M2 OFFLINE 0 0 0
z301t3m2 ONLINE 0 0 18 (resilvering)
wcc4e5ns38e5 DEGRADED 4 0 16 too many errors
errors: Permanent errors have been detected in the following files:
/mnt/zfsmirror/.../DCIM/Camera/VID_20181108_180151.mp4
Nos, ott az érintett fájl, ami resilver végén hibás lesz 1 vagy több ponton. Mint fájl, ott lesz, létezni fog, a ZFS szépsége, hogy ettől még elérhető marad a motyó, csak ... az van benne, amit beolvasott. Bumm. Majd látjuk, mi maradt belőle. Hálaistennek ez egyrészt video, tehát megúszhatom pár képkocka kimaradással, 1 pici kockásodással, majd ránézek.. másrészt bár a mirroron van, tudok nélküle élni + backup van kint polcon, ez pont családi videó.
Nem győzöm hangsúlyozni a cold backup meglétét az életveszélyesen fontos adatokról :)
A cikk még nem ért véget, kérlek, lapozz!
