[linux] Re: Remote encrypted backup

[Peter Fokker]

"Folkert van Heusden" wrote:
> 
> > Gisteren ontdekte ik Folkert's cryptosync
> > (http://www.vanheusden.com/cryptosync). Dat komt in de buurt van mijn
> > eigen gedachtenspinsels over dit onderwerp:
> >  - je kunt op de bron-server een aparte directrory tree bouwen
> >    met encrypted paden + filenamen (en die dan rsyncen). Goed.
> >  - bestanden worden ook nog eens gecomprimeerd. Ook goed.
> > Ik heb alleen een beetje moeite met het feit dat alle informatie
> > over de encrypted backups in 1 enkel bestand 'index.dat' lijkt te
> > staan. En dat bestand staat zelfs op de remote server (dus mogelijk
> > buiten je eigen bereik, althans: modificeerbaar op die remote machine).
> > Klinkt erg als een Single Point of Failure; als 'index.dat' niet
> > meer bestaat is er (voorzover ik kan zien) geen manier meer om uit
> > de encrypted filename de plaintext filename af te leiden, ook niet als
> > je het password weet. Da's lastig (op zijn zachtst gezegd). Anderzijds:
> 
> Nee dat is niet zo:
> --translate  converts a filename into the filename as it would be stored in the datastore
> --untranslate  converts a filename into the orignal filename

Mmmm, ik krijg dat niet echt lekker aan de praat (maar misschien mis ik iets):

| $ ./cryptosync --from foo.txt --password junk --verbose --translate
| Filename: 66/39/0G-Q_pkJ2E4YwWPngrO0vKwG
| $ ./cryptosync --from 0G-Q_pkJ2E4YwWPngrO0vKwG --password junk --verbose --untranslate
| Original filename: A]eb˜Þê"«60¦¾
| $ _

> > je kunt nog wel wat informatie afleiden uit die 'index.dat', in ieder
> > geval of het bestand in kwestie een symlink is of niet. Hmmmm..
> > In mijn toepassing voor een remote backup gaat het bijv. om 250.000
> > a 300.000 bestanden in 45.000 directories (in totaal in de orde van
> > 30 a 40 GB gecomprimeerd). Da's toch wel vrij veel voor zo'n
> > 'index.dat' vrees ik (en ook voor een simpel ADSL-lijntje).
> 
> Is bij mij 7.5MB tekst dat gecomprimeerd kan worden naar 2.9MB.
> 5GB aan data over 29000 files.
> Dus ik schat dat e.e.a. bij jou zo'n 77MB is, gecomprimeerd 30MB.

Ok. Een kleine miscommunicatie. Mijn punt was dat die file 'index.dat'
volgens mij een single point of failure is. Ik vraag me ook af hoe
efficient het is om een plain text file te gebruiken met 29.000 files
(of in mijn geval een factor 9 meer). De opmerking over een simpel
ADSL-lijntje bedoelde ik in de context van gecomprimeerde backups van
30 a 40 GB. Ik geloof graag dat je de tekst-file 'index.dat'
prima kunt comprimeren en 30 MB cq. 77 MB is te overzien...
...behalve als je de hele 'index.dat' moet rsync'en met remote omdat
je 1 enkele file van paar kB hebt aangepast of toegevoegd. 
Immers, als je maar 1 file toevoegt, dan zal de 'index.dat' gewijzigd
worden. Maar misschien pakt rsync dat slim aan...

> > Idealiter zouden die 300.000 bestanden ieder apart gecomprimeerd en
> > encrypted moeten worden op een zodanige manier dat de resulterende
> > file geheel self-contained is, dwz. inclusief de naam _en_ het pad
> > _en_ de permissies en dan ook nog eens zodanig dat je geen dubbel
> 
> Naam en pad zitten er in, permissies e.d. niet. Probleem is dat e.e.a.
> zowiezo al 2x zo groot wordt omdat encrypted binaire data is. Filenames
> hebben een maximale lengte dus daarom doe ik permissies e.d. apart.

Mmm, deze zinnen moet ik nog eens goed doorlezen. Ik zou verwachten dat
het encrypted compressed bestand juist _kleiner_ is dan het origineel,
vooral als je de overhed van filename en pad buiten de berekening laat.
Als _alle_ encrypted files 2x zo groot worden, dan heb ik een probleem;
dan moet mijn backup-schijf 2x zo groot zijn als het origineel. Dat
had ik even niet voorzien... Enniewee.

--Peter Fokker

-- 
Doe mee aan de marktwerking in de Nederlandse spelling:
koop het Witte Boekje in augustus 2006 - http://wittespelling.nl