Files parren of alleen checksum?

[Eric_1993]

Beste Tweakers, hoor graag jullie advies over het volgende:

Ik heb verschillende Veracrypt containers van 50 GB tot 100 GB groot. Sommige containers gebruik ik vaker dan de andere dus ik hoef niet bij iedere wijziging al die containers opnieuw te uploaden. De containers ga ik uploaden naar mijn NAS die bij mn opa staat. Ik heb 6 maanden geen toegang tot het huis.

Het beste is dus om op een afstand te checken of de bestanden niet beschadigd zijn tijdens het uploaden. Dat kan ik op twee manieren doen:

1- De containers splitsen in 1 GB mét wachtwoord en vervolgens PAR-files aanmaken. Dit zorgt bij iedere container voor 5 tot 10 GB extra files. Geen probleem overigens.

2- De md5sum en sha-1 hashcodes laten berekenen. Het bestand uploaden en dan weer terug downloaden en vervolgens verifiëren.

Ik heb zelf een voorkeur voor de eerste optie, maar wil graag van jullie horen wat jullie ervan vinden

[ebia]

In feite zijn het twee hele verschillende dingen die je gaat doen:
Met parity files kun je eventueel beschadigde bestanden nog restaureren, en als je alleen een hash berekend kun je alleen vaststellen of het niet beschadigd is maar verder niets.

Die checksums bereken zou ik trouwens niet doen door de bestanden weer opnieuw te downloaden en te checken; mocht het fout zijn kan dat ook aan de download hebben gelegen en niet zozeer aan de files die nu op de NAS staan. Beter log je met een shell in op die NAS (voor zover mogelijk) en voer je van de command line een sha256sum of iets dergelijks uit om te controleren of de bestanden die je zojuist hebt geupload goed zijn.

Daarnaast gebruik je het beste rsync of een ander protocol wat geschikt is om op blocklevel een mirror te maken van je bestanden. Want met een blockcypher (zoals AES) voor je VC container hoef je niet het hele bestand opnieuw te uploaden maar slechts die blokken die gewijzigd zijn. Maar let wel, een sync is natuurlijk geen back-up.

[Eric_1993]

ebia schreef op vrijdag 21 oktober 2016 @ 22:30:
In feite zijn het twee hele verschillende dingen die je gaat doen:
Met parity files kun je eventueel beschadigde bestanden nog restaureren, en als je alleen een hash berekend kun je alleen vaststellen of het niet beschadigd is maar verder niets.

Die checksums bereken zou ik trouwens niet doen door de bestanden weer opnieuw te downloaden en te checken; mocht het fout zijn kan dat ook aan de download hebben gelegen en niet zozeer aan de files die nu op de NAS staan. Beter log je met een shell in op die NAS (voor zover mogelijk) en voer je van de command line een sha256sum of iets dergelijks uit om te controleren of de bestanden die je zojuist hebt geupload goed zijn.

Daarnaast gebruik je het beste rsync of een ander protocol wat geschikt is om op blocklevel een mirror te maken van je bestanden. Want met een blockcypher (zoals AES) voor je VC container hoef je niet het hele bestand opnieuw te uploaden maar slechts die blokken die gewijzigd zijn. Maar let wel, een sync is natuurlijk geen back-up.

Helaas ondersteund mijn NAS geen checksum over Shell voor zover ik weet. Vandaar dus dat mij het parren het handigst lijkt. Dan maak ik par files, en upload ik het naar de NAS. Mocht ik de bestanden later toch nodig hebben en het bestand is beschadigd kan ik het nog repareren met de PAR files.

rsync is inderdaad een beter protocol. Ik kan daarvoor gebruik maken van Acrosync. Helaas blijft het bestand die verwijderd is van Bron staat op de offsite NAS, kan rsync ook mirror backups maken?

[ Voor 9% gewijzigd door Eric_1993 op 21-10-2016 23:10 ]

[ebia]

Eric_1993 schreef op vrijdag 21 oktober 2016 @ 22:50:
[...]


Helaas ondersteund mijn NAS geen checksum over Shell voor zover ik weet. Vandaar dus dat mij het parren het handigst lijkt. Dan maak ik par files, en upload ik het naar de NAS. Mocht ik de bestanden later toch nodig hebben en het bestand is beschadigd kan ik het nog repareren met de PAR files.

Het probleem van parren is, is dat je dat moet doen op je originele bestanden. Als jij dus vervolgens van alles gaat veranderen (ook al zijn het een paar blokken aan data), dan zullen parity tools denken dat je bestand beschadigd is en dus mogelijk onbedoeld de zaak gaan repareren waardoor je data verlies zult hebben. Dus uiteindelijk heb je niks aan PAR files, als je ze niet telkens opnieuw maakt voor je nieuwe data set. Echter, omdat je al aangeeft dat je geen shell kunt krijgen op die WD NAS, vraag ik mij af of je überhaupt tools hebt om die PAR files te maken.

rsync is inderdaad een beter protocol, is er een manier om via een windows software te backuppen met rsync naar de NAS? Allebei de NAS'sen zijn een WD My Cloud. Ik heb zelf een mini-pc bij de NAS staan, dus mocht er een rsync software zijn voor windows, zou ik dat is kunnen proberen

Om rsync te kunnen gebruiken heb je een client en een server nodig. Daarnaast wil je normaliter niet het rsync verkeer direct over het internet te sturen, dus wil je dat tunnelen via SSH of VPN. Ik ben niet bekend met die My Cloud apparaten, maar als die geen support bieden voor rsync en ssh server dan ben ik bang dat je hier niet ver mee kunt komen.

Een aantal voorbeelden en applicaties die rsync gebruiken kun je hier vinden: Wikipedia: rsync

Ik ben sowieso bang dat je een 'echte' NAS moet hebben om alle bovenstaande functies uit te kunnen voeren. Wat je wellicht beter kunt doen is die mini-pc in dat huis van je opa zetten en die als NAS configureren (al dan niet door de hard disk uit die WD te trekken en dan in die pc te stoppen)...

[jeroen3]

Eric_1993 schreef op vrijdag 21 oktober 2016 @ 20:36:
1- De containers splitsen in 1 GB mét wachtwoord en vervolgens PAR-files aanmaken. Dit zorgt bij iedere container voor 5 tot 10 GB extra files. Geen probleem overigens.

2- De md5sum en sha-1 hashcodes laten berekenen. Het bestand uploaden en dan weer terug downloaden en vervolgens verifiëren.

1. Nogmaals encrypten lijkt me zinloos van de tijd.
Je kunt met multipar ook over één groot bestand een checksum maken. De enige reden waarom het gebruikelijk is om kleinere archieven te maken is om het sequentieel te uploaden, en eenvoudig een blok opnieuw te downloaden. Sleep bronblokken naar max (32k) ipv de standaard usenet blokgrootte. Parity files zullen krimpen, zonder verlies van je herstelbare percentage.
Als de nas nzb's kan downloaden, kan hij ook par2.

2. Dat kan altijd. md5sum is ongetwijfeld beschikbaar op je nas.

find / -name 'par2' 2>/dev/null
find / -name 'md5sum' 2>/dev/null

[Eric_1993]

ebia schreef op vrijdag 21 oktober 2016 @ 23:08:
[...]

Het probleem van parren is, is dat je dat moet doen op je originele bestanden. Als jij dus vervolgens van alles gaat veranderen (ook al zijn het een paar blokken aan data), dan zullen parity tools denken dat je bestand beschadigd is en dus mogelijk onbedoeld de zaak gaan repareren waardoor je data verlies zult hebben. Dus uiteindelijk heb je niks aan PAR files, als je ze niet telkens opnieuw maakt voor je nieuwe data set. Echter, omdat je al aangeeft dat je geen shell kunt krijgen op die WD NAS, vraag ik mij af of je überhaupt tools hebt om die PAR files te maken.


[...]


Om rsync te kunnen gebruiken heb je een client en een server nodig. Daarnaast wil je normaliter niet het rsync verkeer direct over het internet te sturen, dus wil je dat tunnelen via SSH of VPN. Ik ben niet bekend met die My Cloud apparaten, maar als die geen support bieden voor rsync en ssh server dan ben ik bang dat je hier niet ver mee kunt komen.

Een aantal voorbeelden en applicaties die rsync gebruiken kun je hier vinden: Wikipedia: rsync

Ik ben sowieso bang dat je een 'echte' NAS moet hebben om alle bovenstaande functies uit te kunnen voeren. Wat je wellicht beter kunt doen is die mini-pc in dat huis van je opa zetten en die als NAS configureren (al dan niet door de hard disk uit die WD te trekken en dan in die pc te stoppen)...

Ik ga de PAR files ook niet op de NAS zelf maken. Ik maak ze op mijn pc en vervolgens upload ik ze. Maar als er tijdens het uploaden het bestand corrupt raakt, kan ik dat niet checken. Tenzij ik de NAS over SFTP als netwerkschijf instel, dan zou het wel kunnen maar dan wordt alles gecheckt met een snelheid van 30 Mbit door de uploadsnelheid van het pand.

Checkt rsync niet automatisch of het bestand overeenkomt met het bestand op de onsite NAS?

[ebia]

Dat heeft alleen nut als je daarna die kopie niet meer wijzigt. Ga je immers aan de gang met rsync om die kopie aan te passen, dan moet je dus ook de PAR opnieuw berekenen.

[F_J_K]

BV -> CSA, dat lijkt me beter passen.

Welke NAS? Ik zou inderdaad zoeken maar een checksum-tool die er is te installeren. Of op een ander device aan de andere kant vd lijn.

[Eric_1993]

ebia schreef op vrijdag 21 oktober 2016 @ 23:21:
Dat heeft alleen nut als je daarna die kopie niet meer wijzigt. Ga je immers aan de gang met rsync om die kopie aan te passen, dan moet je dus ook de PAR opnieuw berekenen.

Thanks voor je help. Sowieso als ik 1 van de containers wijzig bereken ik de PAR opnieuw en upload ik ze weer naar de NAS. Daarom heb ik de veracrypt containers ook gesplits van 450 GB tot 50 of 100 GB.

BV -> CSA, dat lijkt me beter passen.

Welke NAS? Ik zou inderdaad zoeken maar een checksum-tool die er is te installeren. Of op een ander device aan de andere kant vd lijn.

Het gaat om de WD My Cloud. Ik denk dat ik maar een mini-pc bij de off-site NAS moet zetten ben ik bang. Levert een hoop gedoe op dit

[True]

Eric_1993 schreef op vrijdag 21 oktober 2016 @ 23:35:
Het gaat om de WD My Cloud. Ik denk dat ik maar een mini-pc bij de off-site NAS moet zetten ben ik bang. Levert een hoop gedoe op dit

RaspberryPi met SSH onder een GNU/Linux distro?

[jeroen3]

Je kunt gewoon in je wd mycloud met ssh. En het forum zegt dat apt-get werkt.

[Eric_1993]

jeroen3 schreef op vrijdag 21 oktober 2016 @ 23:42:
Je kunt gewoon in je wd mycloud met ssh. En het forum zegt dat apt-get werkt.

Ja, kan gewoon inloggen in de shell. Maar als ik md5sum typ met erachter de doel locatie krijg ik een melding dat zo'n bestand niet bestaat. Heb daar laatst een uur aan zitten puzzelen en krijg nog steeds geen hash of iets

[Eric_1993]

Ik heb een nieuw methode wat ik waarschijnlijk ga uitvoeren:

Ik splits de container met WinRaR in delen van 1 GB. Dit doe ik om de kans op fouten tijdens het uploaden te verkleinen. Vervolgens maak ik PAR files. Vervolgens upload ik de hele zooi naar de NAS. Ik ga dus geen check of dergelijk maken. Mocht ik de container nodig hebben en het blijkt beschadigd te zijn kan ik het alsnog herstellen met de PAR files.

[F_J_K]

Ik hoop dat je dat allemaal wel automatiseert met een scriptje..

Eric_1993 schreef op vrijdag 21 oktober 2016 @ 23:46:
Ja, kan gewoon inloggen in de shell. Maar als ik md5sum typ met erachter de doel locatie krijg ik een melding dat zo'n bestand niet bestaat. Heb daar laatst een uur aan zitten puzzelen en krijg nog steeds geen hash of iets

Is dat geen rechtenkwestie? Via webinterface werk je misschien onder een andere useraccount.

[Eric_1993]

Heb de laatste tijd dingen onderzocht en gekeken wat het beste is. Het op afstand controleren van bestanden duurt behoorlijk lang >10 uur. Daarbij komt het uploaden ook nog bij.

Het parren lijkt mij het handigste, daarbij maak ik par files met 10% redundancy met 99,8% efficientie. Na het uploaden controleer ik het bestand niet. Mocht ik later het bestand nodig hebben, download ik het bestand en kan ik het zonodig repareren. De PAR-files zelf zijn ongeveer 5 tot 11 GB groot.

Nu kom ik niet uit bij het volgende: Hoe groot is de kans dat het bestand niet meer te herstellen is onlangs de 10% redundancy? Dus is de kans groot dat het bestand tijdens het uploaden meer beschadigd raakt dan 10 %?