 Also willkommen. Kleiner Talk-Abau über Borg-Backup. Also der Talk an sich ist auf Deutsch. Folien habe ich aber auf Englisch, denke mal, kommen die meisten damit klar. Wenn da irgendwas unklar ist auf den Folien, einfach nochmal kurz zwischen rein fragen, dann erkläre ich es nochmal. Der Talk ist jetzt also mehr so über Borg-Backup überhaupt, zu Grundlagen, Anwendungen und so weiter. So für die Entwickler hat er vorhin so eine kleine Runde, wo wir uns den Code ein bisschen angeschaut haben. Generell Borg-Backup ist vielen vielleicht noch nicht bekannt, ist aber eigentlich jetzt keine neue Software, war aber früher unter Namen Attic bekannt und ist jetzt also insgesamt ungefähr sechs Jahre alt. Borg-Backup ist einfach ein Fahrer vom Attic-Projekt. Kommt bei ziemlich vielen Leuten gut an. Ein griechischer Benutzer Stavros auf Twitter hat mal gemeint, er hätte den Holy Grail of Backup Software gefunden, bezog sich damals auf Attic, aber wie gesagt Borg ist praktisch gleich in Grün, nur halt weiterentwickelt. Und jetzt mal zu den Details, warum er das vielleicht haben wollte. Generell von Backup ist immer so ein bisschen eine lächstige Sache, einerseits will man es haben, aber so richtig viel Zeit aufwenden will man auch nicht und wenn es kompliziert wird ist auch blöd. Also man will eigentlich was Einfaches haben, was auch irgendwie schnell funktioniert, sollte also auch auf so einem Gigabyte Daten jetzt nicht ewig lang rumkauen, sondern das sollte halt recht flott gehen. Dann, wenn man nicht arg viel Speicherplatz braucht auf dem Backup-Medium, ist natürlich auch vorteilhaft und ihr könnt euch ja vorstellen, wenn ihr praktisch jeden Tag euren Rechner sichert, die meisten Daten sind ja immer wieder die gleichen, also wer durchaus vorteilhaft, wenn man die Idee duplizieren könnte, sodass die gleichen Daten nicht mehrfach auf dem Speicher-Medium nachher liegen. Kompression ist natürlich auch ein Feature, was man haben will, das ist nicht so schwierig. Bei Kompression ist das einzige, was halt da ein Punkt ist, man will relativ schnelle Kompression haben, also wenn die Kompression ihre Backup-Geschwindigkeit unheimlich runterzieht, wird es halt dann vielleicht auch ein bisschen langweilig. Es sei denn ihr habt irgendwie eine super langsame Verbindung, wo also da was rausholen könnt. Dann das Backup-Backup macht auch authentifizierte Verschlüsselung. Das bedeutet, dass die Daten, wenn ihr wollt, als erstes verschlüsselt werden und dann oben drüber nochmal eine Art Signatur berechnet wird. Das heißt, da kann keiner irgendwo an den Daten oder Krypto-Daten rumfummeln, ohne dass ihr es merkt. Also so ein paar der üblichen Angriffe auf Kryptografie werden praktisch durch diese Signatur schon bekämpft. Was man auch haben will, ist jetzt eigentlich so, ja, kein besonderer Punkt, aber man will natürlich alte Backups auch irgendwann vielleicht mal löschen können. Hört sich jetzt blöd an, ist eigentlich klar, aber ich sage es deshalb, weil manche Backup-Software unterstützt es irgendwie noch nicht. Also es gibt so ein paar Systeme, die arbeiten da irgendwie noch dran und die können also bisher keine alten Backups löschen. Also bei Borg-Backup ist auch desimplementiert. Borg-Backup benutzt ein relativ einfaches Backend, also ihr könnt entweder ein lokal gemauntetes Datei-System benutzen. Das kann also so ganz normal eine USB-Platte oder sowas sein. Ihr könnt euch aber auch per SSH-FS einen lokalen Mount von dem Remote-Datei-System machen. Das geht auch und einfach da das Zeug reinspeichern. Der zweite Modus, der unterstützt wird, ist über SSH. Das funktioniert dann so, dass praktisch ein lokaler Borg-Client die Daten einsammelt, verschlüsselt, komprimiert und so weiter und dann mit einem Remote-Borg auf dem Server kommuniziert über ein Remote-Procedure- Protokoll, das dann über SSH transportiert wird. Das ist also der zweite Betriebsmodus. Also entweder einfach ein lokalen Mount oder halt dieses über SSH drüber. Im letzteren Fall muss man durch Borg auf dem Server installiert sein, dass die zwei sich unterhalten können. Das Ganze ist unter BSD-License, also recht frei verwendbar. Wir haben recht gute Dokumentation, liegt auf borg-backupread-the-docs.io. Da ist also sowohl so ein Quick-Start drin als auch so die Feature-List am Anfang und auch eine Referenz-Dokumentation und so eine kleine FAQ. Was den Plattform-Support angeht, Linux 3BSD, NetBSD, OpenBSD, MacOS X, ohne Gewehr, Cygwin mit Windows und momentan arbeitet jemand dran, ein Native-Port auf Windows zu machen, also wo man keinen Cygwin mehr braucht. Letzteres ist aber noch in Arbeit. Das Cygwin könnte probieren, sollte eigentlich funktionieren, ist jetzt aber nichts, was wir regelmäßig testen. Also wenn jemand irgendwie Windows gerne benutzt, darf gerne mithelfen bei Windows-Testing-Sachen und so. Da gibt es also noch ein bisschen was zu tun. Was die Architekturen angeht, so die normalen X86, X64, AMD, Intel, so das übliche ARM-CPUs sind auch kein Problem, also können sie auf dem Raspberry Pi oder ähnlichen Dingen laufen lassen. Es tut sogar seit Kurzem auch problemlos auf Big-Indien-Architekturen, also wenn ihr noch einen alten Power Mac oder sowas rumstehen habt mit PowerPC drin, da tut es jetzt auch, müsst ihr also nur die neueste Version verwenden. Was auch supportet wird, zumindest auf diesen FreeBSD, Linux und MacOS X in Extended Attributes und ACLs, also bei Linux wird das eine übers andere realisiert, das ist aber nicht bei allen Systemen so. Der Support für NetBSD und OpenBSD, der fehlt noch, also da müsste irgendjemand der diese Systeme benutzt und kennt, das vielleicht noch mal einbauen, ist allerdings ein Dummy drin, also macht kein Problem, wird einfach nur halt nicht mitgesichert, wenn ihr also jetzt NetBSD zum Beispiel habt. Was es auch gibt, ist Fuse Support, also wenn ihr so ein paar Backups gemacht habt und irgendwann halt feststellt, oops, ich habe da nicht Datei gelöscht, ich brauche da 1, 2, 3 Dateien wieder. Man müsste jetzt nicht lange auf Kommando-Zeile rummachen und da irgendwie den Namen eintippen, ihr könnt einfach das komplette Backup Repository übern Fuse Mount mounten und wenn ihr dann in das Verzeichnis reingeht, seht ihr eure ganzen Archive und wenn ihr dann ins Archivverzeichnis reingeht, seht ihr ausgebreitet eure ganzen Dateien und könnt einfach mit einem File Manager das dann rauskopieren, also ist vor allem, wenn man jetzt nicht alles braucht, sondern ein paar Sachen, ist das sehr bequem. Wenn man größere Sachen auspacken will, also so ein komplettes Archiv ist allerdings schneller, wenn man das normale Extrekt benutzt und nicht Fuse. Also Fuse ist Fallsystem in Userspace. Zum Code kurz, das meiste ist in Python, und zwar in Python 3, genauer gesagt 3, 4 plus, also sehr moderne Python Version wird er angefordert. Das haben wir kürzlich hochgezogen, seit er war auch Python 3, 2 und 3, 3 noch dabei, allerdings Python 3, 2, also die, wo Python programmieren, wissen das, das ist ein bisschen nervig, weil da halt manche Dinge noch nicht so richtig funktionieren und weil er auch mehr und mehr Support von den Libraries einfach wegfällt, weil es keiner mehr supportet. Deshalb haben wir halt jetzt bei der 1, 0 Version gesagt, okay ab 3, 4 und das ist auch in der Regel kein Problem, weil die Linuxe das drin haben und auch die anderen Plattformen. Aktuell ist ja 3, 5, 1, also ist jetzt nicht so wild. Was auch noch dabei ist, ist Siphon. Siphon ist so an der Schnittstelle zwischen C und Python Code. Das Nette ist, man kann so diverse Low-Level-Sachen machen, also irgendwie 32-bit Integers definieren und irgendwelche Character arrays und so, also praktisch mit C-Datenstrukturen arbeiten, aber man hat trotzdem praktisch so ein bisschen die Comfort-Features von Python, also die Syntax ist halt mehr an Python angelehnt wie an C und man kann das auch teilweise emissionen und so, also ist sehr bequem und tut einem auch so ein bisschen abnehmen, so Glucode quasi von Hand zu schreiben. Und die letzten 5% vom Code sind in C, das ist also dieser sogenannte Chunker, der die Datein zuhackt in Fragmente. Dann tun wir Open SSL benutzen, LZ4, das sind halt alles in C implementierte Libraries, also da was auf Geschwindigkeit generell ankommt. Insgesamt sind es ungefähr 12.000 Zeilen Code und es ist modularisiert, also man kommt da relativ gut rein, es ist nicht so arg großes Projekt. Bei Ethic waren es glaube noch 6, 7, 8.000 Zeilen irgendwo, also ist deutlich angewachsen im letzten Jahr. Hat relativ wenige Dependencies, also vor allem LZ4, Open SSL braucht man Message Pack und so, ist jetzt aber durchaus übersichtlich. Wir haben einen Haufen Unit Test, so ungefähr 84% Coverage und Travis CI benutzen wir als Continuous Integration System, also wenn ein Pull Request oder sowas macht, wird er automatisch gecheckt, ob die ganzen Tests noch funktionieren. Zur Sicherheit von der Backup Software, da gibt es also so verschiedene Dinge. Einerseits, ich habe es vorhin schon kurz erwähnt, er macht oberhalb der Krypto eine Signatur obendrauf. Die dient als im Endeffekt aber zur Authentifizierung, sind es wirklich die Daten so, wie ich sie gesichert habe oder hat da irgendjemand dran rumgefummelt, also quasi sind das wirklich meine Daten. Das wird über einen HMAC realisiert, HMAC SHA256, also nur wenn man praktisch den Secret Key hat, kann man diese Signatur generieren. Darüber kann man halt verhindern, dass jemand gezielt auf eurem Repository Server an euren Daten rumfummelt, ohne dass er es merkt. Das zweite ist, man will natürlich, wenn man so irgendeinen Host irgendwo angemietet hat und seine Backups da draufschüttet, dann hat man das Dinge nicht unbedingt physikalisch unter Kontrolle. Das kann sein, das steht in irgendeinem Rechenzentrum, wo man normalerweise halt nicht sieht, ob da irgendeiner dran rumfummelt. Und dann will man natürlich vermeiden, dass die Daten da irgendwie sichtbar sind, die man backupt. Deshalb wird bei BORG dann alle Daten und auch alle Metadaten auf dem Kleint verschlüsselt, bevor sie überhaupt auf die Leitung gehen. Wenn sie dann übertragen werden, wird das Ganze noch in der Regel über SSH transportiert, also ich praktisch noch mal über SSH ein Kryptoleier drüber und wenn sie dann im Repo abgespeichert werden, ist das auch in dieser verschlüsselten Form, wie es der Kleinhalt abgeschickt hat. Also wenn man so ein Repo reinguckt, man sieht eine Konfigdatei, wo also ein paar banale Konfigwerte drinstehen und ansonsten sieht man nur viele ungefähr gleich große Dateien, wo ein Haufen Kryptosalat drinsteht. Also da fängt man nicht wirklich was damit an. Also man sieht keine Dateinamen und keine Inhalte. Das Ganze ist Freedom Open Source Software und man kann also den Code Out durchaus lesen, relativ viel, ist in Python und der Code wo in C ist nicht so wahnsinnig komplex. Buffer Overflows z.B. ist ein typisches Problem von C-Software. Hätte man also in dem Fall nur in diesen 5% des Codes, die aber wie gesagt nicht so komplex sind. Der restlichen Python, da hat man solche Problemchen in der Regel nicht. Also von der Sicherheit vielleicht ganz gut schon mal als Grundlage. Anderer Aspekt, ich habe es einmal mit Safety bezeichnet. Man will natürlich, dass wenn man dann Haufen Backups macht, dass man die auch dann irgendwann benutzen kann und dass dann irgendwie was unerwartet unbemerkt schief geht. Deshalb ist in Ethic und auch in Borg das Ganze recht robust designt. Also dieses reprositorisch wie so ein Art Transaction Log. Also er speichert da praktisch Daten rein und irgendwann sagt okay, ich bin fertig, Kommit. Und der macht da entsprechende Syncs auf das Datei-System. Und wenn praktisch der Kommit da ist, dann weiß man auch okay, das war wirklich alles im Komplett und so weiter. Und angenommen der Kommit würde fehlen, dann weiß man okay, alles seit dem letzten Kommit ist irgendwie nur so halblebig, das vergessen wir lieber. Das war wahrscheinlich nix. Es ist irgendwas unterbrochen worden oder irgendwas anders schief gegangen. Also der arbeitet mit so Transaktionen. Was er außerdem macht, sind Checkpoints. Das ist mehr so, wenn man so bisschen eine wackeliche Verbindung hat. Also angenommen hat eine DSL-Verbindung und die bricht halt alle drei Viertelstunde mal weg oder so. Der macht alle fünf Minuten einen Checkpoint. Und wenn man dann zum Beispiel bei Minute sechs so eine Leitungsunterbrechung hat, dann würde man nur diese eine Minute verlieren, weil praktisch bis Minute fünf ein parzielles Archiv erstellt worden ist, was aber gültig ist. Also da ist ein Kommit hinten dran. Die Daten bis zu dem Punkt sind vollständig und committed. Und wenn man dann einfach das Backup neu anstattet, dann macht er im Prinzip nochmal ein komplettes Backup. Also der macht keine Resume und macht an der Stelle weiter oder so. Der fangt im Prinzip von vorne an. Aber dadurch, dass er die Daten schon ins Repo reingespeichert hat und weil er halt detupliciert, muss er die Dateninhalte nicht nochmal übertragen. Er tut praktisch nur die Metadaten vielleicht nochmal reinspeichern. Und von dadurch sieht es dann praktisch so aus, wie man ein Resium machen würde und halt bei Minute fünf dann einfach weitermachen würde. Aber man kann die Checkpointzeit übrigens auch ändern. Also wenn man eine stabilere Leitung hat, kann man da durchaus eine halbe Stunde oder Stunde oder irgendwie so was einstellen. Also bis zu der Zeit, das ist als Maximum, was man quasi in Übertragungszeit verlieren kann, wenn irgendwas schief geht. Ein kleiner Sicherheitsaspekt ist auch noch, wir verwenden eine Bibliothek, die heißt MessagePack. Ihr könnt es euch vorstellen, das ist so ähnlich wie JSON oder Pickle. Also da wird einfach eine Datenstruktur sehr realisiert. MessagePack ist allerdings nicht Textformat, sondern Binär. Und da muss man beim Auspacken ein bisschen aufpassen, weil man kriegt ja da irgendwie von dem Remote-Repositor irgendwie das Zeug rüber. Und wenn es da jemand schaffen würde, halt irgendwie an so einer sehr realisierten Struktur rumzufummeln, dann könnte man natürlich sagen, okay, das werden jetzt nicht fünf Integer werden, sondern vier Milliarden Integer werden. Da wird auf einmal der Speicher explodieren. Also deshalb ist praktisch dieser Unpacker, wo diese Datenstrukturen auspackt, wird halt mit Parametern versorgt, wo man halt von vornherein sagt, okay, das können nur zehn Werte sein, weil in der Datenstruktur einfach nicht mehr drin ist. Also man kann da nicht über Memory, Denial of Service oder sowas machen. Zu den Kryptokies kurz. Also wie gesagt, er macht Kleinzeit, Verschlüsselung, verschlüsselt alles, Metadaten und Daten. Und es werden auch verschiedene Kies für verschiedene Dinge generiert. Also ich weiß nicht, ob das jetzt streng genommen notwendig wäre, aber andererseits sind nur ein paar Bites und es schadet auf jeden Fall nichts. Also der AES Schlüssel ist ein anderer Schlüssel, wie der HMAC Schlüssel. Und es gibt noch einen Seed für die Junker Tabelle, das ist nochmal ein anderer Random Wert. Also die werden da vorsichtshalber einfach auseinander gehalten. Dann, wenn ihr so einen Schlüssel habt, dann macht man da in der Regel eine Passphrase drauf, dass also der Kryptoschlüssel halt Passphrase geschützt ist, so ähnlich wie bei SSH auch. Da wird PPKDF2 mit 100.000 Runden verwendet. Also das ist so auf einem normalen Rechner irgendwie so ein Bruchteil von einer Sekunde. Also wenn jemand da was Brut forschen wollte, wird er praktisch pro Versuch irgendwie halt eine Zehntelsekunde oder eine halbe Sekunde oder sowas brauchen. Also man kann nur relativ wenige Versuche pro Zeit Einheit machen. Das ist nicht so, dass man da eine Million Versuche pro Sekunde machen kann, um da das irgendwie anzugreifen. Ist natürlich trotzdem sinnvoll, dass man eine relativ lange Passphrase nimmt, dass das nicht zu trivial erratbar ist. Es werden drei Modi unterstützt. Also hier steht Kies drüber, aber im Prinzip sind es eigentlich Verschlüsselungsmethoden und wie der Kieh nachher gespeichert wird. Eines ist halt nann. Ihr könnt einfach sagen, ich will keine Verschlüsselung, dann lässt das halt einfach. Ihr könnt auch sagen, ich will Repo Kieh haben, dann wird euer mit Passphrase geschützter Kryptoschlüssel ins Repositorierein gespeichert. Also wenn das remote ist, auf irgendeiner gekmieteten Kiste, dann liegt dort der Schlüssel. Er ist aber über die Passphrase geschützt. Also muss die Passphrase wissen, sonst fängt man nichts damit an. Oder ihr sagt, ich will das nicht haben, ich will den Schlüssel lieber bei mir haben, dann macht ihr Kieheil-Modus, dann speichert ihr den Schlüssel in euer Homeverzeichnis auf dem Kleint ab. Ein Achtteil dabei, ihr müsst diesen Schlüssel, der auf eurem Kleint liegt, separat sichern. Weil damit ist das ganze Repo verschlüsselt. Wenn ihr den Schlüssel verliert, könnt ihr den nicht mehr aus eurem Backup rausholen. Deshalb ist auch der Repo-Kieh-Modus der default, weil ich diesen Fall vermeiden wollte, dass die Leute das vergessen und nachher blöd darstellen, wenn sie keinen Schlüssel mehr haben. Aber wer es beachtet, kann also gerne auch Kieheil-Modus benutzen. Er muss halt nur den Kieh auf jeden Fall sichern. Schadet auch beim Repo-Kieh-Modus nichts, weil es könnte sein, dass mal irgendwie was korruptet wird durch irgendein Problemchen. Also auf jeden Fall eigentlich eine Kopie vom Kieh machen, das ist immer gut. Zu Krypto selber authenticated in Gryption. In Grypt den Mac, das ist eigentlich das, was gerade so in der Krypto-Szene einfach mal als sicher betrachtet wird. Früher wurde es teilweise auch anders herum gemacht, dass man erst quasi signiert hat und dann verschlüsselt, aber das ist super heikel und da kann ziemlich leicht was schief laufen. Deshalb halt diese Reihenfolge. AIS256 im Counter-Modus hat Vorteil, man muss kein Padding oder irgendwas machen. Man kann auch nicht irgendwelche Hex mit Padding machen. Und HMACSHA256, das gab es halt fertig in der Pfeifen-Standard-Bibliothek. Mit dem Letzteren bin ich ein bisschen unglücklich, weil das leider relativ langsam ist. Also relativ im Sinne von so ein paar hundert Megabyte pro Sekunde. Beut-Backup verwendet also diesen Counter-Mode und da wissen ja viele von euch wahrscheinlich im Counter-Mode, muss man beachten, dass sich so ein Counter niemals wiederholt. Das wird so gemacht, es wird halt irgendwo mal angefangen, wahrscheinlich was weiß ich bei Null oder einem Zufallswert weiß ich nicht. Dann wird der Counter einfach werden und Backup immer weitergezählt. Und wenn der am Schluss praktisch sein Manifest schreibt und ein Commit macht, dann steht der Counter-Wert, glaube ich, im Manifest irgendwo mit drin. Und wenn er das nächste Backup macht, liest er das einfach wieder zurück, rechnet dann noch die paar Blöcke drauf, die das Manifest selber gebraucht hat und macht dann bei dem Wert weiter. Also es wird nach Möglichkeit vom Mieten, dass da irgendwas doppelt benutzt wird. Es gibt allerdings einen Fall, wenn man es abwirkt, dann könnten blöde Dinge passieren. Wie ist es, die früher geschriebenen Sachen, also um was dran gehen? Also ich dann nicht dadurch, dass ich eine Kopie von dem Backup ziehe, zwei Monatelbefeile benutzen lassen und ich dann hier eine neue Kopie ziehe als Angriff, aber es zohre den Karmemord entfernt. Ja, also die Frage ist, ob man, wenn man sich einfach eine Kopie zu einem bestimmten Zeitpunkt macht und das dann mit einem neueren Backup X-Ort, ob man damit was anfangen kann. Es gibt zwei Betriebsmodelle, der eine Betriebsmodus ist Append Only, da bin ich ziemlich sicher, dass er damit nichts anfangen kann, weil da wird dann alten Daten überhaupt nichts geändert. Die liegen da einfach rum und werden nie wieder angefasst. Und er macht immer nur zusätzlich dazu. Der andere Modus, wo also nicht Append Only ist, der liest also alte Daten und kompaktiert die, wenn da Löcher drin entstehen und macht neue Chancs draus. Ich wüsste jetzt nicht, wie man es angreifen sollte, aber da tut er auf jeden Fall die alten Daten nochmal anfassen. Er tut sich dann aber auch wieder neu verschlüsseln, also ich wüsste jetzt nicht, wie ich es angreifen. Mit einem neuen Counter oder mit einem neuen? Mit einem neuen. Also der Counter wird im Endeffekt nur am Schluss weggespeichert und zum Weitermachen praktisch. Also ich denke mal, waschal ist nix machbar und selbst mit diesem Backup abwirken und dadurch praktisch provozieren, dass man nochmal die gleichen Counter verwendet. Selbst das ist relativ schwierig, weil ihr müsst euch vorstellen, das ganze geht ja nochmal über SSH in der Regel drüber und also an der Leitung irgendwas rummachen oder so. Irgendwie schwierig. Wobei wir wollen das ein bisschen ändern, dass es vielleicht auch diese Eventualität noch beseitigt. Was auch geplant ist, das Problem an diesem oberen Modus, also erst AIS mit Counter-Modus und dann nochmal den Age-Make rechnen, das ist nicht so wahnsinnig schnell. Das erste geht relativ schnell, weil es hardware beschleunigt ist, aber das zweite ist halt Prozessor und ohne Hardware-Beschleunigung. Daher ist geplant, dass man GZM-Modus implementieren. Der macht nämlich beide Sachen quasi in einem Durchlauf und da wird auch beides über CPU-Instruktionen unterstützt. Das heißt, ich kann 2 GB pro Sekunde da durchpumpen auf einer normalen Laptop-CPU hier mit AIS-Beschleunigung. Und das Feature ist also seit ein paar Jahren schon drin, also wenn man so normale Intel- oder AMD-Hardware hat, hat man das in der Regel auch. Was auch angedacht ist, das ist aber noch nicht so ganz sicher. Es gibt im neuen SSL so ein OCB-Modus, der war früher so ein bisschen problematisch wegen Patenten. Inzwischen gibt es aber so eine Patent-License, wo gesagt wird, okay, OpenSSL darf es benutzen und auch andere freie Projekte. Also von daher, denke ich mal, könnte man das wahrscheinlich jetzt benutzen. Der Vorteil ist, dass es noch ein bisschen schneller und nicht schlechter, also das ist nochmal 30 % schneller. Für CPUs, die keinen Hardware-Support haben, könnte man auch nur so Chacha 20 Poly 1305 oder sowas implementieren. Das ist einfach ein Software-Seifer, auch mit Authentifizierung, der aber halt deutlich schneller berechenbar ist wie AIS. Wie gesagt, wir benutzen OpenSSL, müsste aber deswegen nicht in Panik verfallen. Die Debox, wo so in letzter Zeit den OpenSSL hin und wieder mal waren und diese Sicherheitsprobleme, das war ja relativ oft bei irgendwelchem relativ komplexen Kram mit irgendwelchen Handshakes oder so oder bei Padding oder irgendwas. Also wir verwenden im Prinzip nur die AIS Primitiv. Also immer sagen halt, hier ist ein Datenblock, bitte einmal AIS Counter-Mode, also das ist nicht so besonders schwierig oder komplex von der Abwicklung her. Und man kann das auch nicht irgendwie auf dem Netzwerk durch der Zwischenfunken angreifen, weil das läuft halt lokal auf dem Kleint. Zur Kompression kurz. Also man kann sich einfach ausschalten. Das ist übrigens auch der Default. Also wenn ihr mit Ethic zum Beispiel vergleicht, müsst ihr beachten, Ethic tut bei Default komprimieren. Und zwar Zlib Level 6, also relativ aufwendige Kompression. Und dadurch ist halt auch etwas langsam. Bei Borg habe ich einfach die Kompression aus bei Default, einfach um euch das entscheiden zu lassen, was für eine Kompression ihrem Liebsten haben wollen. Weil das muss man sich wirklich überlegen. Man kann da nicht einfach ein Default, der jetzt für jeden passt, einfach einbauen. Ohne braucht man natürlich keine CPU, ist also von daher am leichtigsten auf der CPU. Was aber eigentlich oft besser ist, ist, wenn man das LZ4 anmacht. Weil LZ4 ist super schnelle. Also da kann man auch so im Gigabyte pro Sekunde Bereich damit komprimieren. Uns braucht trotzdem relativ wenig CPU-Zyklen insgesamt. Und dadurch, dass er dann im Endeffekt weniger Daten zum Weggespeichern hat, ist es oft schneller, wie wenn man die Kompression auslässt. Zlib könnte auch machen, also so Zlib Level 1 oder sowas, ist vielleicht auch noch okay und recht zügig. Je weiter ihr halt mit der Stufe nach oben geht, ist der lahmeter Zalt. Und LCDMA ist so das heftigste. Da würde ich empfehlen, die oberen Levels lieber nicht einzuschalten, weil die sind super rechenintensiv und brauchen auch Unmengen von Speichern. Und es kann sein, dass sie genau gar nichts bringen. Weil die Datenmengen, wo sie was bringen würden, die haben ja nicht am Stück. Wir haben immer nur so ein Megabyte oder zwei. Und wahrscheinlich die hohen Levels würden also nur bei größeren Dateien oder bei größeren Blöcken was bringen. Zur Deduplizierung kurz. Da wird es jetzt interessant für die Leute, die zum Beispiel Ersync mit Hardlings oder irgendwie sowas verwenden. Wenn ihr das macht, dann habt ihr schnell mal ein Problem, wenn ihr jetzt zum Beispiel virtuelle Maschinen-Images sichert, weil sobald ihr eine virtuelle Maschine startet und dann halt wieder eure Ersync-Backup laufen lässt, ist halt die komplette virtuelle Maschine im Prinzip nochmal auf eurer USB-Platte oder auf eurem Server. Weil der halt einfach nur guckt, der HD Datei hat sich geändert. Und wenn sie sich geändert hat, macht er halt kein Hardlings, sondern dann macht er halt nochmal eine Kopie. Also von daher braucht es ziemlich viel Platz. Was man auch beachten muss, das weiß ich jetzt gerade nicht genau, ob das bei Ersync irgendwie machbar ist. Aber VM-Dateien haben ja relativ oft Löcher drin. Also sind Spars, ein Haufen Nullen irgendwo, wird nicht wirklich auf Platte abgespeichert, sondern wird praktisch nur vorgemerkt, ah, hier kommt jetzt ein Gigabyte Nullen. Also oft so der unbenützte Restplatz sage ich jetzt mal auf der Disk. Da ist es wichtig beim Abspeichern, also beim Archivieren ein Backup erzeugen, ist das noch nicht so ein großes Problem. Man kann ja die ganzen Nullen lesen und durch die Kompression verschwinden die da im Endeffekt eh, weil sie zusammen komprimiert werden. Das Problem ist aber, wenn die VM-Datei Spars war, ich tue sie Backup und dann tue sie dann wieder Restoren. Wenn dann mein Backup-Tool keinen Spars-Support hat, dann werden alle Nullen auf Platte geschrieben. Und da könnt ihr euch vorstellen, wenn das Vorhalt irgendwie in Terabyte war und viel Spars dabei war, dann sind es halt auf einmal 10 Terabyte und ich laufe die Platte über. Deshalb ist es wichtig, dass beim Restore halt die Nullen nicht generell auf Platte geschrieben werden, dass man da zumindest eine Wahl hat, das Spars zu machen. Was man auch machen kann ist, dass man physikalische Devices direkt sichert. Also wenn ihr jetzt irgendeine Logical Volume oder sowas sichern wollt, macht ihr ein Snapshot davon und dann könnt ihr bei Backup sagen, bitte sichere mir diese LV. Also einfach das Device-Halt angeben. Dann tut ihr das Device-Fall nicht als Device-Fall sichern, sondern er machts auf und liest halt die ganzen Daten raus. Zum Vergleich mit Ersing noch anderes Beispiel angenommen. Ihr habt eine große Fotoesammlung, knipst halt so vor euch hin, habt viele Bilder im Jahr und am Ende des Jahres geht ihr immer her, tut euren Bilderorten umbenennen auf Bilder 2015 zum Beispiel. Wenn ihr das bei Ersing macht und ihr ändert den Pfad, dann tut euch Ersing nichts mehr deduplicieren mit dieser Hardlink-Methode. Und viele andere Tools, die sich am Pfad orientieren, wissen dann auch nicht mehr, dass es im Prinzip die gleiche Datei ist. Dann habt ihr halt alle Dateien mit einem anderen Pfad nochmal mit zusätzlichem Speicherverbrauch auf dem Speichermedium. Bei Backpackab ist das irrelevant, weil der sich nicht an den Dateinamen orientiert, sondern die Datein in Blöcke zähakt und sich am Inhalt der Blöcke orientiert. Und wenn er die Inhalte schonmal hatte, speichert er sich nicht nochmal. Egal wie die jetzt heißen oder wo die liegen. Dann, wenn ihr ja runtergegangen, mein Schuh ist ramm. Ja, das hat sich geändert. Das war ein Problem von Attic. Attic hat als Chunkgröße, also diese Häppchen, die er produziert, hat er so eine Zielgröße von 64 Kilobyte gehabt. Und jetzt musst du einfach ausrechnen. Ich habe ein Terabyte Daten geteilt durch. Im Mittel 64 Kilobyte sind ziemlich viele Chunks. Und jeder Chunk muss verwaltet werden. Und der liegt in der Hashtable in Memory. Und deshalb gab es bei Attic regelmäßig Probleme von Leuten, die jetzt nass hatten mit 4TB Plattendrinnen. Aber das Nass hatte halt nur ein halbes Gigabyte Ramm, denn es ist regelmäßig Ramm ausgegangen. Und deshalb bin ich hergegangen und habe die Standardchunkgröße einfach auf ein Megabyte oder zwei erhöht. Dort ist der Rammverbrauch halt auf einen Schlagfaktor 16 oder so runtergegangen. Und deshalb hast diese Probleme in der Regel nicht mehr. Es sei denn, so ein System ist halt extrem unausgewogen. Also wenn unheimlich viel Plattenplatz kombinierst mit wenig Ramm, dann kannst du im Prinzip immer noch passieren. Aber so auf normalen Konstellationen hat man das Problem deutlich seltener. Und auch natürlich der Index, wo auf Platte dann gespeichert wird, das ist im Endeffekt das Gleiche, der braucht natürlich auch weniger Platz. Und die Transaktionen gehen schneller, weil er weniger umschaufeln muss. Also das hatte durchaus positive Auswirkungen, hat natürlich auch eine negative Auswirkung. Wenn man diese Häppchen gröber macht, gröber hackt quasi, dann ist natürlich die Detuplicierung nicht mehr so feinkranular. Also da kann es sein, dass er nicht mehr ganz so gut detupliciert. Ist aber jetzt nicht so kritisch jetzt einig, wie wenn man einfach das Ramm ausgeht. Wenn ihr euch jetzt vorstellt, ihr tut irgendwie eine bestimmte Menge von Datensichern, dann wird ja praktisch innerhalb dieser Datenmenge detupliciert. Also angenommen, ihr habt ein paar Dateien doppelt auf der Platte oder vielleicht in irgendwelchen Vm-Dateien halt irgendwo viele Nullen drin. Dann wird also da praktisch durch Detuplication die Luft rausgelassen. Also selbst ohne Kompression. Das ist preis die erste Art, wie man oder was man detuplicieren kann. Das ist aber oft nicht so arg viel. Also wenn ihr jetzt nicht aus Versehenen hoffen Doppelte auf der Platte habt, ist das jetzt nicht so arg Ausschlag geben. Was aber viel massiver zuschlägt, ist die historische Detuplicierung. Also ihr macht jeden Tag ein Backup und 98% aller Dateien sind immer die gleichen. Dadurch hat man also eine sehr hohe Detuplicierung, wenn man die alle betrachtet. Und das macht Beug-Backup. Also Beug-Backup weiß immer, was für Datenchanks im Repository sind. Und zwar alle nicht nur die jetzigen und die letztlich vorherigen, sondern praktisch bis zum Anfang zurück. Und was auch ganz nett ist, wenn ihr mehrere Rechner ins gleiche Repository rein backupt, dann könnt ihr sogar ein Datenbestand von Rechner A nach Rechner B verschieben und da tut es trotzdem detuplicieren, wenn ihr ins gleiche Repository reinsichert. Weil einfach die Häppchen nachher die gleichen sind wie vorher, egal wo das Zeug jetzt liegt. Oder wenn ihr ein Haufen Rechner habt, wo überall das gleiche Betriebssystem drauf ist, das sind ja auch die gleichen Dateien dann, würde auch detupliciert werden. Hat allerdings einen kleinen Haken. Die Synchronisation mit den Junkindexes, die braucht ein bisschen Zeit, also es ist nicht ganz perfekt. Also wird halt ein bisschen langsamer. Zu dieser Detuplicierung kurz noch die Erklärung, wie das funktioniert. Also man könnte ja im Prinzip sagen, okay ich habe so eine Datei, ein Gigabyte groß, und ich tue jetzt einfach bei 0 anfangen, nach einer Megabyte tue ich trennen, nach 2 Megabyte tue ich trennen, nach 3 Megabyte tue ich trennen. Dann hätte ich so Blöcke, könnte ich den Hash rechnen, könnte ich detuplicieren. Das Problem, was dann Auftritt ist, wenn man vorne quasi was in die Datei einfügen würde, und der Rest würde sich komplett nach hinten verschieben, dann würde praktisch beim nächsten Mal Haken an diesen definierten Grenzen, würden praktisch immer andere Blöcke entstehen. Da werden wir nie das gleiche drin wie vorher. Deshalb wird nicht ein bestimmten Offsets geschnitten in Blöcke, sondern der richtet sich praktisch nach dem Inhalt der Datei. Dazu wird es einen so genannten Rolling-Hash verwendet, da wird praktisch wie eine Art Fenster über die Datei drüber geschoben, immer wieder ein Hashwert in dem Fenster berechnet, und wenn der Hashwert einen bestimmten Wert auf den letzten paar Bits annimmt, das ist praktisch das Signal dann zum Schneiden. Und da sich das halt am Inhalt orientiert, kann ich praktisch den Inhalt nach vorne, nach hinten verschieben, wie ich will, der tut praktisch immer sinngemäß an der gleichen Stelle schneiden. Und der ist halt so parametrisiert bei Borg, dass er halt, glaube ich, eine oder zwei Megabyte typischerweise so als Zielgröße hat. Das kann er dadurch, je nachdem wie der Hash sich entwickelt, mehr oder weniger sein. Das Einzige, was vermieden wird, wir haben so eine Mindestgröße, also er macht keine kleineren Schnitte wie ein halbes Megabyte, und das Maximum ist, glaube ich, 8 Megabyte. Also irgendwo dazwischen drin, macht er dann mal einen Schnitt. Die Paranoiden könnten jetzt annehmen, ja, wenn dieser da nach diesem Hash immer schneidet, dann kann ich ja an der Länge der Stückchen erkennen, was der für Daten hatte, selbst wenn es verschlüsselt ist. Das wird allerdings vermieden, indem die Tabelle, die dieser Hashing Algorithmus benutzt, da stehen im Prinzip Zufallswerte drin, die wird praktisch mit dem RandomKey noch mal Xort. Und dadurch kann man also, wenn man den RandomKey, den Sieb praktisch nicht kennt, kann man nicht vorhersagen, wo geschnitten wird. Also selbst, wenn man die gleiche Datei hat und das praktisch versucht, nachzustellen. Also wenn zwei Leute die gleichen Daten zahacken im Kryptomodus, sind die Schnittstellen unterschiedlich. Der, das Repository an sich, ist wie ein Key Value Storage organisiert. Ich habe also einen Schlüssel, und unter diesem Schlüssel wird halt als Value dieser Brocken abgespeichert, dieser Junk. Und die Adresse quasi, die ID, ist einfach der HashWert von dem Inhalt. Also normalerweise, ohne Kryptomodus, SHA256, sobald die Krypto anmacht, wird halt HMAC SHA256 benutzt. Und da geht dann halt der MacKey mit ein. Das heißt, die Signatur kann auch niemand anderes machen, wenn er den MacKey nicht hat. Jetzt mal der Zeit aus. Okay, ich hatte ja letztes Jahr hier schon einen Vortrag gehalten. Das war ungefähr so zu der Zeit, wo wir auch den Fork dann gemacht haben von Ethic. Also 2015, ungefähr im Mai. Die Ausgangsbasis nochmal, also bei Ethic war nicht ein recht guter Code da. Und es hat im Prinzip eigentlich nur so an so vielen Kleinigkeiten, sage ich mal gescheitert, also so viele kleine Bugs und so ein paar Ärgernisse und so. Und was halt leider ein bisschen unschickt war, der Hauptentwickler hatte irgendwie relativ wenig Zeit, sich da irgendwie drum zu kümmern. Aber gleichzeitig wollte er trotzdem lieber alles selber machen. Also er wollte da nichts irgendwie delegieren oder andere Entwickler da groß beteiligen. Deshalb haben sich halt damals diese Pull Request alle ein bisschen aufgestapelt und selbst schon mal jetzt reinguckt, da sind immer noch 30 alte Pull Request drin. Da hat sich also leider nicht so arg viel getan. Obwohl eigentlich viele Leute da was machen wollten. Und das war im Prinzip damals der Grund, dass ich es gefolgt habe, einfach halt, dass ich weitermachen kann und dass ich halt das Zeug was gut ist, halt anmörzen konnte. Auch die Ziele waren so ein bisschen unterschiedlich. Wir haben das also mit dem Hauptentwickler so kurz diskutiert. Er wollte mehr so das sehr sehr konservativ halten und für ewig kompatibel bleiben und so. Und das ist halt so ein bisschen so ein Modus. Das ist zwar bei Backup Software verständlich und ist natürlich auch ein Wunsch von vielen Anwendern. Aber wenn wir dann halt einmal eine falsche Designentscheidung machen, wenn wir ewig kompatibel bleiben, dann wird halt die Codebasis im Prinzip immer grösser und komplizierter und mit FLs und so. Also fand ich ein bisschen unangenehm die Vorstellung. Und deshalb haben wir halt bei Borgbackup gesagt, okay, wir versuchen zwar auch kompatibel zu bleiben, aber wenn wir irgendwo merken, das was irgendwie blöd ist, dann machen wir es halt anders und machen halt vielleicht irgendwie ein Konverter oder sowas, dass man halt sein Zeug dann konvertieren kann. Aber wir wollen nicht immer diesen alten Code auf Ewigkeit mit schleppen. So, auch wollte man natürlich das Ganze ein bisschen schneller entwickeln und das, also wenn neue Entwickler reinkommen, dass also die Pull Requests auch mal akzeptiert werden oder wenn sie nicht akzeptiert werden, dass halt zumindest ein Feedback kommt. So, hier geht es so nicht oder mach mal anders. Das war alles halt ein bisschen so schwierig im Ethik-Projekt. Wie sie das jetzt entwickelt hat, sieht man hier, also im Ethik-Repo, wenn ihr da auf Github reinguckt, da seid ihr immer noch 600 Change-Sets, da hat sich nicht arg viel geändert, ist von unserer Seite her sehr angenehm, weil wir haben keine komplexen Merchesets zu machen mit irgendwelchen Änderungen, die von Ethik herkommen. Und in unserem Repo sind inzwischen 2.300 Change-Sets drin, viele von mir, aber auch viele von anderen Entwicklern. Und ich hab auch teilweise die alten Pull Requests, wobei Ethik offen war, noch hab die Leute angequatscht halt und da haben wir das einfach bei uns halt mit reingemerkt. Also da ist jetzt praktisch halt sehr viel zusammengeführt worden, was im Prinzip halt irgendwie so Pending war. Es ist auch nicht mehr ein Ein-Man-Projekt, inzwischen haben wir so 5, sag ich mal, aktive Leute. So 2, 3 machen sehr viel. Die anderen so ab und zu halt mal was. Einer hat sich jetzt sogar auf Windows gestürzt, also da gehts durchaus voran. Auf Github ist recht viel los. Im Earth Channel auch. Mail English ist ein bisschen ruhiger. Wer seither Ethik benutzt, will sich vielleicht den Issue Nummer 5 bei uns mal angucken. Da ist so eine riesenlange Liste mit Ethik links drin. Also die ganzen Issues, wo da noch offen waren. Und ich habe im Prinzip alle abgehakt, die wir entweder gefixt haben oder wo wir ein eigenes Issue-Tracker haben. Aber so 80, 90 Prozent, denke ich mal, sind einfach gefixt worden. Also kein Problem mehr. Paar neue Features haben wir eingebaut. Das Testing haben wir noch stark optimiert. Also mehr Testen, mehr Plattform-Testing, Vagrant und auch die Dooku habe ich ein bisschen überarbeitet, dass die noch ein bisschen besser ist. Weil diese ganzen Mailing-Listen-Diskussionen und hier mal ein bisschen Info, da mal ein bisschen Info, das ist halt besser, weil wir das alles zusammenführen, dass man das alles in einer Stelle hat. Und da geht es im Endeffekt auch weniger Fragen. Wir haben dann vor Kurzem eine 1.0 Release gemacht. Das habe ich vom Timing her so gemacht, dass es bei Ubuntu noch reinpasst in die 16.04 Release. Weil wenn da halt die alte Version noch reingekommen wäre, die hätten wir dann halt irgendwie fünf Jahre lang pflegen müssen. Und das wollte ich eigentlich nicht machen. Ich wollte dann redlich aktuellen Stand drin haben. Und das hat auch geklappt. Also inzwischen sind wir bei 1.0.3. Und die Point-Releases, das waren halt so ein paar kleine Fixes, wo sich noch nachträglich rausgestellt haben, hat. Bei BSD ist es auch bei recht vielen Distributionen drin. In Package Source habe ich gesehen, ich glaube, drin gelandet. In Homebrew, für Mac, ist es glaube drin. Also das macht gerade so die Runde. Cygwin, wie gesagt, ohne Gewehr, sollte aber auch so für einfache Backups brauchbar sein. Irgendwann kam es dann auf Slash dort. Das hat auch ziemlich viele Zugriffe gebracht. Und auf Twitter redet und in irgendwelchen Blocks wurde doch einiges darüber geredet. Also es spricht sich gerade so ein bisschen rum. Das war bei Ethic auch so ein bisschen das Problem. Ethic war, hat zwar im Prinzip schon irgendwie funktioniert, aber irgendwie kannte es keinen. Man hat es eigentlich nur so durch Zufall gefunden. An der 1.1. Release arbeiten wir gerade. Ich denke mal so 1, 2, 3 Monate wird die dann released. Da kommen noch ein paar Features hinzu. 1 ist, dass man sagen kann, diff. Und ich kann dann einfach die Differenz zwischen zwei Backup-Archiven berechnen. Wenn man jetzt ein incrementelles Backup-Schema hätte, wäre das trivial, weil das tut ja einfach nur die Unterschiede dann sichern. Auch bei Backup müsste man bedenken, jedes Backup ist ein Vollbackup. Also wenn man da die Differenz wissen will, muss man das quasi wirklich berechnen anhand der Metadaten. Was auch reinkommt, ist ein Re-Create-Feature. Das hat ein anderer Entwickler entwickelt. Da kann man praktisch, wenn man sich vielleicht mal, also wenn man zum Beispiel mit Ethic gebackupt hat, mit dieser kleinen Chunkgröße und hat jetzt so viele kleine Chunks im Repo und man will die loswerden, kann man einfach ein bestehendes Backup-Archiv neu erzeugen mit der größeren Chunkgröße. Dass einfach der Verwaltungsaufwand geringer wird. Oder wenn man die falsche Kompression genommen hat und man hat sich da anders entschieden, dass man es einfach nochmal mit einer anderen Kompression neu komprimiert. Und es geht halt ohne, dass man das jetzt komplett auf Platte auspacken muss, sondern das macht er dann halt so intern, ohne wegspeichern. Ja, also die Frage war, ob der das bestehende Archiv umbastelt intern oder ob der ein neues Archiv anlegt. Also er legt ein neues Archiv an. Also temporär braucht man schon ein bisschen mehr Platz. Es ist allerdings die deutlich sichere Methode, weil wenn ihr halt in bestehende Daten rumfummelt und irgendwas geht schief, dann habt ihr halt möglicherweise ein Zustand, wo irgendwie superoptimal ist. Also Backup versucht immer so mit Transaktionen zu schaffen, dass man irgendwie erst was Neues macht, kommt mit und der alte Kram erst danach wegschmeißt, nachdem er sich sicher ist, dass das neue in trockenen Tüchern ist. Also auch schon von daher will man das Regret dann so machen. Manche Leute wollen, wenn sie so ein Backup-Repository haben, wollen sie es nochmal kopieren, irgendwo anders hin. Und könnte man zum Beispiel mit Ersing machen. Dann hat man ein bisschen das Problem, dass wenn man da Ersing laufen lässt, will man natürlich vermeiden, dass man aus Versehen jetzt Ersing genau zu dem Moment laufen lässt, wo gerade Backup läuft. Weil dann wird immer quasi ein Zustand Ersing, der intern nicht konsistent ist. Deshalb habe ich das With-Lock gemacht. Da kann ich einfach sagen, Borg, With-Lock, Ersing, und dann die ganzen Ersing-Parameter. Und dann wird praktisch Borg so als Rapper um Ersing drum herumgenommen. Der macht halt erst eine Repository-Lock. Dann tut er das Ersing aufrufen, wartet bis der Prozess von Ersing sich terminiert. Und wenn der terminiert ist, dann nimmt der halbes Lock wieder weg. Dadurch kann ich vermeiden, dass mir dann irgendwie da ein Borg-Backup zwischen reinläuft. Und die sich dann irgendwie in die Haare kriegen. Borg-Komment ist so ein kleines Feature, damit könnt ihr nachträglichen Kommentar zu einem Archiv hinzufügen. So dieses Archiv habe ich gemacht vor der großen Migration oder irgendwie so was. Also einfach was, was über den Namen vom Archiv hinausgeht. Dann ich habe noch an der Kompression ein bisschen gearbeitet und habe da so einen sogenannten Compression-Decider an zwei Stellen eingebaut. Also der erste Entscheider, der arbeitet einfach mit einer Konfig. Und in die Konfig könnt ihr dann reinschreiben, Sternpunkt MP3, Sternpunkt JPEG, Sternpunkt ZIP, Sternpunkt sonstwas und bitte Kompressionen an. Weil das braucht ihr nicht versuchen zu komprimieren, das ist relativ hoffnungslos. Da kann man sich also die CPU-Zeit sparen einfach. Man könnte theoretisch auch sagen, Sternpunkt irgendeine große VM-Image-Statei-Format und bitte da LZ4 nehmen, weil es halt schnell ist. Und Sternpunkt Text, wenn ich nur so klein Kram-Textdateien habe, dass ich da sehr viel auf und dann reinstecken will und bitte mit LZMA komprimieren will. Also man kann sich einfach für die Kompression entscheiden. Abhängig vom regulären Ausdruck auf den Pfad. Also ich kann sogar abhängig vom Pfad entscheiden. Es muss nicht die Erweiterung sein. Wenn ich zum Beispiel in irgendeinem Web-App ein Verzeichnis habe, wo halt ein Haufen Images liegen, die aber nicht Punkt JPEG heißen, die einfach nur eine Hex-ID haben, kann ich trotzdem sagen, diesen Pfad bitte nicht komprimieren, aber alles andere trotzdem. Das ist die erste Stufe, also die entscheidet anhand von Pfad- und Fallnahme-Metadaten. Das ist die erste Stufe von dem Entscheider. Die kriegt also diese Informationen von dem ersten Entscheider. Wenn der dann schon entschieden hat, ich will LZ4 haben, dann macht es das einfach. Wenn der bisher noch keine Entscheidung getroffen hat, weil es da keine Regel gab, dann tut einfach der zweite Entscheider versuchen, die Daten mit LZ4 zu komprimieren. Dann gibt es in zwei Möglichkeiten. Entweder das Zeug lässt sich nicht komprimieren, ist also genauso groß oder vielleicht sogar noch ein bisschen größer wie vorher. Dann lässt es einfach bleiben, dann macht er keine Kompression oder erstellt fest, das lässt sich auf 60% komprimieren und dann kann man konfigurieren, was er dann machen soll. Er könnte dann z.B. Z-Lip draufschmeißen und einfach nochmal eine teure Kompression mit Z-Lip machen, um das letzte bisschen noch rauszuholen. Vortrag bei LZ4 ist es so schnell, das fällt nicht groß auf, wenn man das einfach mal probiert, ob da was geht. Was auch noch kommt in 1.1, ist Geschwindigkeitsverbesserungen, also dieses Fuse-Mount ist deutlich schneller geworden. Dann, wenn man Festplatten als Quelle hat, ist einer auf die Idee gekommen, wenn ich jetzt so eine Directory abarbeite mit vielen, vielen Dateien drin und ich habe eine Festplatte, dann ist es geschickt, wenn ich die Dateien einfach nicht nur in der Reihenfolge, wie sie im Directory stehen, abarbeite, sondern wenn ich die nach Einode-Nummer sortiere abklappe, weil dann ist das praktisch ein linearer Sieg quasi auf der Platte und nicht so hin und her auf der Platte. Es gibt noch eine andere Änderung beim Traversal, das ist auf eine Paisenoptimierung zurückzuführen. Paisen war früher da ein bisschen suboptimal und hat praktisch beim Directory-Listen immer auch noch ein Stadt zusätzlich gemacht und die neue AP, die verhindert halt diesen einen Call und wenn man dann halt die Stadtdaten haben will, macht man halt einfach selber. Was ich noch vorhab, ist im Repositorium ein bisschen aufräumen und den Sourcecode in den Sourceverzeichnissen reinzupacken und auch noch ein paar Imports und so aufräumen, das ist also mehr so Sourcecode-Kosmetik. Und dann machen wir eine Release, weil dann kommt die große Baustelle. Borg ist momentan noch single fredded, das merkt er dann, wenn ihr ein großes Backup macht und da haben wir ein Prozessor irgendwie nur zu 30% ausgelascht und ich hab zwar 8 Cores, aber irgendwie langweilen sich die meistens, obwohl es eigentlich viel zu komprimieren und zu verschlüsseln und zu haschen gibt. Das liegt einfach da dran, es ist nur ein Fred und der macht halt alles linear hintrennender. Ich hab bei Ethics schon Multithreading mal in so einem experimentellen Branch gemacht oder könnt ihr euch vorstellen, das ist immer so ein bisschen eine haarliche Sache. Also da kann man relativ schnell so Race-Conditions kriegen und beim Krypto muss man auch aufpassen. Also da muss man ein bisschen aufpassen, dass da nicht irgendwie sich das Ding aufhängt oder sonst was Blödes passiert. Das ist das Gute. Man denkt zwar, ja, Python und Global Interpreterlog und Multithreading, das ist alles nicht so toll. Ist im Fall von Borg Backup eine gute Situation, das Giel tut ja nur Python-Code gegeneinander abschirmen, das also nicht an zwei Cores gleichzeitig Python-Code läuft. Aber die heftigen Sachen, die wir machen, sind ja I.O. Und bei I.O. wird das Giel freigegeben. Noch heftig ist Kompression, ist C-Code, wird auch skillfrei gegeben. Verschlüsselung, auch C-Code, wird auch skillfrei gegeben. Hashing, auch C-Code, wird auch skillfrei gegeben. Wir haben wenig Probleme mit dem Giel, weil die ganzen heftigen Sachen, die wir machen, ist alles irgendwo I.O. oder C-Code und da haben wir keine Gielprobleme. Also von dem Aspekt her haben wir Glück gehabt, wenn wir jetzt so rein numerische Berechnungen in Python machen würden, da hätten wir viel größere Probleme, da irgendwas vernünftig zu parallelisieren. Was allerdings halt als Problem auftritt in Race-Conditions, dass halt verschiedene Dinge unterschiedlich schnell da irgendwie durchlaufen oder die hinten rausfallen, wie seither war. Oder dass vielleicht bei Krypto irgendwie diese Counter-Values da irgendwie ein bisschen schwieriger sind. Deshalb wollte ich im ersten Ansatz so eine Art serielles Multithreading machen. Also wie so Fließbandarbeit, erstes Fließband macht so I.O., geht es in die Queue rein, nächstes Ding macht Hashing, Krypto, Kompression, geht es wieder in die Queue rein und dann wird es halt irgendwie rausgeschrieben und praktisch jeder dieser Fließbänder bedient sich immer aus so einer Queue raus. Das heißt, das Ganze ist immer noch genauso seriell wie vorher. Das passieren aber doch mehrere Dinge gleichzeitig. Also wenn ich z.B. in der hintersten Stufe beim weggeschreibenden Sync mach, so ein Sync sorgt dir dafür, dass alles auf die Platte geschrieben werden muss. Und seither war das so, dass er dann einfach das gemacht hat und gewartet hat, bis es fertig war. Wenn ich das jetzt mit frez mach, macht er zwar den Sync genauso, aber während der Erwartezeit kann ich vorne schon wieder die nächsten paar Dateien lesen und in die Warteschlange reinschmeißen. Also ich krieg so ein bisschen Multifredding dadurch, ohne dass ich jetzt die Gefahr hab, dass alles in Gaug gibt und irgendwelche Fellfunktionen auslöst. Und die schwierigen Sachen kann man dann im zweiten Schritt machen. Also ich hab mit dem richtigen Multifredding, also nicht mit dem hier, sondern mit dem, wo es so richtig parallel probiert, habe ich Faktor 3, glaub ich, hingegibt. Ist nicht ganz perfekt, weil Python ist da so mit dem Geel ein bisschen auf der Bremse. Ich glaub, das war auf dieser Kiste hier, also ein Durakor mit Hyperthreading. Also viel mehr kann man eigentlich nicht erwarten, weil das Hyperthreading ist ja nur so ein bisschen Beschleunigung. Es wird natürlich umso heftiger, je stärkere Kompression man verwendet. Wenn man hier sagt, okay, ich will unbedingt jetzt mit LZMA level 6 komprimieren, dann hat er rein mit der Kompression so viel zu tun, dass ich praktisch da 8 oder 16 Kors problemlos auslasten kann. Je mehr sich das mit der IOMischt, desto schlechter wird aber wahrscheinlich dann das Verhältnis. Also da hatte ich halt so gedacht, dass man so grob diese Stufen vielleicht machen könnte. Man kann im ersten Schritt vielleicht ein paar weniger Stufen haben. Wenn man dann merkt, dass mehr Stufen besser sind, macht man ein paar mehr. Aber dadurch, dass es alles schön in der richtigen Reihefolge abgearbeitet wird, habe ich keine Probleme, dass da irgendwie Races entstehen. Und CPU Last geht halt dadurch entsprechend etwas höher. Neuer Backup ist schneller fertig. Was auch noch geplant ist, für die 1.2 ISGZM hinzuzufügen, weil es einfach halt viel schneller ist, wie diese 2-Pass-Geschichte. Und auch im Keymanagement, wo wir ein bisschen was ändern, hat er auch unter anderem mit der Flexibilität zu tun. So, ihr seid alle eingeladen, mitzuarbeiten. Also wir nehmen Python oder C spricht. Kann ihr gerne mitprogrammieren. Ansonsten halt testen, wenn ihr Backs findet, ein Backreport aufmachen. Wenn es in der DoCu irgendein Problem gibt, irgendwas fehlt oder ist unklar, könnt ihr auch ein Ticket aufmachen. Also generell einfach da ein bisschen Feedback geben. Oder wenn ihr ein Security-Review machen könnt und irgendwas Neues findet, was nicht eh schon im Issue-Tracker steht, das wäre also auch sehr willkommen. So, und Authentifizierung und so hier im Werk. Ansonsten weiter sagen halt, wenn es euch gefällt, es ist leider halt noch nicht so arg bekannt. Also erst so ist es natürlich viel bekannter, weil es viel älter ist. Was man auch immer brauchen können, sind Distributions-Packages. Also wenn irgendwie eine Linux-Distribution noch kein Backup-Package hat und ihr benutzt die Distribution, könnt ihr vielleicht einfach eins machen. Oder auch für verschiedene Plattformen halt und ein bisschen dafür sorgen, dass alles rundläuft. Also wenn ihr irgendeine exotische Hardware habt, wo wir bisher nicht regelmäßig testen, halt einfach mal gucken, ob es funktioniert. Im Irk gibt es ein Backup-Channel, da ist einiges los. Da liegt die Docu, read.docs.io. Ich bin auch noch bis morgen hier auf der Konferenz, ihr könnt mich also auch hier abgreifen. Und angesichts dessen, dass wir nur noch fünf Minuten haben, machen wir noch ein bisschen die Fragerunde. Ich bin inzwischen eigentlich ein Fan von CryptoCommerce geworden. Also auch mal jetzt zum Beispiel eine jubikie. Ich werde die Frage glaube ich nochmal. Ich benutze gerne jubikie und es ist geplant solche Dongles tatsächlich auch zu benutzen, um jetzt zum Beispiel die Kieferl zu ersetzen. Also sagen wir so, das wäre durchaus sinnvoll, weil momentan ist so, wir machen ja symmetrische Crypto. Das heißt so ein Backup-Klein, der jetzt in den Crypto-Repository reinspeichern soll, muss irgendwo diesen symmetrischen Kieherum liegen haben. Und üblicherweise steht halt die Passphrase drin, das müsst ihr auch beachten, da bitte dann die Rechte richtig setzt, dass da nicht jeder reingucken kann. Aber es ist natürlich nicht die optimale Weise jetzt irgendwie Kies zu speichern. Also von daher wäre es durchaus sinnvoll, müsste sie aber halt irgendjemand darum kümmern. Und wenn es irgendwie so machbar wäre, dass man es nicht unbedingt im Core-Code einbauen muss, sondern dass das vielleicht anders geht, wäre es natürlich angenehm, weil es gibt halt sehr viele unterschiedliche solche Systeme in den Kielern. Von daher wäre es vielleicht so ein Related-Projekt mehr. Müsste ja aber halt irgendjemand machen, also ich habe kein Ubiqui. Und es gibt ja auch noch andere, wie heißt es so Nitro-Key und so gibt es ja auch noch. Also wäre durchaus sinnvoll, aber ist momentan jetzt noch nichts drin. Es gibt ein Ticket zum Thema Keychain-Support, wo man also mehr so die Software-Dinger supportet, Gnome, Ubuntu, so eine Software-Schlüsselspeicher oder bei Apple gibt es auch irgendwie sowas. Ist aber momentan auch nur ein offenes Ticket, hat sich jetzt also niemand draufgestürzt. Wäre aber sicher sinnvoll, weil sonst liegen halt die Keys irgendwie so rum und vor allem halt die Passphrases um die Keys zu öffnen. Ja, wenn man Remote-Backups verwendet, geht es ja über SSH. Besteht da die Möglichkeit, Ride-Only-Backups zu erzeugen, dass man quasi von der Kiste, die Backups macht, das Backup auf der anderen Seite gar nicht mehr löschen kann? Nein. Also Ride-Only geht nicht, weil wir müssen teilweise auch Daten zurücklesen können. Also wir können jetzt nicht einfach asymmetrische Krypto machen und wir verschlüsseln es für den Empfänger und kümmern uns nie wieder darum. Das geht nicht, weil ich muss zumindest das manifest mit der Liste der Archive zurücklesen können. Was aber geht und was auch schon implementiert ist im sogenannten Append-Only-Modus, da kann ich dir für sorgen, dass die alten Segmentdateien, die er also in den letzten Monaten halt produziert hat, dass die praktisch nach am erstmaligen Schreiben nie wieder modifiziert werden. Er tut immer nur neue hinten ranhängen. Das heißt, angenommenen Angreifer würde den Server ohne, würde ruht werden, würde das Beugzeug finden, würde versuchen, alles zu löschen, auch auf den Backup, dann würde er quasi nur ihre Transaktionseinträge produzieren in dieser großen Log-Datei, die einfach hinten ranhängen. Und neuerdings tun wir eine Log-Datei, schreiten wo diese, die Nummern quasi drinstehen, wo so eine Transaktion anfängt. Also ich könnte praktisch hergehen danach, wenn so was passiert, in das Log reingucken, sehen, aha, bis 32.500 waren es noch meine Kommits, der Nachwars der Angreifer, also schmeiß ich einfach alles Segmentdateien weg, die danach kamen und mein Repro ist wieder genau wie vorher. Hat allerdings den Nachteil, er löscht dann halt nix, also der Platzverbrauch steigt halt. Und man müsste wahrscheinlich dann halt so alle Monate oder Jahre, je nachdem wie viel Platz man hat, halt mal das Append-Only rausmachen und dann vielleicht halt doch mal was löschen lassen und danach wieder reinmachen. Also so ein bisschen wird supported, aber ja, ich weiß nicht, die perfekte Lösung die wir schon gefunden haben. Oft wird auch nach Pull-Modus gefragt, also dass man nicht den Push vom Kleint auf der Server macht, sondern irgendwie andersrum. Gibt es jetzt in der Software selber noch keinen supporter für, man kann aber möglicherweise über SSH-R so ein Reverstunnel-Modus aktivieren, dann kann man also zumindest von dem Repo-Server, der hinter der Firewall steht, die Verbindung nach außen machen und statt umgekehrt. Man müsste allerdings noch jemand orientieren, habe ich jetzt selber noch nicht getestet. Okay, kannst du was zum Restore-Zeiten sagen? Ich habe da recht extrem schlechte Erfahrungen mit Tarsnip und auch OpenM gemacht, wo ich halt zwar der Tag auf mein Restore gewartet habe. Ja. Gibt es zwei Fälle, einmal ist Fuse. Fuse ist so ein Convenience-Feature, sag ich mal, wo dafür optimiert ist, dass jemand sich ein paar wenige Data-Inos im Backup holen will. Fuse ist relativ langsam. Also das ist nicht auf maximale Performance gedacht, sondern mehr halt, dass man so rumgucken kann und sich das eine oder andere rausholt, nicht hier zum Terrain-Arbeits komplett zurückzuspielen. Das andere ist der normale Extract-Modus, also wenn ich es einfach über Kommando-Zaile anschmeiß, da ist so, der sollte eigentlich doch mit recht maximaler Geschwindigkeit laufen, erst aber nicht so stark optimiert, wie es create, weil er halt seltener benutzt wird. Aber ich sag mal so, ein Create auf dieser Kiste hier. Ich weiß nicht, was waren es 30 MB pro Sekunde, ich denke mal so ein Restore wäre wahrscheinlich 10, 20, 30. Also vielleicht nicht ganz so schnell wie ein Create, aber zumindest nicht so schlecht jetzt, wie wenn ich da mit Fuse rummach. Und wenn es also, kannst du vielleicht mal testen, ich habe jetzt keine Benchmarks gerade im Kopf vom Restore, weil es halt wie gesagt seltener benutzt wird. Aber mir wäre es jetzt nicht bewusst, wenn es ein Problem ist, dann vielleicht ein Ticket aufmachen. Auch das Multis-Rating übrigens ist natürlich vor allem für den Create Fall dann optimiert erst mal während dem Restore, kann man es vielleicht auch dann irgendwann machen, wer aber dann praktisch erst in zweiter Stelle. Aber im Generell also beim Extract ist halt so, der geht ja dann praktisch innen bestimmtes Archiv rein, zieht sich die Metadaten, in den Metadaten steht die Liste drin, die so eine Datei zusammensetzen und der fordert dann halt einfach die Chunks an. Und da gibt es also so ein Get-Many-Call in der Software, also der macht es auch nicht einzeln, sondern immer so ein Paar. Also von daher denke ich mal, hängt es vielleicht vor allem von der Latency der Netzwerkverbindung ab und wie schnell die Verbindung ist. Also da wäre es zumindest in der Software mir nicht bewusst, dass es da jetzt ein Riesenproblem irgendwo gibt. Und generell, also Borg-Backup ist deutlich ein Obnamm. Also ich habe am Anfang, bevor ich Ethik entdeckt habe, habe ich Obnamm entdeckt. Aber ich habe es meinen gleichen Tag auch wieder abgewöhnt, weil das so langsam war. Und Borg ist im Vergleich zu Ethik jetzt auch noch mal in Taken schneller geworden durch ein paar Optimierungen. Und von daher bin ich da durchaus optimistisch, dass wir uns da kein großes Problem haben. Ist natürlich nicht ganz so schnell, wie wenn du einfach nur die Dateien ohne was übers Netz schiebst. Also ich gehe stark davon aus, dass es existiert, aber es gibt wahrscheinlich auch eine Möglichkeit, so ein Repository dann auf eine Konsistenz zu prüfen, dass man einfach sicher sein kann, okay, das Backup funktioniert auch, wenn ich es dann tatsächlich mal brauche. Also da gibt es zwei Sachen. Das eine heißt Borg-Check. Und das Borg-Check wiederum ist unterteilt. Man kann da also sagen minus, minus Repository only. Dann würde er zum Beispiel nur diese ganzen Segmentdateien angucken und die CRC prüfen. Das ist also so für schlechte Plattensektoren oder sowas, oder mal aus versehene Bit irgendwo gekippt. Wird es wahrscheinlich gefunden. Ist aber keine kryptografisch starke Prüfung, weil so eine CRC hat halt bis 32 Bit. Vorteil ist, man kann sowas auf dem Server laufen lassen, weil er kein Kryptokie braucht, um die CRC zu prüfen. Man kann noch einen Erweiterten-Check laufen lassen, wo er also auch die ganzen Archive entschlüsselt und entkomprimiert. Das geht allerdings dann nur vom Kleint aus, wenn man da halt den Kryptokie dafür braucht und macht entsprechend vielleicht Netzwerktreffig. Da würde er aber praktisch dann die ganzen Metadaten auch lesen, gucken ob er alle Chunks hat und so weiter. Das einzige, was er in der aktuellen Release noch nicht macht, ist die Daten wirklich zu lesen. Also er guckt praktisch nur, ob er die Chunks hat, nicht ob da wirklich es richtig getrennt steht. Kommt aber in der nächsten Version wirklich viel Zeit verbraten will. Kann man auch noch alle Daten lesen lassen. Dann wird also der Hash beziehungsweise die HMAC geprüft. Wenn man das momentan haben will, kann man es indirekt tun, wenn man sagt Borg Extract minus minus Dry Run. Dann macht er praktisch alles wie bei einem normalen Extract, außer die Daten auf die Platte zu speichern. Also muss er sie auch entschlüsseln, verifizieren, MAC checken und so. Also das ist im Prinzip noch eine genaue Prüfung. Da die SHA256 und HMAC Kryptografisch stark sind, ist da eigentlich fast ausgeschlossen, dass da irgendwas schief geht, ohne dass man es merkt. Noch Fragen, Anregungen Feedback Connor Ja okay, dann danke ich für die Aufmerksamkeit. Und wenn noch jemand sonstige Fragen hat, ich bin noch eine Weile da.