Humanist | Kernpower! | Determinist | Verken uw geest | Politiek dakloos
Met Duplicity kan je par2 gebruiken: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...
--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 ]
Zet je backups op ZFSBrent 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...
Die checksummed alleen maar (wat al heel wat is, zeker).
Dank u zeer! Ik ga dit bekijken. Gebruik jij dat ook?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 )
Humanist | Kernpower! | Determinist | Verken uw geest | Politiek dakloos
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 reparerenBrent schreef op woensdag 16 december 2015 @ 16:09:
Die checksummed alleen maar (wat al heel wat is, zeker).
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.
"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock
Het gaat me idd om bitrot, en omdat par2 niet zo lekker werkt tegen hele filetrees zoek ik een andere oplossing.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.
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?
Humanist | Kernpower! | Determinist | Verken uw geest | Politiek dakloos
Duplicity wel, par2 nog niet eigenlijk ..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?
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 ]
Maar ik kan dus niet monitoren of het archief zelf rotte bits heeft?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.
Wat gebeurd er precies bij verify? worden alle lokale files gechecksummed en dan gecheckt tegen de backup (die vermoedelijk de checksums niet herberekend)?
Humanist | Kernpower! | Determinist | Verken uw geest | Politiek dakloos
Dat laatste standaard niet ..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)?
--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.
ZFS
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?
"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock
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.Paul schreef op woensdag 16 december 2015 @ 17:38:
[...]
ZFSSowieso geeft het bij een scrub aan welke bestanden er rot zijn, en als je voldoende parity hebt in je vdev dan repareert het ook.
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
Humanist | Kernpower! | Determinist | Verken uw geest | Politiek dakloos
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 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.
Humanist | Kernpower! | Determinist | Verken uw geest | Politiek dakloos
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 ]
Vandaar toch uiteindelijk de ontwikkeling van ZFS en BTRFS ?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.
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.
Volgens de datacorruption wiki is er wel aanleiding om te veronderstellen dat dit toch niet altijd het geval is: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.
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 ]
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).Brent schreef op woensdag 16 december 2015 @ 18:48:
Met vdev bedoel je schijven bijgooien?
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
[ Voor 15% gewijzigd door Paul op 17-12-2015 15:37 ]
"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock
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?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).
Bovendien zit je vast aan je fs.
Heb je ECC geheugen? Dat verklaard al een hoopOverigens, als je zoveel last hebt van bitrot dan zou ik eens onderzoeken waar dat vandaan komt, want je lijkt nu aan symptoombestrijding te doenAls 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.
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.
Humanist | Kernpower! | Determinist | Verken uw geest | Politiek dakloos
Humanist | Kernpower! | Determinist | Verken uw geest | Politiek dakloos
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.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 hoopPunt 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.
(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)
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.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?
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.
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.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.
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.
This post is warranted for the full amount you paid me for it.
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.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).
[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 ]
Humanist | Kernpower! | Determinist | Verken uw geest | Politiek dakloos
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?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?
Om vervolgens net dat FS af te schietenZou ik een fs hebben dat automatisch bijv. 5% parity biedt, dan laat ik dat niet liggen, toch?
Dan doe je het toch zonder (extra) hardware?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.
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
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.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.
"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock
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.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?
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?
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 isOm 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
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![...]
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.
Humanist | Kernpower! | Determinist | Verken uw geest | Politiek dakloos
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 ]
All my posts are provided as-is. They come with NO WARRANTY at all.
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..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.
...
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 ]
Nee, lees topic.jan99999 schreef op vrijdag 18 december 2015 @ 05:38:
ZFS Raid is wat je nodig hebt.
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.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..
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 ]
Humanist | Kernpower! | Determinist | Verken uw geest | Politiek dakloos
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.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.
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.Ik zou dan 10 volumes moeten maken, waarbij ik 9 volumes gebruik en 1 parity, toch? Of werkt het zo niet meer?
Heb je een linkje?Heb je het artikel over poorZFS.py gelezen?
Je hebt een backup ergens van en je wilt deze beschermen tegen bitrot? Dit is de eerste keer dat je over portabiliteit begintIk geloof dat je nog steeds niet begrijpt wat mn doel is
Euhm, in plaats van "zpool create" met disks doe je hetzelfde met files? It's that simpleIk 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!
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 diskCyBeR 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.
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 uitleggenBrent schreef op vrijdag 18 december 2015 @ 11:00:
Nee, lees topic.
"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock
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.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.
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).
http://users.softlab.ntua.gr/~ttsiod/rsbep.html
Leek me impliciet bij het bespreken van backup tool.[...]
Je hebt een backup ergens van en je wilt deze beschermen tegen bitrot? Dit is de eerste keer dat je over portabiliteit begint
Die zitten dan weer op een ander fs, mogelijk zfs? Ik dacht dat we zo eerlijk mogelijk moesten zijn tegen zfs[...]
Euhm, in plaats van "zpool create" met disks doe je hetzelfde met files? It's that simplehttps://flux.org.uk/tech/2007/03/zfs_tutorial_1.html
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[...]
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
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 ]
Humanist | Kernpower! | Determinist | Verken uw geest | Politiek dakloos
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 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 ...
Humanist | Kernpower! | Determinist | Verken uw geest | Politiek dakloos
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 ]
Whut, dat gaat allen maar over melt.sh en freeze.s... oh wacht, het wordt één keer poorZFS genoemd
Leek me impliciet bij het bespreken van backup tool.
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.Die zitten dan weer op een ander fs
Wat, gewoon schrijven naar /mnt/backup (of wherever)? Als naar /strong schrijven lukt dan moet het naar het mountpoint van ZFS ook lukkenMaar het klinkt wat lastig in gebruik...
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.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 vanWat ik zoek in het kort: resistentie tegen bitrot op filetrees, liefst onafhankelijk van fs, maar zeker onafhankelijk van disks of aantal 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).
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...Brent schreef op vrijdag 18 december 2015 @ 14:32:
Om heel precies te zijn, ben ik geinteresseerd in het landschap
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).Die laatste kennen we goed, maar is niet echt praktisch wanneer je tot 1 schijf bent veroordeeld.
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.
"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock
Paul, ben blij dat je wil meedenken, maar toch maar weer RAIDZ erbij halen helpt niet echt
Zo werkt poorZFS.py dus. Heb nog geen tijd gehad het te testen, maar klinkt inderdaad als een goede optie.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.
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=264Heb min of meer iets gevonden: zfec, mar het kan bijna niet anders of er is meer.
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.
Humanist | Kernpower! | Determinist | Verken uw geest | Politiek dakloos
Is geen probleem, dus ook geen reden om op af te vallenBrent schreef op zondag 20 december 2015 @ 14:43:
Heb nu al meer dan eens aangegeven waarom dat afvalt (single drive
Vast, ik geef alleen aan dat de mate waarin jij het ervaart niet normaal isbitrot is wel een echt probleem
Wat dan ook niet hoeft.en ik wil het niet oplossen met een RAID array die ik niet in mijn laptop kan hebben).
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.
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.Zodra ZFS Reed-Solomon gebruikt om van checksums naar een 'echte' parity check te gaan hoor ik het graag
Let op, FUSE is een filesystem(enabler), en je wilde onafhankelijk zijn van een FS...Een FUSE-laagje over de tool is inderdaad een goed idee (precies als poorZFS.py)
"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock
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!
Humanist | Kernpower! | Determinist | Verken uw geest | Politiek dakloos
SpammenBrent 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
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

"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock
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!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
[ Voor 7% gewijzigd door Brent op 21-12-2015 12:05 ]
Humanist | Kernpower! | Determinist | Verken uw geest | Politiek dakloos
[ Voor 5% gewijzigd door begintmeta op 21-12-2015 12:17 ]
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.Brent schreef op maandag 21 december 2015 @ 12:01:
Je reageert nergens inhoudelijk op mijn of begintmeta's links
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...
"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock
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.
This post is warranted for the full amount you paid me for it.
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.
Humanist | Kernpower! | Determinist | Verken uw geest | Politiek dakloos