Backup truecrypt files

[arvidbeheerder]

Goedenavond medetweakers,

Ik weet niet zo goed waar ik deze vraag moet posten. Als ik verkeerd zit wil 1 van de modjes dit topic dan even verplaatsen?

Ik zit met het volgende:
Voor een bedrijf moeten bepaalde dossiers beveiligd opgeslagen worden. Per dossier wordt een truecrypt container van 500mb aangemaakt. Als er aan een bepaald dossier gewerkt moet worden, wordt deze gemount en dan kan de gebruiker er mee aan de slag.
De reden om per dossier op te slaan is omdat er meerdere gebruikers zijn. Als ik 1 file zou maken, kan maar 1 persoon de file mounten en gebruiken.

Alle dossiers/containers (ong 50 stuks) staan op een synology nas. Deze nas draait in RAID1. Mijn probleem is het backuppen van deze containers. Als een container geopend is, er bestanden aangepast zijn en vervolgens gesloten wordt verandert de grootte van de container niet. Ook kan je niet zien dat de container die dag voor het laatst gewijzigd is.
Mijn angst/probleem is nu dat ik denk dat bij een backup door de nas naar een usb schijf het aangepaste dossier niet meegenomen wordt omdat er voor de software geen verandering is opgetreden in de file.

Ik heb al een tijdje lopen zoeken naar een oplossing, maar ben die nog niet tegen gekomen. De meeste oplossingen zijn het mounten van de container en dan de inhoud backuppen. Omdat het om 50 containers gaat vind ik dat niet echt een optie.

Mijn vraag aan jullie is:
Is mijn redenatie correct? Zo ja, wat zou een oplossing zijn? Zo nee, waar ga ik de fout in met mijn redenatie?

Alvast bedankt

[kluyze]

Truecrypt heeft command-line opties. Is het een idee/mogelijkheid om de backup software de volumes te mounten?

http://www.truecrypt.org/docs/?s=command-line-usage

[brambo123]

Is afhankelijk van de backup software / methode.
Sommige gebruiken hash, sommige datum/size of het bestand worden gewoon gekopieerd.
Ik zou zeggen, gewoon testen.
Klopt de backup?
Ja -> Mooi
Nee -> Zoek betere software

[jan99999]

1 Kun je niet met een checksum zien of de file/container gewijzigd is, en dan de gewijzigde file weer backuppen.
2 Dacht dat er ook backup software bestaat die alleen de wijzigingen veranderd aan de file en niet de hele file moet backuppen.
Bacula kan nummer 2.
Kun je met rsync niet alle files controleren met checksum, en dan kopieren wat gewijzigd is, en dan elke keer weer alles checken.

[FireDrunk]

Wat sowieso te wijzigen moet zijn, is het feit dat je NAS de last-accessed time niet opslaat blijkbaar.
Want ook daarop kan je je backup software laten werken. Als je een Full Backup doet, zouden sowieso alle bestanden gebackupped moeten worden, los van het feit of deze gewijzigd zijn.

[krijn1985]

Wat ik laatst getest heb is het gebruik van Rsync met checksum op een container. Ik weet het niet 100% zeker meer, maar volgens mij werkt het daarbij wel. Wanneer er bestanden in de container gewijzigd zijn verandert de checksum, waardoor rsync dus gaat kijken wat er gewijzigd is en dit zal kopieren. Hij kopieert niet de hele container mee maar alleen wat gewijzigd is.

Ik moet hierbij dus vermelden dat ik het even geprobeerd heb en niet 100% zeker meer weet. Ik heb het onder windows 7 met dit programma geprobeert: klik

Zal het binnenkort nog even kunnen controleren.

[Verwijderd]

Dan slaat truecrypt wel de juiste datum van wijziging op.

Helaas zelf achter gekomen dat SyncToy de file ook niet backupte na wijzigingen.
Gewoon kwestie van vinkje weghalen in de Truecrypt instellingen.

Succes verder

>>edit, plaatje deed het niet<<

[ Voor 49% gewijzigd door Verwijderd op 16-12-2012 23:01 ]

[arvidbeheerder]

Ik ga dat van Klerk zeker proberen, bedankt voor jullie antwoorden!

[ebia]

Weet wel dat je ook bij de meest minimale wijziging, telkens die 500MB aan het overpompen bent. In normale omstandigheden kan back-up software immers niet zomaar in TC container kijken naar de exacte wijzigingen, en alleen die wijzigingen meenemen in back-up. Dat kan overigens ook niet op block niveau (met rsync of wat dan ook), want door de encryptie zal dat namelijk niet goed werken.

De vraag is dus even of deze set-up wel wenselijk is voor je. Zeker als je meerdere archieven bewaart van oude back-ups, en deze bestanden met regelmaat geopend en gewijzigd worden, dan kan het hard oplopen met je opslagbehoefte voor dit alles.

Sowieso vraag ik me af, maar dat is een beetje een zijsprong, of je überhaupt deze manier van werken moet toepassen. Mooie van TC is dat alles natuurlijk veilig is. Nadeel is ook dat je vervolgens als beheerder/organisatie uitgesloten kan worden van de data die je zelf beheert en nodig hebt. Dit zou kunnen gebeuren per ongeluk (of opzettelijk) als een medewerker bijvoorbeeld het wachtwoord van de container wijzigt. Dat valt zo goed als niet meer te kraken of achterhalen, en ben je gewoon de pineut.

Een belangrijk deel van informatiebeveiliging zit niet alleen in het stukje confidentiality (ofwel vertrouwelijkheid, hetgeen wat jij probeert te krijgen), maar evengoed integrity (klopt je data inhoudelijk wel, bijvoorbeeld door alleen mensen toegang te geven die er bij mogen komen) en availability (dit dus: hoe ga je er voor zorgen dat je data beschikbaar blijft). Je kunt wel de sleutel van de kluis weggooien om iets veilig te krijgen, maar het nadeel is dat je er dan zelf niet meer in kunt

Als je bij je Synology wilt blijven kun je denk ik beter de disk die daarin zit voorzien van encryptie (als dat echt een vereiste is), en vervolgens je dossiers verdelen over folders, waarbij je alleen die mensen toegang geeft die daarbij moeten kunnen (dus eigenlijk het 'normale' model voor het delen van bestanden eigenlijk).

[krijn1985]

ebia schreef op maandag 17 december 2012 @ 21:34:
Weet wel dat je ook bij de meest minimale wijziging, telkens die 500MB aan het overpompen bent. In normale omstandigheden kan back-up software immers niet zomaar in TC container kijken naar de exacte wijzigingen, en alleen die wijzigingen meenemen in back-up. Dat kan overigens ook niet op block niveau (met rsync of wat dan ook), want door de encryptie zal dat namelijk niet goed werken.
*knip*

Hoezo werkt dat niet goed dan? Ik heb hier een test container aangemaakt (NTFS) van 50MB. En heb hiermee even wat getest.
1. md5sum van lege container berekent
2. lege container met rsync (licielrsync op windows 7) met checksum optie erbij naar mijn nas gesyncd
3. md5sum op nas bereknt (is zelfde als op laptop)
4. container gemount Word document erin gezet, unmount en md5sum weer berekent
5. weer syncen naar nas en md5sum controleren (weer het zelfde) (vanwege klein bestand is er maar 38Kilobytes geupload
6. de container van mijn nas naar mijn desktop gekopieerd (geen truecrypt op nas), md6sum nog steeds hetzelfde.
7. eerst de initiele container gemount en md5sum van het bestand erin berekent, daarna zelfde op het bestand in de container gekopieerd vanaf nas. Komt weer overeen
8. 32MB aan mp3's in container gestopt, md5sum berekent, syncen naar nas, md5sum berekent en komt weer overeen. Hierbij werd dus 33,91Megabyte geupload.

Zover ik het dus getest hebt kun je prima een truecrypt container rsyncen (alleen de wijzigingen + kleine overhead) zonder deze te mounten.

[ebia]

krijn1985 schreef op woensdag 19 december 2012 @ 22:24:
[...]

Hoezo werkt dat niet goed dan?

My bad. Ik dacht door de symmetrische encryptie dat dit gewoon niet ging werken. Door het omzetten van één byte in een datafile, zou technisch gezien ná encryptie de complete datafile er totaal anders uitzien dan voorheen. Het blijkt dus dat de interne structuur van een TC daar rekening mee houdt, en dus er voor zorgt dat je niet met Rsync daarmee in de knoei komt (denk dat de encrpytie in blocken wordt opgedeeld of zo).

Volgens mij blijf je wel een probleem houden als je gaat werken met hidden containers in een container.

Hoe dan ook blijft de vraag staan of je wel wilt werken met encrypte containers waar je individuele medewerkers toegang op gaat geven. Als je daar bedrijfskritische data in hebt staan, wil je onder geen enkele mogelijkheid toegang daartoe kwijtraken. Dat kan met TC wel, en het is daarom ook minder geschikt voor dit type van gebruik imho.

[krijn1985]

Ik moet eerlijk zeggen dat ik het ook niet verwacht had. Had het echter ergens gelezen dat het dus mogelijk was om rsync en de checksum optie dus alleen het gewijzigde te syncen. Echter wanneer de hoeveelheid data groter wordt, betekent dit dat het syncen een stuk langer gaat duren (door de checksum berekening).

@TS, ik heb het dus getest en het werkt, ik durf echter geen toezegging te doen op dagelijks gebruik op deze manier. Ik ga waarschijnlijk zelf ook op deze manier containers tussen mij en mijn ouders syncen met data.

[Verwijderd]

>sorry antwoord stond hierboven<

[ Voor 92% gewijzigd door Verwijderd op 06-01-2013 21:08 ]

[Thralas]

ebia schreef op donderdag 20 december 2012 @ 16:54:
My bad. Ik dacht door de symmetrische encryptie dat dit gewoon niet ging werken. Door het omzetten van één byte in een datafile, zou technisch gezien ná encryptie de complete datafile er totaal anders uitzien dan voorheen.

Dat is zelfs logisch te beredeneren. Het zou immers niet wenselijk zijn als een kleine edit een rewrite van de gehele container (50 GB) zou betekenen.

TrueCrypt kan verschillende block ciphers in XTS mode gebruiken; allen hebben een block size van 128 bits. Een wijziging van 1 bit wijzigt dus ook de overige bits in het block. Afhankelijk van hoe 'random' je writeacties zijn is de overhead zeer beperkt.