Linux redundáns adattárolás

 ( Adamyno | 2019. június 4., kedd - 13:31 )

Sziasztok!

A Nem kell Google téma adta az inspirációt egy projekthez, amit fejben már szépen összeraktam, viszont lenne egy csomó gyakorlati kérdésem, mert még soha nem csináltam ilyet (valahol el kell kezdeni).

A terv a következő:

0. Debianban gondolkodom az eddigi tapasztalataim miatt.

1. Kell egy adattároló, ami minimum RAID1-ben tárolja az adatokat.
-Van erre most egy NAS-om, feldobtam rá a Debiant OpenMediavault társaságában. Nagyjából rendben van a dolog, de bőven vannak korlátai, ezt itt most nem fejteném ki viszont emiatt szerintem váltok ARM -> x86.
-A raid tömböt meg tudom csinálni viszont meg lehet azt oldani, hogy a rendszer is tükrözve legyen? Tehát ha elszáll az egyik lemez, akkor a másikról megy tovább minden további nélkül, amíg mellé nem teszek egy újat. Ha igen, valami instrukciót kérnék szépen.

2. Szolgáltatások:
-Nextcloud (nem ismerem, csak látásból, hallásbül)
-A következő szolgáltatások csak akkor lennének külön telepítve, ha a NextCloud nem tudja:
-> e-mail szerver (postfix?)
-> rsync
-> smb (emellett még talán ftp)
-> transmission
-> upsd
-> lehet, hogy az előző 3-at egy OMV-vel kiváltanám

Az e-mailt és a NextCloudot úgy képzelem, hogy regisztrálok valahol egy domaint, amit dyndns-el linkelek. Pontosan nem tudom hogyan működik, de tudtommal lehet dinamikus IP-hez is domain nevet rendelni valahogy.

3. A teljes gépről egy klón
Csinálnék 2 ilyen gépet és az egyik földrajzilag máshol lenne, aztán menne rá a backup automatikusan. Na erről abszolút fogalmam sincs hogyan csináljam, a plusz poén pedig, hogy ha az 1. eszközzel gond lenne (elszáll az alaplap, leég a lakás, stb..), a 2. automatikusan átveszi a helyét.

Mindenképpen szeretném egy blogban leírni a folyamatot, (ahol természetesen linkelném ezt a topikot) ha valaki hasonlóra adná a fejét, akkor legyen egy kis segítség egy helyen.

Köszi előre is ha hozzá tudtok tenni!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

0. ok

1. Igen.
Minden gond nélkül lehet akár RAID 10-be is tenni... https://www.google.com/search?q=debian+raid1+boot

2. A levelezést nem ajánlom dinamikus IP-ről.
A témában olvasgass egy kicsit az SPF, DKIM, DMARC szavakra keresve.
Mellesleg egy ilyen szolgáltatást olcsón is megkaphatsz. Ha kell, keress meg. (GLSYS)

3. Lehet klónozni, de inkább rendszeres backup-ot készíts!
Ha leég a lakásod, akkor a net is odavész :) És főleg nem az lesz a legnagyobb gondod, hogy elérd a fénykép gyüjteményed... :) Nem beszélve arról, hogy nem hiszem, hogy szinkron gigabites net-ed lenne mindkét helyen... :)
Illetve még akkor sem igazán jó ötlet minden változtatást eltárolni a másik gépen, ha mondjuk csak fel kell a szerverre időlegesen másolni 1-2TB adatot... Amit aztán 1 óra múlva le is törölsz...

--
Debian Linux rulez... :D
RIP Ian Murdock

1. A RAID-nek picit utánaolvastam, elvileg a GRUB kezeli a software raid-et minden gond nélkül. Most csak azért szívok vele a NAS-on, mert ott nincs BIOS/UEFI csak uBoot.

2. Levelezést egyelőre félre teszem, ha lesz egy működő alaprendszer, akkor ráfordulok.

3. Igazad van! A klónozás helyett backup. Egyébként nem kell hozzá szinkron gigás net, mert jellemzően csak kisebb fájlokat hozok létre... programozás, projektek, dokumentumok, képek. Persze néhány nagyobb fájl is biztosan lenne, de felőlem mehet a backup éjszaka is. Terv szerint egyébként lenne egy mentéssel nem rendelkező tároló is iso imageknek, filmeknek.

Létrehoztam egy blogbejegyzést, ott könnyebb lesz követni:

https://hup.hu/node/164576

---
- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Ha x86 lesz akkor valami kis fogyasztású (vagy lényegében bármilyen ami van) cucc plusz 8GB RAM és Proxmox alapon meg lehet csinálni, a többit CT vagy/és VM gépekben, OMV is. A Proxmox is Debian. Lehet telepíteni direktben és lehet úgy is hogy először egy Debian és abból csinálsz utólag Proxmox rendszert.
Az e-mail szerver kivételével kb. hasonló nálam is működik otthon. De persze postfix csak küldés megy, főleg jelentések e-mailben.
Ebben a felállásban plusz LAN kártyával még profi software tűzfalakat is lehetne használni: pfSense, OPNsense, Sophos UTM Home stb..

Jó ötlet, virtuális környezetben tesztelem. Gondoltam pfSense-re, de vannak célhardverek is erre. Van egy tök jó MikroTik routerem, ami részletesen konfigurálható de vannak elfekvő cisco routereim is. Az más kérdés, hogy mely eszközöknek mennyire vannak ismert de még nem javított sebezhetőségei, azok mennyire vannak kihasználva, mennyire jellemzik az adott platformot a 0day sebezhetőségek illetve azokra milyen gyorsan reagál a gyártó/fejlesztő - ha egyáltalán foglalkoznak vele.

Egy régi cisco szerintem már nem igazán támogatott.
A RouterOS-t aktívan fejlesztik, de az elmúlt időszakban elég komoly sebezhetőségeket tártak fel.
pfSenset ilyen téren nem ismerem. Állítólag az egyik legbiztonságosabb rendszer, így talán nyugodtabb is lennék ha kiengedném a rendszert a netre, bár a folyamatos -és lehetőleg automatikus- frissítések hangsúlyosan jelen lennének a projektben természetesen megfelelő backup társaságában.

--
- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Sophos UTM Home tűzfal otthoni felhasználóknak 50 belső IP-ig ingyenes. Aktív tűzfal funkciók is vannak benne, nem csak egy csomagszűrő tűzfal. Vírusvédelem, IPS/IDS stb. Persze azt is meg kell tanulni belőni, de a legtöbb cucc alapból benne van és működik. Már ha fontos a magas szintű biztonság. Viszont a másik oldalon megvan az ára, alap teljesítményű processzorral nehezen megy 100Mbit/s fölé

0. Debian is jo, mas is jo erre a celra.
1. Soft RAID / alatt, sima ugy.
2. Egy (vagy keves) useres MTA-nak inkabb Exim-et mondanek. Dynamic DNS felejtos ha mail servert uzemeltetsz. Olyan IP cim kell ami nem DHCP poolbol van, meg mondjuk normalis hosting cegtol. Plusz DKIM, SPF, de meg DNSSEC is.
3. Esetleg VPS-en tegyel ele HA Proxy-t. E-mailnel a backup MX (a backup geped), tudja tarolni a mailjeid, amig az elso gepet helyre nem allitod.
Hogy folyamatosan sync-elj a backup gepre, arra jo az rsync, tar+ssh, scp, barmi hasonlo, 1000 dolog van ra. Utemezett full (novekmenyes) backupra is.

Sok sikert, ebbol azert lehet tanulni ezt-azt :)
____________________
echo crash > /dev/kmem

Ami bármely rétegben egy példányban van meg, az nincs meg. Addig oké, hogy a raid tükör okán minden két fizikai meghajtón ott van, azaz ebben a layerben két példányod van, de fájlrendszer szintjén már csak egy példányod van, és hiába lenne egy másolatod a szerveren belül a fontosabb adatokról egy másik könyvtárban/diszken/stb is, még mindig egy dobozod van, ami ha megsérül/megsemmisül, akkor fújhatod az adataidat. Röviden a raid nem backup, úgyhogy a raid-re pakolt adataidrol illendő időközönként tessék offline backup-okat csinálni (azaz a mentőeszköz nincs rákötve a mentett gépre direktben/nem megy 7x24-ben), illetve a még sokkal fontosabb dolgaidnak a mentését meg mindenképp érdemes off-site mentéssel is biztonságossá tenni - azaz egy mentést nem a lakásban tartani.

Igaz, viszont lényegében erről szólt a 3. pont. Elméletileg egy off-site másik szerverre szinkronizált backup megoldja ezt a problémát.

---
- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Talán egy kicsit jobban meg lehet világítani azt amit a kolléga írt:
Ha folyamatos szinkron van a másik gépre tolva és nem több snapshoot backup, akkor amikor az asszony törli a házassági videokat, na akkor leszel gondban... :)
Ugyanis a törlés mindkét helyen el lesz végezve...
--
Debian Linux rulez... :D
RIP Ian Murdock

Senki nem kap írási jogot rajtam kvül :D

Viccet félretéve.. azt hiszem a növekményes backupnál ez nem okoz gondot de ebben nem vagyok biztos. Egyébként rsync-el tervezem megoldani.
---
- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Úgy érzem kicsi zavar van a fogalmakban. A klón/szinkronizálás nem offsite backup. A Raid egyáltalán nem ad adatbiztonságot, csak rendelkezésre állást növel. Mi a célod a második géppel? Ha egy "klónt" akarsz ami "átveszi" az első helyét, akkor még a hálózattal is foglalkoznod kell, viszont az nem mentés. Ha "csak" mentés akarsz akkor nem a gépet kell klónozni, hanem meghatározni a mentendő adatok helyét/formáját és utána lehet megoldást keresni. Ha csak fájlokat akarsz menteni az egyszerű (pl. duplicity) ha adatbázisokat is akkor már egy kicsit variálni kell. Ha mentést akarsz azt is meg kell határozni mennyi időre kell biztosítani az adatok rendelkezésre állását. Ha tudod a változások gyakoriságát ki lehet számolni a szükséges tárterületet.

Igen, ez már tisztázódott. Az eredeti elképzelés ilyen szinten hibás volt.
Jelenleg csak fájlokat akarok menteni, adatbázist nem (ha igen, az max ilyen sqlite). A szinkronizálás hibás megfogalmazás volt. Viszont ha valamilyen formában az email is innen fog menni, akkor kelleni fog az adatbázis szinkronizálás. Utóbbi miatt lenne értelme annak is, hogy a másodlagos gép átveszi az első helyét, ha az nem elérhető. Ez egy jóval magasabb szint. Az a baj, hogy windows szerverekhez és virtuális környezethez vagyok szocializálva, viszont ezeket jó lenne fizikai vason megoldani - bár itt a fix IP lesz kérdéses ha e-mail szolgáltatást is akarok magamnak -> email projekt pihen.

1.a) Ha csak fájlok vannak akkor elméletileg elég az off-site backup.
1.b) Ha 'A' nem elérhető, manuálisan elérem a 'B' helyet vagy dyndns segítségével valahogy talán lehet HA-t konfigurálni.
2.a) Ha már van NextCloud is, akkor is elvileg elég a backup amennyiben a config változásokat manuálisan mindkét helyen megcsimálom. Ha az a cél, hogy 'B' helyen lekövesse a rendszer az 'A' helyen történt konfig változásokat is, akkor már szükség lesz adatbázis szinkronizációra is. (?)
2.b) -> 1.b)
3. Ha viszont e-mail szerver is kell, akkor kell fixip, kell adatbázis szinkronizáció és kell egy HA szolgáltatás, aminek a segítségével automatikusan 'B' irányba mennek az adatok, ha 'A' nem elérhető.

Jól látom?
---
- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

3. Nem. Ezt az MX rekordokkal lehet megoldani...
Mármint ez arra jó, hogy ha az alacsonyabb értékű MX nem elérhető, akkor a következő MX-et próbálja a rendszer. De mondjuk az SMTP nem keverendő össze az IM (Instant Messaging)-el...
Ahhoz, hogy a leveleket te is el tudd érni, más trükköt kell bevetni.
--
Debian Linux rulez... :D
RIP Ian Murdock

Aha. Jó régen csináltam egy weboldalt, akkor volt ilyenhez közöm, de akkor sem tudtam mi ez. Így már értem :)

Ezt az MX dolgot a domain regisztrációnál kell beállítani ha jól tudom. Ott viszont korlátozott az IP címek mennyisége ha jól sejtem.
---
- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

[Feliratkozás]

Szia, előttem leírtak sok jó megoldást, csak pár kiegészítés:

A 3. ponthoz én vagy egy máshol tárolt gépre szinkronizálnék (rsync bizonyos mappák, bizonyos időnként, például rendszert naponta, adatokat naponta többször).

Másik út hogy VM-ben fog futni az egész megoldás, és erről a VM-ről csinálsz mentést / snapshot-ot valahova, titkosítva. Azért nem real time / online tartanám, mert akkor már szinte HA (high availability) cluster lenne, illetve ott már érdemes lenne minimum 3 node, amiből 2 legalább valódi. Ez sok sávszélességet ehet, amihez a 10 GBites net az igazi.

Annyit raknék még hozzá, hogy én az OS-en kívüli adatokat egy külön partíción / fájlban tartanám, például TrueCrypt / VeraCrypt konténerben (AES + még valami kódolás és 60+ karakteres jelszón kívül egy 1+ Mbyte-os kulcs fájl használattal, amit például USB-ről olvas be, vagy máshonnan, esetleg manuálisan indítható csak el), és azt a fájlt is külön szinkronban tartanám, menteném. Akár típusonként külön file, például a programozásnak X GB, egyébnek Y GB. A szinkronizálásnál vagy a felcsatolt konténeren belül RSYNC, vagy a legszebb lenne, ha sávszélesség milliomos vagy, akkor a teljes konténer fájlt menteni, lehetőleg úgy, hogy előtte lecsatoltad.

Persze lehet még az egész (OS) is titkosítva a Linux által támogatott különböző módokkal is, hogy csak jelszóval (és kulccsal) induljon.

Sakk-matt,
KaTT :)

Ez egy jó ötlet, viszont van ezzel kapcsolatban egy érdekes tapasztalatom.
Egyszer kipróbáltam, hogy kivettem a raidből az egyik lemezt (sima raid1 tükör volt) és bedobtam egy másik gépbe, hogy lementsem az adatokat róla. Nem láttam semmit, raw fájlrendszernek látszódott az egész.
Kell emiatt egyáltalán bármiféle titkosítás? Vagy mi lehet ennek az oka?

Annyira nem erős a vas, hogy virtualizáljak, bár az ötlet jó viszont akkor akár a virtuális gépet tárolhatnám hosting cégnél is. A lényeg igazából annyi lenne, hogy minden adatom lehetőleg nálam maradjon beleértve az e-maileket is és ez utóbbi okozza a legnagyobb feladatot szerintem. Persze a titkosítás nem hátrány, bele is írom a topik indítóba.

Edit: szerkesztési lehetőséget nem látok, így az első hozzászólást módosítom.

---
- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Ha Linux által telepítéskor is felkínált titkosítást használtad, akkor a másik gépről Linux alól kell felcsatolni, jelszóval, vagy amivel védve volt, és akkor látod az egészet. LUKS.

Veracrypt / Truecrypt esetén Windows / MAC alól is csatolhatod fel, ha tudod a jelszót/kulcsot, és látod, de az nélkül ugyanúgy nem látsz semmit.

Én magamnak ilyen esetben úgy csinálnám meg a gépet, hogy
/boot : nem titkosított
/ : linux által támogatott titkosítás + jelszó és/vagy kulcs, amit USB-ről húz be mondjuk, amit indításkor te beleraksz, és utána nincs benne, így áramszünet esetén nem indul el, vagy ha leállítják. (szünetmentes táp)
/data : pedig egy Veracrypt / Truecrypt partíció, kulcs + jelszóval, akár az USB-ről változatlanul, és ez mount-olja fel az adataidat, ez sem lesz elérhető áramszünet után, sem másik gépről nézve, csak a kulcs + jelszóval.

Mindez RAID1-ben. Vagy ha hotswap-ot támogatja az eszközöd, akkor 3 disk-es RAID1, és az utolsó disk-et csak esetlegesen rakod be, akkor rászinkronizálódik az egész, és újra kiveszed. Persze ez nem mentesíti az offline backup-ot.

Sakk-matt,
KaTT :)

Ha mdraid volt, akkor ott valami nagyon nem volt kerek, mert azt simán lehet olvasni - természetesen úgy, ahogy az eredeti helyén volt, tehát ha lvm van ráhúzva, akkor az adott vg-t kell előbb életre lehelni, és utána jöhet a lv(k) meg a fájlrendszerek maszírozása, ha meg simán partícióra ment az fs, akkor mount, oszt' jó'van. Hardveres raid esetén is eléggé esélyes, hogy egy megfelelő vezérlőre akasztva a "féllábú" tükröt életet tudsz lehelni bele, de az azért mókolósabb dolog.

Lvm volt. Akkor itt van a kutya elásva :)
---
- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Meglehet... Ahova átvitted a diszket ott első körben egyébként a "féllábú" raid-et "illik" megcsinálni, majd pvscan, vgimport, vgchange -a y, és "máris" mehet a mount, ha jól emlékszem :-)

Létrehoztam egy blogbejegyzést, ott könnyebb lesz követni:

https://hup.hu/node/164576

---
- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Igazából, amire szükséged van, azt az én lowcost NAS-om is bőven tudja, talán az emailt nem, de az dinamikus IP-vel nem is fog menni. Ahhoz mondjuk egy $5-s DO instance is elég, és arra fix v4-et kapsz.

A teljes klónozás máshová minek? Betörés + lopás miatt? Szintén DO-s storage elég lehet rá.

Ja igen, a NAS-om rendszere egy RO flash-en van, egyedül frissítéskor kapcsol RW módra, amúgy nem, tehát a rendszer tovább fog élni, mint maga a vas.

--
openSUSE 42.2 x86_64