Backup megoldás hibatűréssel

Segédprogramok

Aránylag nagy darabszámú (1-2M) és összméretű (500-600GB) fájlt szeretnék minél hatékonyabban és hibatűrően tárolni.

Szempontok:
- lehetőleg optimális diszk foglalás, lehetőleg közel zip mérethez
- tárolt formátumban is olvasható, hozzáférhető egyesével (könyvtárankénti zip-nél pl. ez problémás)
- hibatűrő, tehát diszk hiba, gép hiba esetén is sérülésmentes

Eddig az alábbi a legszimpatikusabb:
- nyers formátumba RAID1 felett ext4-ben
- külső tárolón deduplikációval, pl. borg backup

kérdés, hogy ez mennyi hibatűrő pl. bit hiba esetén, hogy ellenőrizhető?

  • 1875 megtekintés

( uid_17626 | 2018. 12. 31., h – 17:37 )

BTW: Becsomagolva nem lesz hibatűrő. Ha mégis sérül a "zip" mindent buksz.
EZ mentés lesz vagy aktív tárolás felhasználókkal?

Jut eszembe, talán nem teljesen offtopic itt, de úgy kell csomagolni :) Ezért választottam egyszer az arj-t. (Asszem a rar is tud ilyet, ám az valamiért megbukott egy teszten.)

Ja, és régen minden jobb volt :) https://en.wikipedia.org/wiki/Parchive (bár lehet hogy még élő technológia, az usenet nekem kimaradt az életemből).

Csak ne legyen baja a hw-nek. Igazabol a legnagyobb erv a sw raid mellett, hogy nem igazan fugg az alatta levo retegtol, igy szabadabban/egyszerubben lehet disasterbol visszallni. Kb radugod barmire amin elgut az os.

-
First impressions of the new Cloud Native programming language Ballerina

Csodalkoznek, ha kiveszed a disket a tombbol, radugod egy masik gepre sima diskkent, es bebootolna rola a rendszer. Jo ideje nem frissitettem a tudasom hw raid-el kapcsolatban, szoval lehet en nem tudok valamit, de azert van nemi metaadat, ami a tomb egybentartasahoz kell, es azt csak a disken tudja tarolni. Regen meg az sem volt eleg ha azonos gyartotol volt a kartya, ha nem talaltal pont ugyanolyat ment az adat a levesbe.

-
First impressions of the new Cloud Native programming language Ballerina

Van rajta metadata és tök érdekeset tud csinálni. Előtte jobb tesztelni.
DELL Perc 5 és 6 nem volt kompatibilis egymással. 5-ös vinyókat formázni akarta, nem ismer fel a 6-os vezérlő.

De tekintve a topik indító kérdését: backup megoldás. Akkor meg kit érdekel ez az eset. Ez egy mentés lesz, nem az egyedüli példány.

De aki fél tőle, JBOD-ként kiajánlani a rendszernek és sw raiddel összehúzni. Általában az már nem kavar be.

Írjál meg egy kicsit többet a topik elejére, mert felesleges köröket futunk, ha te lelövöd mindet.
Egy nyomvadt hw raid1 miatt én cseppett sem érzem ezt: "nem fog menni a zfs átállás"
Használom hw raid1, raid5, raid6 alatt, söt még hw raid feletti virtuális gépben létrehozott zfs-t is használok. N+1 baromi jól skálázható backup (compress) és archiv (compress+dedup) célt szolgál. Több hónapra vissza napi mentést tárol, mindig csak annyival növelve a diszk foglaltságot, amennyivel aznap _változott_. Még is minden napra egyben látom a teljes mentést (zfs előnye) dátum mappában. Az egészet meg rsync eteti. Faák egyszerű és gondozás mentes. A snapshotok meg kirotálódnak a a megadott lejárati időben.

( tompos v | 2018. 12. 31., h – 17:37 )

Ha lokalis, akkor vmi ZFS megoldast valasztanek (magam egy koegyszeru custom scriptet hasznalok).
Ha lehet remote, akkor meg vmi cloud megoldast, pl. backblaze, v. vmi S3-ra epulo, glacier stb., igenytol fuggoen.

t

( sj | 2018. 12. 31., h – 19:07 )

- hibatűrő, tehát diszk hiba, gép hiba esetén is sérülésmentes

a hibatureshez redundancia kell es ellenorzo kod. Tehat diszk hiba ellen tobb diszk, gep hiba ellen tobb gep, stb.

ez mennyi hibatűrő pl. bit hiba esetén, hogy ellenőrizhető?

ugy erted, mennyire hibaturo bithiba eseten? Bithibat a hw-hez kozel kellene kezelni a driver-nek/firmware-nek/akarminek. Te ugy tudod ellenorizni, hogy menteskor a forras oldalon keszitesz egy tartalomjegyzeket a file-ok neve ill. sha256sum alapjan. Visszaolvasaskor ujra kiszamolod az sha256-ot es osszeveted a tartalomjegyzekben szereplovel. Ezt a backup megoldasnak kellene kezelnie.

--
O1G

"ha mondjuk a forrás romlott el" fixme, de erre nem nagyon lesz gyogyszer. Ha a forras elromlik, akkor az elromlott. Marmint hogyan allapitod meg, hogy rossz? Tartalombol nem tudod, ha mellekraksz egy checksumot, akkor meg lehet a checksum is rossz mar. Ezert kell visszamenolegesen is tarolni az adatot.

-
First impressions of the new Cloud Native programming language Ballerina

( freeoli v | 2018. 12. 31., h – 20:15 )

Mekkora az adat kritikussági frekvencia?
Mekkora a példány igény fájlonkent?
Mennyi a az adatváltozas blokk és fájl szinten?
RTO RPO igény mennyi?
OS?
Egyéb lényeges service?
Csak az adat vagy a rendszer is lényeges?

A pontos és jó megoldáshoz ismerni kell az összes lényeges információt a környezettel és a felhasználással kapcsolatban.

( _Franko_ v | 2018. 12. 31., h – 20:36 )

Mindenképp magad akarod megoldani? Ha backup, akkor gondolom nem változik a fájlok tartalma, tolt fel Glacier-be, ott ez az adatmennyiség mennyiség havonta ~2.5 dollárba van és bulk módban ~1.5 dollár a visszaállítás innen. A hátránya az, hogy API-n keresztül tudod elérni. Magadnál megy úgy tárolod, ahogy olcsó, és van backup, ha kell.

--
https://iotguru.live

Vegyük ketté a kettőt:
- Backup: időnként írod, ritkán olvasod, akkor is vagy cherry picking (aka véletlenül törölt fájl) vagy teljes visszaállításra használod (aka disaster recovery)
- Live: magadnál tartott adatmennyiség, általános meghibásodásra elég redundanciával, mert bármikor vissza tudod állítani a backup-ból

Ezek szerint Te ezt a két homlokegyenest más feladatot akarod egy lépésben megoldani? Miért?

"backupot meg azért nem raknám felhőbe, mert saját tároló 1x-s költség, felhő pedig havi"

Hát, havi 2,5 dollárból a villanyszámlája nem jön ki a saját tárolódnak, főleg, ha három-négy földrajzi helyszínen akarod tárolni, de te tudod...

--
https://iotguru.live

Oké, de majd szólj, hogy mi lett az olcsóbb megoldás, mert én egyelőre ennél olcsóbbat nem találtam. A saját hardver, szoftver és üzemeltetés csak akkor olcsóbb, ha ingyen dolgozol és nem számolod a hardver költségét sem, mert "az már úgyis van"...

--
https://iotguru.live

Engem csak az erdekelne, hogy hogyan tud az amazon hardver ara alatt szolgaltatni.
Egyszer csak el kell tarolnia neki is, es a kulonbozo emberek backupjai csak kulonbozoek.

Valahogy a penzugy nem all ossze.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Pedig nagyon egyszeru a matek. hogy tudsz aliexpresszrol 30 Ft-ert zoknicsipeszt rendelni, es ugyanaz a zokni csipesz miert kerul a muanyagboltban 600 Ft-ba? Ugy tudja, hogy az hw koltsege teljesen mas mint a tied, valamint kiepitett rendszere van, tehat az egy diskre juto operatorok szama is joval alacsonyabb mint nalatok. Szerinted o milyen dijjon kapja az aramot hozzad kepest? Egyszeruen akkora ceg, hogy neki fillerekbol jon ki a dolog. Arrol nem is beszelve, hogy ha berant teged egy 2.5 dollaros backuppal vagy egy "annyit fizetsz amennyit futtatsz" lambda-val, akkor piaci elonybe kerul masokkal szemben, amikor egyeb dolgokat ki szeretnel szervezni.

-
First impressions of the new Cloud Native programming language Ballerina

"Engem csak az erdekelne, hogy hogyan tud az amazon hardver ara alatt szolgaltatni."

Nem tud a hardver ára alatt szolgáltatni, egy LTO tud nagyjából 1,5 - 2 dollár / TB áron működni és a szalag nem kér áramot, ha épp a polcon pihen, tehát az Amazon legombolja rólad néhány havonta azt, amibe az több telephelyre kimásolt adataid fizikai tárolása kerül neki life-time. Nyilván ezen felül kell áram, telephely, kiszolgáló személyzet, öltönyösök és a többi corporate cucc, meg a toronyóra lánccal.

Ha saját LTO megoldásod van, akkor a hardver, a telephely és a villany nagyjából a felére-harmadára jön ki, mint az Amazon Glacier... az apró hibácska az, hogy ez nagyjából pár ezer TB adatmennyiség felett éri meg, mert hiába 10-15 dollár egy 6,25 TB LTO-6 szalag (ha nem egyesével veszed a piacon), ha a drive 5000 dollár, amibe kézzel kell tömnöd a megfelelő kazettát... és persze erősen függ az üzemeltető technikai személyzet tudásától és bérköltségétől is, hogy a problémákat mekkora költségszinten oldják meg vagy mekkora kárt okoznak a problémamegoldás közben, mert balfaszok.

Ha neked nincs ennyi adatmennyiséged és nincsenek szakértőid, akkor go to cloud, ha meg vannak, akkor go to on premise.

--
https://iotguru.live

> egy LTO tud nagyjából 1,5 - 2 dollár / TB áron

'''
Amazon employee as saying that Glacier is based on custom low-RPM hard drives attached to custom logic boards
'''

Wikipediarol.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Pletykák vannak mindenféléről, ha tovább olvasod, akkor látod, hogy van ugyanígy pletyka a szalagos tárolásról, az optikai tárolásról és a kevert technológiájú tárolásról... normál esetben akár órák múlva tudod csak letölteni a cuccodat, ami vagy optikai vagy szalagos megoldást jelez. Vagy direkt szopat az Amazon, hogy elfedje, hogy drága HDD-t használ ekkora méretben baromi olcsó tape helyett. :)

--
https://iotguru.live

"mert saját tároló 1x-s költség" ez igy jol hangzik, csak nem feltetlen igaz :) hw koltseg, disk koltseg mondjuk raid5-el, configuracios koltseg, szunetmentes tap. Aztan jonnek a havi kiadasok, mint aram/hosting, karbantartas. Es akkor imadkozz, hogy ne legyen mondjuk tuzeset azon az egy helyen ahol az adatokat tarolod. Vajon az itt felsorolt osszegbol mennyi geo redundant storaget lehet venni?

-
First impressions of the new Cloud Native programming language Ballerina

( andrej_ v | 2018. 12. 31., h – 21:26 )

Egy RAID1 (vagy RAID1+0), akár 2+ (4+) diszkből és az rdiff-backup -pal igen jó eredményeket lehet elérni. Az offsite verzióra rsync, olyan módon, hogy több fullos példányt mentesz (naponta egyet és mondjuk vasárnaponként egy külön példányra). (Az offsite mellett én néha egy helyi diszkre is kitennék egy példányt...)

Ha fizetős megoldás is szóba jön, akkor nézd mega Veeam-et, az jóval kényelmesebb és mindenféle luxusfunkciókat is tud.

( SySERR | 2019. 01. 01., k – 11:57 )

Btrfs compress=zlib paraméterrel és ezzel be se kell csomagolni az egészet zip-be. Mehet a RAID1 is, btrfs natívan tudja.

-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

( mhmxs v | 2019. 01. 01., k – 12:36 )

"tárolt formátumban is olvasható, hozzáférhető egyesével" kb fs szintu tomoritessel lehet ezt csak kivitelezni. Vagy a backup cuccon keresztul kell elerni. Szoval jo lenne tisztani mit jelent a hozzaferhetoseg? a user felcsatolja a disket es olvassa a fajlokat, vagy pl a backup szoftverben lehet bongeszni a fajlokat, es akar egyesevel visszaallitani? Nagyon nem mindegy!

"RAID1" a raid nem backup, attol, hogy atsynceled egy masik raid 1-es storagera, a backupolast nem uszod meg.

First impressions of the new Cloud Native programming language Ballerina

En azt mondanam, hogy !legyen! ket tarolo, a problemadat nem lehet ugyanis megoldani egy lepesben. Kell egy raid1 tukor fs szintu tomoritessel, halozatban felcsatolva. A tukrozes-hez jo lenne ha a forras fs tamogana a snapshotokat, maskulonben a hajadra kenheted a tukrozest. Es a tukorrol szinten snapshotolva lehet kesziteni a tavoli szerverre az inkrementalis es mondjuk heti full backupot. Ide erdemes raid5-ot pakolni, ott talan a "legoptimalisabb" a kapacitas/biztonsag arany. Tervezd meg, hogy mit szeretnel, aztan lehet valami kesz sw meg is felel.

-
First impressions of the new Cloud Native programming language Ballerina

( Fisher v | 2019. 01. 01., k – 12:37 )

A bithibához: a fotóiról md5sumot készítek amikor lemásolom a kártyáról. Úgy döntöttem, hogy ez a változat a jó változat. Az md5sum később kényelmesen ellenőrizhető. Nem állítom hogy milliós nagyságrend esetén is remek megoldás, de lehet hogy a havi egyszeri futás belefér. Esetleg ionice-szal idomítva.

Csak egy ötlet.

Ha mar homebrew.
En bongeszo alapon csinaltam meg:)

Az md5sum helyett sha256, mert van parancssorbol sha256sum bongeszoben meg crypto.sublte.digest.
Kb. egy .bittorrent fajlt csinalok hozza, amiben benne van a fajl sha256 sumja, a chunkok listaja, a neve es merete.
Ha a feltoltes megszakad, akkor csak azokat a darabokat tolti ujra, ami a szerver oldalon hianyzik.

Konyvtarra is mukodik a webkitdirectory attributummal.
Meg az hianyzik, hogy a szerver is tudja a chunkokat egymas kozt adni venni:)
Egy 2GB-os fajl letoltese kicsit trukkosebb, mert ott is chunkokat tolt le a bongeszo, csak indexedDB-be.

Nehany gondolatebreszto:
https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/webki…
https://github.com/mi-g/webextensions-examples/blob/example/indexeddb-f…

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nem ugyanaz:)

En azert csinaltam, hogy tudjak 4GB-os fajlt feltolteni es letolteni. Ugy, hogy megszakadhat a net alatta, meg meg lehet allitani es folytatni.

Ez a primary usecase weboldalon. Innen indult, erre keszitettem.

Az osszes tobbi (szerverek adjak-veszik a chunkokat) mar csak a tovabbgondolasa es todo.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....