Backup pakket met bescherming tegen bitrot

[Brent]

Gebruikt er hier iemand backup tools als bup of attic? Zoja, welke? Ik zoek me scheel naar een tool die parity checks (en fixes!) doet, ten behoeve van resistente tegen bitrot, maar ik vind niks...

[gekkie]

Brent schreef op woensdag 16 december 2015 @ 14:02:
Gebruikt er hier iemand backup tools als bup of attic? Zoja, welke? Ik zoek me scheel naar een tool die parity checks (en fixes!) doet, ten behoeve van resistente tegen bitrot, maar ik vind niks...

Met Duplicity kan je par2 gebruiken:
--par2-options options
Verbatim options to pass to par2.

--par2-redundancy percent
Adjust the level of redundancy in percent for Par2 recovery files (default 10%).

(met dit als onderhavige techniek: Wikipedia: Parchive )

[ Voor 9% gewijzigd door gekkie op 16-12-2015 14:40 ]

[InflatableMouse]

Brent schreef op woensdag 16 december 2015 @ 14:02:
Gebruikt er hier iemand backup tools als bup of attic? Zoja, welke? Ik zoek me scheel naar een tool die parity checks (en fixes!) doet, ten behoeve van resistente tegen bitrot, maar ik vind niks...

Zet je backups op ZFS .

[Brent]

InflatableMouse schreef op woensdag 16 december 2015 @ 14:48:
[...]


Zet je backups op ZFS .

Die checksummed alleen maar (wat al heel wat is, zeker).

gekkie schreef op woensdag 16 december 2015 @ 14:38:
[...]

Met Duplicity kan je par2 gebruiken:
--par2-options options
Verbatim options to pass to par2.

--par2-redundancy percent
Adjust the level of redundancy in percent for Par2 recovery files (default 10%).

(met dit als onderhavige techniek: Wikipedia: Parchive )

Dank u zeer! Ik ga dit bekijken. Gebruik jij dat ook?

[Paul]

Brent schreef op woensdag 16 december 2015 @ 16:09:
Die checksummed alleen maar (wat al heel wat is, zeker).

Als je het op een JBOD of stripe zet wel, als je het op een RAID-Z1/2/3 zet dan kan het zeker ook repareren

Als het puur om bitrot gaat en niet om uitval van de schijf dan kun je hetzelfde doen met partities (of bestanden) ipv hele disken.

[Brent]

Paul schreef op woensdag 16 december 2015 @ 16:17:
[...]
Als het puur om bitrot gaat en niet om uitval van de schijf dan kun je hetzelfde doen met partities (of bestanden) ipv hele disken.

Het gaat me idd om bitrot, en omdat par2 niet zo lekker werkt tegen hele filetrees zoek ik een andere oplossing.

Ik zie dat duplicity het woord 'verify' iets anders gebruikt dan andere tools: het is een vergelijking met een andere dir, ipv een integriteitscheck met checksums/par files. Ik zie onder de par2 note dat hij, indien par2 files aanwezig, de files terugzet en automatische corrigeert indien nodig. Ik zie echter geen mogelijkheid gewoon het archief op integriteit te controleren. Kan dat ook? En wanneer ik verify tegen een lokale dir, is dat dan bit voor bit?

[gekkie]

Brent schreef op woensdag 16 december 2015 @ 16:09:
[...]
Die checksummed alleen maar (wat al heel wat is, zeker).
[...]
Dank u zeer! Ik ga dit bekijken. Gebruik jij dat ook?

Duplicity wel, par2 nog niet eigenlijk ..

Uhmm hij doet dus par2 op je backup (geencrypte en gezipte files) .. niet op individuele files in je archief. Bij een restore doet hij checksum controle, is er iets loos dan wordt er een repair gepoogd op basis van de par2 files. Slaagt dat dan wordt de meuk vanuit het gerepareerde backup-bestand terug gezet.

[ Voor 35% gewijzigd door gekkie op 16-12-2015 16:37 ]

[Brent]

gekkie schreef op woensdag 16 december 2015 @ 16:32:
[...]

Duplicity wel, par2 nog niet eigenlijk ..

Uhmm hij doet dus par2 op je backup (geencrypte en gezipte files) .. niet op individuele files in je archief. Bij een restore doet hij checksum controle, is er iets loos dan wordt er een repair gepoogd op basis van de par2 files. Slaagt dat dan wordt de meuk vanuit het gerepareerde backup-bestand terug gezet.

Maar ik kan dus niet monitoren of het archief zelf rotte bits heeft?

Wat gebeurd er precies bij verify? worden alle lokale files gechecksummed en dan gecheckt tegen de backup (die vermoedelijk de checksums niet herberekend)?

[gekkie]

Brent schreef op woensdag 16 december 2015 @ 16:40:
[...]
Maar ik kan dus niet monitoren of het archief zelf rotte bits heeft?

Wat gebeurd er precies bij verify? worden alle lokale files gechecksummed en dan gecheckt tegen de backup (die vermoedelijk de checksums niet herberekend)?

Dat laatste standaard niet ..
--compare-data
Enable data comparison of regular files on action verify. This is disabled by default for performance reasons.

Gok dat hij standaard alleen meta-data checkt zoals modification timestamp .. size etc.
Met --compare-data zal hij wel met rolling-checksums (is gebaseerd op librsync) gaan vergelijken.

In principe slaat hij volgens mij de checksums ook op in losse signature files bij de backup, dus deze zouden te checken moeten zijn qua integriteit van het archief.

[Paul]

Brent schreef op woensdag 16 december 2015 @ 16:40:

ZFS Sowieso geeft het bij een scrub aan welke bestanden er rot zijn, en als je voldoende parity hebt in je vdev dan repareert het ook. De checksums staan in de metadata en de data waarmee hij het origineel herstelt staat op de overige "disken" van je vdev.

Groot voordeel boven PAR2 is dat het bijwerken van de parity geheel automatisch gaat, je hoeft niet opnieuw te parren als je het archief bijwerkt. Tevens beschermt het de individuele files in plaats van enkel het geheel. Gaat er iets gruwelijk mis dan ben je misschien bestand C en H kwijt, maar A, B, D, E, F, G en I heb je nog, terwijl je met PAR mogelijk het hele archief af moet schrijven (of je moet losse files uit het archief gaan parren ).

Maareh, kun je hier niet beter een nieuw topic voor starten?

[Brent]

Paul schreef op woensdag 16 december 2015 @ 17:38:
[...]
ZFS Sowieso geeft het bij een scrub aan welke bestanden er rot zijn, en als je voldoende parity hebt in je vdev dan repareert het ook.

Met vdev bedoel je schijven bijgooien? Dat is niet echt de oplossing die ik zoek, ik zoek iets tussen dat en checksums in. Het gaat me om bitrot, niet disk failure. Ik checksum nu handmatig en zie met enige regelmaat rotte bitjes. Elke kopie afzonderlijk (want par is natuurlijk geen backup) resistent te maken lijkt me een stuk veiliger dan schijven bijzetten.

Voor zover ik kan overzien is de enige tool duplicity, waarbij ik het archief zelf niet op integriteit kan checken, maar wel een andere dir kan checken c.q. terugzetten.

Ik vond een bup cronjob script waarbij iemand het er zelf opgeklust heeft maar daar vertrouw ik maar liever niet op

[begintmeta]

Er zijn allerlei tools om streams van FEC te voorzien, maar files op zich niet, wel interessant eigenlijk.

[Brent]

begintmeta schreef op woensdag 16 december 2015 @ 19:43:
Er zijn allerlei tools om streams van FEC te voorzien, maar files op zich niet, wel interessant eigenlijk.

Ik weet niet precies wat een HDD/SDD dezer dagen op block level doet, maar het verbaast me enorm dat met de wetenschap dat TBs aan data fysisch gezien zeker omgeslagen bits moeten hebben, we daar toch niets aan doen om fs niveau of een tree hoger. Raid is niet echt de oplossing hiervoor, zeker niet voor je moeder terwijl die inmiddels ook een TB schijf heeft en dus bitrot.

[begintmeta]

Voor zover ik weet worden in low-level storage-hardware en overdrachtprotocollen allerlei foutcorrigerende methoden gebruikt, anders was het allemaal nog veel erger (of onwerkbaar) geweest, maar uiteindelijk is er altijd een afweging die moet worden gemaakt van wat nog tolerabel/zinvol is en wat het kost, je kan tenslotte ook componenten(software/hardware) toevoegen om op hoger niveau weer wat extra zekerheid te verkrijgen, ook afhankelijk van de toepassing. In die zin snap ik wel dat men een soort 'bouwstenen' voor een redelijke prijs maakt die universeel te gebruiken zijn in systemen die eventueel grotere betrouwbaarheid vereisen, het zal ongetwijfeld zo zijn dat mettertijd complexere/nu duurdere methoden in de bouwstenen terecht komen.

Wat betreft RAID: als de schijf gewoon netjes aan het RAID-systeem meldt dat fouten zijn opgetreden, kan op zich op RAID-niveau naar oplossingen worden gezocht lijkt me.

[ Voor 16% gewijzigd door begintmeta op 17-12-2015 12:04 ]

[gekkie]

Brent schreef op donderdag 17 december 2015 @ 11:11:
[...]
Ik weet niet precies wat een HDD/SDD dezer dagen op block level doet, maar het verbaast me enorm dat met de wetenschap dat TBs aan data fysisch gezien zeker omgeslagen bits moeten hebben, we daar toch niets aan doen om fs niveau of een tree hoger. Raid is niet echt de oplossing hiervoor, zeker niet voor je moeder terwijl die inmiddels ook een TB schijf heeft en dus bitrot.

Vandaar toch uiteindelijk de ontwikkeling van ZFS en BTRFS ?
Op z'n minst kun je het detecteren, afhankelijk van je setup en de mate ook restoren.

Dat het nog betrekkelijk weinig wordt ingezet zal dan toch betekenen dat de gevolgen voor de meeste mensen in de praktijk kennelijk nogal meevalt tot nu toe.

begintmeta schreef op donderdag 17 december 2015 @ 11:49:
Wat betreft RAID: als de schijf gewoon netjes aan het RAID-systeem meldt dat fouten zijn opgetreden, kan op zich op RAID-niveau naar oplossingen worden gezocht lijkt me.

Volgens de datacorruption wiki is er wel aanleiding om te veronderstellen dat dit toch niet altijd het geval is:

As an example, ZFS creator Jeff Bonwick stated that the fast database at Greenplum – a database software company specializing in large-scale data warehousing and analytics – faces silent corruption every 15 minutes.[9] As another example, a real-life study performed by NetApp on more than 1.5 million HDDs over 41 months found more than 400,000 silent data corruptions, out of which more than 30,000 were not detected by the hardware RAID controller. Another study, performed by CERN over six months and involving about 97 petabytes of data, found that about 128 megabytes of data became permanently corrupted.[10][11]

[ Voor 39% gewijzigd door gekkie op 17-12-2015 14:43 ]

[Paul]

Brent schreef op woensdag 16 december 2015 @ 18:48:
Met vdev bedoel je schijven bijgooien?

Nee. Een ZFS pool is opgebouwd uit vdevs, virtuele devices. Een virtual device kan zijn opgebouwd uit een of meerdere schijven, maar dat hoeft absoluut niet, je kunt het ook met bestanden doen. Bij het aanmaken van een vdev bepaal je de redundancy, net als bij RAID 1, 5, 6 (en 7).

Als je geen hele disken gebruikt dan beschermt het ook niet tegen uitval van een disk, maar het beschermt je nog steeds tegen bitrot.

Overigens, als je zoveel last hebt van bitrot dan zou ik eens onderzoeken waar dat vandaan komt, want je lijkt nu aan symptoombestrijding te doen Als voorbeeldje, mijn ZFS NAS met ~10 TB aan data voert iedere maand een scrub uit, en heeft afgelopen jaar precies nul fouten gevonden, dus nul bitrot. Als jij aan de lopende band omvallende bitjes hebt is er misschien iets mis met je schijf of de kabel of zo.

[ Voor 15% gewijzigd door Paul op 17-12-2015 15:37 ]

[Brent]

Paul schreef op donderdag 17 december 2015 @ 15:35:
[...]
Nee. Een ZFS pool is opgebouwd uit vdevs, virtuele devices. Een virtual device kan zijn opgebouwd uit een of meerdere schijven, maar dat hoeft absoluut niet, je kunt het ook met bestanden doen. Bij het aanmaken van een vdev bepaal je de redundancy, net als bij RAID 1, 5, 6 (en 7).

Het grote verschil is dat jij meer overhead hebt dan bijvoorbeeld .par files. Je dupliceert gewoon in ZFS, toch? Geen 5-10% parity, nee, een parity drive of volume tegen N drives. Of begrijp ik het verkeerd?

Bovendien zit je vast aan je fs.

Overigens, als je zoveel last hebt van bitrot dan zou ik eens onderzoeken waar dat vandaan komt, want je lijkt nu aan symptoombestrijding te doen Als voorbeeldje, mijn ZFS NAS met ~10 TB aan data voert iedere maand een scrub uit, en heeft afgelopen jaar precies nul fouten gevonden, dus nul bitrot. Als jij aan de lopende band omvallende bitjes hebt is er misschien iets mis met je schijf of de kabel of zo.

Heb je ECC geheugen? Dat verklaard al een hoop Punt is niet zozeer dat ik een oplossing wil, maar eentje die de realiteit van consumenten hardware en multiTB opslag in acht neemt. Dan zit je, zonder maatregelen, gegarandeerd aan een bepaald minimum. Ik zou er liever helemaal niet over na denken dmv slimme software. Gezien het feit dat checksummen tegenwoordig bijna standaard is, waarom niet de volgende logische stap? Zou ik een fs hebben dat automatisch bijv. 5% parity biedt, dan laat ik dat niet liggen, toch?

Maargoed, ik ben niet zo geïnteresseerd in de hardware kant van het verhaal. Ik zoek backup software, of software die parity toevoegt op filetree niveau.

[begintmeta]

Wellicht kan je naar een distributed file system backuppen, ik meen dat die vaak FEC implementeren.

[Brent]

Toevallig een draadje op Hackernews precies hierover, en dit tooltje kan middels fuse transparant een dir voorzien van zo'n soort parity.

[gekkie]

Brent schreef op donderdag 17 december 2015 @ 15:54:
[...]
Het grote verschil is dat jij meer overhead hebt dan bijvoorbeeld .par files. Je dupliceert gewoon in ZFS, toch? Geen 5-10% parity, nee, een parity drive of volume tegen N drives. Of begrijp ik het verkeerd?

Bovendien zit je vast aan je fs.
[...]
Heb je ECC geheugen? Dat verklaard al een hoop Punt is niet zozeer dat ik een oplossing wil, maar eentje die de realiteit van consumenten hardware en multiTB opslag in acht neemt. Dan zit je, zonder maatregelen, gegarandeerd aan een bepaald minimum. Ik zou er liever helemaal niet over na denken dmv slimme software. Gezien het feit dat checksummen tegenwoordig bijna standaard is, waarom niet de volgende logische stap? Zou ik een fs hebben dat automatisch bijv. 5% parity biedt, dan laat ik dat niet liggen, toch?

Maargoed, ik ben niet zo geïnteresseerd in de hardware kant van het verhaal. Ik zoek backup software, of software die parity toevoegt op filetree niveau.

Maar zonder ECC geheugen en een gegarandeerd foutloze kernel + firmware hou je toch nog genoeg problemen over die je bestanden corrupt kunnen maken. Wat dat betreft kan alles wat voor je FS zit de handel ook corruperen zonder dat je dat merkt in je checksums (hooguit in sommige gevallen met een bit voor bit verify met je bron als je aanneemt dat die niet aangetast is en hetzelfde probleem niet altijd optreed.
(kortom zonder draconische maatregelen (en met er niet over nadenken) is het eigenlijk onmogelijk om alles uit te sluiten).

Maar goed zelf heb ik meerdere fullbackups staan, die ook nog een gemirrord worden (maar niet gecheckt op bit niveau .. dus als mijn kopie hier kapoet gaat zou die niet naar de overkant moeten gaan) ... dus al met al acht ik het risico beperkt (en dat is dan nog buiten 2 werk kopiën op m'n laptops)

[CAPSLOCK2000]

Brent schreef op donderdag 17 december 2015 @ 15:54:
Het grote verschil is dat jij meer overhead hebt dan bijvoorbeeld .par files. Je dupliceert gewoon in ZFS, toch? Geen 5-10% parity, nee, een parity drive of volume tegen N drives. Of begrijp ik het verkeerd?

Ja en nee. De overhead is inderdaad een hele drive (of zelfs meerdere drives). Daar staat tegenover dat je meer fouten kan opvangen. De hoeveelheid overheid is min of meer gelijk aan de hoeveel redundantie die je hebt.
Als je 10% PAR data hebt dan kun je 10% van je data verliezen en herstellen. Met een RAIDZ1 van 3 disks kun je 33% van je data verliezen en weer herstellen.
Een RAIDZ1 van 10 disks heeft ook maar 10% overhead (dat wordt afgeraden maar dat terzijde).
Als je wil kan je PAR ook vragen om 50% genoeg herstelblokken te maken om 50% van je data te kunnen verliezen. Dan is het net zo efficient als een RAID1 met twee schijven.

Wat betreft RAID: als de schijf gewoon netjes aan het RAID-systeem meldt dat fouten zijn opgetreden, kan op zich op RAID-niveau naar oplossingen worden gezocht lijkt me.

Nee, zo werkt het niet. RAID kent 1 oplossing voor fouten: schakel de disk uit. Het is een misverstand dat RAID fouten in je data kan detecteren of zelfs herstellen. Het enige wat RAID kan detecteren is dat een schijf helemaal stuk is. Een schijf die een beetje stuk is en de verkeerde bitjes terugstuurt wordt niet gezien.

Het kan in theorie wel. Dat is precies wat ZFS doet.


Ik ken geen backupsystemen die parity goed geregeld hebben. Meestal is de aanpak juist dat de backup heel dom is, niet meer dan een recht-toe recht-aan lijst met bitjes. Het enige doel van zo'n systeem is de bitjes zo snel mogelijk op tape zetten of ze er weer af lezen. Al het andere doe je daar buiten. Als je meer wil dan maak je verschillende backups die je met elkaar kan vergelijken.

[Brent]

gekkie schreef op donderdag 17 december 2015 @ 17:13:
[...]

Maar zonder ECC geheugen en een gegarandeerd foutloze kernel + firmware hou je toch nog genoeg problemen over die je bestanden corrupt kunnen maken. Wat dat betreft kan alles wat voor je FS zit de handel ook corruperen zonder dat je dat merkt in je checksums (hooguit in sommige gevallen met een bit voor bit verify met je bron als je aanneemt dat die niet aangetast is en hetzelfde probleem niet altijd optreed.
(kortom zonder draconische maatregelen (en met er niet over nadenken) is het eigenlijk onmogelijk om alles uit te sluiten).

Ik merk dat er mensen zijn die het probleem willen voorkomen, terwijl makers van opslagmedia al in de jaren 70 wisten dat zonder Reed Solomon nergens zijn. Een extra om onvermijdelijke fouten te herstellen zie ik dus als nuttigere inzet van mijn middelen dan het probleem minimaliseren. Dat tooltje met freeze.sh en meld.sh is gebaseerd op rsbep, kennelijk al een oude tool. Ziet er leuk uit, ook omdat het onafhankelijk van het fs lijkt te zijn.


[edit] Ik zie nu net dat bup ook par2 ondersteunt: https://github.com/bup/bup. Met bup-fsck kun je je archief checken en fixen. Testbaar met bup-damage, dat random bits flipt. Kijk, das wat ik zoek!

[ Voor 7% gewijzigd door Brent op 17-12-2015 17:31 ]

[Paul]

Brent schreef op donderdag 17 december 2015 @ 15:54:
Het grote verschil is dat jij meer overhead hebt dan bijvoorbeeld .par files. Je dupliceert gewoon in ZFS, toch? Geen 5-10% parity, nee, een parity drive of volume tegen N drives. Of begrijp ik het verkeerd?

Op zich begrijp je dat goed, maar wat is het verschil tussen 1x parity "volume" op 10 data"volumes" of een PAR2-bestand dat net zo groot is als 10% van je data?

Zou ik een fs hebben dat automatisch bijv. 5% parity biedt, dan laat ik dat niet liggen, toch?

Om vervolgens net dat FS af te schieten

Maargoed, ik ben niet zo geïnteresseerd in de hardware kant van het verhaal. Ik zoek backup software, of software die parity toevoegt op filetree niveau.

Dan doe je het toch zonder (extra) hardware?

Mij heb je er niet mee als je iets anders gebruikt, maar vooralsnog krijg ik het idee dat je ZFS afwijst om de verkeerde redenen

CAPSLOCK2000 schreef op donderdag 17 december 2015 @ 17:15:
Een RAIDZ1 van 10 disks heeft ook maar 10% overhead (dat wordt afgeraden maar dat terzijde).
Als je wil kan je PAR ook vragen om 50% genoeg herstelblokken te maken om 50% van je data te kunnen verliezen. Dan is het net zo efficient als een RAID1 met twee schijven.

RAIDZ1 op 10 disken wordt afgeraden omdat de kans dat je een 2e URE krijgt tijdens de rebuild / resilver erg groot wordt. Sowieso vind ik 10% parity aan de lage kant, maar als je niet tegen een URE wilt beschermen (want hardware) en de filetree die je wilt beschermen geen terabytes groot is dan kan het best.

[Brent]

Paul schreef op donderdag 17 december 2015 @ 22:34:
[...]
Op zich begrijp je dat goed, maar wat is het verschil tussen 1x parity "volume" op 10 data"volumes" of een PAR2-bestand dat net zo groot is als 10% van je data?

Een stuk lastiger te beheren/vergroten/verkleinen? Een par-file, een bup repo of bijvoorbeeld die freeze.sh/melt.sh metadata kopieer je makkelijk naar een nieuwe schijf, ongeacht fs.

Misschien begrijp ik niet hoe zfs tegenwoordig werkt, maar ik kan niet een volume aanmaken op een bestaande schijf en zeggen: zorg dat ik tegen een willekeurige 10% parity heb. Ik zou dan 10 volumes moeten maken, waarbij ik 9 volumes gebruik en 1 parity, toch? Of werkt het zo niet meer?

Om vervolgens net dat FS af te schieten

Mij heb je er niet mee als je iets anders gebruikt, maar vooralsnog krijg ik het idee dat je ZFS afwijst om de verkeerde redenen

Heb je het artikel over poorZFS.py gelezen? Snap je hoe dat erg praktisch en portable dat is? Ik geloof dat je nog steeds niet begrijpt wat mn doel is

[...]
RAIDZ1 op 10 disken wordt afgeraden omdat de kans dat je een 2e URE krijgt tijdens de rebuild / resilver erg groot wordt. Sowieso vind ik 10% parity aan de lage kant, maar als je niet tegen een URE wilt beschermen (want hardware) en de filetree die je wilt beschermen geen terabytes groot is dan kan het best.

Ik kan werkelijk niets vinden over single-drive raidz1 pools, kan me ook niet voorstellen dat dat werkbaar is eigenlijk. Maar als jij daar een howto voor hebt, ik lees het graag!

[CyBeR]

Single-drive RAID-Z1 bestaat ook niet. Daarvoor heb je minimaal 2 drives nodig en dan ben je feitelijk al degraded bezig. Voor daadwerkelijke fault-tolerance moet je er 3 of meer hebben.

De enige manier om 't op 1 drive te doen zou zijn door meerdere files (op dezelfde disk) in een vdev te stoppen maar dat is natuurlijk idioot.

[ Voor 10% gewijzigd door CyBeR op 17-12-2015 23:01 ]

[begintmeta]

Brent schreef op donderdag 17 december 2015 @ 22:53:
...... Een par-file, een bup repo of bijvoorbeeld die freeze.sh/melt.sh metadata kopieer je makkelijk naar een nieuwe schijf, ongeacht fs.
...

Ook daarom ben ik ook een grote voorstander ervan dat applicaties hun data zo nodig opslaan in een formaat met foutcorrectiemogelijkheden, uiteindelijk moeten de applicaties toch de integriteit van de data bewaken..

[jan99999]

ZFS Raid is wat je nodig hebt.

En als raid 6 instellen.
Dus bijv 5(of 6 of 7) schijven, dan mogen 2 defect gaan, dan zou raid deze nog kunnen repareren.
En niet raid 5 gaan gebruiken.

File beschadigd, dan door zfs raid kan dit gerepareerd worden.
File beschadigd met zfs zonder raid, dan is file verloren, wat zfs aangeeft(wat andere FS doen dit niet).

Zoek met youtube en google hoe dit werkt, dus ZFS.

YouTube: Interesting things you didn't know you could do with ZFS by Allan Jude
Interesting things you didn't know you could do with ZFS by Allan Jude
YouTube: ZFS Feature Overview
YouTube: Arcing ZFS | BSD Now 116
YouTube: ZFS War Stories | BSD Now 45
YouTube: Allan's ZFS Server Build | TechSNAP 34

[ Voor 48% gewijzigd door jan99999 op 18-12-2015 05:41 ]

[Brent]

jan99999 schreef op vrijdag 18 december 2015 @ 05:38:
ZFS Raid is wat je nodig hebt.

Nee, lees topic.

begintmeta schreef op donderdag 17 december 2015 @ 23:20:
[...]

Ook daarom ben ik ook een grote voorstander ervan dat applicaties hun data zo nodig opslaan in een formaat met foutcorrectiemogelijkheden, uiteindelijk moeten de applicaties toch de integriteit van de data bewaken..

Helemaal gelijk in, maar dat doet bijna geen formaat. Het gaat me om muziek, fotos, wat documenten. Backups doe ik braaf, en checksums met het handje, maar fouten opzoeken en terugzetten vergt toch elke keer weer mee handwerk dan me lief is. En het lijkt mij extreem logisch dat dedicated backup software (of inderdaad toch een fs zelf) zoiets ingebouwd heeft, niet alleen checksums.

Het doel is fire and forget: zet backup op externe schijf bij vrienden/familie en die gegarandeerde bitflips die er over 3 jaar zijn zijn een peuleschilletje voor melt.sh/par2/etc. Lokaal kan ik natuurlijk wat vaker checken, en dan heb ik hetzelfde voordeel. Helemaal mooi is als het een ouders-proof oplossing is, want ook mijn vader heeft tussen zijn terabytes aan fotos weleens corruptie gehad. Zelfs een archiefformaat als .dng doet niet eens aan checksummen.

[ Voor 77% gewijzigd door Brent op 18-12-2015 11:11 ]

[Paul]

Brent schreef op donderdag 17 december 2015 @ 22:53:
Een stuk lastiger te beheren/vergroten/verkleinen? Een par-file, een bup repo of bijvoorbeeld die freeze.sh/melt.sh metadata kopieer je makkelijk naar een nieuwe schijf, ongeacht fs.

Vergroten? Zeker niet. De afzonderlijke onderdelen van de onderliggende storage vergroten, pool vergroten, klaar. Verkleinen, geen idee, volgens mij moet je dan een 2e pool maken en de data kopiëren.

Ik zou dan 10 volumes moeten maken, waarbij ik 9 volumes gebruik en 1 parity, toch? Of werkt het zo niet meer?

Zo heeft het nooit gewerkt. Je hebt inderdaad 10 schijven, files, whatever, en die worden gecombineerd naar één pool die je ergens mount. Je hebt dus maar één plek waar je naartoe schrijft / vandaan leest, geen 9.

Heb je het artikel over poorZFS.py gelezen?

Heb je een linkje?

Ik geloof dat je nog steeds niet begrijpt wat mn doel is

Je hebt een backup ergens van en je wilt deze beschermen tegen bitrot? Dit is de eerste keer dat je over portabiliteit begint

Ik kan werkelijk niets vinden over single-drive raidz1 pools, kan me ook niet voorstellen dat dat werkbaar is eigenlijk. Maar als jij daar een howto voor hebt, ik lees het graag!

Euhm, in plaats van "zpool create" met disks doe je hetzelfde met files? It's that simple https://flux.org.uk/tech/2007/03/zfs_tutorial_1.html

CyBeR schreef op donderdag 17 december 2015 @ 23:00:
De enige manier om 't op 1 drive te doen zou zijn door meerdere files (op dezelfde disk) in een vdev te stoppen maar dat is natuurlijk idioot.

Waarom is dat idioot? Ja, het beschermt je niet tegen de uitval van de disk, maar al het andere wat ZFS je aan databeveiliging biedt heb je wel, en TS heeft expliciet aangegeven niet geïnteresseerd te zijn in het beschermen tegen uitval van de disk

Brent schreef op vrijdag 18 december 2015 @ 11:00:
Nee, lees topic.

Ik weet het niet hoor, als er nu al 3 mensen zijn die zeggen dat het een oplossing is voor je probleem en jij blijft volhouden van niet dan moet je jezelf ofwel eens verdiepen in wat die oplossing precies is, ofwel je probleem beter uitleggen

[gekkie]

Brent schreef op vrijdag 18 december 2015 @ 11:00:
[...]
Nee, lees topic.
[...]
Helemaal gelijk in, maar dat doet bijna geen formaat. Het gaat me om muziek, fotos, wat documenten. Backups doe ik braaf, en checksums met het handje, maar fouten opzoeken en terugzetten vergt toch elke keer weer mee handwerk dan me lief is. En het lijkt mij extreem logisch dat dedicated backup software (of inderdaad toch een fs zelf) zoiets ingebouwd heeft, niet alleen checksums.

Het doel is fire and forget: zet backup op externe schijf bij vrienden/familie en die gegarandeerde bitflips die er over 3 jaar zijn zijn een peuleschilletje voor melt.sh/par2/etc. Lokaal kan ik natuurlijk wat vaker checken, en dan heb ik hetzelfde voordeel. Helemaal mooi is als het een ouders-proof oplossing is, want ook mijn vader heeft tussen zijn terabytes aan fotos weleens corruptie gehad. Zelfs een archiefformaat als .dng doet niet eens aan checksummen.

Tsja afwegingen afwegingen, een hoop formaten doen hun best om het zo compact mogelijk op te slaan. Redundant bitjes komt daar uiteraard niet geheel mee overheen. De vraag is ook of het optioneel mogelijk maken in een bestandsformaat voor een hoop bestandsformaten zo veel gebruikt gaat worden.
Kortom er zijn initiatieven gekomen om het achter op file niveau, of voor je gehele storage volume in een keer te doen. Er is dus backupsoftware die er gebruikt van maakt, er zijn filesystems die het inbouwen (maar de implementatie te samen met een vorm van RAID is gedaan om inefficiente gestapelde redundancy op redundancy te voorkomen, opzich ook niet onlogisch).

[Brent]

Paul schreef op vrijdag 18 december 2015 @ 11:13:
[...]
Heb je een linkje?

http://users.softlab.ntua.gr/~ttsiod/rsbep.html

[...]
Je hebt een backup ergens van en je wilt deze beschermen tegen bitrot? Dit is de eerste keer dat je over portabiliteit begint

Leek me impliciet bij het bespreken van backup tool.

[...]
Euhm, in plaats van "zpool create" met disks doe je hetzelfde met files? It's that simple https://flux.org.uk/tech/2007/03/zfs_tutorial_1.html

Die zitten dan weer op een ander fs, mogelijk zfs? Ik dacht dat we zo eerlijk mogelijk moesten zijn tegen zfs Ik neem m door! Maar het klinkt wat lastig in gebruik...

[...]
Ik weet het niet hoor, als er nu al 3 mensen zijn die zeggen dat het een oplossing is voor je probleem en jij blijft volhouden van niet dan moet je jezelf ofwel eens verdiepen in wat die oplossing precies is, ofwel je probleem beter uitleggen

Ik droeg een paar linkjes aan, als iemand weer met de raidz hamer komt, dan ga ik ervan uit dat ze het topic niet hebben doorgenomen Nogmaals, er is een groep mensen voor wie parity gelijkstaat aan RAID Z/5+, ik weet dat die kerk bestaat maar ben er geen lid van Wat ik zoek in het kort: resistentie tegen bitrot op filetrees, liefst onafhankelijk van fs, maar zeker onafhankelijk van disks of aantal disks.

In feite dus hetzelfde als wat je disk intern ook al doet (ECC) of je optische media (Reed-Solomon), maar dan een extra laag omdat ik zie (en op basis van mtbf we weten) dat dat niet genoeg is.

[ Voor 7% gewijzigd door Brent op 18-12-2015 11:44 ]

[begintmeta]

Goed, dus om het even wat kort door de bocht op een rijtje te zetten:

A Bestanden moeten direct, zonder 'tussenstappen' (conversie/transformatie), beschikbaar zijn.
B Bestanden moeten op op 1 fysiek medium (b.v. harddisk, tape, dvd, cloudstorage) worden opgeslagen
C Bij bitflips op die drager/in de bestanden (waarbij we aannemen dat dat de spuigaten niet uitloopt), blijft de informatie in de bestanden intact beschikbaar
D In het geval de bestanden beschadigd zijn, moet op zijn minst automatisch worden gewaarschuwd.
E Bestanden moeten eenvoudig op verschillende gangbare besturingssystemen beschikbaar kunnen worden gemaakt.
F Het moet eenvoudig zijn de structuren waarin de bestanden zich bevinden te wijzigen (kopieren naar ander medium, vergroten/verkleinen op hetzeflfde medium...

Om aan alle voorwaarden te voldoen ben je volgens mij afhankelijk van het bestandsformaat/de software die de gegevens in de bestanden aanmaakt/verwerkt. Als je A zou laten vallen kan je gebruik maken van bestaande archiefformaten, bij E/F van kleiner belang kan je eventueel zfs met ...

[Brent]

begintmeta schreef op vrijdag 18 december 2015 @ 14:28:
Goed, dus om het even wat kort door de bocht op een rijtje te zetten:

A Bestanden moeten direct, zonder 'tussenstappen' (conversie/transformatie), beschikbaar zijn.
B Bestanden moeten op op 1 fysiek medium (b.v. harddisk, tape, dvd, cloudstorage) worden opgeslagen
C Bij bitflips op die drager/in de bestanden (waarbij we aannemen dat dat de spuigaten niet uitloopt), blijft de informatie in de bestanden intact beschikbaar
D In het geval de bestanden beschadigd zijn, moet op zijn minst automatisch worden gewaarschuwd.
E Bestanden moeten eenvoudig op verschillende gangbare besturingssystemen beschikbaar kunnen worden gemaakt.
F Het moet eenvoudig zijn de structuren waarin de bestanden zich bevinden te wijzigen (kopieren naar ander medium, vergroten/verkleinen op hetzeflfde medium...

Om aan alle voorwaarden te voldoen ben je volgens mij afhankelijk van het bestandsformaat/de software die de gegevens in de bestanden aanmaakt/verwerkt. Als je A zou laten vallen kan je gebruik maken van bestaande archiefformaten, bij E/F van kleiner belang kan je eventueel zfs met ...

Om heel precies te zijn, ben ik geinteresseerd in het landschap, en dan met name niet in Raid z/5+. Die laatste kennen we goed, maar is niet echt praktisch wanneer je tot 1 schijf bent veroordeeld. Met een beetje speuren kwamen we op Duplicity,bup,poorZFS.py. Ben benieuwd wat er meer is.

[begintmeta]

Zou het niet best makkelijk zijn de een of andere ldpc-coder/decoder te maken voor de commandline?

ldpccod < familiefoto.jpeg > familifoto.jpeg.ldpc
ldpcdec < familifoto.jpeg.ldpc > familifoto.jpeg

Kan me voorstellen dat zoiets ook al bestaat (er zijn in iedergeval allerlei libs voor erasure coding en/of toevoegen van ec-informatie), bup is natuurlijk ook wel aardig.


Heb min of meer iets gevonden: zfec, mar het kan bijna niet anders of er is meer.

[ Voor 34% gewijzigd door begintmeta op 21-12-2015 12:09 ]

[Paul]

Brent schreef op vrijdag 18 december 2015 @ 11:36:
http://users.softlab.ntua.gr/~ttsiod/rsbep.html

Whut, dat gaat allen maar over melt.sh en freeze.s... oh wacht, het wordt één keer poorZFS genoemd Qua concept ziet het er wel ok uit denk ik?

Leek me impliciet bij het bespreken van backup tool.

Jij sleept je tapes / disklibrary van hot naar her, en gebruikt ze daar? Mijn backups worden op één locatie neergezet en daar blijven ze tot de retentie verloopt. Dus nee, dat is niet echt impliciet nee

Die zitten dan weer op een ander fs

Dat klopt, wat je maar wil, ext3, ext4, fat32, whatever. net als bij die freeze/melt-oplossing hierboven zet je bestanden op een willekeurig FS en vervolgens bied je het aan via (in dat geval) FUSE.

Maar het klinkt wat lastig in gebruik...

Wat, gewoon schrijven naar /mnt/backup (of wherever)? Als naar /strong schrijven lukt dan moet het naar het mountpoint van ZFS ook lukken

Nogmaals, er is een groep mensen voor wie parity gelijkstaat aan RAID Z/5+, ik weet dat die kerk bestaat maar ben er geen lid van Wat ik zoek in het kort: resistentie tegen bitrot op filetrees, liefst onafhankelijk van fs, maar zeker onafhankelijk van disks of aantal disks.

Parity staat zeker niet gelijk aan RAIDZ, maar RAIDZ is wel een manier van parity waarop je makkelijk bitrot opfiletrees kunt opvangen, wat onafhankelijk is van het onderliggende FS en ook onafhankelijk is van disks of aantallen disks.

De reden dat men het over het algemeen met disks doet is omdat je dan nog meer bescherming hebt dan wanneer je het met files doet, maar als je doel expliciet is om data van A naar B te transporteren (wat je nog steeds niet hard hebt uitgesproken) dan is het niet handig om met meerdere schijven te gaan lopen ipv één USB-stickie...

Ik denk nog steeds dat je beter naar de oorzaak van die bitrot kunt gaan zoeken want je bent de enige die meldt met grote regelmaat bitrot tegen te komen, zo vaak dat je iedere kopieeractie ermee wilt gaan beschermen. Volgens mij is gewoon je PC stuk... De laatste keer dat ik bitrot tegen ben gekomen was toen ik nog met floppies rondliep. En nee, ik gebruik geen ECC geheugen over het algemeen (wel in de fileserver, maar dat is vooral statische data, mijn werkstation zet veel meer data om).

Brent schreef op vrijdag 18 december 2015 @ 14:32:
Om heel precies te zijn, ben ik geinteresseerd in het landschap

Heb je nu wel of niet een specifiek probleem dat je op wilt lossen? Want als dit geheel een theoretische exercitie is dan moet je dat zeggen...

Die laatste kennen we goed, maar is niet echt praktisch wanneer je tot 1 schijf bent veroordeeld.

Vergroten en verkleinen van het archief is een probleem, dat klopt, maar verder is het net zo simpel als PoorZFS.py... Je PC moet er ondersteuning voor hebben (ZFS <> Pyton / FUSE / rsbep) en je moet het mounten / unmounten (zfs import <> PoorZFS.py).

Maar goed, je bent dus op zoek naar het totaal aan programma's / oplossingen, dan heeft het weinig zin dieper in te gaan op één daarvan, dat is dan voor een vervolgstudie of zo.

[Brent]

Paul schreef op zondag 20 december 2015 @ 14:22:
[...]

Paul, ben blij dat je wil meedenken, maar toch maar weer RAIDZ erbij halen helpt niet echt Heb nu al meer dan eens aangegeven waarom dat afvalt (single drive, bitrot is wel een echt probleem, en ik wil het niet oplossen met een RAID array die ik niet in mijn laptop kan hebben). Zodra ZFS Reed-Solomon gebruikt om van checksums naar een 'echte' parity check te gaan hoor ik het graag

begintmeta schreef op vrijdag 18 december 2015 @ 15:01:
Zou het niet best makkelijk zijn de een of andere ldpc-coder/decoder te maken voor de commandline?

ldpccod < familiefoto.jpeg > familifoto.jpeg.ldpc
ldpcdec < familifoto.jpeg.ldpc > familifoto.jpeg

Kan me voorstellen dat zoiets ook al bestaat (er zijn in iedergeval allerlei libs voor erasure coding), bup is natuurlijk ook wel aardig.

Zo werkt poorZFS.py dus. Heb nog geen tijd gehad het te testen, maar klinkt inderdaad als een goede optie.

Heb min of meer iets gevonden: zfec, mar het kan bijna niet anders of er is meer.

Er lijkt niet zoveel gedaan te worden met dit soort wiskunde, jammer inderdaad. Hier wat over de wiskunde in zfec: http://blog.richardkiss.com/?p=264
Een FUSE-laagje over de tool is inderdaad een goed idee (precies als poorZFS.py), en natuurlijk heeft iemand ook al zo'n tooltje geschreven: https://github.com/peter-x/zfec_fs Toch lijkt het doel van zfec meer het distribueren (vandaar TahoeFS) dan resistentie.

[Paul]

Brent schreef op zondag 20 december 2015 @ 14:43:
Heb nu al meer dan eens aangegeven waarom dat afvalt (single drive

Is geen probleem, dus ook geen reden om op af te vallen

bitrot is wel een echt probleem

Vast, ik geef alleen aan dat de mate waarin jij het ervaart niet normaal is

en ik wil het niet oplossen met een RAID array die ik niet in mijn laptop kan hebben).

Wat dan ook niet hoeft.

Oftewel, je leest gewoon niet wat er door anderen wordt aangedragen. Dat mag hoor, maar je snapt dat ik je dan niet meer serieus neem.

Zodra ZFS Reed-Solomon gebruikt om van checksums naar een 'echte' parity check te gaan hoor ik het graag

Nou, bij deze hoor je het... Wat denk je dat er op die 'verloren' ruimte staat? Precies, parity data. De checksums staan in de metadata maar bevatten niet de paritydata.

Een FUSE-laagje over de tool is inderdaad een goed idee (precies als poorZFS.py)

Let op, FUSE is een filesystem(enabler), en je wilde onafhankelijk zijn van een FS...

[Brent]

Paul, je haalt nu zoveel door elkaar (fuse en fs-afhankelijkheid, metadata-duplicatie en reed-solomon), ik denk dat je gewoon niet echt weet waar je het over hebt. Bovendien is het kennelijk lastig voor je om te lezen, want zfs valt voor me af.

Maar ik gok zo dat je gewoon doorgaat met spammen, dus ik vertrek wel. Ik was er bang voor dat er zo'n sysadmin langs ging komen die met zijn zfs/btrfs hamer ging komen en elk data-integriteitsprobleem als spijker zou zien, daar had ik kennelijk toch gelijk in. Ben blij dat er in ieder geval een aantal andere geïnteresseerden langskwamen en wat tips gaven, dank!

[Paul]

Brent schreef op maandag 21 december 2015 @ 10:19:
Maar ik gok zo dat je gewoon doorgaat met spammen, dus ik vertrek wel. Ik was er bang voor dat er zo'n sysadmin langs ging komen die met zijn zfs/btrfs hamer

Spammen Dat heet reageren op posts die je maakt, iets waar dit platform voor is ontwikkeld.

Fijn dat je me beschuldigd van het niet weten waar ik het over heb terwijl ik juist de misvattingen die jij hebt probeer te verhelderen. Fine, your loss. Succes met je vooroordelen en het niet (goed) lezen van andermans antwoorden en het dan raar vinden dat je nergens komt

[Brent]

Paul schreef op maandag 21 december 2015 @ 10:59:
[...]
het niet (goed) lezen van andermans antwoorden en het dan raar vinden dat je nergens komt

Anderen in deze draad slagen er anders prima in me verder te helpen. Misschien eens hand in eigen borst steken? Je reageert nergens inhoudelijk op mijn of begintmeta's links, je ageert alleen maar herhaaldelijk je eigen idee, waar ik al bekend mee ben (gebruik het tenslotte voor een ander doel). Maargoed, tabee!

[ Voor 7% gewijzigd door Brent op 21-12-2015 12:05 ]

[begintmeta]

Brent, misschien is het leuk als je een tabel maakt van eisen (bijvoorbeeld zoals hier geformuleerd(maar dan vollediger en doordachter)) en bestaande producten/in hoeverre die aan welke eisen voldoen. Gezien het doel wat je voor dit topic hebt geformuleerd zou dat een mooie toevoeging zijn.

[ Voor 5% gewijzigd door begintmeta op 21-12-2015 12:17 ]

[Paul]

Brent schreef op maandag 21 december 2015 @ 12:01:
Je reageert nergens inhoudelijk op mijn of begintmeta's links

Ik reageer misschien niet heel inhoudelijk op specifieke links, ik weet dan ook niks van zfec of melt/fuse af. Waar ik wel (inhoudelijk!) op reageer zijn de misvattingen die in dit topic leven over bepaalde zaken.

Kijk, als je de discussie over ZFS af wilt kappen omdat je überhaupt geen discussie over ZFS wil dan vind ik dat prima, maar dan moet je dat zeggen, nu zeg je alleen steeds dat je geen ZFS wil vanwege misvatting 1, misvatting 2 en misvatting 3. Dan moet je niet vreemd opkijken als iemand die misvattingen wil ophelderen...

[CAPSLOCK2000]

Mensen,
ik stel voor dat we ophouden over ZFS, of het nu relevant is of niet. Het doet er niet meer toe wie "gelijk" heeft, op deze manier komen we er toch niet uit. Laten we er verder van uitgaan dat "geen ZFS" deel van eisen van die project is, ongeacht wat de reden daar achter is.

In deze discussie speelt het probleem dat backups vooral door bedrijven worden gemaakt en maar weinig door consumenten. Bedrijven hebben andere eisen en kunnen enerzijds veel geld en hardware tegen problemen aangooien, anderzijds zijn ze heel goed in risico's accepteren. "Alles kwijt kost X, goede backup kosten Y, dat risico accepteren we maar." Absolute integriteit van je media (zodat je geen bitrot hebt) is in de meeste backupsystemen geen eis, dat is te duur voor wat je terugkrijgt. De systemen die dat wel doen richten zich op de bovenkant van de markt en daar is draagbaarheid geen eis (en zelfs een nadeel want diefstalgevoelig).

Wij tweakers hebben wel vaker het probleem dat we tussen de wal en het schip vallen. Financieel gezien zijn we gewone consumenten maar qua kennis, wensen en eisen doen we het beter dan het gemiddelde MKB.

[Brent]

Kleine update voor diegenen die het interesseert: bcachefs heeft in december een use_fec_from_device optie iig in de dev branch, ik heb geen idee wanneer het in mainline te verwachten valt. Net zoals met rsbep is het te tunen met dezelfde parameters. Veelbelovend!

Ook vond ik dat CERN stille corruptie op ongeveer 1kb/1TB/6mnd bemeet, en dat op vermoelijke niet consumentenhardware: Wikipedia: Data corruption
Behoorlijk significant dus.