 Legen wir mal los. Also es geht heute um Boardback-Up. Kurze Frage. Wer kennt Boardback-Up noch gar nicht? Zwei, okay. Hat es mittlerweile ein bisschen rumgesprochen. Kennt ihr Ethik? Die beiden? Auch nicht, oder? Okay. Also für die zwei, die es nicht kennen, wird vielleicht jetzt die erste halbe Stunde am interessantesten sein. Die, die es kennen, werden vielleicht eine oder andere Details noch entdecken. Also es geht um Boardback-Up. Die Software ist als Fork von der anderen Software Ethik entstanden. Das lag einfach daran, da ging es nicht so richtig weiter. Das Zitat hier mit dem Holy Grail, das habe ich nicht mehr ausgedacht. Das hat irgendein griechischer Benutzer in seinem Blog-Post erwähnt, also Ethik entdeckt hatte damals. Und ja, es ist vielleicht ein bisschen übertriebe, aber ich fand das ganz lustig. Zu den Features kurz. Also das ist ein relativ einfaches Tool. Also ich weiß nicht, wenn ihr mal Bakula oder Ähnliches konfiguriert habt. Das ist ja so ein bisschen ein komplexeres Set-up. Also Boardback ist relativ einfach. Das ist also ein Kommando-Zeil-Tool. Man kann im Prinzip mit zwei Befehlen, kann man sagen, erst das Back-Up machen. Das Ganze ist auch relativ schnell. Es gibt andere deduplizierende Back-Up-Software, die deutlich langsamer ist. Weiteres Feature oder das Hauptfeature eigentlich ist die Deduplizierung. Das heißt, wenn ihr irgendwelche Dateien aus Versehen doppelt rumliegen habt, die werden quasi rausoptimiert oder auch natürlich die historische Deduplizierung. Ihr tut ja, wenn ihr ein rechner Back-Up jeden Tag, die meisten Dateien sind ja immer wieder die gleichen. Das heißt, die historische Deduplizierung gespart euch wahnsinnig Platz im Vergleich, wenn ihr jetzt immer Vollback-Ups machen würdet. Und man sieht auch nachher noch, das hat auch noch einen anderen Vorteil. Man kann ja sagen, ich mache nicht da ein Vollback-Up, ich mache ein Volles und dann Inkrimitelle usw. Aber dieses Deduplizierungsverfahren hat also auch noch andere nette Features. Es kann auch Kompression, momentan sowohl sehr schnelle Verfahren, LZ4 als Kompressionsverfahren, als auch langsamere wie LZMA und so ZLIP als Kompromiss und ihr könnt auch den Level genau einstellen. Da kommt es also ein bisschen darauf an, wie viel CPU ihr da investieren wollt und wie schnell euer rechner ist, wie schnell eure Leitung ist usw. Dann auch sehr nett, das Ding tut nicht nur verschlüsseln, sondern das macht authenticated Encryption. Also erst verschlüsseln und dann quasi ja so ähnlich wie signieren. Das dient dazu, dass ein Angreifer praktisch nicht an euren Krypto-Bits, irgendwo Bits drehen kann, ohne dass ihr das merken würdet. Das ist also das, was in der Krypto-Szene so eigentlich die aktuelle empfohlene Methode ist. Erst verschlüsseln und dann authentifizieren. Beziehungsweise beim Entschlüsseln halt erst authentifizieren und dann erst entschlüsseln. Ein Vorteil im Vergleich zu so dieser Vollback-Up und Inkrimitelle-Backup-Methode ist, ihr könnt einfach alte Backups löschen. Wenn ihr diese Voll- und Inkrimitell-Methode macht, da könnt ihr ja nichts euch entscheiden, okay, dieses Vollback-Up löschig, aber diese inkrimitellen Backups will ich weiterhin haben, das macht ja keinen Sinn. Die Inkrimitellen sind ohne das Volle, worauf sie basieren ja nichts wert. Das heißt, ihr müsst immer das Volle und alle Inkrimitellen, die drauf basieren, wegschmeißen. Und dadurch, dass ihr da dazu gezwungen seid, es so zu machen, müsst ihr auch in relativ hoher Frequenz immer wieder Vollback-Ups machen, weil sonst könnt ihr nichts löschen. Und das ist der Vorteil von dieser Arbeitsweise von Borg. Ihr könnt jedes beliebige Back-Up löschen. Es ist völlig egal, welches. Es gibt keine Inkrimitelle. Jedes Borg-Backup ist ein Vollback-Up. Es fühlt sich nur nicht so an, wenn ihr es macht. Es dauert nicht so lange. Die Backends, die wir anbieten, ist ein relativ einfaches Backend. Es ist quasi in Key-Values da. Der Key ist quasi der Hash mehr oder weniger. Und der Value ist halt der Datenbrocken, der weggespeichert wird. Und wir können zwei Sachen machen. Wir können entweder einen Fallsystem rein speichern, ganz normal so Ordner und Dateien. Oder man kann über SSH mit einem Remote-Borg-Prozess das Ding reden lassen. Dann ist es quasi so ein kleinen Server und schickt die Datenäufer über SSH halt rüber. Das setzt natürlich dann voraus, dass ihr auf der Remote-Serie den Borg entweder installiert habt. Durch irgendeinen Provider oder halt selber installieren könnt. Das Ganze ist schon der BSD-License, also sehr freilizensiert. Das war auch beim Folgen natürlich praktisch. BSD ist sehr freizügig, kann man einfach machen. Die Docku ist ziemlich gut. Wir haben da so mit Zvings recht umfangreiche Usage und Quickstart und so weiter. Auch so ein bisschen für Developer haben wir inzwischen Dokumentation. So die Plattform und Architekturunterstützung ist auch sehr gut. Also ihr könnt es auf ganz normalen 86 oder auch 64-Bit laufen lassen, wenn ihr jetzt ein MIPS-CPU habt. Und wenn euch das schnell genug ist, könnt ihr es auch auf MIPS laufen lassen. Es geht mit Little-Endien, es geht mit Big-Endien. Also wir haben recht breite Tests, wo das alles durchtestschen. Und auch bei den Distributionen, z.B. bei Debian wird es durch den ihren Testing-Prozess auch sehr breit getestet auf allen möglichen Architekturen. Auf manchen Systemen werden Extended Attributes und ACLs supportet. Also Linux z.B., FreeBSD und OSX. Bei den anderen Systemen liegt es daran, entweder die haben keine Extended Attributes oder wir haben halt noch keinen speziellen Code, wo speziell diese Systeme supportet. Also wenn ihr jetzt, weiss nicht, netBSD oder irgendwas ein bisschen Exotischeres habt. Da müsst ihr mal also vielleicht noch mal danach gucken. Da ist dann auch Mitarbeit gefragt, weil wir supporten also diese Systeme, wo wir halt so gewöhnt sind. Auch sehr nett. Wir haben Fuse Support, also Fuse heißt File System in User Space. Ihr könnt also, wenn ihr so ein Backup gemacht habt und ihr habt so ein Backup-Archiv, könnt ihr einfach sagen, mounte mir bitte dieses Backup-Archiv in diesen Ordner hier rein und dann könnt ihr da drin rumgucken und rauskopieren, wie wenn es Dateien wären. Das eigentliche Borg-Repository ist nicht einfach eine Sammlung von den Dateien, die ihr da reingespeigert hat. Das tut ja die Dateien zu hacken und verschlüsseln und alles Mögliche. Also ihr könnt nicht wie bei Ersing einfach aus einem Backup rauskopieren. Aber durch dieses Fuse fühlt sich Semendeffekt genauso an. Ihr braucht halt einen Befehl für den Mount und danach kann man das dann sehr einfach benutzen. Vor allem wenn man was sucht, sehr praktisch. Man kann auch ein komplettes Repository mounten. Dann sieht man praktisch in der ersten Ordnerebene alle Backups, die man jemals gemacht hat und kann dann da dazwischen drin rumspringen oder auch diff laufen lassen um festzustellen, wo ist jetzt die Datei drin, die ich haben will. Man kann Feind benutzen, alles Mögliche. Also das übliche Toolset kann man dann sehr gut benutzen zum Code. Die Zahlen sind vielleicht nicht mehr ganz richtig, weil wir arbeiten ja sehr viel dran. Aber so eine Großteil ist in Pfeifen und wir haben das auch vor einiger Zeit auf Pfeifen 3, 4 hochgezogen. Früher war es Pfeifen 3, 2. Die Pfeifenentwickler unter euch wissen aber vielleicht, Pfeifen 3, 2 ist eher so ein bisschen neuer. Die Version 3, 3 war auch nicht besonders toll. Also ab 3, 4 wird eigentlich Pfeifen so gut brauchbar. Pfeifen 2 wird nicht unterstützt, das hat schon der Attic-Entwickler nicht unterstützt und inzwischen gibt es eh keinen Grund mehr da jetzt ein Backport zu machen. Jetzt könnt ihr euch natürlich vorstellen, wenn das komplett in Pfeifen wäre, wäre das in manchen Stellen vielleicht ein bisschen langsam. Deshalb haben wir auch die Geschwindigkeitskritischen Sachen in C geschrieben. Das ist zum Beispiel der sogenannte Chunker. Das ist das Ding, was die Dateien zähakt, bevor sie gehäscht werden. Und so ein bisschen Interface Code, Glue Code, auch Richtung OpenSSL und so weiter, mit Siphon gemacht. Siphon ist praktisch, wenn man was relativ schnell haben will, aber trotzdem Pfeifensyndax verwenden will. Also man kommt da relativ nah an C ran. Man kann auch die C-Datentypen verwenden, aber es ist halt hübsch formatiert. Man braucht nicht so viele geschweifte Klammern und so. Also ist viel angenehmer eigentlich so vom Programmieren her. Und man kann praktisch in Siphon dann sagen, okay, das ist jetzt mehr so Richtung Pfeifen vom Code her und von den Möglichkeiten her. Und dieses Stückchen ist jetzt mehr Richtung C. Also man kann das so ein bisschen die richtige Gegend sich raussuchen, je nachdem, was man macht. 12.000 Zeilen Code, da müssen wir auch mal noch mal nachzählen. Das ist wahrscheinlich inzwischen ein bisschen mehr geworden. Aber ist relativ wenig, weil halt ziemlich viel vom Code eigentlich High Level in Python geschrieben ist. Und nur Junkern, Hashtabelle, die sind halt in C implementiert. Dependencies haben wir eigentlich nur Message Pack, sonst wüsste ich grad, also auf der Python-Ebene. Und dann halt brauchen wir noch OpenSSL für die Verschlüsselung. Und die Kompressions Libraries, also LZ4 Library zum Beispiel. Aber eigentlich relativ wenig, also das irgendwo zu Partner oder so ist in der Regel kein großes Problem. Wir haben ziemlich viele Unit Test, also Coverage ist so irgendwie 80%. Können wir noch vielleicht ein bisschen verbessern. Und das Ding läuft auch regelmäßig durch Continuous Integration durch, also Travis CI benutzen wir da, also jeder Pull Request und jeder Commit wird durchgetestet. Zur Sicherheit von dem Ganzen, das ist auch einer der Schwerpunkte von dieser Software. Es gibt ja viele Backup Software, da ist eigentlich gar keine Sicherheit drin. Aber bei Attic und Borg ist da schon vom Design her recht viel drin. Es wird also, wenn man die Verschlüsselung an hat, und das ist mittlerweile der Default. Also wenn ihr nichts Besonderes macht, ist das Ding verschlüsselt. Es wird also überall drübersigniert. Also man kann nicht irgendwo unbemerkt eine Corruption haben. Also wenn ihr zum Beispiel ein Bitflip hättet auf der Festplatte vom Repository, ihr würdet das merken, es kann nicht sein, dass es unbemerkt irgendwie durchrutscht und ihr Daten wiederherstellt, die gar nicht in Ordnung sind. Genauso natürlich, wenn ihr versucht, wenn ihr das Repository von dem Rechner von irgendeiner Person oder Firma liegen habt, wenn ihr versucht daran rumzutwiegen, um euch irgendwie einzulegen, würde sofort bemerkt werden. Die Verschlüsselung ist AIS256, also ist so nach aktuellem Stand auch recht gut. Dadurch ist also die Vertraulichkeit gesichert, ihr könnt auf irgendeinen Rechner eurer Sicherung draufkippen, auch wenn er nicht unter eurer Kontrolle ist. Das einzige, worauf ihr euch all zu halbwegs verlassen können müsst, ist, dass der Server nicht verschwindet, wenn ihr einen Backup braucht. Also wenn ihr durch das Repository Provider euch das Repository wegnimmt, indem ihr den Server abklemmt, gut ist und richtig blöd, aber ihr könnt ja also nicht so subtil irgendwas modifizieren oder einfach reingucken in eure Daten. Er sieht nicht mal Metadaten oder sowas, also Selbstständige Feinnahmen oder sowas, das ist alles verschlüsselt. Ihr könnt euch das auch selber angucken, müsst ihr jetzt also nicht glauben, das ist Open Source Software, also die kryptoschen Keypunkt per Y und in Open SSL. Bei Open SSL rümpfen vielleicht manche die Nase, weil die ja so ab und zu so ein bisschen Security Probleme hatten in der Vergangenheit. Ich denke mal für uns ist es wahrscheinlich kein Problem, weil wir machen nichts Kompliziertes mit Open SSL, also wir machen jetzt keinen TLS Handshake oder irgendwas, man tut nur die Kryptopremitive eigentlich benutzen. Also das AIS256 in Counter Mode und dafür hat Open SSL, denke ich mal Unit Hashts. Also da sollte eigentlich normalerweise nichts schiefgehen. Genauso sind natürlich die Hashes, wenn wir dann Scha256 oder einen HMAC Scha256 benutzen, da gibt es auch Tests dafür. Also das sollte relativ unkritisch sein. Ach so ja, und dadurch, dass ein Großteil in Python ist, haben wir auch so ein bisschen weniger Probleme mit irgendwelchen Buffer Overflows, wie jetzt Software, die in C geschrieben ist. Wir haben zwar ein paar C-Komponenten drin, aber die sind nicht so wahnsinnig kompliziert, die kann man also durchaus mal durchlesen und sich halt wirklich sicher sein, dass es wahrscheinlich kein Buffer Overflow hat. So zum Thema Safety, das Ganze ist vom Design her auch so gemacht, dass es robust ist. Also wenn ihr jetzt zum Beispiel einen Backup macht und zwischendrin fliegt euch eure SSH-Verbindung weg, weil irgendjemanden Stecker irgendwo zieht oder ihre Internetverbindung bricht zusammen oder Rechner stürzt ab, Strom ist alle. Es macht im Prinzip nichts aus, wenn ein Backup startet, fängt ja eine Transaktion an, dann macht er Backup, Backup, Backup, ganz im Schluss macht er ein Commit und erst mit dem Commit ist das ganze Ding, wird es als Valide betrachtet. Wenn da kein Commit am Ende ist, ist das ungültig und wenn ihr das nächste Mal das Repository anfasst, macht ihr einfach ein Rollback auf den letzten Commit und dann ist alles wieder gut. Also da kann man eigentlich so von den normalen Fehlerquellen kaum was schiefgehen. Außerdem wird alle fünf Minuten ein Checkpoint gemacht, wenn ihr halt Stunden oder Tage lang ein Backup macht und fünf Minuten vor Schluss stirbt die Leitung, das wäre halt blöd, wenn man da wieder von vorne anfangen muss. Deshalb halt macht er quasi alle fünf Minuten auch ein Commit und dieses Teilarchiv, was da entsteht, ist auch Valide. Es ist halt nur nicht vollständig, es enthält nicht alle Dateien, die ihr sichern wolltet, aber das, was drin ist, ist korrekt. Also es sind keine angefressenen Elemente oder sowas drin, das ist in sich stimmig. In der 1.0-Version muss ich dazusagen, dass diese fünf Minuten Checkpoints nur zwischen Dateien stattfinden. Also wenn ihr eine Datei mit einem Thera-Abeit habt und schiebt die rüber, dann macht er nicht alle fünf Minuten ein Checkpoint, sondern erst wenn die fertig ist. Das ist ein bisschen ungeschickt, wenn man so große Dateien hat, deshalb haben wir auch in der 1.1-Version das gefixt. Also die 1.1-Version macht auch bei Teilen von Dateien Checkpoints und die tauchen dann als Punkt-Part so und so auf. Also die sind dann natürlich nicht vollständig aus prinzipiellen Gründen, aber man sieht, dass es eine Teildatei ist, also man hält es nicht aus für Säen für die Richtige. Was wir auch machen, ist, wir tun den Message-Pack in so einem Art Limited-Mode aufrufen. Das Problem ist ja ein bisschen, wenn so über Netzwerk irgendwelche Daten kommen oder aus dem Repositori, wo ihr nicht unbedingt alleine kontrolliert Daten kommen und man packt das aus, das ist ja immer so ein bisschen heikler Moment. Wenn da halt einer in so ein Paket reinschreiben würde, ja jetzt kommen 4 Milliarden Integers oder so und er würde da erst mal versuchen, 32 Gigabyte RAM zu allokieren. Das haben wir entsprechend eingeschränkt. Wir wissen ungefähr, was da kommt und von daher tut er nur relativ wenig auspacken. Und wenn da auf einmal viel mehr kommt, dann gibt es halt eine Exept-Schnappe. Er tut euch kein DOS auf die Maschine machen. Zur Krypto noch. Die Krypto ist natürlich kleinzeitig, weil das Modell ist halt dem Klein Vertrauen mir. Das ist die Kiste, wo wir Backup'n tun. Dies sollte normalerweise okay sein, aber der Repositori-Anbieter ist halt möglicherweise eine Kiste von irgendeinem Provider, wo wir vielleicht nicht komplett unter Kontrolle haben. Und deshalb tun wir halt auf klein Seite, bevor es übertragen wird, sowohl die Daten als auch die Metadaten verschlüsseln. Es sind insgesamt drei Keys im Einsatz. Das eine ist quasi der AES-Key, das zweite ist der HMAC-Key und das dritte ist mehr so ein Art Random Secret, was für das Zahacken der Dateien benutzt wird. Da komme ich nachher noch dazu. Wenn ihr die Encryption benutzt, was default ist, die Passphrase wird mit ppk.f2 mit 100.000 Runden. Im Prinzip durchgearbeitet, also da ist absichtlich eine Bremse drin, dass man da nicht mit beliebiger Geschwindigkeit Angriffe drauf fahren kann. Da hat es schon ein bisschen Diskussionen gegeben, ob diese 100.000 Runden jetzt okay sind. Wir haben deshalb 100.000 Runden, dass man das sowohl auf sehr langsameren Rechnern als auch auf sehr schnellen auf beiden Halt benutzen kann. Wenn ich das jetzt auf 10 Millionen setzen würde, wäre es zwar ein bisschen sicherer, aber wenn dann halt einer mit einem Raspberry Pi irgendwas machen will, dann muss er halt ewig lang warten bis sein Kommando mal losläuft. Das kann aber sein, dass wir das irgendwann in der Zukunft dann noch ein bisschen hochdrehen. Was die Verschlüsselung an gibt, gibt aktuell drei Modi. Man kann die Verschlüsselung abschalten. Das muss man aber explizit machen. Die fällt die Schiff an. Man kann einen sogenannten Repo-Key-Modus verwenden. Der macht im Prinzip genau das, wie er heißt. Der speichert den Key im Repository, also auf dem unvertrauenswürdigen Server möglicherweise. Das ist aber kein Problem, weil der Key an sich nochmal verschlüsselt ist. Also ist nicht ganz so sicher natürlich, wie wenn ihr den lokal habt. Das ist dieser letzte Modus. Also der Key-File-Modus steht jetzt hier nicht dabei. Ne, doch steht hinten Key-File. Key-File wäre quasi das gleiche auf eurem Klein gespeichert. Also ihr könnt, wenn ihr dem Repository überhaupt nicht trauen wollt, auch den Key lokal speichern. Aber dann müsst ihr halt aufpassen, dass ihr den Key sichern müsst. Das Backup, wo ihr von der ganzen Maschine macht, ist ja verschlüsselt. Da kommt er ohne Key nicht ran. Also wenn ihr vergesst den Key zu sichern und die Maschine raucht euch ab, dann war's das halt. Deshalb haben wir als Default-Repokey, um dieses Problem zu vermeiden, dass das jemand vergisst. Und jemand, der es dann explizit umschaltet, der denkt dann vielleicht auch dran, dass er ein Backup davon machen sollte. Steht auch in der Docku. Das habe ich vorhin schon so ein bisschen erwähnt. Wir machen also authenticated encryption additional details. Ich glaube bisher noch nicht so wirklich benutzt, kommt aber bald. Und das ist Counter-Modus. Das ist also einer der AIS-Modi, wo es ein bisschen sicherer ist, wie manche andere. Also die meisten Angriffe auf AIS-Verschlüsselung waren ja meistens dieses CPC-Modus. Und wie gesagt, obendrüber ist eh nochmal eine Authentifizierung. Also von da sollte da normalerweise eh nichts passieren. Es wird auch aufgepasst, dass dieser Counter, der da im Spiel ist, natürlich immer inkrementiert werden muss. Man darf keine Counterwerte doppelt verwenden. Die Software speichert sich praktisch den Counter, den Letzten ins Manifest mit rein. Und wenn der das nächste Backup macht, liest er das Manifest. Zählt noch so ein paar weiter, weil das hat ja auch eine gewisse Größe und macht dann an der Stelle weiter. Ist in der 1.0 vielleicht nicht ganz sicher, weil wenn euch jemand ein Backup abbricht und ihr startet dann wieder eins neu, also das ist noch nicht so ganz perfekt, ist aber auch nicht superproblematisch, weil das Ganze läuft ja nochmal über SSH drüber. Also wenn jetzt jemand an der Leitung lauscht, sieht er da eh nichts von euren Backup-Daten. Also nicht mal die verschlüsselten Backup-Daten, weil die ja durch SSH dann nochmal verschlüsselt sind. Also das wird wahrscheinlich in 1.2 dann so voll ganz gefixt. Da haben wir größere Ändungen vor. Das ist auch das, was im nächsten Punkt steht. Dieser Modus, wo oben erwähnt wird, das ist nicht besonders schnell, weil das AES wird zwar hardware-beschleunigter vielen rechnen, aber das H-Max-H2, 5.6 halt nicht. Also da geht relativ viel CPU dafür drauf. Wir haben jetzt vor, AES 2.5.6 GZM zu machen. Das wird also beides dann hardware-beschleunigt. Vielleicht auch irgendwie Chacha oder sowas, das müssen wir noch sehen, vielleicht auch AES OCB. Aber generell diese Modis sind etwas schneller als das, was wir momentan haben. Sondern das CPU-Spaß sind wird es natürlich, wenn ihr eine CPU habt, wo AES in i macht, ist heutzutage eigentlich oft kein Problem, weil es seit wieviel, 5 oder 10 Jahren oder so ist das üblicherweise drin. Wenn ihr jetzt eine Nicht-X86 oder X64-CPU habt, dann kann es natürlich sein, dass die CPU das alles in Software rechnen muss. Aber gut, die sind dann meistens AES ein bisschen langsamer, schon von vornherein. Kompression ist eins vielleicht noch erstaunenswert. Das habe ich ja vorhin schon erwähnt, was es alles gibt. Wenn ihr LZ4-Kompression macht, ist das in vielen Fällen schneller als wenn ihr gar keine macht. Er muss dann zwar ein bisschen Aufwand treiben, um das Zeug zu komprimieren, aber LZ4 ist wahnsinnig schnell und erspart sich ja dann bei der Datenübertragung, beim wegspeichern Zeit. Also wenn ihr quasi da keine Idee habt, was ihr da jetzt am besten benutzen soll, probiert einfach mal LZ4. Das ist also zumindest, wenn man relativ schnelle Leitung oder einen schnellen Storage hat, eigentlich so das Beste. Wenn ihr jetzt natürlich so ein DSL-Upstream mit einem Megabit pro Sekunde benutzen müsst für euer Backup, dann nehmt ihr nicht LZ4, dann probiert ihr vielleicht irgendwo LZMA niedrigen Level aus. Bei LZMA muss man noch dazusagen, bitte nicht LZMA.9 verwenden. Das macht keinen Sinn. Das Maximum, was Sinn macht, ist so 0,6 oder so was. Weil wenn ihr noch höhere Kompressionen von LZMA anfordert, dann versucht es halt, wahnsinnig große Datenmengen quasi zu betrachten. Aber so viel Daten haben wir gar nicht in den Eingabendaten, weil wir zu hacken ja die Dateien in kleine Stückchen. Das heißt der Verbrennter nur unnötig Prozessorzeit, wenn ihr eine hohe Kompression anfordert. Also maximal LZMA.6, das ist auch schon langsam genug. Die D-Duplition vielleicht noch. Ich denke mal, viele von euch werden ja wahrscheinlich so R-Sync benutzen mit Hard Links vielleicht. Und da fragt ihr euch, was soll das? Kann ich doch auch schon. Das macht doch mit diesen Hard Links diese D-Duplizierung. Das Problem bei R-Sync ist, wenn ihr zum Beispiel ein virtuellen Maschinen-Image habt, irgendeine Windows oder FreeBSD, VM, was auch immer, ihr startet das Ding so alle paar Tage mal an. Und jedes Mal, wenn ihr das startet, ändert sich ja die virtuelle Maschinen-Datei irgendwie. Und wenn ihr da ein sehr einfaches Backup macht, also wie mit R-Sync, dann merkt ihr halt, ah, die Datei ist anders. Okay, ich speichere die wieder neu weg. Und im Repositori habt ihr dann im Prinzip für jeden Tag eine virtuelle Maschinen-Datei rumliegen, die jeweils euch 10 Gigabyte oder 50 Gigabyte Platz wegfrisst auf eurem Repositori-Speicher. Bei Borg ist das etwas praktischer, dadurch dass die Dateien zu hackt werden und dann die Stückchen alleine betrachtet werden. Tut ja wirklich nur die Daten dann neu weg speichern, die sie wirklich geändert haben. Die 90 Prozent der virtuellen Maschine, die sie eh nicht geändert haben, die tut ihr dann nicht nochmal weg speichern. Ihr könntet euch auch von physikalischen Platten-Images machen, das ist im Prinzip der gleiche Fall wie eine virtuelle Maschine. Wenn ihr zum Beispiel eine große Bildersammlung habt, wo ihr so übers Jahr Bildersammelt und am Ende vom Jahr tut ihr halt den Ordner umbenennen von Bilder auf Bilder 2016 oder so, hätte R-Sync auch ein Problem, das würde diesen Ordner einfach nochmal drauf speichern, weil es halt nicht merkt, dass das die gleichen Dateien sind. Borg interessiert sich für die Dateinnahmen überhaupt nicht, das betrachtet immer nur diese Datenbrocken. Also ob das Ding jetzt FU oder BAR heißt, ist völlig egal, wenn da gleiche Inhalt drin ist, wird das auch dedupliziert. Wenn ihr doppelte Dateien habt, ist das quasi die innere Deduplizierung, also von diesen Daten, die ihr jetzt im Moment gerade sichert, wird dadurch weg dedupliziert. Diese historische Deduplizierung, wenn ihr halt 100 Backups macht und meistens ist immer wieder das Gleiche bis auf so ein paar Dateien, wird auch dedupliziert. Und ihr könnt auch zwischen verschiedenen Maschinen Deduplizierung kriegen, wenn ihr die Maschinen in das gleiche Repositorie reinspeichert. Hat allerdings einen kleinen Nachteil. Wenn die praktisch wechselseitig von verschiedenen Maschinen speichern, muss er sein Cash neu synchronisieren. Also Borg hat kleinzeitigen Cash. Und wenn halt das Repositorie nicht mehr mit dem Cash übereinstimmt, muss halt der Cash neu aufgebaut werden. Also wenn man mehrere Maschinen ins gleiche Repo reinspeichert, das ist nicht die schnellste Methode, aber kann euch halt ein bisschen Platz sparen. Also vor allem wenn halt auf den Maschinen das größtenteils das Gleiche drauf ist, Betriebssystem und so weiter vielleicht. Die Deduplizierung an sich ist ganz interessant, wie das funktioniert. Da wird ein so genanter Rolling-Hash verwendet. Ihr kennt ja so die normalen Hashes. Also entweder die nicht kryptografischen oder die kryptografischen, dann nimmt man halt einfach einen Datenblock, macht irgendwelche aufwendigen Rechenoperationen und dann spuckt es halt irgendein Hash-Wert aus. Das Problem ist, wenn man das wie eine Art Fenster über eine riesengroße Datei den Hash vom Fensterinhalt immer wieder berechnen will, immer wieder ein Byte weiter setzen will, dann wäre so ein normaler Hash unheimlich aufwendig, weil ich halt jedes Mal wieder ganz vorne anfange. Ein Rolling-Hash hat ein bisschen einen anderen Algorithmus und der zeichnet sich dadurch aus, dass wenn ich das Fenster ein Byte weiterschiebe, kann ich praktisch das Byte, was das Fenster verlässt, einfach durch eine Operation rausrechnen aus dem Hash-Wert und das Byte, was ins Fenster reinkommt, dann einfach reinrechnen. Also ich brauche nur zwei Kollektu-Operationen, um den letzten Hash dann zu aktualisieren, sodass er für meine aktuelle Fensterposition stimmt. Ja, das ist der Grund, warum das gemacht wird. Wir können ja bei dies, also wir wollen ja Häppchen haben, wir wollen nicht die ganze Datei als Gesamtes betrachten, was die Detuplizierung angeht, sondern Bereiche dieser Datei. Und wenn wir jetzt einfach sagen würden, okay, wir hacken nach ne Megabyte und nach zwei Megabyte und nach drei Megabyte, das wäre dann halt blöd, wenn einer vorne ein Byte einfügt und alles rutscht nach hinten und kein Block stimmt mehr. Und dann würden sich ja alle Blöcke ändern, selbst wenn das ein Thera-Byte ist. Und durch diese Methode, dass der halt den Inhalt betrachtet und dann halt den Hash anguckt, ob der auf den letzten paar Bits null wird und dann hackt. Da hängen praktisch diese Hackstellen, direkt vom Inhalt ab. Das heißt, wenn euer Inhalt verrutscht, verrutschen auch eure Stellen, wo ihr schneidet. Und dadurch bleibt man halt, selbst wenn man Sachen rausnimmt außer Datei oder einfügt oder alles sich so ein bisschen nach hinten oder vorne verschiebt, bleibt man halt die meisten Brocken, die gleichen. Und das ist der Vorteil von diesen Verfahren. Und dadurch, dass es halt diese Rolling-Hashes gibt, ist es auch nicht so schlimm von der Performance her. Man kann die durchaus relativ effizient berechnen und deshalb wird es halt so gemacht. Also Borg macht es so, Ethik macht so, Restik macht so. Ich glaube, OpenName zum Beispiel, das ist auch so eine Software, die detupliciert, die macht es glaube nicht so. Ich glaube, der tut einen festen Offsets hacken, wenn ich es recht im Kopf hab. Diese Parameter, wie das genau diese Brocken macht, also chunks, heißen sie auf Englisch, die könnt ihr so ein bisschen einstellen. Wir machen so einen Default-Wert, der so im statistischen Mittel ungefähr 2 Megabyte große Brocken generiert. Das hat den Vorteil, die Anzahl dieser Chunks ist relativ gering dann. Wenn ich jetzt so Häppchen mit 64 Kilobytes mache, was der Default von Ethik war, dann entstehen unheimlich viele Chunks und die müsste halt alle verwalten. Die Software muss ja zu jedem Zeitpunkt wissen, was hab ich schon und was hab ich noch nicht. Und bei Ethik war also das Problem, dass teilweise halt der Ramm ausgegangen ist, wenn man halt so ein Raspberry Pi oder so was hatte. Und deshalb haben wir also diese Chunkgröße deutlich höher gedreht. Ihr könnt aber, wenn ihr spezielle Anwendung habt, wo sie diese kleineren Chunks Sinn machen, könnt ihr es also auch wieder runterdrehen, das ist parametrisierbar. Nur halt sich bewusst sein, dass es halt nicht umsonst ist, wenn man so viele Chunks produziert. Der letzte Punkt vom Oberen ist auch noch interessant. Hab ich vorhin bei den Keys schon erwähnt, wir haben einen Random, wo praktisch als Seed für diesen Chunking Algorithmus verwendet wird. Das heißt, wo der genau schneidet, ist praktisch bei jedem Repository, bei jedem Key, den ihr habt, anders. Das heißt, wenn ihr zum Beispiel irgendein so ein Public Domain-Movie irgendwie rumliegen habt und ihr sichert den in eure Repository rein, könnte man also an den Größen der Stückchen nicht sehen, welcher Film das war. Man müsste praktisch diesen Random Key noch zusätzlich wissen, weil nur dann würde er genauer die gleichen Brocken schneiden. Das Wegspeichern, da gibt es zwei Möglichkeiten. Das ist das untere. Wenn ihr die Verschlüsselung abschaltet, dann macht ihr einfach einen Schad 256 momentan. Das ist natürlich nicht besonders sicher, weil da ist dann keine Authentifizierung drüber und man kann den Hash halt auch direkt sehen. Also da ist eigentlich nur dieser Random-Parameter beim Chunking, dann ist ein bisschen Sicherheit. Aber man kann dann ja eh neue Daten reingucken, weil ihr habt es ja nicht verschlüsselt. Von daher ist es dann egal. Sobald ihr die Verschlüsselung anmacht, macht ihr also einen H-Mack. Das heißt, man kann auch diesen Hash-Werten in Anführungszeichen, wenn nicht ansehen, was da dahinter steckt, weil man halt euern Secret Key braucht, um die zu berechnen. Also ist auch da, was so die Datenleaks angeht, relativ sicher gemacht. Wir versuchen also, möglichst wenig Informationen zu leaking, wenn jemand bei euch ins Repositorierein guckt. Ich habe es vorhin schon erwähnt, das Ganze ist durch ein Volk entstanden von Ethic vor ungefähr zwei Jahren. Das Tolle war, also Ethic hatte schon eine ziemlich gute Codebase eigentlich. Also so vom Entwurf von der Software war das eigentlich alles prima. Und auch bei der Kryptografie war ich also durchaus erstaunt. Also der hat so die Fehler, die man vielleicht gern macht, hat er also schon gleich vermieden gehabt. Das war dadurch auch durchaus beliebt und hat einige Entwickler angelockt, die da vielleicht sich Pull Requests gemacht haben, also ich auch. Und da hat sich dann also mit der Zeit so ganz viel Pull Requests und Aktivität irgendwie angesammelt. Aber das Problem war, der Hauptautor hatte irgendwie keine Zeit. Und er wollte auch lieber eigentlich Sachen selber programmieren wie Pull Requests-Revion. Und deshalb ist das Ganze halt irgendwie ein bisschen gestanden und hat sich nicht wirklich weiterentwickelt. Wir haben dann das kurz im Isiotracker diskutiert und haben halt festgestellt, ja gut, die Ziele sind etwas unterschiedlich. Also er wollte das eigentlich mehr so für privat für sich als Spielprojekt haben und halt nur, wenn er Zeit hat. Und die anderen Leute wollten halt, das irgendwie ein bisschen schneller weiterentwickeln und halt so, dass es wirklich vielleicht für viele Entwickler interessant ist. Außerdem, der Originalautor hatte auch so die Idee Kompatibilität forever. Und da dachte ich auch, ja, es ist vielleicht nicht so, man will das zwar eigentlich haben so in der Theorie, aber wenn man sich dann die Auswirkungen überlegt, der Code wird halt immer größer und immer schrecklicher mit allen möglichen Fallbehandlungen. Also deshalb haben wir uns bei Borg auch rausgenommen, dass wenn wir eine Major Release machen, dass wir dann auch vielleicht Kompatibilität brechen und halt irgendwie ein Konverter anbieten oder irgendwie sowas. Wollt aber natürlich nicht zu oft machen, weil macht ja immer so einen gewissen Aufwand. Was auch ein Ziel von Borg war, ist natürlich, dass es nicht ein Mannprojekt sein soll, sondern dass halt Entwickler auch natürlich beitragen können. Das klappt auch ganz gut. Also als wir Ethik gefolgt haben, waren das ungefähr 600 Change Sets im Repository. Inzwischen haben wir also über 4.000 Change Sets. Und die letzten 3.400, das sind also zwei Jahre. Die ersten 600 waren ungefähr 4, 5 Jahre. Also es entwickelt sich jetzt deutlich schneller weiter. Und wenn ihr also mitmachen wollt, einfach mitmachen. Der Code ist durchaus recht gut lesbar. Python, Python, C. Wir wollen das auch in so diversen Stellen so ein bisschen redesignen, wo wir vielleicht merken, okay, ist nicht so ganz optimal. Und halt, wenn wir einen guten Grund haben, auch wirklich inkompatible Änderungen machen. Dorthin ist es natürlich etwas weniger stabil, so im Debian-Sinn, wie wenn man jetzt nichts anfasst und auf ewig kompatibel sein will. Aber wir versuchen also, dass es durch die Tests halt trotzdem immer eigentlich ganz gut läuft. So, das haben wir schon. Ach so, wenn ihr, also wenn ihr, weiß nicht, benutzt jemand Ethik oder hat es jemand schon benutzt? Einer? Ja. Also wir haben so ein Issue Nummer 5 auf GitHub. Das sind so die ganzen Ethik-Issues, alle eigentlich größtenteils abgehakt. So ein paar sind übrig, aber das sind mehr so nice-to-have-Sachen. Also nicht bugs im engeren Sinne. Also von daher haben wir praktisch den kompletten Ethik-Issue-Träger schon durchgearbeitet. Und können jetzt also praktisch in unserem eigenen Issue-Träger dann auch weitermachen. Das ist einfach so eine Checkliste von GitHub. Ein paar neue Features haben wir eingebaut. Tests haben wir erweitert. Plattformen haben wir auch etwas erweitert. Und die Docu haben wir auch so ein bisschen noch aktualisiert, weil da war auch diverse Sachen nur auf der Mailingliste verfügbar. Was ihr momentan jetzt produktiv benutzen könnt, ist die 1.0-Version. Also 1.0.10 ist die aktuelle. Bald war schon eigentlich 11. Linux, BSD, Mac OS X, das sind so die Hauptplattformen. Ihr könnt es auch unter Cygwin benutzen. Tut eigentlich auch ganz gut. Allerdings, was es halt nicht kann, sind Spezialfeatures von Windows, also Windows-ACLs, zum Beispiel kann es noch nicht, natürlich. Also mehr vielleicht so für eure Bildersammlung oder irgendwie so was nicht für einen kompletten System Backup verwenden. Ja, und so kommt da so ein bisschen Feedback rein, so Twitter und Reddit. Da findet ihr so diverses Blockposts und Posts. Also das ist eigentlich immer recht positiv. Momentan arbeiten wir stark an der BORG 1.1-Version, die ist jetzt gerade bei Beta 6. Ich hoffe, dass wir irgendwann bald RC1 oder Beta 7 dann machen können. Neu ist vor allem das Difffeature, dass ihr sagen könnt, okay, zeig mir bitte die Differenz zwischen diesem Archiv und diesem Archiv an. Hört sich jetzt vielleicht banal an, aber es ist halt ein Vollbackup-Programma. Also ihr habt nur Vollbackups, also da eine Differenz zu berechnen, das ist schon ein bisschen Aufwand. Ein incrementelles Backup-Tool hat es natürlich viel einfacher, weil das tut ja nur die Differenz wegspeichern, dann ist die Differenz anzeigen oder durch Trivial. Aber können wir jetzt auch Recreate bedeutet, ihr habt vielleicht ganz früher mit Attic-Backups gemacht, mit relativ kleinen Chunks. Ihr wollt aber diese Backup-Archive jetzt mit diesen größeren Chunks neu generieren, dann kann man Recreate sagen, einfach mit neuen Chunker-Parametern oder auch mit neuer Kompression. Also man kann also diverse Parameter ändern, einfach ein Archiv, das man schon hat, nochmal neu erzeugen mit anderen Parametern. Man kann auch die Exclude-List ändern, das ist, wenn man so Sachen vergessen hat, die zu excluden und die doch excluded haben will, kann man also auch diese Exclude-List ändern, auch ganz praktisch. With Lock ist ein Befehl, wo man so ein bisschen das Interfacing mit anderen Tools machen kann. Also manche Leute wollen ihr eigentliches Backup erst mal mit Borg machen, aber dann ihr Borg-Repositori noch mal mit Arsync auf eine andere Maschine irgendwie rüber kopieren. Und man soll dann natürlich vermeiden, dass man es jetzt gerade in dem Moment kopiert, wo der gerade Backup-en ist. Dann hätte man halt einen Zustand, den man eigentlich nicht so haben will. Und With Lock beachtet halt einfach das Lock von Borg und das Kommando, was ich hinter With Lock dahinter schreibe, wird dann halt erst ausgeführt, wenn ein Lock bekommen werden kann, also wenn das acquired werden kann. Also ähnlich wie zwei Borgprozesse quasi aufeinander warten, indem der erste halt lockt und der zweite wartet, bis das Lock weggeht. Kann man es mit With Lock halt auch mit weiteren Tools genauso machen. Ihr könnt dann auch Kommentare auf Archive drauf machen, also außerdem Namen. Die Autokompression ist auch ganz lustig. Oft weiß man ja nicht so richtig, ja gut, ich habe so ein paar Daten, die lassen sich gar nicht komprimieren, aber ein paar andere lassen sich komprimieren. Und dann ist immer so ein bisschen die Frage, was man dann besten nimmt. Diese Heuristik macht Folgendes, die tut einfach auf den Datenprocken LZ4 anwenden und wie gesagt LZ4 schon wahnsinnig schnell, also das ist kein großer Aufwand. Und je nachdem, wie stark LZ4 es dann komprimieren konnte, fällt dann halt die Entscheidung, okay, ich lasse es einfach oder ich verwende das LZ4 so wie ich es eh schon berechnet hab oder ich mache dann LZMA. Also wenn ich gesehen hab, halt Kompression macht Sinn. Wenn das jetzt so ein JPEG war, bringt LZMA halt auch nicht mehr so arg viel, ja, wahrscheinlich gar nichts oder minimal nur. Also damit kann man praktisch durch einen kurzen Test mit dem schnellen Verfahren vom Maiden, dass man jetzt alle Daten durch ein langsames Verfahren durchschleusen muss, wenn es keinen Sinn macht. Wir haben auch noch ein bisschen rumgetuned, also das Fuse ist ein bisschen schneller geworden, also dieses Mount-Kommando und auch auf Festplatten das Durchgraben durch die Direkturistruktur, da haben wir auch ein bisschen dran rumoptimiert, also vor allem auf Festplatten ist es deutlich schneller jetzt. Es wird einfach die Ein-Node-Reihenfolge beachtet. Er tut glaube nicht, was er da vorher gemacht, glaube früher war es einfach so die Direkturireihenfolge und jetzt tut er also versuchen, sortiert nach Ein-Nodes das abzuarbeiten. Und im Sauscode haben wir auch so ein bisschen reorganisiert und aufgeräumt. Eine größere Baustelle wird an Berg 1-2 werden, das werden wir also diesen Sommer anfangen. Wir haben auch schon viele Versuche in der Richtung gemacht, aber es ist noch nichts wirklich Produktives im engeren Sinne. Also Multifredding ist da einer der Punkte und ich habe vor ein, zwei Jahren schon mal einen Versuch gemacht, das liegt nur irgendwo in einem Experimentalbransch rum. Bei Multifredding könnt ihr euch vorstellen, das kann tun oder auch nicht. Da gibt es halt manchmal nette Race-Conditions, die einen dann irgendwo beißen und da muss man also ein bisschen aufpassen, was man da tut, sonst kann es halt sein, dass das ganz blöd abstürzt oder sonst irgendwas Komisches tut. Der aktuelle Plan ist da vielleicht auch Zero-MQ zu verwenden. Das habe ich im Endeffekt auch erst vor nicht allzu langer Zeit entdeckt, ist aber wohl ein recht nettes Verfahren, wie man quasi so die Synchronisierung zwischen verschiedenen Frats machen kann. Also wenn man nicht das normale Locking und Semaphore und was so alles gibt, machen will. Und die Idee ist also momentan ist also Borg Single frettet. Also wenn ihr das laufen lasst, werdet ihr sehen, das benutzt maximal einen Core von eurer CPU und wenn ihr nicht allzu langsame Kompression verwendet, vielleicht sogar noch mal deutlich weniger, weil ihr halt immer wieder auf I.O. warten muss zwischendrin. Und die Idee ist halt einfach, das sind verschiedene Teilbereiche zu unterteilen, die dann über Zero-MQ kommunizieren, im gleichen Prozess. Also das muss nicht unbedingt verschiedene Prozesse geben. Und dass man halt einen Teilprozess hat, der halt die Daten einsammelt und einer ist halt für Kompression zuständig, einer für Krypto und einer fürs Wechschreiben. Und dadurch können die dann halt auch besser parallel arbeiten. Ja, vor allem die I.O. Wartezeit ist da halt ein Problem, weil es wenn er lesen tut, ist klar, müsste warten bis die Daten kommen. Und auch beim Schreiben ist es nicht ganz so, wie in anderer Software. Viele Software schreibt die Daten einfach weg und egal quasi, wird es schon irgendwie ankommen. Bei Borg machen wir öfters mal auch einen Sync, um sicherzustellen, dass die Daten wirklich auf dem Medium landen. Und wir machen auch einen Sync auf die Direktoris, dass wir also auch die Metadaten auf dem Medium haben. Und spätestens bei diesem Sync fällt dann halt wieder Wartezeit an, wenn er dann halt wartet, bis das Zeug auf dem Medium ist. Die Krypto ist auch nicht ganz ohne. Insbesondere, wenn man diesen einfachen Counter-Mode, wie man es momentan haben, verwendet, muss man halt natürlich vermeiden, dass man Counter-Werte doppelt verwendet. Deshalb haben wir auch als im Krypto-Bereich Änderungen vor, dass man quasi so wie eine Art Session-Key verwenden. Und wenn man mehrere Fretz haben für die Krypto, dass vielleicht jeder Fretzer einen eigenen Session-Key kriegt, dann vermeiden wir das Counter-Problem komplett. Wenn es Python-Entwickler hier gibt, haben Sie vielleicht manche gedacht, ja, aber das Geel ist doch in Python immer so das Problem beim Multithreading. Da haben wir kein großes Problem damit, weil wir machen ziemlich viel I.O. lesen und schreiben. Und selbst in Python, wenn ihr I.O. macht, wird das Geel freigegeben, wenn diese I.O. läuft. Genauso, wenn wir jetzt Krypto und Kompression machen, würde es so gar ein ganz normales Python auch, bevor so ein Haschets berechnet oder so, das Geel freigegeben und erst dann nach sich wiederholen. Und so generell, dass der Python-Code ist halt mehr so oder der komplexe obere Code und so die unteren Schichten, haben wir ja größtenteils ENC. Und da können wir uns also auch von uns aus entscheiden, okay, jetzt ist es geschicktes Geel freizugeben, weil wir eh nichts mehr in Python machen, das ist jetzt alles C, was da kommt. Und erst, wenn wir fertig sind, holen wir uns das Geel wieder. Also es ist nicht ganz so das große Problem, das habt ihr vor allem dann, wenn ihr jetzt Computing quasi in Python parallel machen wollt. Zur Krypto, da habe ich schon ein Pull-Request gemacht, wo diese APIs ein bisschen auf aead-Style umstellt, also das heißt authenticated in Kryption additional data oder auch authenticated data, also meint beides das Gleiche. Das bedeutet praktisch, dass man Daten verschlüsselt, also meine Nutzdaten, und dass ich dann aber noch zusätzliche Metadaten haben kann, die ich nicht verschlüsseln will, und dass ich über alles drüber eine Authentication mache, also dass mir an keinem einzigen Bit irgendeiner rumdrehen kann, ohne dass ich es merken würde. Was man auch haben wollen ist, dass man verschiedene Verschlüsselungsverfahren haben kann, also verschiedene Cyphers und Kielängen vielleicht auch diverse schnellere Verschlüsselungsverfahren vor allem Single-Pass-Verschlüsselungsverfahren, weil wir haben ja seit immer einen Pass-IS-Counter-Mode, dann noch mal einen Pass-SHA256 und HMAC, und es gibt halt Verfahren, die machen beides in Einnahmen, sind dadurch viel effizienter. Der letzte Punkt habe ich erst vor Kurzem ergänzt, das ist noch so ein bisschen ein Fragezeichen, das war mir aber selber gar nicht bewusst. Ketchup ist vielleicht manchen von euch bekannt als SHA3, und das ist ja eigentlich ein kryptografischer Hash, das ist jetzt nicht, denkt man, nicht direkt in einem Verschlüsselungsverfahren, ist ja nur ein Hash, aber bin ich darauf hingewiesen worden, dass also mit den gleichen Kernroutinen quasi auch kryptomachbar ist. Also wir haben da irgendein Paper veröffentlicht, war mir so gar nicht bekannt vorher. Ja, seht ihr T-Shirt hinten? You can be assimilated auf freiwilliger Basis, also ihr könnt gerne mithelfen, probiert das Ding einfach mal aus, wenn ihr viele Daten habt, macht auch gerne mal ein Skalierbarkeitstest oder die Zuverlässigkeit, ihr könnt sie so parallel am Anfang betreiben, wenn ihr also ein eingefahrenes Backup-Verfahren habt. Auch ein Security-Review, wer durchaus wünschens wäre, das ist ein richtig formelles Review, gab es bisher noch nicht. Könnte man also jetzt mit der produktiven Version machen, oder man wartet noch bis eins, zwei fertig ist, wenn man da die Krypto-E nochmal umbauen. Generell halt ein bisschen aufpassen, vor allem wenn ihr natürlich irgendwelche Beta-Versionen oder so ausprobiert, Beta-Versionen sind Daumen-Bucks zu finden, also für Produktionen doch lieber die Release-Versionen nehmen, dürfte auch gerne Bucks finden und fixen Pull-Requests auf GitHub machen. Wenn ihr unter Druck oder irgendwas findet, was fehlt oder was irgendwie schlecht oder missverständlich ist, auch Bescheid sagen, wenn ihr es benutzt und ihr seid happy so weit, einfach vielleicht auch mal weitersagen, es ist noch nicht so arg bekannt, also Ersing ist natürlich durch das Projekt alter viel bekannter und wenn ihr irgendwelche Plattformen habt und Distributionen, wo es noch keine Pakete gibt, könnt ihr auch gerne Pakete machen. Es gibt schon relativ viele, also die üblichen Kandidaten sind schon abgedeckt, aber wenn ihr irgendwas etwas Exotischeres habt, fehlt vielleicht noch ein Paket und wenn ihr irgendwelche exotischen Plattformen betreibt, mit komischen CPUs drin, vielleicht auch mal testen. Da liegen die Docus auf Free Note, gibt es auch ein IRC-Channel. Ich bin auch bis morgen hier auf der Konferenz, könnt mich auf Twitter erreichen. Das Einfachste ist vielleicht über GitHub, also auf GitHub einfach Borgbackup als Organisation suchen, da liegt der ganze Kram drin. Okay. Das war jetzt mal so im Prinzip der Einführungsvortrag. Ich dachte mir, wir können jetzt so relativ flexibel vielleicht erst mal Fragen machen. Hat jemand akut noch Fragen, Anmerkungen? Wünsche. Ja. Also generell, wenn du es produktiv benutzen willst, also vielleicht auch Restore, dann so ist es, machen wir es schlimm, lieber die Release Version. Die Beta ist, da wird momentan immer noch Features eingebaut und wir werden erst dann von Beta auf RC wechseln, wenn wir die Features so größtenteils drin haben. Also da ist man immer noch besser mit der Release bedient. Wenn du dann doch jetzt sagst, okay, ich habe dann Backup, was ich produktiv benutze, mit einem anderen System und ich will das jetzt nur mal ausprobieren, ob mir das überhaupt gefällt und überhaupt funktioniert, dann kannst du natürlich auch die Beta benutzen. Aber dann beschämt es sich vor allem nicht darauf angewiesen, dieses Repositori so benutzen zu müssen oder so zu erhalten für alle Zeit, sondern kannst du jetzt vor allem sagen, okay, ich lösche es wieder und fange wieder neu an. Also spät es eigentlich, nicht möglich. Du musst extra testen, was du sagst. Dann machen Sie mal das Test zum Konzentrum ein, du siehst ja die Idee, wenn du den Board setzst. Ja, okay, also ich wiederhole vielleicht die Fragen nochmal. Die Frage war mit dem Cache, das Problem ist, wenn ich mehrere Maschinen in eine Repositori rein sichere, dann habt ihr ein Cache-Coherence-Problem, heißt es üblicherweise. Also ihr habt zwar mit der Maschine A einen lokalen Cache erzeugt, der zu dem Zeitpunkt mit dem Repositori übereingestimmt hat, aber dadurch, dass Maschine B sich in das gleiche Repositori reingesichert hat, hat ihn dadurch im Prinzip euren Cache invalidiert, weil sie das Repositori danach geändert hat. Das ist wie wenn ihr mehrere Prozessoren habt, die aufs gleiche Ramm zugreifen, da muss man das genauso machen. Die Frage war also nach einem speziellen Ticket, das habe ich mir mal ausgedacht. Borgception steht da als Titel drüber, weil so ein bisschen der Inception-Gedanke dahinter steckte, also dass man quasi den Cache von Borg wieder mit Borg sichert irgendwie in so ein kleines Zusatz-Repositori oder so. Also da hat sich bisher nichts getan. Das ist immer noch so als Idee, steht es im Raum. Man könnte theoretisch den Cache auf die Platte speichern. Ja, wäre wohl möglich. Sollte tun. Ich habe es allerdings noch nicht ausprobiert. Vielleicht gibt es irgendwelche Details, die dann nicht so ganz funktionieren. Aber wenn, spricht jetzt eigentlich direkt nichts dagegen. Da spricht nichts dagegen. Das ist ja kein anderer Fall eigentlich, wie wenn du das auf einer hast. Also man fällt zumindest ad hoc nix ein. Probier es vielleicht mal vorsichtig aus, als ich mir jetzt dann mal nicht mal ein Hand dafür ins Feuer legen. Aber mir fällt jetzt auch ad hoc nix rein, was dagegen spricht. Ich muss allerdings dazu sagen, wir haben diese Routinen, wo diese Synchronisierung machen, ein bisschen getuned. Also die sind nicht mehr ganz so langsam wie vor einem Jahr. Die sind auch an sich ein bisschen schneller geworden. Also wir haben Hashtabelle ein bisschen rumoptimiert. Und auch so ein paar andere Sachen noch. Also ich hatte der Eindruck, so in letzter Zeit geht es durchaus relativ schnell. Was ein bisschen ärgerlich ist bei diesem Cash-Synchronisierungsverfahren, das kaliert nicht so wirklich. Der arbeitet halt alle Archive von 1 bis n durch. Ja, und wenn das n halt mit der Zeit größer wird, wird das halt potenziell immer langsamer. Genauso wenn wenn ihr relativ große Archive habt. Die Geschwindigkeit hängt auch von der Archivgröße ab. Ja, also von daher ist es mit dieser Cash-Synchronisierung nicht so ganz glücklich. Daher auch der Tipp, wenn ihr es eigentlich habt, tut nicht mehrere Maschinen in einer Repositorie sichern, macht einfach eine Repositorie pro Maschine. Und nur wenn ihr quasi das letzte bisschen Speicherplatz noch rausquetschen wollt, was geht durch diese Detuplizierung zwischen Maschinen, dann könnt ihr halt sagen, okay, ich will Platz sparen, aber ich habe Zeit zu investieren. Das ist halt das übliche Problem, Platz gegen Zeit. Also ich habe eines Ding so laufen, aber ich merke es halt auch jedes Mal. Das dauert halt ein bisschen am Anfang, bis er da wieder aktuell ist. Ihr könnt natürlich auch eure Pruning-Polizie dementsprechend einstellen. Weil wenn ihr jetzt sagt, okay, ich mach jede Stunde ein Backup und ich heb die ewig auf, gut, es gibt halt ziemlich viele dann irgendwann. Wenn ihr aber sagt, okay, sinnvoll ist vielleicht, dass ich jetzt von den letzten paar Tagen halt ganz viele Backups hab, aber wenn es dann weiter in die Vergangenheit geht, dann kann ich die ja immer weiter ausdünnen. Wenn dann irgendwie mein Backup mal ein Jahr alt ist, dann reicht vielleicht auch noch eins pro Monat oder eins jede Woche oder so. Dann ist die Anzahl der Archive nicht ganz so hoch, die euch die Geschwindigkeit beim Sync runterzieht. Der Marian, einer der anderen Burgentwickler, hat auch gerade noch eine Idee, dass man das sogar ganz anders macht. Wenn man im Prinzip nur ein Backup machen will und nichts löschen will, dann muss man diese aufwendige Castingchronisierung eigentlich gar nicht so machen. Dann kann man eigentlich einfach das Repo fragen, was gibt es alles für I.D.s, gibt mir einfach mal alle I.D.s rüber und eigentlich muss ich ja nur wissen, ich hab's schon oder ich hab's noch nicht. Das ist die einzige Entscheidung, die ich treffen muss beim Backup. Ich muss nicht wissen, wie viele Referenzen auf den Datenblock sind. Ich muss nur wissen, ob überhaupt da ist. Und das wäre natürlich ein viel schnelleres Verfahren. Allerdings, das würde halt nicht helfen, wenn ich halt löschen will. Wenn ich löschen will, muss ich wissen, wie oft wird dieser eine Datenblock referenziert von irgendwelchen Archiven. Also da ist durchaus noch was in Arbeit. Aber probier's vielleicht einfach mal aus, macht diese Methode mal so, dass du den Cash verschiebst. Probier's aus, also vielleicht tut es auch einfach. Ja, wird es genau simulink machen. Ja. Ja, weil das ist ein kryptografischer Key, was dann im Einsatz ist. Also das ist auch noch so ein bisschen Haken. Also das kann man natürlich nur innerhalb einer Trust Zone sage ich jetzt mal machen. Also wenn die Leute, wenn das mehrere Leute sind, sich gegenseitig vertrauen. Also für deine eigenen Maschinen könntest du das natürlich locker machen, weil da ist ja dann sonst niemand dran. Aber es ist überall der gleiche AES-Key dann im Einsatz. Ja, du kannst Sport dann ganz normal benutzen und sagen, licht mir die Archive auf und dann siehst du alle Archive. Also das ist jetzt, es sind keine Access-Kontroll-Lists oder sowas da, wo jetzt den Zugriff auf Archive irgendwie regulieren. Also der, wo Zugriff aufs Repository hat und den kryptografischen Key hat, der kann dann alles machen, was er will, auch löschen, zum Beispiel. Das ist übrigens auch ein bisschen Problem, um die Frage vielleicht vorwegzunehmen, wenn euch jemand, euren Client-Hacked, also irgendein produktiver Server, den ihr mit Borg-Backupen tut. Und der sieht da, aha, der macht mit Borg-Backups und der Kryptokiesch im Skriptalt oben drin, wie üblich, also angehören wir, der wird rot auf eurer Maschine. Gut, die Maschine könnt ihr dann eh vergessen, wenn die geäunt worden ist. Aber da könnt ihr natürlich potenziell auch eure Backups löschen. Da könnt ihr mehrere Sachen dagegen machen. Also ihr könnt natürlich außerhalb von Borg, zum Beispiel mit ZFS oder mit Wasser immer von eurem Repository einfach Snapshots machen. Das ist also eine Methode, die ihr unabhängig von unserer Software jetzt machen könnt. Ihr könnt auch mit Borg ein Repository im sogenannten Append-Only-Modus betreiben. Also generell die Arbeitsweise, wie Borg arbeitet mit diesen Transaktionen ist eigentlich eh in der Regel, dass hinten angehängt wird. Also alte Daten wird normalerweise nicht, erst mal nicht angefasst. Aber, wenn er halt alte Daten durch Neue ersetzt, was eigentlich nur bei Manifesterfall ist oder wenn ihr löschen tut, dann wollt ihr natürlich irgendwann den Platz auch wieder haben und normalerweise wird dann kompaktiert, dass also alte Segment-Dateien gelesen werden und praktisch die Daten, wo noch erhalten bleiben sollen, halt dann in Neue übertragen. Und an der Stelle wird dann halt Daten im Endeffekt die irgendwann mal darlagen, auch weggeschmissen. Also wenn der Angreifen Delet macht, wird es erst mal angehängt, aber sofort, gleichzeitig auch dann gekillt. Wenn ihr Append-Only macht, dann tut ja quasi nur die Delet-Operationen sich merken. Also welche Daten wollte ich alle löschen, die liegen aber zunächst mal alle noch weiter rum. Und wenn das im Append-Only-Modus ist, passiert ja erst mal gar nichts. Ihr könnt ihr dann also ein Rollback machen, dass diese ganzen Delets quasi wieder vergessen werden und alles erscheint wieder. Ihr müsst dann allerdings aufpassen. In der Regel wollt ihr ja selber auch ab und zu mal was löschen, dass das nicht endlos wächst, das Ding. Und sobald ihr halt einen Schreibzugriff macht, wird halt diese Compaction ran gemacht. Und dann würdet ihr möglicherweise die Delet-Operation, die ein Angreifen reingeschmissen hat, dann halt realisieren. Also müsst ihr euch vorher quasi davon überzeugen, dass im Repositori noch der Zustand ist, den ihr gerne hättet, kann man anhand der Hashes der Archive am besten vielleicht machen. Das ist vielleicht so die geeignete Methode. Also wenn der Hasch vom Archiv immer noch dergleiche ist, wie im Sollzustand, dann hat sich an dem Archiv nichts geändert. Ich würde es gerne ab und zu malen, der Testbatterie, die neuesten Backups, auch eine andere Testbatterie, Backupen, die ich dann direkt tue in Schrampe oder so. Sind gemäß das Einzige, was mir einfällt, dass ich muss irgendwie die neue Archive per Fuse machen, und kann dann die gemauten Archive irgendwie wegappen. Oder gibt es da irgendwie direkt ein Weg, was ich vorhin sagen kann, schnell lesen wir den Archiv und schraub schraub ein. Also was es noch nicht gibt, da gibt es nur ein Ticket dazu, ist, dass man so sagt quasi Archiv X von Repo A nach Repo B kopieren. Wer theoretisch machbar ist, ist allerdings nicht ganz trivial, weil die Verschlüsselung ja dann vielleicht doch ein anderer Schlüssel sein soll, gerade irgendwelche Counterprobleme oder sowas zu vermeiden. Was man im Prinzip immer machen kann, ist, dass man euch einfach A-Sync nimmt und einfach das Repo von A nach B synchronisiert, wenn ich einfach nur den gleichen Zustand auf beiden Platten haben will. Gut, ja, das geht mit A-Sync nicht. Ja, da bräuchte ich vielleicht wirklich diese Operation, die es noch nicht gibt. Also wer machbar ist halt relativ aufwendig. Also es ist eigentlich fast genauso aufwendig wie ein Backup zu machen, nur dass man halt die Daten mehr so aus einem Stream gibt, also vielleicht ein bisschen weniger Siegs auf der Platte. Ja, da brauchst du wahrscheinlich noch das, was in diesem Ticket angedacht ist. Also einfach mal das Ticket raussuchen, Kommentat runtermachen, brauche ich oder so. Generell noch zum Thema, weil ich gerade A-Sync von dem Repo von Platte A nach Platte B erwähnt hab, bei dem muss man auch ein bisschen aufpassen. Generell, wenn ihr mehrere Operationen seriell hintereinander schaltet, dann kann es natürlich sein, dass potenziell bei jedem Glied dieser Kette eine gewisse Fehlerwahrscheinlichkeit irgendwo da ist. Und wenn er da eine serielle Schaltung davon macht, dann steigt diese Fehlerwahrscheinlichkeit mit jeder Stufe wieder an. Also dass ich daran Fehler einschläge, daran Fehler einschläge, daran Fehler einschläge. Von daher ist vielleicht manchmal geschickter, nicht jetzt ein Backup auf A zu machen und das mit A-Sync auf B zu kopieren, sondern einfach ein Backup auf A zu machen und unabhängig nochmal ein Backup auf B zu machen. Weil dann habt ihr im Prinzip zwei unabhängige Pfade und ihr habt nicht diese Fehlerfortpflanzung, die da vielleicht auftreten kann. Es könnte ja sein, dass auf eurer ersten Backup-Festplatte vielleicht irgendwas ein Bit kippt. Wenn ihr das halt dann einfach mit A-Sync kopiert, dann habt ihr halt zwei Backups so gekippte Bits drin sind. Und wenn ihr unabhängig zwei Backups direkt von der Datenquelle macht, dann hättet ihr das Problem halt nur auf einer Festplatte. Noch Fragen? Eine Regung in Unklarheiten? Hat nix. Okay, wie liegt man denn so in der Zeit? Eine Stunde haben wir rum. Okay. Ja, beugt der Project? Weiß ich nicht. Also da geht es so generell darum, was wir so für alles Tools verwenden und so. Das hatte ich eigentlich mehr so für Einsteiger und vielleicht Europython-Konferenzen so angedacht. Ich kann mal kurz drüber zappen. GitHub, Sphinx, Askinema, Mailingliste, PyTest, Vagrant, PyEnf, PyInstaller, SetupTools, GpG, wie man sichere Releases macht, Python, Siphon. Ich weiß nicht, ist das für euch interessant? Ansonsten könnte ich alternativ auch Tester anbieten, dass wir noch ein bisschen über Internas reden. Also wer will Project was hören? Nicht so viele. Internas, lieber. Okay, also dann haben wir Internas. Das ist ein Punkt, der regelmäßig aufpoppt. Es gibt ein ganz fundamentales Problem. Dadurch, dass Bauch sehr stark de-dupliziert. Tut er euch natürlich alle Redundanzen entfernen. Also es ist nicht so, wenn ihr 1000 Tarrarchive habt und fünf davon sind kaputt, dann könnt ihr immer noch die anderen 995 Tarrarchive einfach verwenden und die tun dann. Wenn ihr bei Borg Daten verliert im Repository, also angenommen eine dieser Segment-Dateien, geht euch irgendwie hops aus irgendwelchen Gründen, dann kann es natürlich sein, dass ihr in allen Archiven irgendwelche Daten verloren habt, weil das ja nichts doppelt speichert, weil das ja immer auf die gleichen Daten draufreferenziert. Also da müsst ihr ein bisschen aufpassen, dass halt das Speichersystem, wo ihr das drauf schreibt, halt doch so für eure Zwecke ausreichend zuverlässig ist. Also wenn das super wichtige Daten sind, würde ich vielleicht nicht jetzt nur eine Festplatte dafür nehmen, sondern vielleicht eher so mindestens ein ZFS-Mirror vielleicht, dass wenn die eine Hälfte vom Mirror irgendwie Lochfras hat, dass das ZFS dann halt erkennt, okay, die Daten auf der anderen Seite sind die besseren und sich dann die richtigen raussuchen kann. Da kommt öfters mal der Wunsch dann auf, ja, baut doch irgendwie Arrow-Correction-Codes oder so was ein. Das ist ein bisschen ein Problem, weil da muss man sich halt überlegen, was will ich eigentlich genau mit diesem Fehlerkorrekturverfahren erreichen und welche Fälle will ich da erfolgreich damit behandeln. Dieser ganz simple Fall, ich speichere jetzt ein Datenblock weg und hänge irgendwo vielleicht so ein bisschen an der anderen Stelle noch einen ECC-Code extra. Der könnte mir natürlich ein Bitfailer korrigieren, wenn da so ein einzelnes Bit flippt, nämlich den ECC-Code, kann ich dieses Bit korrigieren, ist wieder alles prima. Das Problem ist aber halt bei Festplatten, wisst ihr ja selber, da kann es auch durchaus auch mal sein, dass ein ganzer Sektor weg ist oder die ganze Platte stirbt oder die SSD plötzlich der Kontrollern-Geist aufgibt und dann habt ihr halt auf einmal viel mehr Daten verloren, wie jetzt irgendein so ein kleiner ECC-Code euch korrigieren könnte. Und deshalb ist auch dieses Ticket immer noch offen und so der momentane Stand der Dinge ist, eigentlich, wir lassen das lieber, anstatt falsche Dinge zu versprechen. Wenn wir sagen, ja, das Ding kann error-correction, dann denkt jeder, ja, gut, das wird's schon korrigieren, aber wenn ihr dann halt ein Fehler habt, der halt über die Korrekturmöglichkeiten hinausgeht, dann habt ihr halt vielleicht falsche Hoffnung gehabt und danach kriegt ihr eure Daten doch nicht wieder. Deshalb wollen wir das also lieber lassen, als jetzt irgendwas falsches zu versprechen. Was auch ein bisschen problemisch borg ist, ja, eigentlich ein ganz normales Anwendungsprogramm. Das ist also nichts, was irgendwie tieferen Einblick hat ins Datei-System oder welche Datei jetzt, auf welchem Sektor irgendwie rumliegt. Das heißt, wenn wir versuchen würden, quasi da die Daten hinzuschreiben und da unsere Korrekturinformationen, wir könnten uns nicht wirklich verlassen, dass die nicht nachher doch so da liegen und beide kaputt sind. Also das ist so ein bisschen ein Problem, das kann ja durch ein System, also ZFS zum Beispiel, kann man so mit Mirror betreiben oder auch mit Copies gleich zwei, wenn man nicht zwei Medien hat. Und ZFS kann wohl eher wissen, aha, das speichere ich jetzt da irgendwo an Anfang hin und das speichere ich ins Ende hin, wobei das wahrscheinlich auch nur bei Festplatten so wirklich stimmt. Wenn ich jetzt eine SSD hab, wo der Controller mir einfach will, irgendwo die Daten über die Flashblocke verteilen, hab ich im Prinzip ja eigentlich gar nicht keine Kontrolle mehr, welche Daten jetzt gerade im gleichen Flashblock drin liegen, der gleichzeitig stirbt und welche jetzt wirklich getrennt irgendwo liegen. Das heißt, da gibt es ganz fundamentale Probleme, die man sowohl nicht auf Applikationsebene lösen kann. Was man auch machen kann, ist natürlich ein normaler Rate Mirror. Da muss man sich dann halt darauf verlassen, dass die Festplatte halt einen Failercode auswirft, wenn der Sektor kaputt ist. Das kann natürlich auch in manchen Fällen schiefgehen, wenn quasi der ECC Code nicht triggert. Also da werden Fälle denkbar, dass quasi der Rate Controller sich gar nicht entscheiden kann, was ist jetzt eigentlich korrekt und was nicht, oder dass der das gar nicht merkt, dass da überhaupt ein Problem gibt. Also ZFS ist da etwas besser, weil die machen ja wirklich Hashes über die Datenblocke und da kann man also dann mit sehr hoher Sicherheit sagen, ja, das ist die richtige Kopie und die stimmt offensichtlich nicht. Es gibt da noch andere Software-Lösungen. Also generell, ihr könnt natürlich Software-Rate auch machen, also Linux-Körner-Software-Rate zum Beispiel. Es gibt in diesem Ticket, wo ich erwähne, Nummer 225 gibt es so eine ganze Liste von irgendwelchen Software-Tools und Layern, die man vielleicht verwenden könnte. Teilweise sind es Sachen, die ihr als Administrator machen könnt, weil das einfach halt ein Fallsystem oder irgendein Layer ist. Teilweise sind es auch Bibliotheken, die man vielleicht in Borg dann einbauen könnte, wenn man so diese grundsätzlichen Probleme irgendwie gelöst kriegt. Aber das ist also noch eine offene Diskussion und wie gesagt, der letzte Punkt war mir halt relativ wichtig, dass wir nicht irgendwie Versuche machen und Versprechungen machen, die nachher dann doch nicht stimmen. Das ist jetzt für die Version 1.2 so ein bisschen das Thema, die die Krypto noch ein bisschen zu modernisieren. Grundproblem ist ganz am Anfang, ist, dass Schad256 halt ausgeguckt worden. Ich vermute mal wegen der Länge vom Hash, weil der halt ausreichend lang ist, aber nicht zu lang. Was damals übersehen wurde, ist, dass Schad256 relativ langsam ist. Wenn man eine 64-Bit CPU hat vor allem, also falls ihr mal selber was machen müsst, nimmt einfach Schad512, nicht 256, der ist deutlich schneller. Denkt mal so nicht, normalerweise denkt man immer, mehr Bitz, mehr Aufwand, aber es ist halt nicht so, Schad512 ist deutlich schneller. Und wenn ihr die ganzen Bitz nicht braucht, dann könnt ihr einfach die Hälfte wegschmeißen und nur 256 davon nehmen, dann habt ihr einen gleichen Output quasi. Genauso ist natürlich AIS auch ein bisschen langsam, wenn man keine Hardwarebeschleunigung hat. Und deshalb wollen wir da also jetzt so ein paar modernere Verfahren verwenden. Also Poly1305 für die Authentifizierung, Chacha für die Krypto, Blake2 ist ein recht netter Hash oder Blake2B insbesondere. Also praktisch ähnlich von den Eigenschaften wie jetzt irgendwie so ein Chacha-Hash, aber halt deutlich performanter. Das Krypto übrigens in der 1.1, sondern der kann Blake2B-Repos generieren. Da habt ihr also ein bisschen weniger Last auf der CPU und ein bisschen schneller. Dieser Schad512-256, das ist also diese abgehackte Variante. Das kann man vor allem dann verwenden, halt wenn man jetzt keine Zusatzlibrin noch reinziehen will. Was leider auch ein bisschen schief lief. Attic hat sich damals für den ganz normalen CRC32 entschieden, der also genauso heißt, es gibt einen ähnlichen CRC32, der CRC32C heißt und der wer bei Intel CPUs Hardwarebeschleunigt, aber halt nicht der andere. Wir haben das inzwischen so gelöst, wir haben eine etwas optimiertere CRC32-Bibliothek, wo halt einfach so was nicht SSE, Loop Unrolling und alles Mögliche macht, um also die CRC32-Berechnungen etwas zu beschleunigen, auch wenn man nicht diesen speziellen Hardware-Support hat. Das Problem ist, wenn man das ändern würde, das wäre ein Breaking Change, also das wäre halt was für die Version 2.0, aber dann passt halt nichts mehr. Die CRC ist nur für repository-Ebene verwendet, dass quasi der repository Server einen lokalen Check machen kann, ohne den Krypto-Key haben zu müssen, ob die ganzen Segmenten, wo da drin liegen, ob die alle noch korrekt sind. Also so normale Bitflips von einer Festplatte oder defekte Sektoren oder irgendwas, kann man damit finden. Man kann nicht gezielte Angriffe damit finden, also man kann auch Daten so verändern, dass die CRC32 das nicht merkt. Aber das Nette ist halt, ich muss für einen ganz simplen Check, muss ich nicht alle Daten über das Netzwerk pumpen, sondern ich kann dem Repo Server sagen, da check mal dein Repo. OpenSSL 1.1 ist jetzt auch schon ein Weile draußen, hat auch ein bisschen Aufwand gemacht, weil die da einige Sender API geändert haben. Haben aber schon seit langer Zeit Support dafür. Also wenn eure Distribution nur OpenSSL 1.1 hat, ist kein Problem, können da einfach benutzen. Und was ja nett ist, die haben jetzt auch ASOCB drin. Das ist von den Eigenschaften so ähnlich wie Gcm, nur noch ein bisschen schneller. War aber früher so ein bisschen verpönt, weil es da Patente drauf gibt. Der Patent-Inhaber hat aber so eine recht generelle Lizenz jetzt an freie Softwareprojekte und insbesondere auch OpenSSL gegeben, so von wegen, können da benutzen, ist kein Problem. Bei Gcm ist es so ein bisschen umstritten dieser Modus. Also es liegt noch nichts Konkretes vor, aber so diverse Kryptografen haben so leichte Bauchschmerzen so von wegen, das wäre etwas fragil, die Konstruktion. Und es gibt wohl auch Hinweise, dass das nur dann sicher ist, wenn es hardwarebeschleunigt ist. Und wenn man es per Software macht, dann so ein bisschen weniger. Also es ist wohl etwas Geschmacksache, sage ich mal. Deshalb, wenn wir vielleicht auch einfach mehrere unterstützen oder wir machen vielleicht auch nur Cha Cha Poly, um das Problem zu vermeiden. Play to Be, wie gesagt, kommt schon. Und ich habe so ein Pull Request offen, das ist dieser 1034, wo ich schon seit Monaten dran arbeite, dieses Krypto-AP, die interne auf IAD umzustellen. Also wenn jemand in Krypto-Tief drin ist, darf er sich das auch gerne mal angucken, ist aber noch nicht gemärscht. Also das werden wir erst, wenn wir 1, 2 dann anfangen, werden wir das merken. Die Krypto-Keys und generell so Keymanagement ist gerade auch nur so ein bisschen simpel. Ihr habt halt pro Repositori einen symmetrischen AES-Key. Und ja, das war's dann halt, es gibt nicht mehr. Und es gibt noch diesen Counter-Werte, der halt immer weiter hochgezählt wird. Aber das war's dann halt, es hat so diverse Probleme. Also zum Beispiel, wenn man jetzt Multithreading machen will, diese Counter-Werte verwalten, da muss man ein bisschen aufpassen, da könnte vielleicht was schiefgehen. Also das wollen wir generell so ein bisschen monetisieren, dass wir vielleicht diese Session-Keys haben und dass wir dann auch diesen Counter-Wert nicht wegspeichern müssen, so dass wir dann halt einfach bei jeder Session immer bei Null starten. Weil wenn wir immer neu hinmachen, ist das ja dann egal. Es gibt auch Tickets, wo irgendwas mit asymmetrischen Krypto drinsteht. Das ist aber wahrscheinlich noch ein bisschen fernere Zukunft, dass man also irgendwie die symmetrischen Schlüssel dann nochmal asymmetrisch irgendwie entkrypftet. Es ist schon ein bisschen schwierig, weil ihr braucht ja generell für Repository Zugriff, müsst ihr das entschlüsseln können. Also man kann jetzt nicht einfach sagen, okay, ich hab das für die Backups und dann ist gut. Ihr müsst ja beim next Backup-Alt zumindest die Archiv-Liste vom letzten Lesen können, dass da das aktuelle Archiv hinten rangehangen werden kann. Also von da ist das mit asymmetrischen nicht ganz trivial. Dieses höchste Wertspeichern übrigens, da fällt mir grad noch ein, wir haben da schon was gefixt. Ich weiß jetzt nur nicht, ob wir es in 1-0 oder 1-1 oder Beiden drin haben, also in 1-1 auf jeden Fall, 1-0 bin ich mir grad nicht sicher. Wir haben das Problem, was ich vorhin erwähnt hab, mit diesen abgebrochenen Backups, haben wir schon gefixt. Und zwar, was er jetzt macht, ist, wenn der Counter-Werte haben will, dann macht er quasi wie eine Art Reservierung. Er sagt also, okay, der Counter-Wert, wo ich weitermachen will, ist, was war sie, eine Million. Und ich will jetzt also Backup, also ich brauch da ein paar, also ich mach jetzt mal eine Reservierung bis 2 Millionen. Und diese Reservierung, die wird quasi committed und dann legt er erst los mit Verschlüsseln. Und wenn er dann abricht, dann ist die Reservierung ist trotzdem weiterhin da. Das heißt, er würde nie wieder den Bereich zwischen 1 und 2 Millionen an Counter-Werten noch mal benutzen, sondern würde ihn dann halb bei 2 Millionen weitermachen. Dann gehen halt ein paar verloren, aber das ist immer noch besser, wie wenn man diese Counter doppelt benutzt. Was auch noch ein bisschen unhübsch ist, wenn ihr automatisieren wollt, könnt ihr natürlich nicht die Pass-Frays eintippen. Das heißt, die steht üblicherweise halt in irgendeinem Skript drin, wo eine Environmentvariable gesetzt wird. Da müssen wir auch nochmal überlegen, ob das geschickter geht. Was ich auf jeden Fall halt beachten müsste ist, dass ihr die passenden Zugriffsrechte auf dieses Skript drauf macht, also, dass das nur Ruth lesen kann, nicht dass da jeder reingucken kann und nach ihrem Repo Schlüssel weiß. Meine Frage, das schreibt, ich glaube, da haben wir sogar 2 Sachen. Also, der Kleint schreibt es in seinen lokalen Cash rein. Und das bleibt da einfach liegen und das macht er im Prinzip bevor überhaupt anfängt, irgendwas zu verschlüsseln. Ja, ich glaube, es wird auch noch so ein, ich glaube, er tut sowohl den Server fragen als auch in den kleinen Cash reingucken und nimmt dann, glaube ich, den maximalen Wert von beiden. Also, wenn die da irgendwie unterschiedlicher Meinung sind, tut er lieber ein paar Counter-Werte wegschmeißen, als doppelt zu verwenden. Also, der Code ist nicht so ganz trivial. Schausch vielleicht mal rein. Aber ich hatte so der Eindruck, dass der nach Möglichkeit versucht, alle Fälle zu betrachten. Also, wenn der Cash zum Beispiel verloren ging, hier vom Kleint, dass er auch diesen Fall betrachtet, dass man dann halt den Wert vom Server nimmt. Wenn du überhaupt keine Informationen mehr hättest, dann wird es natürlich schwierig. Wenn du lokalen Cash verlierst, dann gut und hast keine Informationen mehr, außer das, was vom Server kommt. Aber du hast ja eben repository manifest, hast ja quasi einen Commit gemacht und hast authentifizierte Daten reingeschrieben und da ist auch dieser letzte Counter-Wert drin. Also, musst mal gucken, ob du den Loch findest. Aber das ist gerade diese Security-Review, was ich meinte. Also, wir gucken da halt, wir haben drei Entwickler, die sich so halbwegs mit Krypto auskennen und die gucken also gegenseitig ein bisschen, aber es ist nicht auszuschließen, dass nur irgendeine Lücke drin ist. Also, schau vielleicht einfach mal rein. Keypey und irgendwie Keymanagement oder sowas, da ist der ganze Kram drin. Wenn du da einen lokalen Cash verloren hast, dann vielleicht ja. Wenn du den noch hast, würde er ihn nicht akzeptieren, weil er dann merkt, das ist alter Kram. Also generell ist halt, wenn du selber gar nichts mehr weißt und hast nicht all viele Optionen, außer halt das zu nehmen, was du kriegst. Das ist so ein ganz fundamentales Problem. Aber da kannst du halt auch eine begründete Hoffnung haben, dass nicht beide Fälle vielleicht gleichzeitig aufdrehen, du den Cash verlierst und nicht deinen Server bescheißen will. Aber ja. Also die heiklen Sachen haben ja unter Punkt, Konfig, Borg und so weiter drin. Also da liegen sowohl die Keys, wenn du sie lokal hast, als auch diese Kryptosachen, irgendwelche Counter oder sonstige Informationen. Der eigentliche Cash kann übrigens bei Borg relativ groß werden. Also da tut er sich so auch die Archivindices immer wieder so ein bisschen merken. Aber die ganz wichtigen Sachen sind nicht im Cash drin, sondern im Verzeichniskonfig. Also wenn ich Cash gesagt habe, das war ein bisschen unpräzis, also eigentlich in dem Konfigverzeichnis liegen die wichtigen Sachen drin. Und da kann man auch reingucken, die Dateien sind üblicherweise Textdateien, also ist durchaus lesbar, was da drin ist. Mal gucken. Mal noch andere Fragen. So, das sind, glaube ich, durch. Ja, Rammverbrauch ist auch noch so ein Thema. Also generell, Ethik hat viel mehr Rammverbraucht wie Borg durch diese Junkgröße, weil die halt viel kleiner waren, dadurch halt viel mehr Junks verwaltet werden mussten. Und die Junks würden alle im Prinzip in der Hashtabelle gehalten. Also die liegen im Ramm während des läuft. Und es ist ja, sagen wir so mit einfachen Mitteln zumindest nicht besonders toll anders machbar, weil halt die Zuggriffe doch relativ random sind und eine Hashtabelle ist da eigentlich schon eine ganz gute Methode, das zu machen. Wenn man das Ding jetzt halt auf Platte lagern würde, jedes Mal einen Plattenzugriff machen würde, dann würde zumindest eure so ein quasi incrementelles Backup würde dann deutlich langsamer laufen, weil er da halt sehr viele Zuggriffe machen muss auf einen Schlag, habe ich das schon oder habe ich es nicht. Bei Borg Z1.0, also wie gesagt, durch die größere Junks deutlich weniger Rammverbrauch, aber halt der Junksindex, der Fileindex und der Repoindex, die sind im Prinzip halt im Ramm. Das heißt so ein Raspberry Pi 1 mit 512 MB kann man zwar nehmen für Borg, aber man muss sich halt klar sein, wenn ich das halt dann mit 10 Terabyte großen Repositories kombiniert, dann ist wahrscheinlich doch der Ramm alle. Also die der Rammverbraucht steigt quasi mit der Zahl der Junks an. Und auch ein bisschen mit der Zahl der Dateien, die ich in der Eingabe hab. Also wenn ich sehr viele kleine Dateien hab, kann das also auch bei relativ kleinen Repos vielleicht schon ziemlich viel Ramm verbrauchen. Wobei ich so normalen Servern, wo ihr rechtlich Ramm drin habt, ist das in der Regel kein Problem. Aber wie gesagt, wenn ihr halt NAS-Divises habt, wo eher sparsam bestückt sind, also so normale, kommerzielle, fertige Dinge, wo halt ein halbes Gigabyte Ramm nur haben oder irgendwelche. Single-Board-Computer, dann könnt ihr also in das Problem reinlaufen. Der meiste Rammverbrauch findet auf dem Kleinstadt. Die Repository-Seite ist etwas sparsamer, weil halt die nur den Repository-Index geladen hat. Wenn das allerdings beides die gleiche Maschine ist, also wenn ihr nicht klein selber fahrt, sondern im Fall zu stehen, dann summiert sich es natürlich, dann hat da die ganzen Indizes im gleichen Prozess drin. In der Dooku-Gezibbing ist eine Formel, wo man das so ein bisschen überschlagen kann. Also ihr müsst halt wissen, wie viele Dateien habe ich und wie viele Datenmengen. Dann kann man so eine grobe Überschlagsrechnung machen. Es ist aber relativ schwierig, genau zu berechnen, weil das halt dann immer so ein bisschen vom Chunking noch abhängt und wie lange ist jetzt jede individuelle Datei und so. Also ist etwas schwierig zu berechnen. Dieser Rammverbrauch war übrigens auch der Grund, warum wir diesen selbstgeschriebenen Hashtable-Code haben. Wir hätten ja einfach ein Python-Dictionary nehmen können. Das ist im Prinzip ja auch ein Hashtable. Aber dadurch, dass wir das selber geschrieben haben, können wir praktisch sehr kompakt ablegen. Da liegt halt einfach vorne der Hasch, also die ID, und dahinter liegen einfach 3 Integer-Werte im Ramm. Und dann kommt praktisch der nächste ID wieder 3 Integer-Werte. Und so liegt das alles hintereinander in einem Block im Ramm drin. Wenn ich jetzt Python genommen hätte, dann hätte ich da noch einen Haufen Zusatzverwaltungsinformationen gehabt. Rammverbrauch wäre wahrscheinlich zwei oder dreimal so hoch. Von daher wollten wir das halt vermeiden. An der Hashtable wird übrigens gerade auch gearbeitet. Das ist also ein relativ einfaches Verfahren, also ohne irgendwelche Linked-Lists oder so, wo also alles in einem Block verwaltet. Und das frühere Verfahren hat im Prinzip einfach lineare Suche dann halt gemacht, wenn es eine Kollision hatte, um ein freies Plätzchen zu finden. Und wir haben einen Pull-Request offen, wo ein Entwickler dieses Robinhood-Hashing quasi implementiert hat. Das ist so eine etwas geschickterere Methode, wie man vermeiden kann, dass diese Suchketten-Zugriffe quasi zu lang werden. Ist ganz interessant. Das könnte vielleicht auch noch ein bisschen Review gebrauchen. Generell hatte ich so der Eindruck, dass diese Geschichte mit Hashtabellen durchaus noch in der Forschung so ein bisschen ist. Und dass sich da durchaus noch einiges tut. Also so manche Papers, wo ich da gefunden habe, waren durchaus aus den letzten 10 Jahren oder so, nicht schon uralt, wie so diverse andere Algorithmen. Und da ist auch immer so ein bisschen Blackmagic dabei, bei Hashtabellen. Das ist alles nicht so ganz präzise, und auch manchmal nicht ganz einfach voraussagbar, was jetzt eigentlich passiert. Und vor allem, wenn man da Benchmarking machen will, muss man schwer aufpassen, dass man da nicht irgendwie falsche Schlüsse zieht, weil sobald ich den Algorithmus fürs Haschen halt ändere, tue ich halt selbst mit den gleichen Eingabendaten halt einen ganz anderen Zustand produzierende Hashtabellen. Das kann dann sein, dass der schneller ist, aber dass er halt für andere Daten wiederum langsamer wäre. Also das ist da sehr schwierig zu entscheiden, ob ich jetzt eigentlich was optimiert habe, oder ob es einfach nur Zufall war oder durch die andere Verteilung entstanden ist. Ein Hinweis noch, das haben wir erst vor kurzem, sind wir uns da so bewusst geworden, der Code, der die Indexpfeils lädt, der ist auch in C-Code mit drin, und der hat leider F-Reed und F-Ride benutzt, also die 32-Bit-Aufrufe, nicht die 64-Bit-Aufrufe. Das heißt, der kann mit nicht mehr als 2 Gigabyte großen Indizes arbeiten. Also die Hashtabelle darf nicht 2 Gigabyte überschreiten. Wenn man das umrechnet auf Chunks, bedeutet das so ungefähr 35 Millionen Chunks. Also die meisten Leute haben das noch nicht erreicht, aber wenn ihr zum Beispiel eine unheimlich große Menge winziger Dateien hättet, könntet ihr das relativ leicht erreichen. Also einer hat es schon geschafft, der hatte irgendwie so eine Map aus lauter winzigen Tiles zusammengesetzt, und hatte da irgendwie 300 Millionen Stück halt, und der hat dann gemerkt, ob das geht nicht. Also für normale Rechner und so ist kein Problem, und wenn ihr auch ein bisschen größere Dateien habt, aber vielleicht auf die Größe ein bisschen gucken. Wir zeigen auch die Anzahl der Chunks, die im Repositori sind, zeigen wir an. Also da ist momentan noch ein Limit auf 35 Millionen ungefähr. Im 1.1 ist das schon gefixt dieses Problem. Wir wollten jetzt aber erst in der 1.1-Version noch so ein bisschen testen, und erst dann den Backport auf 1.0 machen. Also in 1.0 wird das in einer der nächsten Version dann kommen. Aber ich bin bisher eher selten aufgetreten. Also einer oder zwei Leute haben das Problem bisher gefunden. Da hatte ich jetzt schon ein bisschen was erwähnt dazu. Also Closed hashing ist das... Ich komme immer durcheinander bei closed and open hashing. Das ist so ein bisschen unintuitiv irgendwie. Aber das ist halt das, wo alle Buckets in einem RA liegen, ohne Linklisten außen dran hängen zu haben. Dann linear probing momentan, bald vielleicht Robin Hood. Was wir übrigens in jüngster Zeit auch in der 1.0 schon optimiert haben. Also die, wo es benutzt haben, haben es vielleicht auch manchmal schon live gesehen. Manchmal hat immer so der Eindruck, dass es ein bisschen lahmt. Und das konnte dann passieren, wenn der auf der Hashtabelle sehr viele Löschzugriffe und wieder was reinfüllen und wieder Löschen und wieder was reinfüllen. Dann entstehen ja in dieser Hashtabelle mit diesem Verfahren so genannte Tomstones. Also praktisch Plätze in der Hashtabelle, wo eigentlich nichts mehr drin liegt, aber wo der Hashtagalgorithmus, also der, wo dann das probing macht, wo der trotzdem weiß, dass da mal was lag, also dass er da quasi drüber lesen muss, wenn er was sucht. Und das Problem war, wir haben zwar die Hashtabelle größer gemacht, wenn die Anzahl der Einträge, also der gültigen Einträge, bestimmtes Limit überschritten hatte. Wir hatten aber die Tomstones nicht mit berücksichtigt. Das heißt, es konnte passieren, dass die komplette Hashtable voll war, also zum Teil halt mit Validen-Einträgen und der Rest war alles mit diesen Grabsteinen voll. Und dann ist das Ding super langsam geworden, weil es dann praktisch immer die komplette Hashtable komplett durchsuchen hat müssen. Und wenn die halt groß ist, dauert es halt ewig. Das ist gefixt worden, also die letzten Versionen jetzt, oder weiß ich nicht, entweder die letzte, wo schon Relistisch oder die, wo jetzt in Kürze rauskommt, da ist das gefixt. Also da läuft es dann ein bisschen schneller. Was auch noch fehlt, ist so ein bisschen Instrumentation-Code in der Hashtable, das ist halt C-Code. Von daher ist der nicht ganz so einfach zu handhaben, wie jetzt Pfeifen. Also wenn man so Performance-Messungen machen will, müsste man da eigentlich mehr Statistik noch irgendwie mitführen. Aber was dann, oder ich arbeite auf die Performance-Auswirkungen hat, also das ist alles so ein bisschen schwierig. Aber wenn sich also jemand für Hashtabellen interessiert, Pull-Request mal anzugucken mit Robinhood-Hashing, dann müsste man auch demnächst mal Merch'n, wenn da mal falsche Richtung. Hier ist noch ein bisschen was zu dem Sync, das hat er mal vorhin schon ein bisschen angesprochen. Also vor allem, wenn man halt mehrere Clients hat, die ins gleiche Repo reinsichern wollen, dann muss man halt das immer wieder neu synchronisieren. Und der versucht zwar mit seinem lokalen Cache, das ein bisschen zu optimieren, also vor allem, wenn man eine langsame Übertragungsstrecke zum Repositori hat, also wenn das alles irgendwie über DSL oder so drüber geht, dann hat er diesen lokalen Cache. Das Problem wiederum vom lokalen Cache ist aber, das sind N-Dateien, wo für N-Archive halt die Hashtable fertig drin liegt. Das heißt, wenn ihr wahnsinnig viele Archive hat, wird auch euer lokaler Cache wahnsinnig groß. Also es könnte durchaus Gigabytes werden. Es gibt einen kleinen Hack, wie man das vermeiden kann. Man kann einfach dieses Cache Directory durch ein File mit gleichem Namen ersetzen, dass an der Stelle kein Directory machen kann. Dann lässt er das mit diesem Caching. Allerdings ist dann halt das wiederum langsamer, weil er dann halt alles von Remote lesen muss. Also da ist auch das übliche Zeitversuchsverbrauchproblem da. Ja, für Entwickler vielleicht nur interessant, der letzte Punkt für die Statistik müssen wir immer so ein bisschen die Größe mitführen. Also wie groß ist so ein Chunk? Beziehungsweise, wie groß ist der komprimierte Chunk? Nur dann kann man halt diese ganze Statistik-Werte anzeigen. Es hat sich rausgestellt, dass es ein bisschen ungeschickt teilweise gemacht worden ist im ursprünglichen Design. Also zum Beispiel, wenn ich halt in die Archive die komprimierte Größe mit rein schreibe und ich tue das Ding dann einfach durch so ein Recreate nochmal neu erzeugen Beziehungsweise angenommen, ich wollte die Blöcke euphorfrisch komprimieren. Da ist jeweils so ein Type-Bite dran, wo er sieht, welche Kompression das ist. Dann ist aber halt schlecht, wenn in meinem Archiv-Datenstrom halt der komprimierte Größe mit drin steht, weil das stimmt da nicht mehr überein. Also da wäre es quasi geschickter gewesen, wenn man das an der Stelle weglassen hätte. Aber das ist halt momentan leider auch drin. Und dieser Schnellig-Synchronisierungs-Modus, wo ich vorhin erwähnt hab, wo einfach das Repository fragt, was habe ich alles für IDs im Repository? Der Repository-Index hat keine Informationen über die komprimierte Größe. Also die sind überhaupt nicht, das sind was nicht, die unkomprimierte Größe, die ist überhaupt nicht greifbar. Die komprimierte Größe könnt ihr mir an der Länge vom Datensatz sehen und dort davon ableiten. Aber ich hab da generell nicht alle Informationen, die ich eigentlich bräuchte. Also um den lokalen Index komplett aufzubauen. Von daher ist das also nur für diesen einen Modus interessant, wenn ich halt ein Archiv anlegen will und eigentlich nur wissen muss, habe ich den Block schon oder habe ich ihn noch nicht. Aber irgendwie eine Statistik-Sache kann ich nicht machen mit der Methode und löschen wie gesagt auch nicht. Okay, das war jetzt so ein bisschen tiefer rein. Wir könnten noch oder generelle Frage, wer programmiert in Python oder in C oder in Seifen. Ja, doch durchaus einige, ja. Also ich kann auch anbeten, dass wir ein bisschen im Code herum gucken, was da so alles gibt. Schon halt für die Software-Entwickler vor allem interessant oder für die Leute, die ein Review vielleicht auch machen wollen, was die Security angeht. Ich nenne vielleicht gerade mal die Größe wegen. Ja, es gibt da ein Ticket dazu, schon seit einiger Zeit. Es gibt ja relativ viele neue Verfahren. Also es gibt von Facebook, dieses ZSCD, es gibt Brotli, von Google und nochmal ein paar wahrscheinlich. Das Problem ist immer ein bisschen, wir unterstützen ja sehr viele Betriebssysteme, Plattformen, CPU-Architekturen und wenn wir jetzt praktisch irgendwas einbauen, dann will man den Fall vermeiden. Ich habe auf Plattform X ein Backup produziert. Ich kann es aber auf Plattform Y noch nicht lesen, weil da das Kompressionsverfahren fehlt. Also von da muss ich eigentlich das über alle Plattformen haben. Also die ganz neuesten Verfahren, da scheitert es oft dann da dran, dass einfach die Library dafür nicht da ist. Außerdem will man natürlich auch immer so ein bisschen abwarten, bis so die gröbsten Bax mal draußen sind, die vielleicht am Anfang noch existieren und dann muss die Lizenz natürlich auch irgendwo kompatibel sein und das sollte nicht irgendwie Patente in der problematischen Form drauf sein. Also wenn eine Patente drauf ist, muss eine Lizenz da sein, wo es halt frei gibt. Also da gibt es viele Punkte, wo man berücksichtigen muss und deshalb sind wir nicht so arg erpicht drauf, jetzt jedes Kompressionsverfahren sofort einzubauen, was uns da auf dem Rad erscheint. Es ist jetzt aber nicht ausgeschlossen, dass mir vielleicht in einem Jahr, wenn überall ZSTD als Library vorliegt, dass wir das dann einbauen. Am momentanen sagen wir halt, wir haben eine recht gute Abdeckung, wir haben ein super schnelles Verfahren, das ist LZ4, wir haben ein zwar so mittelbrechtig komprimiert, das ist halt ZLIP und wir haben ein zwar sehr stark komprimiert, das ist LZMA. Klar, ZSTD wäre noch von der Geschwindigkeit und Kompression noch ein bisschen besser in manchen Situationen, aber wie gesagt, das ist halt noch relativ frisch alles und wir müssen halt warten, bis die Distributionen das haben und vor allem auch so die Stable-Releases, die haben ja manchmal eh so ein bisschen ältere Sachen also da müssen wir einfach ein bisschen ein bisschen zuwarten, wir dürfen dann nicht zu schnell das Zeug requieren und das ist also in diesem einen Ticket ein bisschen ausformuliert, also wenn du nach Kompression und Policy suchst, findest du es, also ist natürlich klar, dass ein da ein bisschen in den Fingern juckt, dass man da immer das Tollste Neustil irgendwie haben will, aber es macht halt ein bisschen Probleme und wenn wir jetzt halt irgendwas einbauen würden, wo halt fünf Distributionen dann keine Pakete machen können, weil sie halt erst mal was anderes noch brauchen, das wäre halt irgendwie auch blöd. Aber wir haben es auf dem Radar, also ich denke mal so in der Zukunft ist das durchaus ein Thema, dass man da noch was dazu macht. Es ist übrigens nicht jedes Verfahren interessant, was irgendwo spektakuläre News produziert, weil wir haben ja immer diese ungefähr 2 Megabyte großen Chunks, also Verfahren, die jetzt zum Beispiel darauf basieren, dass sie wahnsinnig viel Daten betrachten können, also mehr als 2 Megabyte und nur dadurch besonders Toll sind, die bringen uns nix. Also das muss auch mit 2 Megabyte irgendwie gut komprimieren oder andere Verfahren, die nur auf bestimmten Dateitypen arbeiten können. Die bringen uns wahrscheinlich auch nix, weil wir ja nicht komplette Dateien komprimieren, sondern immer nur diese Brocken. Das heißt, der Kompressionsalgorithmus sieht ja nicht die komplette Dateien, kann keine Spezialgeschichten machen, sondern würde nur irgendwelche wilden Brocken sehen. Also das sind so ein bisschen die Probleme halt, die es da in dem Bereich gibt. Von daher also nur manche und auch mit so ein bisschen Verzögerung, dass halt keinen Stress gibt, der Wägen. Noch Fragen? Ja? Ja. Ja, wenn du einen Simlink machst, der auf den Directory zeigt, dann ist das okay, dann tut das ja ganz normal. Wenn du eine langsame Leidung hast, wenn du komplett lokalisch gewinst, dann ist es vielleicht nicht so arg viel. Vielleicht müsste man messen, das hängt von vielen Parametern ab. Wenn er den Cash hat, passiert im Prinzip Folgendes, er hat dann für jedes einzelne Archiv, also für jedes einzelne Backup, was du gemacht hast, hat er eine fertig gestrickte Hashtable einfach als Dump auf der Platte liegen. Also die braucht er im Prinzip nur reinlesen, dann kann er mit der Hashtabelle arbeiten. Was er aber halt machen muss, er muss halt gucken, welche Archive sehe ich momentan im Repository und dann muss er sich die passenden Caches rauspicken und die alle zusammen merken. Und dann hat er praktisch den globalen Überblick, welche Chancs gibt's, welche sind wie oft referenziert und so weiter. Man muss aber praktisch in Hashtabellen merken zu einer. Also reinlesen, merken, das sind die Operationen. Und beim Merken kann natürlich passieren, dass die Hashtable anwächst, dann muss er halt nochmal reallokiert werden und nochmal umgefüllt werden und so weiter, also das kann auch ein bisschen dauern. Wenn man diesen Cache gar nicht hat, weil man diesen Hack gemacht hat, ich leg da einen Pfeil an und der kann da keinen Cache machen, dann passiert Folgendes, dann macht er halt das Repository auf und geht ein Archiv nach dem anderen durch, liest den kompletten Metadatenstrom rüber, entpackt die Metadaten, entschlüsselt sie auch, dekomprimiert sie und so weiter und tut dann halt anhand dieser Metadaten eine Hashtabelle aufbauen. Also dieses viele Hashtabellenmörschen entfällt dann, weil er halt das gleich am Stück halt dann macht, aber halt er muss halt dafür mit diesen ganzen Metadaten einzeln rumfrickeln. Also kann ich jetzt schlecht sagen, kann in manchen Fällen langsamer sein, vielleicht auch wenn das eine super schnelle CPU hast ein sehr schnelles Storage, vielleicht auch schneller. Ja, ja klar, also er muss Metadaten quasi lesen, entpacken, entschlüsseln und dann hat er quasi halt die Einzelinformation und die muss er dann halt in die Hashtabelle eintragen. Er hat nicht diese großen fertigen Hashtabellen, die er noch zusammenmörschen muss. Entschlüsselung ist ein gutes Stittwort. Die Daten im Cash unverschlüsselt, wenn man die Backup-Petate tut, dann habe ich eine Metadaten... Oh ja, das ist ein Punkt. Das sollte man vielleicht berücksichtigen. Jetzt müssen wir uns gerade überlegen, wie stark die Auswirkungen sind. Also wenn du Entschlüsselung anhast, sind ja die IEDs HMAX. Also die IEDs hättest du eh im Repository sichtbar. Das kannst du nicht vermeiden. Die stehen auch im Repository Index. Also da wäre nix verraten, zusätzlich. Was zusätzlich halt drinsteht, ist der Referenz-Count. Kann man es vielleicht auch nicht so viel damit anfangen, außer dass mal die beliebtesten Chunks eine Hitliste machen könnte. Und dann steht halt noch die komprimierte Größe und die plaintext Größe drin. Aber da das ein Gesiedet der Chunker ist, wo nicht überall gleich chanken würde, also wahrscheinlich keine wilden Auswirkungen. Also glaubt der, verrät man jetzt nix, was nicht eh schon sichtbar ist. Also von daher denke ich mal, kannst du das machen. So, sonst keine Fragen. Ich hab hier gerade mal den Code aufgemacht. Ach ja. Aha. Ja. Mhm. Wart vielleicht mal eine kurze Sekunde. Man hat es jetzt auf dem Ton nicht richtig drauf. Ich wiederhol's noch mal kurz. Also kleine Success-Story von Barcula Barrio S. Umgestellt auf Borg und ungefähr Faktor 10 die Daten reduziert im Endeffekt. Und Barcula schalt eher ein komplexes System, was historisch halt von Tapes noch irgendwie herkommt. Und Borg schalt mehr so auf Random Access Zugriff ausgelegt. Ja. Ja. Aha. Ja. Ja. Ja. Ja. Ja. Mhm. Mhm. Ja. Das ist ein Thema. Ich wiederhole es noch mal kurz. Also was mir anbieten ist dieser Append-Only-Modus. Also durch dieses Transaktionsverhalten und das repositorisch quasi, wenn man so will, eine lockartige Datenstruktur. Also lock im Allgemeinen bedeutet ja, ich hänge immer nur hinten was ran. Und so arbeitet Borg by default. Es hängt eigentlich immer neue Daten hinten ran, macht immer neue Dateien mit den neuen Daten. Aber was halt passiert, wenn ich was löschen tue, um den Platz wieder zu gewinnen, läuft halt diese Kompaktierung dann bei den richtigen Schreibzugriffen los und tut halt diese Löcher im Käse quasi dann halt entfernen und schreibt halt die Dinger kompakt in neue Segmenten rein und hängt die auch wieder hinten ran. Was jetzt mit Append-Only passiert ist Folgendes. Der vermeidet einfach, dass alte Daten angefasst werden. Das heißt, die können da ruhig Löcher haben, die bleiben einfach so liegen wie sie sind und ich spare erst mal überhaupt keinen Platz. Und wenn jetzt ein Angreifer hergeht und sagt, okay, ich delete einmal jedes einzelne Archiv, dann sind die quasi, wenn man in das Repositorien mit Borg reinschaut, sind die auch wirklich deleted. Ich sehe die nicht mehr. Die verschwinden also aus der Archivliste. Und das Ding verhält sich so, als ob die nicht existieren. Weil er hat ja die Delete-Befähle auch hinten ran gehängt. Das heißt, logisch sind die eigentlich weg. Aber dadurch, dass die ganzen alten Dateien noch so darliegen, wie sie halt vorher auch waren, könnte ich praktisch einfach hinten im Repositor ist ein paar Dateien weglöschen und der ganze Delete wäre vergessen und er würde die Dateien halt im vorherigen Zustand wieder auffinden. Und dann hätte ich quasi den Angriff abgewährt. Das Ding wäre wieder so, wie es vorher war. Was jetzt passiert, wenn ich einen administrativen Client habe, der ohne Append Only ab und zu mal einen Brun machen will, ist Folgendes. Sobald er halt das Repository ohne Append Only aufmacht, dann macht er selber halt irgendwelche Operationen, dann macht er einen Commit und anschließend macht er praktisch diesen Compaction Run. Und dann würde der praktisch die ganzen Deletes, die der Angreifer gemacht hat, realisieren. Also die Daten wirklich wegwerfen. Und das ist natürlich dann ein Problem, weil wenn du den Angriff halt nicht bemerkt hast, ja, dann hast du die Daten dann halt gelöscht und dann hat das Append Only die am Endeffekt nichts gebracht. Deshalb müsste man, wenn man dieses Verfahren halt benutzt, Folgendes machen, dass bevor man das Repository im normalen Modus öffnet, also ohne Append Only, dass man sich vorher halt vergewissert ist, das Repository nicht in dem Zustand, wie ich es haben will. Oder hat er irgendjemand rumgelöscht oder sonst irgendwas Böses gemacht. Die einfachste Methode, wie man das wahrscheinlich erreichen kann, müsste man aber vielleicht auch nochmal im Detail darüber nachdenken. Ich kann mir ja diese Archivliste holen, wo also immer der Archivname und der Zeitstempel und am Schluss dieser Hasch dransteht. Und der Hasch von einem Archiv, der ist ja praktisch über den Archivdatenstrom gerechnet, beziehungsweise eigentlich über die Junklisten, die das Archiv darstellen. Und in den Archivmetadata stehen ja wiederum die ganzen IDs der Datenblöcke drin, die referenziert werden. Das heißt, ich könnte wahrscheinlich an diesem Archiv Hasch dann durchaus sehen, ob das Archiv in diesem Zustand ist, wie ich es haben will. Weil die Rektor der Kleine macht ihre Crews selber. Das ist die Eisensauer. Als Techniker, die das machen, dann macht das Crews selber. Und er fasst das Kleine-Sort zu zeigen, wovon er fühlt, dass ihr das Crews auskühlt. Und da stellt sich die Frage, wie der Fasste, also der Archivliste-Service, auch wissen kann, welche Operationen tatsächlich zulässig waren oder nicht. Das heißt, es wird die Crews auf dem Archivliste-Sort zu sehen, wo ich will. Also ich denke mal, wenn man zu einem bestimmten Zeitpunkt sagt, okay, mein Archiv, also mein repositorischem guten Zustand, und ich würde quasi eine Liste von den Archiven haben, wo jeweils der Hasch mit dran steht. Und ich würde dann, bevor ich das Ding halt im Normalmodus aufmache, gucken, Archivliste wieder, das ist schon eine Lese-Operation, da brauche ich das Append Only nicht wegmachen. Da könnte ich ja die Hashes auch gucken und dann halt die Archive, die noch da sind, halt vergleichen, ob die Hashes die gleichen sind. Dann kann ich, denke ich mal, auch darauf schließen, dass das Archiv das Gleiche ist. Und bei Archiven, die verschwunden sind, dann müsste ich dann halt entscheiden, ist es okay, dass die verschwunden sind, seitdem ich das letzte Mal geguckt habe oder war das eine böse Aktion, die verschwinden zu lassen. Also da müsste man quasi noch so ein bisschen Zusatzpolicy und Software reinstecken, um das beurteilen zu können. Was man natürlich auch machen kann, ist das, was ich vorhin erwähnt habe, ist, dass man nicht nur dieses Append Only benutzt, sondern dass man halt extern nochmal irgendwie Snapshots macht oder was auch immer. Wobei, das Problem ist natürlich das Gleiche. Die Snapshots kosten ja auch Platz. Die willst du also auch vielleicht irgendwann mal wieder loswerden. Also das Problem hast du eigentlich immer dann. Ja, bitte. Also die Frage war, ob BorgSurf dann nicht so mehr Kontrolle ausüben könnte, dass zwar eine Archive einlegen darf, aber keine halt löschen darf zum Beispiel. Das ist schon ein bisschen schwierig, weil der BorgSurf-Prozess, wenn man so will, also das Kommando heißt auch BorgSurf, man tut das aber nie von Hand aufrufen, weil das der Klein halt automatisch startet. Das ist im Prinzip ein Key Value Store. Also was der macht, ist halt, dass halt ein Put mehr oder weniger kommt. Diese ID und diese Daten können dazu und dann speichert er das halt so weg. Oder es kommt ein Get, lief er mir bitte die Daten für diese ID, dann muss er halt die Daten liefern. Oder es kommt ein List. Was hast du alles im Repository? Dann muss er halt die Liste von den IDs liefern. Also die übliche Key Value Store Semantik ist da implementiert. Plus noch so ein paar kleinere Sachen, vielleicht Locking und so. Aber im Prinzip ist ein Key Value Store. Und die Schwierigkeit ist jetzt natürlich bei einem Create. Klar, da kommen halt ein Haufen Putz, der die neuen Daten wegspeichern. Und am Schluss kommt ein Putz dann noch aufs Manifest, beziehungsweise ein Lesezugriff erst, wo halt alte Manifest irgendwann liest. Dann hängt er halt an die Liste der Archive, das neue hinten dran und dann schreibt er es wieder zurück. Das heißt, das ist so ein normaler Backup. So ein Get, ein paar Putz und Commit und so. Das ist das normale Backupverhalten. Wenn ich jetzt die Lead verbieten wollte. Dann könnte ich zwar, also die Lead-Operation an sich verbieten. Aber der Klein könnte ja zum Beispiel einfach irgendwelchen Blödsinn da rein speichern. Das wäre möglicherweise auch genauso bösartig. Also das müsste man nochmal genauer durch überlegen. Aber da gibt es auch ein Ticket zu dem Thema, da haben wir es uns mal schon länger durch überlegt. Und wir haben also entschieden, das ist so einfach nicht machbar, dass ich da einfach ein Schalter umlegen kann und das halt Backup erlauben, aber alles andere nicht. Nur eines ist relativ einfach zu verbieten. Also wenn das Repository im Append-Only-Modus ist, dann ist zum Beispiel der Repository-Delete als Gesamtes derstand verboten. Also das ging relativ einfach. Und es wäre halt auch schlecht, wenn das erlaubt wäre, weil das ist ein RM-RF, wo einfach das komplette Directory wegputzt. Da gibt es also dann keine Historie oder sowas. Also der ist auf jeden Fall verboten, sobald es im Append-Only ist. Aber die einzelnen Schreib-Operationen oder die Delete-Texts, die sind halt nicht verboten, die tun logisch, werden halt nur nicht realisiert. Also das müsste man vielleicht in Ruhe nochmal überlegen und vielleicht auch das Ticket nochmal nebenher durchlesen, weil da gab es schon mal eine längere Diskussion, aber ich habe es jetzt nicht mehr so ganz genau im Kopf, was da die ganzen Details waren. Okay, schauen wir mal ein bisschen kurz in den Code noch rein. Ich hole mir vielleicht noch kurz den Master-Branche, also das ist das, was dann in absehbarer Zukunft irgendwann die 1.1 gibt. Ach nee, habe ich schon. Also eine Umstrukturierung, die wir gemacht haben, früher lag der ganze Code im Verzeihnis Borg drin. Aber das ist bei Python-Projekten aus diversen Gründen etwas ungeschickt. Also besser ist es, wenn man das Ganze unter einem separaten Verzeichnis drunter hat, dass quasi nicht das Package direkt durch, direkt den Punkt, wo man üblicherweise ist, sichtbar ist. Also unter Source Borg liegt das jetzt alles drin. Das war eine dieser Umstrukturierungen, die wir gemacht haben. Und dann vielleicht so als Einstiegspunkt, wenn ich mal reingucken will, was das wollte, was das Ding alles macht. Das ist der Borg-Archiverpy, und das ist im Prinzip das Kommando-Zeilen-Interface. Also da wird praktisch mit arg pass, halt das Kommando gepasst und dann halt dispatched auf die verschiedenen Einzelbefehle. Wir können mal kurz reingucken. Und üblicherweise heißen die Dinger dann Do-Unterstrich irgendwas. Also hier Do-Serve zum Beispiel, das ist meist die Server-Komponente. Wenn also der klein, praktischen SSH auf den Server macht und auf dem Server dann seinen Counterpart startet. Ich such gerade mal das ganz normale. Hier zum Beispiel Do-Extract, das ist so der Einstiegspunkt für halt wiederherstellen von Daten. Und wir haben den Code ein bisschen dedupliziert. Also früher war der Code etwas länger, weil er praktisch immer so repositorisch aufgemacht hat und wieder zu und Cash auf und zu und alles. Wir haben jetzt so ein paar Dekoratoren gemacht, wo praktisch diese auf und zu machen von irgendwelchen Dingen in den Decorator ausgelagert haben. Also wenn man einfach sagt, with repository, dann kriegt der schon ein offenes Repository und wenn er fertig ist mit dem Ganzen, macht er es dann auch wieder zu. Genauso with Archive, liefert halt praktisch ein fertiges Archiv-Objekt in diesem Parameter hier und macht es am Schluss halt auch wieder zu. Also diese ganze Duplizierung, wo es früher gab, die ist jetzt alles draußen. Und dann wird halt hier üblicherweise irgendwas mit den Parametern angestellt. Und irgendwann wird dann meistens halt auf irgendeinem Archiv eine Operation gemacht. Und dieses Archiv-Objekt ist jetzt nicht in dieser Datei drin, weil das ist wie gesagt mehr so der Kommando-Zellen-Parser und so der Oberstell-Layer. Also das Archiv-Objekt liegt halt in Archive drin, ist also auch relativ leicht zu merken, ist alles relativ sinnvoll benamst. Da sieht man also wie praktisch Archiv-Operationen gehen. Cash sind so, wie der Name sagt, diverse Cash-Operationen drin. Hier muss man ein bisschen aufpassen. Ich habe ja hier schon mal ein Bild gemacht in diesem Verzeihnis. Also Chunker.C ist zum Beispiel nichts, was wir selber geschrieben haben. Steht auch oben drin, das ist durch Seifen generiert worden. Also der eigentliche Chunker, den man sich vielleicht angucken will, der liegt in, wo liegt er denn? Da hat sich kürzlich was geendet, der liegt hier unter Algorithms, Chunker drin. Und da sieht man, das ist also auch ein größer, halt stimmt nicht. Da muss ich dir zusagen, da bin ich jetzt gerade selber ein bisschen verwirrt, weil das war erst vor ein paar Wochen, da haben wir da ein bisschen umstrukturiert. Aber er müsste halt die Datei suchen, wo nicht generated by Seifen drin steht. Eigentlich hätte ich die jetzt auch unter Algorithms erwartet. Unterstrich hash index ist die Hash-Tabelle. Also momentan noch diese lineare Suche, bald vielleicht Robin Hood. Hier Crypto C, man sieht es auch an der Länge, wenn das Ding 300 Kilobyte lang ist, dann haben wir es nicht selber geschrieben. Dann ist das automatisch generiert der Output. Der übrigens nicht so wahnsinnig gut lesbar ist, also zur Not kann man den auch lesen, aber ist nicht besonders toll. Hier unter Fuse, wenn sich jemand für dieses Borg-Mount interessiert und da irgendwelche kreativen Ideen hat, wie man das noch viel besser machen kann, da ist die komplette Filesystemimplementierung drin. Also das, was ihr seht, wenn ein Borg-Mount macht. Ich habe da auch ein bisschen rumoptimiert in letzter Zeit. Also die ursprüngliche Variante war so, dass man halt einfach pro Archiv-Directory hatte und in jedem Archiv-Directory halt den Backup-Inhalt gesehen hat. Ich habe da kürzlich noch eine andere Ansicht eingebaut, dass da quasi alle Backups in einen Tree reinmärscht und dass man dann quasi an der Stelle einer Datei ein Verzeichnis hat. Wo heißt wie die Datei? Und da drin liegen dann die unterschiedlichen Versionen, die es da jemals gab, unter irgendwie einem Hash oder laufenden Nummer oder sowas drin. Das heißt, dann kann man relativ einfach irgendwelche Diffs zwischen Versionen machen. Man muss nicht in zwei Dateibäumen rumwühlen. Und da gibt es auch noch so ein paar andere Ideen, was man alles machen könnte, aber das müsste man dann halt da implementieren. Helpers, wie der Name schon sagt, da ist so alles mögliche in Utility-Funktionen drin. Da ist auch noch ein Ticket offen, wo man das mal ein bisschen auseinanderzieht. In Item, das habe ich mal eingebaut, ist so eine Abstraktion praktisch drin. Also in den Archiven, wenn eine Datei reingespeichert wird, oder ein Link oder ein Block-Device, also das wird generalisiert als Item bezeichnet. Also wir haben es nicht File genannt, weil es halt nicht immer ein File ist, es kann auch ein Directory oder irgendein anderes Objekt sein, aber es gibt ja auch noch ein paar andere Ideen. Und da ist praktisch so ein Wrepper drin, wo das ein bisschen hübsch zugreifbar macht. Das war früher im Code alles ein bisschen komplizierter und teilweise mit Indexzugriffen 0123. Und das ist jetzt halt schön über benahmte Attributige gemacht. Locking, da ist der Locking-Code drin, da hatte ich ursprünglich Hoffnung. Also man muss dazu sagen, bei Ethic war das Locking ein bisschen problematisch, aber man hat auch ein Problem. Und wie der Name schon sagt, es gibt es halt vor allem auf Posix-Plattformen. Wenn man irgendwas anderes machen will, hat man ein Problem. Und selbst auf den Posix-Plattformen hat man auch noch ein Problem, weil es irgendwie halt nur manchmal funktioniert. Ich habe das dann ersetzt durch ein einfacheres Verfahren, wo einfach ein Directory angelegt wird, beziehungsweise unbenannt wird, also wo auch quasi eine atomare Operation ist, die generell überall funktioniert. Es ist vielleicht nicht auf jeder Plattform wirklich atomar, aber zumindest so gut genug, dass sie wahrscheinlich in der Regel funktioniert. Wir machen da auch kein super schnelles Locking, dass man jetzt tausendmal die Sekunde da irgendwas machen. Das ist ja in der Regel mehr so einmal die Stunde oder so. Da ist diverser Locking-Code drin. So einen kleinen Last Recently Used Cash haben wir drin für diverse Zwecke. Paper Key ist noch ganz witzig. Das ist auch relativ jung. Ihr könnt ja, wenn ihr euren Key vielleicht backupen wollt, könnt ihr zwei Methoden machen, halt entweder ein separates Datenbackup, USB-Stick, CD-Brennen, was auch immer. Oder was ihr auch machen könnt, seit es Paper Key gibt, ihr könnt es einfach als QR Code rausdrucken. Und deshalb gibt es da so ein bisschen HTML, weil das so irgendwie mit HTML gebastelt wurde. Also ist relativ hübsch und man kann das dann quasi automatisiert auch wieder reinlesen. Man muss es nicht alles abtippen. Patterns, das Modul ist auch noch relativ neu. Das ist praktisch so für Include, Exclude-Operationen, welche Dateien will ich haben, welche will ich ausschließen. Da wird gerade auch noch recht viel gearbeitet. Remote, das ist diese Remote-Repository-Objekt drin und auch der eigentliche Server-Prozess, der auf der anderen Seite dann ist. Repository, da ist das lokale Repository drin. Also wo einfach nur Datei-Operationen in einem lokal gemauenden Fallsystem macht. Self-Test ist auch ganz witzig. Das gibt es auch noch nicht immer. Da macht das Ding, wenn ihr es ganz normal benutzt, ganz kurzen Selbsttest, ob das so gut aussieht, als ob die Krypto so funktioniert prinzipiell und so ein paar andere Sachen. Also das nicht so richtig anbrennt. Hier sind Extended Attribute, Implementierungen drin für verschiedene Plattformen. Upgrader ist auch noch interessant. Das ist vor allem für Leute, die von Ethic auf Borg umstellen. Das Repository-Format ist also größtenteils immer noch das Gleiche. Wir haben aber die Magics verändert. Wir wollten damals vermeiden, dass Leute Borg und Ethic in schnellem Wechsel benutzen und sich da irgendwelche Probleme einhandeln. Deshalb haben wir einfach die Magics vorne in den Segment-Dateien geändert, dass das eigentlich vom anderen ist. Der Upgrader, da gibt es auch ein offenes Ticket dafür. Der tut momentan nur, wenn euer Repository lokal liegt. Also ihr könnt keine Remote Repositories upgradeen damit. Das ist auch noch so ein kleines Manko. Aber das war leider nicht so einfach machbar. Seit neuestem gibt es jetzt noch ein paar Packages. Hier unter Algorithms hat der Marian so die ganzen Algorithmen rein verschoben. Ich habe ihn dann ein bisschen kritisiert, dass er gut alles natürlich ein Algorithmus ist. Aber er meinte insbesondere halt mehr so, was eine bestimmte Datenstruktur oder einen well-known Algorithmus implementiert, also z.B. CRC32. Oder, ach ja, genau, Bass-Hash heißt es, also das ist quasi der Junking-Algorithmus. Da können wir mal reingucken. Da sind übrigens auch ein paar Wikipedia und andere Verweise drin, wenn ihr euch diesen Rolling-Hash mal angucken wollt, was der genau macht. Der heißt übrigens deshalb Bass, weil der Erfinder, das war wohl dem sein Spitzname. Da sieht man da ist so eine vorgesiedete Tabelle drin. Wobei die wird, wenn ihr Verschlüsselung anmacht, dann nochmal modifiziert mit eurem Private Seed. Da wird da einfach nochmal ein X-Order oder irgendwas drüber gemacht. Also es wird nicht unbedingt diese Werte verwendet. Da sieht man halt, es ist so ein bisschen C, aber jetzt nicht so wahnsinnig komplex. Und das muss halt auch schnell sein, das Ganze. Das sind also die Algorithmen. Hier haben wir übrigens noch eine Kopie von der Blake-2 Referenzimplementierung drin. Das war auch aus dem Grund, weil Blake-2 nicht auf jeder Plattform jetzt schon fertig verfügbar ist. Wir haben aber froh, die vielleicht auch irgendwann wieder rauszuschmeißen, wenn wir halt überall mit Blake-2 einfach dazu linken können. Hier ist auch ein bisschen Kryptogramm drin. Also auch das Management von irgendwelchen Keys, irgendwelche Nonces oder Counterwerte, die man noch einmal benutzen darf. Und was wir in Zukunft auch machen werden, wir werden ja auch diese Caches, die wir auf Platte speichern, wenn wir in Zukunft auch signieren, dass wenn irgendjemand Festsplattenprobleme hat, dass der nicht einen korrupten Cash aus Versehen reinlädt, also da wird es in Zukunft auch noch eine Art Hash oder Mac drüber geben. Hier sind Plattformanpassungen drin für OSX, also Darwin heißt es dann, FreeBSD-Linux. Und so ein paar ganz allgemeine Sachen, wo auf allen POSIX-Plattformen tun, müssten sie in den POSIX-C drin. Und hier gibt es noch viele, viele Tests. Die kann man also einfach mit TOX laufen lassen, sind so, glaube ich, ungefähr 800 Tests, wo dann durchlaufen. Und die sollten halt in der Regel tun. Ja, glaube ich, das ist mal so der gröbste Überblick. Hier gibt es noch Dockus mit Zwinx gemacht, also RST-Format. Ja, und so diverse Verzeihen, das sind temporäre Sachen von mir. Okay, ich glaube zeitlich sind wir durch. Ja, haben wir auch Zeit für Fragen, oder? Ja, gibt es jetzt zum Source Code noch spezielle Fragen? Ich bin jetzt relativ schnell drüber gesprungen, ohne jetzt in die Details zu gehen. Aber glaube ich, ganz so viel Zeit haben wir dann doch nicht mehr. Ja, defektes RAM ist relativ böse Geschichte. Wobei, das ist jetzt nicht baukespezifisch, was ich sage. Also generell, wenn du RAM hast, das habe ich gerade akustisch nicht verstanden. Ja, das kann passieren. Also sagen wir so die alten Daten, die du irgendwann mal reingespeigert hast, ist wie gesagt dieser Append-Only-Modus. Also da wird versucht, möglichst nicht mehr anzufassen. Also bald du diesen Compaction-Run machst, was üblicherweise nach Delete- oder Schreib-Operationen gern mal aufgerufen wird, da tut du dann natürlich alte Segmenten auch reinladen, kompaktieren und wieder neu weggeschreiben. Und wenn du dich zwischen reinladen und weggeschreiben, die dir alle möglichen Daten verbiegt, dann hast du was kaputt gemacht. Aber das ist nicht baukespezifisch, die kannst du natürlich auch ein komplettes Dateisystem zersägen, wenn es irgendwelche Dateisystem-Metadata im Fallsystem Cache erwischt. Oder auch beliebige Abstürze, also RAM kaputt ist relativ böse. Da kann ich noch eine aktuelle Anekdote dazu erzählen. Ich habe vor ein paar Monaten diese Google-Studie von 2009 gefunden, wo es sich mit RAM-Fählern beschäftigt. Und die haben praktisch ECC-Counter von ihren vielen Maschinen ausgelesen und da Statistikbetrieben in Zusammenarbeit mit ein paar Forschern von der Uni. Und also als ich diese Studie gelesen hatte, war mir irgendwie ziemlich mulmig und gruselig, weil die doch eine recht hohe Bitfählerrate pro Gigabyte und Stunde ausgerechnet hatten. Also ich weiß da genau, ich werde nicht mehr, aber so gefühlt ein Bitfähler pro Gigabyte, pro Stunde. Und ich so, ups, das war dann doch etwas mehr als erwartet. Und habe ich mir erst mal überlegt, okay, also manche Leute haben ECC, die haben dann vielleicht noch kein Problem, aber auch nur vielleicht, weil ECC natürlich auch nur bestimmte Mengen Fehler korrigieren kann, oder bestimmter Typ von Fehler. Aber viele Leute haben halt kein ECC und die werden dann halt schon relativ schlimm dran, wenn es dir pro Stunde irgendwo ein Bit verbiegt. Und habe ich mir schon überlegt, muss ich jetzt Software ECC implementieren für unsere Hashtabellen oder was machen wir jetzt? Dann habe ich aber mal weiter rumgeforscht und habe noch mal eine Studie gefunden, ein paar Jahre später, wo dann auf die Google-Studie Bezug genommen hat und geschrieben hat, ja, also so kann man das nicht zählen. Weil was die gemacht haben, war einfach die ECC-Fähler auszuläsen und die sind quasi direkt in die Statistik eingeflossen. Und jetzt könnt ihr euch vorstellen, wenn so ein Ramodul stirbt und so eine Bit-Spalte stirbt irgendwie, dann fängt man durch der ECC-Zählers-Rennen an. Dann produziert er innerhalb kurzer Zeit tausende Millionen von Fehler. Und wenn man die dann als Counterwert nimmt und in die Statistik reinschmeißt, dann kommen da halt relativ hohe Werte zustande. Und diese Forscher haben also gemeint, ja, also wenn man das richtig zählt, müsste man das quasi als einen Event zählen, wenn so ein Ramchip stirbt. Und also in der Studie kam dann wieder ein deutlich angenehmerer Wert und fehlere Rate raus, der also mehr so was weiß ich, einer pro Jahr oder so war, also was man vielleicht so erwarten würde. Aber generell, also wenn die Daten super wichtig sind und irgendwie viel Geld oder Menschenleben davon abhängen, sollte man vielleicht wirklich ECC-Rennen benutzen und nicht das normal oder nicht das ohne. Die Kosten fürs Rammern sich sind ja nicht arg viel mehr. Was halt etwas nervig ist, ist, dass man halt der passende Chipsatz und der passende Prozessor da noch braucht. Aber wenn ihr so was günstig machen wollt, die Polizie von Intel ist da etwas komisch. Also im mittleren Bereich gibt es kein ECC. Also wenn ihr euch irgendwie ein i5 oder i7 kauft oder so, da gibt es halt es nicht. Ihr könnt einen Xeon kaufen, der kostet dann halt ein bisschen mehr und da kann dann ECC. Der wird sich aber, ihr könnt auch weiter nach unten gehen. Da gibt es auch ECC. Also wenn ihr so ein Pentium kauft für Billig, die sind halt nur nicht ganz so schnell. Aber für so ein Nass-System zum Beispiel oder so ein Back-Upserver für Borg oder so was, müsst ihr jetzt nicht den fettesten Prozessor nehmen. Da reicht auch durchaus so ein Pentium mit Dualcore und Hyper-Fredding. Und die können erstaunlicherweise ECC und dann müsst ihr euch nur noch ein passendes Board kaufen. Das kostet auch ein bisschen mehr wie ein normales, aber das ist nicht ganz so tragisch. Also man kann da auch relativ günstige Lösungen mit ECC basteln. Bei AMD ist noch etwas so unklar. Die haben ja jetzt auch neue Prozessionen gebracht, aber momentan halt mehr Zielgruppe Gamer als jetzt Server, die Server-Dinger kommen ja erst noch. Also das muss man dann sehen, wie das dort aussieht. Aber ich vermute mal, dass ich bei den Server-Teilen natürlich ECC einmachen. Die Frage ist dann halt nur, was die dann kosten. Aber generell, also wenn in so einer Hashtabelle natürlich Bits verbiegt, also wenn es da in einem Schad 256 Einbit verbiegt, ist dann natürlich kaputt. Dann bedeutet da etwas anderes. Und wenn du dann im Repository das passende Objekt finden willst, dann sagt er halt Object.Nut.Found, weil er es wahrscheinlich nicht hat. Wir hatten auch im Issue Tracker, einen Issue drin bisher, wo genau diese Fehlermeldung drin war, in einem Traceback Object.Nut.Found. Und der zeigt dann die Objekteidee an. Und diese Objekteidee, also ungefähr 250 Null-Bits und 6-1-Bits. Und jetzt muss man wissen, unsere normalen ID sind Schad 256, die sehen aus wie Rauschen. Also, dass da 250 mal Null gerauscht wird und 6 mal 1 ist relativ unwahrscheinlich. Und wir haben einen einzigen Hasch, eine einzig ID muss man sagen, die besteht aus 256 Null-Bits. Das ist nämlich das Manifest vom Repository, das müssen wir halt leicht wiederfinden können. Deshalb wird das einfach auf die Null gespeichert. Und gut, als ich konnte mir nur eine Erklärung halt machen für diesen Traceback, dass der halt kaputtes RAM hatte, wo es halt 6-Bits umgebogen hat auf 1. Ich habe zu dem dann gesagt, der soll bitte mal im M-Tesh 680 Plus laufen lassen. Feedback war dann, war okay. Also ich kann mir das nicht so wirklich erklären, was da schief lief, aber offensichtlich hatte der da irgendwo ein Hardware-Problem. Weil so rein von der Wahrscheinlichkeit, dass irgendein so ein Hasch 250 mal Null rauskommt, glaube ich doch eher unwahrscheinlich. Also ich vermute mal irgendein Hardware-Fähler, entweder im RAM oder auf dem Bus-System, Prozessor, Platte, keine Ahnung. Aber irgendwie sowas muss das gewesen sein. Und ja, das sollte man halt vermeiden. Genauso sind natürlich die Counter-Werte, wo die Referenz-Counter darstellen. Sag mal so, wenn die Größe werden, wäre es noch nicht ein Problem. Aber wenn der Counter-Wert geringer ist, dann wird er durch dieser Block zu früh gelöscht werden, wenn er irgendwann mal ein Delet darauf macht. Die Größenwerte werden jetzt nicht tragisch, würde wahrscheinlich nur die Statistik modifizieren. Aber generell RAM-Fähler will man nicht haben. Also entweder halt mindestens gutes RAM haben oder halt mit ECC besser. Okay, noch Fragen? Ja, ich glaube, dann sind wir durch. Also wenn noch was ist, ich bin auch noch da. Man kann mich einfach greifen und speziell es dann auch klären. Ansonsten danke für die Aufmerksamkeit.