 Ich erzähle heute etwas über Borg-Backup bzw. vielleicht bekannter als Ethic-Backup. Kommt dann später noch mehr zu dem Thema. Das ist Ratshift, was man gerade wahrscheinlich sieht. Das ist wahrscheinlich schon ein bisschen röder gewesen als gewünscht. Also falls ihr es nicht kennt, Ratshift bringt euch vielleicht ihre gesunden Schlafzüge zurück. Okay, also es geht um Borg-Backup. Mein Name ist Thomas Waldmann und ich habe das vor ein paar Wochen gefolgt. Vom Ethic-Projekt kommt dann später noch mehr dazu. Untertitel der Holy Grail of Backups habe ich nicht selber erfunden. Das habe ich wirklich mal auf Twitter rumgedwittert. Dem hat es also wohl auch ganz gut gefallen. Featuresets sollen schnell und einfach sein. Man will nicht die Duplicierung haben im Backup-Tool, also gleiche Daten, nicht mehrfach Speicherplatz belegen lassen. Man will Kompression haben. Was man auch haben will, ist authenticated Encryption. Das heißt, die Backup sollen natürlich nicht für andere Leute lesbar sein und wenn einer dran rumfummelt irgendwo ein Backup, will man das zumindest auch merken. Die Authentisierung ist wie eine bessere Prüfzumme. Was man auch haben will, ist, dass man alte Backups löschen kann. Also ihr Easy Pruning hört sich jetzt eigentlich banal an, aber ich habe gehört, es gibt Backup-Tools, wo alte Backups nicht löschen können oder noch nicht. Also es scheint wohl ein Feature zu sein. Es ist auch ganz nett, wenn das Backup-Tool ein einfaches Backend hat, dass man das vielleicht austauschen kann und dann verschiedene Zielmedien speichern kann. Das borgisch und der BSD-License, genauso wie Ethic. Es gibt ganz gute Docus. Plattform- und Architektur-Support ist auch ganz gut. Das liegt daran meistens in Python geschrieben, der Rest in C, also so auf allen POSIX-Systemen und Mac OS X. Wenn man Cycling installiert, läuft es also auch. Es können ein paar Spezialsachen wie Extended Attributes und auch ACLs. Und was auch ganz nett ist, ihr könnt also ein Backup, da könnt ihr nicht direkt reingucken, das ist ein spezielles Format, aber ihr könnt es über ein Fuse-Datei-System mounten und dann quasi doch mit dem File Manager reingucken und irgendwas auskopieren zum Beispiel. Also muss nicht jede einzelne Datei über ein Backup-Beselbe zurückholen, sondern einfach auskopieren. Zum Code, ich habe es mal nachgezählt, 91% Python 3. Also es ist wirklich nur Python 3, es läuft nicht mit 2.x, also es ist eines der wenigen Projekte, die da recht modern sind. Seifen wird dazu verwendet, um so Richtung Low-Level-Code, den Interface-Code praktisch zu schreiben. Seifen ist das ein bisschen optimiert, dass wir das recht gut machen können, ohne als große Verrenkungen machen zu müssen. Der Code in Teil praktisch, das ist alles, was so auf relativ hoher Ebene stattfindet. Und der richtige Low-Level-Code, der stand in C geschrieben, halt aus Performance-Gründe, dass das Ding halt so schnell ist wie möglich. Das Ding hat insgesamt nur ungefähr 6000 Code-Sälen und das ist also wohl, wenn ich recht weiß, da auch mit Kommentaren sogar, also das ist relativ wenig für so ein Projekt. Hat nur wenige Dependencies und hat gute Tests und hat ein Continuous Integration-System. Also man kann sich so verlassen, dass das Ding so, das tut, was es tun soll. Zur Sicherheit, was gemacht wird. Wenn der also Zeug praktisch in den Weggapspeiche reinschiebt, wird praktisch alles signiert. Also sobald man praktisch die Kluptografie anschaltet, wird praktisch jeder Datenblock, der in den Storage reingespeichelt wird, unterschrieben. Das heißt, kann ja nicht passieren, dass da jemand böswillig dran rumfummelt oder es kann auch nicht passieren, dass es einfach auf der Festplatte ein paar Bits verbiegt und er merkt es nicht. Also der wird auf jeden Fall praktisch dann die Prüfung würde anstrengend und sagen halt, da stimmt irgendein Hash nicht. Was es auch macht, ist Verschlüsselung. Wird mit AES 256 verschlüsselt. Das hat auch den Vorteil, dass AES ja auf so Intel und AMD Hardware durch spezielle CPU-Institutionen beschleunigt ist. Also das Ganze gibt trotz Verschlüsselung eigentlich doch recht schnell. Und dadurch könnt ihr praktisch auch offene Server, die ihr nicht kontrolliert, der vielleicht irgendein Provider oder so gehört, könnt ihr eure Weggaps da drauf speichern, ohne dass ihr jetzt angeschaut haben muss, dass ihr alle ganzen Daten seht oder auch nur erahnen kann, was ihr überhaupt habt. Also was man dadurch sieht, ist die Menge, wie 100 Gigabyte oder 1.000 sichert. Aber man kann keine Dateinahmen erkennen, keine Inhalte erkennen. Es ist halt alles, selbst die Meta-Daten, verschlüsselt. Das Ganze ist reihe und offene Software in Python. Also wer sich es angucken will, kann es auch angucken, kann speziell auch vielleicht diesen Sicherheitsrelevanten Code mal reviewen. Was auch noch netter interessant, der netten Effekt von Python ist, ihr habt keine Buffer-Overflows, wie bei so der üblichen C-Software, dass da irgendwas überläuft. Aber es kann prinzipiell nicht passieren. Zur Sicherheit noch. Das Ganze ist so designed, dass er die Datein DR praktisch in Storage reinspeichert, dass er da so ein Append-Modules verwende. Das heißt, wenn er da einmal was aufgespeichert hat, das wird danach nicht mehr modifiziert und dann immer nur Daten hinten rangehängt. Also wenn da mal was crescht oder so, ist das eine relativ sichere Methode, dass irgendwie verloren geht oder korrupt wird. Und er arbeitet auch mit Transaktionen und mit Checkpoints und so. Also dadurch ist das schon durchs Design praktisch gegeben, dass da nicht viel schiefgehen kann, auch wenn man Backup abbricht oder irgendwas. Die Checkpoints sind auch ganz praktisch, wenn ihr zum Beispiel über ein Internetverbindung Backup und die Internetverbindung bricht euch halt weg, dann habt ihr, wenn ihr schon fünf Stunden lange Backup, da habt nicht fünf Stunden verloren, sondern maximal die letzten fünf Minuten. Es gibt leider eine kleine Ausnahme, die ich dazusagen muss. Er macht diese Checkpoints nur zwischen Dateien. Das heißt, wenn ihr eine riesengroße Datei habt, eine virtuelle Maschine, als innerhalb der Dateien dann leider noch keine Checkpoints gemacht. Also die müsste man dann praktisch wieder von vorne anfangen. Was auch noch ein Security-Feature ist, da wird so eine Bibliothek verwendet. Die heißt Message Pack. Die dient praktisch dazu, Daten, Strukturen zusammen zu packen, zu serialisieren. Ihr könnt es euch vorstellen, es ist so ähnlich wie JSON oder XML, nur halt mehr so auf Low-Level-Ebene für binary Daten. Bei dem Ding kann man also auch beim Auspacken angeben, was man so erwartet. Also wenn ich da nur 10 Integer werde, auspacken will und ich weiß das, dann sage ich halt, okay, das kann maximal 10 Integers sein. Wenn ich das nicht hertut, mir 4 Milliarden Strings auspacken oder irgendwie sowas. Also das schützt auch ein bisschen gegen meine Impulation, das an der Irgerin versucht reinzulegen. Zum Thema Krypto noch. Die Krypto wird alles auf Kleinzäte gemacht. Also mit Klein ist der Rechner gemeint, den ihr back-upt. Da läuft dann das Ethik drauf. Und entweder ihr speichert das Lokal auf irgendein Fallsystem, USB-Plate, andere Fisch-Plate, was auch immer. Oder ihr speichert es über eine IP-Verbindung, über SSH auf irgendeinem anderen Rechner. Wichtig ist halt, bevor die Daten halt diesen Klein-Rechner verlassen, wird komplett alles verschlüsselt. Also selbst der eigene back-up-Service sieht quasi nicht, was da kommt, dass sie halt nur beizukommen. Es werden verschiedene Dinge, unterschiedliche Schlüssel verwendet. Also es gibt zum Beispiel für die HMAX, also für die Authentizierung gibt es einen Key. Für die Krypto gibt es einen Key. Und es gibt sogar noch mal einen separaten Key, wo diese ID-Hashes berechnet werden. Und es gibt noch mal einen Random-Ware, wo praktisch noch dieses Chunky randomisiert wird. Kommt nachher später noch mehr dazu. Also wenn man so einen Passwort geschützten Key hat, wird also die Passphrase mit KWKDF2, schon im vorherigen Vortrag kurz zur Sprache gekommen, wird es abgespeichert, also dass man keine so gut Force-Angriffe oder so was recht machen kann. 100.000 Runden ist schon recht viel. Also wenn das jemand knacken will, müsste er schon sehr, sehr lange dran rumknacken. Also das ist nicht wirklich Vaktikabeln. Man kann drei verschiedene Modi machen. Der eine Modi ist, dass man sagt, okay, ich will keine Verschlüsselung, dann lässt das halt. Man kann sagen, ich will mit einer Passphrase verschlüsseln. Dann wird praktisch aus der Passphrase über PBKDF2 werden praktisch die Keys generiert. Hat allerdings den Nachteil, dass wenn die Passphrase mal bekannt werden würde, dann kann man sie halt nicht ändern, ohne seine Backups neu machen zu müssen. Also das ist ein bisschen unpraktisch. Von daher, also wenn man das benutzt, benutzt vielleicht diesen Keyfile-Modus, da stehen die Cryptokies einfach in der Datei drin. Und diese Datei ist dann durch die Passphrase geschützt. Und dadurch könnte die Passphrase dann ändern auch, weil die Keys halt dadurch nicht beeinflusst werden. So, so kommt da noch mal ein bisschen genauer. Also was ja wenn so State of the Art ist, ist, dass man sogenannte IAD-Siphers verwendet. Also heißt so viel wie authenticated encryption with associated data. Im Klartext heißt es, ich tu nicht nur Verschlüsseln, sondern ich sorge auch dafür, dass mir keiner an den Siphertext rumfummelt. Also das ist authenticated. Ich sorge dafür mit einer Prüfsumme quasi, mit einer Kryptografischen, dass mir keiner am Siphertext rummacht und dann versucht mich reinzulegen oder versucht irgendwas zu verfälschen. Also das ist das AE und das AD. Das ist praktisch, wenn man Zusatzdaten hat, wie zum Beispiel so ein header-Wert, wo halt irgendwie so ein Typ Parameter drinsteht oder die Länge oder irgendwas. Also Dinge, die man vielleicht in Klartext lassen will aus irgendwelchen Gründen, wo man aber trotzdem die Prüfsumme mit rüberziehen will. Also es ist erkennbar, was da drinsteht, aber trotzdem durch die Prüfsumme geschützt. Und das sind also so die aktuellen Verfahren. Und was die Software verwendet, ist also AS256 im Counter Mode. Und als Absicherung wird danach ein sogenannter HMAC drübergelegt. Also ist praktisch diese Prüfsumme mit SHA256 in der Regel. Also ist schon ziemlich sicher. Ich habe dann noch ein alternatives Verfahren, was auch in OpenSSL vorhanden nicht noch implementiert. Das heißt AS256 G-CM, also dieser Galua Counter Mode. Der hat einen netten Vorteil. Bei dem anderen Verfahren muss man praktisch zweimal über die Daten drüber. Alle AS machen in Counter Mode und dann nochmal drüber und halt diesen HMAC berechnen. Und dazu muss man halt nochmal alle Daten anfassen. Der Vorteil an diesem G-CM-Modus ist, der läuft praktisch nur einmal drüber und tut praktisch parallel die Kryptomachen und auch die Prüfsumme berechnen. Und das Ganze gibt es fertig. In OpenSSL brauchen wir nur aufrufen. Und was auch sehr nett ist, Intel und AMD CPUs haben spezielle Instuktionen, wo dieser Modus auch beschleunigt wird. Also ist eine feine Sache und läuft nachher praktisch doppelt so schnell, ohne dass nicht groß was dafür tun muss. Wo auch darauf geachtet wird in der Software, wichtig ist, wenn man so ein Counter Modus verwendet. Man muss ja sehr peinlich genau darauf achten, dass der Counter sich niemals wiederholt. Also man darf ruhig mit 0 anfangen, das ist kein Problem. Aber wenn man halt beim ersten Backup bis 100.000 gezählt hat, dann muss man halt beim nächsten Backup mit 100.001 weitermachen und nicht mit irgendwas anderem. Also man darf nicht den gleichen Counter halt mehrfach verwenden. Stellt die Software relativ gut sicher, erspeichert sich am Schluss den Counterwert immer ab. Die Krypto ist auch nicht selbst gestrickt. Das ist wie gesagt OpenSSL. ObenSSL gab es jetzt ziemlich viele Problemchen in letzter Zeit, allerdings wenn man das Krypto selber stricken würde, wäre es wahrscheinlich noch viel schlimmer. Also von daher ist das in dem Fall ein Vorteil, weil da mehr Leute drauf gucken, denk ich mal. Uns ist natürlich auch in C implementiert, also auch schneller, als wenn man da jetzt was in Python oder so machen würde. Das ISNI kennt ihr vielleicht, das ist also das, was moderne Intel CPUs haben. Bei AMD gibt es was Ähnliches. Und dieses PCL und so weiter, das sind praktisch zwei CPU-Instuktionen, wo halt diese ganze Krypto sehr stark beschleunigen. Also wenn irgendwas halbwegs Frisches von Intel oder AMD habt, läuft es dann sehr schnell. Zur Kompression, im normalen Ethik beziehungsweise im Borg so wie es momentan ist, im Master Branch, wird Z-Leap verwendet. Die normale Z-Leap-Kompression, die kommt einfach aus der Python Standard-Bibliothek, ist Feststoff Level 6 eingestellt. Also das ist so relativ hohe Kompression schon. Ich habe da aber momentan gerade was in Arbeit, das wird es relativ flexibel gestalten kann in Zukunft, weil nicht immer wieder mal so stark komprimieren. Also manchmal hat das einfach eilig und hat genug Speicher und dann soll das auch ein bisschen schneller gehen. Aber wenn ihr es einfach aus dem Master Branch gerade auscheckt, macht ihr halt Z-Leap. LZMA wird es dann auch zusätzlich geben, das ist etwas stärker komprimierendes Verfahren, ist allerdings auch erheblich langsamer. Also das wird immer nur verwenden, wenn es wirklich notut, also zum Beispiel wenn ihr über DSL absträben, eure Backups irgendwie hoch ins Internet schieben wollt und der absträben halt sehr langsam ist, dann nimmt man vielleicht LZMA, weil man dann genug Rechenpower hat. Und die Leitung dann eigentlich der Engpass ist. Was ich auch in dem Experimental Branch schon eingebaut habe, also wenn ihr so ein Sternchen hinten dran seht, das ist praktisch nicht die Master Branch drin, sondern Experimental. Also es sind halt etwas größere Änderungen. Sie tun teilweise schon ganz gut, aber halt noch etwas mit Vorsicht zu genießen. Da habe ich eine Library-Indect, die heißt BLOSC. Und das ist so ein wissenschaftlichen Bereich und da fand ich das ganz spannend, was die für eine Ansage gemacht haben. Die haben gesagt, wir versuchen Kompression, die schneller ist als Memcopy. Also die programmieren unter euch kennen Memcopy wahrscheinlich für den Rest. Memcopy ist praktisch, wenn man aus dem Ram liest und irgendwo anders ins Ram schreibt. Also man denkt sich eigentlich, dass eine Kompression da nicht schneller sein kann, wie nur so ein ganz simpler Vorgang, weil wenn eine Kompression muss man relativ viel rechnen. Der Trick ist aber der, dass die komprimierten Daten halt weniger sind, wie die inkomprimierten. Und die haben ihren Dekompressionsalgorithmen so gemacht, dass er beispielsweise komplett in den Cache der CPU reinpasst. Und von daher haben die praktisch den Engpass von ihrem Datentransfer am Rammbus. Also früher hat man gesagt, okay, der Fischblatt und Zugriff ist der Engpass. Also die Leute, die da dran arbeiten, wenn ihr Engpass ist am Second Level Cache oder am Third Level Cache, nicht am Ramm. Und deshalb haben die praktisch Kompression und Dekompression so schnell hingekriegt, dass sie praktisch diesen Engpass beschleunigen können. Und da merkt man schon ein bisschen, das Zeug ist schneller wie Z-Leap. Also so typische Werte komprimieren. Durchaus einige Hundert mb pro Sekunde, mit vielen Kurs auch mehr. Und Dekomprimieren geht es also bis in die Gigabytes pro Sekunde. Und da habe ich gedacht, das ist eine nette Sache und das habe ich mal eingebaut und sie da auf einmal konnte ja auch deutlich schneller komprimieren wie vorher. Also vor allem dieses LZ4 Verfahren, das ist relativ populär auch bei anderer Backup Software inzwischen, das ist halt etwas moderner und deutlich schneller wie jetzt irgendwie Z-Leap oder so. Zur Detuplizierung noch was. Ich habe vor allem mal ein bisschen rumgefragt. Einige von euch verwenden irgendwie so Ersing und Hardlings zum Backups machen. Und das Ersing tut ja auch so ein bisschen detupliziert. Wenn das merkt, da hat die Datei schon auf dem Storage drauf, dann tut es nicht normal hinspeigen, sondern macht es einfach so ein Hardlink. Die Detuplizierung, wo das Borg beziehungsweise Ethik macht, ist noch etwas besser, weil das geht praktisch her, wenn es eine Datei reinkriegt, desto die Datei erstmal ein Häckchen zu hacken. Und diese Stellen, wo da gehackt wird, die richten sich nach dem Inhalt der Datei. Das heißt selbst in Sicht, mein Datei-Inhalt irgendwie so ein bisschen nach vorne verschiebt aus irgendwelchen Gründen, weil da drin gearbeitet wurde, der würde trotzdem noch an sinngemäßen gleichen Stellen hacken. Und dadurch kann der praktisch dann in verschiedenen Dateien die übereinstimmenden Bereiche relativ gut finden, weil der hat automatisch da gehackt hat. Und dort kriegt man so eine viel stärkere Detuplizierung hin, wie wenn man es nur halt gleiche Dateien erkennt. Also der würde praktisch jedes dieser Häckchen, wo er einmal schon gespeichert hat, noch einmal speichert. Das ist ein riesen Vorteil, wenn man so virtuelle Maschinen zum Beispiel zu Back-up'n hat, weil wenn man halt so eine Windows vor allem einmal angestartet hat, dann haben sie da halt so ein paar Megabyte auf diese virtuellen Festplatte geändert. Die restlichen 50 Gigabyte, aber sind halt gleich geblieben. Und die will man halt deshalb nicht nochmal alle Back-up'n. Und das kriegt dieses Tool also durchaus hin. Das sichert dann also nur die Bereiche, wo sich dann geändert haben. Vielleicht ein kleines bisschen mehr, nachdem halt, wo er gehackt hat. Aber es ist relativ wenig. Auch sonst, wenn man irgendwelche Platten-Images hat dementsprechend, wenn ihr zum Beispiel ein Verzeichnis habt mit Bildern, mit 10 Gigabyte Digital-Fotos drin, dann kommt da irgendwann auf die Idee, ich könnte jetzt mal das Verzeichnis auf Bilder 2014 umbenennen. Wenn ihr Ersynk benutzt, klatscht euch das Ersynk-Halt das nochmal auf euren Speicher, weil er hat sich nur an den Namen orientiert. Wenn ihr dieses Tool verwendet, erkennt es an den Inhalten, was er schon hatte. Das heißt, er wird das auch im unbenennten Zustand trotzdem deduplizieren. Was man auch hat, ist so die innere Deduplizierung innerhalb von dem Datensatz angenommen. Ich habe halt den Datei zufällig 2-mal auf der Platte. Der würde die finden, wenn er die halt genau in die gleichen Häppchen zu hackt. Oder wenn ihr bei ihr Linux-System 100-mal hintereinander, einmal pro Tag Back-up, also meistens ist immer gleiche was drauf, da ändert sich ja nur ein paar Dinge. Also da gibt es ziemlich großes Potenzial für diese Deduplizierung. Uns kann also sein, dass ihr praktisch, wenn ihr eure Backups zusammenzählt, kommt ihr rüber auf Tierarbeits, was ihr gesichert habt. Und wenn ihr dann guckt, wie groß ist das Backup-Archiv, das Säderhalt, das ist immer nur 50 Gigabyte groß, obwohl er alles hat. Weil er hat einfach das meiste immer doppelt warm. Was man auch machen kann, wenn man mehrere Maschinen hat, und ich habe überall Linux drauf, vielleicht sogar überall das gleiche Linux, wenn der Betriebssystem Teil wird halt dann dedupliziert, weil es ist immer gleiche in Prinzip. Also die Frau ist für sich, die tut alle Christen halt, gleichmäßig updaten, dann würde er das auch raus schmeißen. Auch wenn ihr irgendwo so Luft drin habt, sag ich mal, also zum Beispiel, wenn ihr ein virtuelles Disk-Image macht, kann es sein, dass ganz am Anfang da halt ganz ein Haufen Nullbytes drin sind, oder sogar Sparsfiles, was im Endeffekt auch wie Nullbytes aussieht, diese ganzen Nullbytes liste auch die Luft raus, weil sie hat sie halt halt irgendwie größere Stückchen von Lauter Nullen, und jedes dieser Nullstückchen speichern halt einmal ab, wenn der Nächster sagt, okay, das habe ich schon, und macht einfach eine Referenz drauf. Also das klappt ganz gut. Wie das Ganze jetzt funktioniert, da gibt es so ein spezielles Hash-Verfahren, das ist ein sogenannten Rolling-Hash. Funktioniert so, man hat praktisch eine Art Window und Fenster. Also angenommen hier die Tischkante ist eure Datei, man fängt ja praktisch an, dieses Fenster so über die Datei drüberzuschieben, und der berechnet immer, innerhalb dieses Fensters berechnet er einen Hash-Wert, also praktisch eine Art, charakteristische Prüfzummen. Und dann schaut er auf die hintersten 16-Bit, dieses Hash-Werts, und dann ist halt einfach so definiert durch das Verfahren, wenn die hintersten 16-Bit Nulls sind, alle, dann hacke ich. Und dadurch reinstatistisch, so im Mittel alle 64 Kilobyte, hacke ich halt. Manchmal früher, manchmal später, das richtet sich halt nach diesen Müllstellen dieses Hashes. Und den Rolling-Hash, den nimmt man deshalb, man könnte theoretisch auch einen normalen Hash nehmen, aber der Rolling-Hash ist halt praktisch, weil wenn ich den um ein Byte weiterschiebe, dieses Fenster, muss ich nicht den kompletten Hash noch mal rechnen, sondern da kann ich praktisch das eine Byte, was ausgefallen ist, ausrechnen, also das ist relativ effizient, diese Methode. Und dadurch hat man halt dann praktisch so charakteristische Stellen, wo das hakt. Und weil die sich nach dem Inhalt richten, hat man halt eine nette Möglichkeit, das zu deduktizieren. Diese 64K, das ist also die typische Chunk-Größe, man spricht ja dann von Chunks, also diese Häppchen sind die Chunks, komme ich auch dann nachher noch mal dazu. Was auch noch gemacht wird, ist so eine minimale Größe festzulegen, also man sagt halt, okay, ich will nicht weniger als ein Kilo weiterhaben aus verwaltungstechnischen Gründen. Und man kann theoretisch auch eine maximale Größe festlegen, wenn man sich nicht darauf verlassen will, dass es irgendwann eh nur wird. So, und was er dann macht, wenn also ein so ein Häppchen hat, wo er halt geschnitten hat, dann brechen der über dieses Häppchen ein Hash, also so ein Schad 256 zum Beispiel, und dieser Hash ist ja praktisch dann quasi die Identität dieser Daten. Und wenn ich dann einfach so ein Key-Value-Store habe und tue unter diesem Hash-Welt halt diese Daten wegspeichern, dann muss ich eigentlich nur wissen, was für Hashes habe ich in meinem Storage. Und wenn der dann halt nochmal kommt, später dieser Hash, dann weiß ich, ah, den habe ich schon, muss ich nicht nochmal speichern. Und dann tue ich nur den Referenz-Counter um eins erhöhen, dass ich halt weiß, wenn ich mein Zeug löschen kann, falls ich noch mal ein Backup-Slashen will. Und dadurch halt, tut es dann net de-publizieren. Man kann das auch machen, sobald man die Crypto anschaltet mit einer Pass-Face oder dem Key-Val, man kann natürlich anstatt dem Hash auch einen Mac rechnen. Da fließt also praktisch euer Passwort mit ein. Das heißt, diese Mac könnte dann nicht geben und euer Passwort nicht weiß, irgendwie fälschen oder so, und euer Backup irgendwie komisch korrumpieren. Aber da steckt im Prinzip genau so eine Hash-Funktion eigentlich drin. So, ich habe es vorhin schon gesagt, das ist das Backup-Soft, der die Ethic heißt. Das hat sich so ergeben. Der Autor von Ethic, der hat gerade Nachwuchs und kommt gerade relativ wenig zu seinem Projekt. Und so ein paar andere Leute haben da halt gedacht, okay, da helfen wir ein bisschen und haben halt fleißig Code aufgeräumt, Bugs gefixt, Pool-Requests gemacht und so weiter. Aber es hat sich dann mit der Zeit irgendwie halt rausgestellt. Ja, gut, der Originalautor will wohl alle selber machen, hat aber halt keine Zeit. Deshalb geht es da halt gerade leider nul voran. Und er will auch irgendwie niemand anderes damit vertrauen, das zu machen. Er will es halt wirklich selber machen. Und am liebsten will er sogar den Code selber schreiben und nicht andere irgendwie programmieren lassen und so. Also von daher war da der Fortschritt in diesem Projekt etwas begrenzt, um nicht zu sagen, fast nul. Und ja, ein paar Leute haben sich das angeguckt, aber irgendwann hat sich dann halt ausgestellt, ja gut, es ist wohl so nicht lösbar und da gibt es wohl unterschiedliche Ansichten. Und deshalb habe ich es dann gefolgt irgendwann, dass das halt irgendwie dann halt wieder parallel wieder entwickelt werden kann. So ist also dieses Borg-Back-Ab entstanden, gibt es auf GitHub. Momentan ist so der Master-Branch im Borg, der orientiert sich praktisch an der Entwicklung von Ethic, wobei wie gesagt, da entwickelt sich gerade nicht viel, aber da gibt es noch mal ein Change Set. Was ich zusätzlich gemacht habe, sind die ganzen Pull-Requests vom Original-Repo, die gut aussahlen, die habe ich eingebunden. Also die ganzen Backsticks, die ganzen Doku-Updates, die ganzen kleinen Features, wo haulos sind, die sind also alle bei mir am Master-Branch drin. Ich hatte das vorher übrigens auch schon für Ethic gemacht, aber wie gesagt, es ist nicht akzeptiert worden, der wollte es lieber selber machen. So sieht also gerade der Master-Branch aus. Ich habe einen zusätzlichen Experimenter-Branch gemacht und habe das ganze andere Zeug, was ich gemacht habe, wo es ein bisschen heikler ist, also neue Krypto, neue Kompression und so weiter, wo ich als E-Bedenken hatte, ob ich das abwille. Das ist also momentan im Experimenter-Branch drin. Tut im Prinzip auch, aber halt ein bisschen mit Vorsicht zu genießen. Also Master quasi konservativ, Experimenter wie der Name sagt, weniger konservativ. Borg ist momentan nicht kompatibel mit Ethic, weil ich die Magics geändert habe. Die Backup-Softe guckt praktisch in Storage rein und am Anfang der Datei steht so ein Magic-Ware drin und bei Ethic steht da halt Ethic drin, bei Borg steht Borg drin. Das heißt, wenn man das gegenseitig auf sich loslässt, sagt es halb ne, das ist nicht von mir. Das hat jetzt momentan einen kleinen Nachteil, wenn man es halt nicht für seine alte Ethic-Backups loslassen kann, hat aber auch den Vorteil, dass man sich gegenseitig nichts kaputt macht. So, der Erfolg, wie gesagt, ist vor allem auch deshalb gekommen, weil wir da so ein paar Sachen anders machen wollen. Unter anderem wollen wir halt das ein bisschen offener gestalten, also das soll keine ein Mann-Show werden, weil sonst hätte man gleich Ethic weiter genutzen können. Also von daher, wenn ihr mitentwickeln wollt, seid ihr willkommen, einfach Pull Requests machen oder wenn ihr ein Back-in-der-Drogo findet, genauso, einfach im Issue-Tracker vielleicht ein Issue aufmachen. Das Ganze soll auch ein bisschen schneller entwickelt werden, weil dadurch, dass es z.B. gefolgt worden ist, ist es quasi wie als neues Projekt zu betrachten. Der ganze Code ist zwar schon richtig getestet und jahrelang entwickelt worden, aber im Prinzip kann man jetzt eigentlich irgendwo ein Neuanfang machen. Von daher stelle ich mal so ein bisschen vor, dass wir vielleicht ein paar Sachen, wo in Ethic vielleicht nicht so ganz optimal sind, vielleicht halt jetzt fixen können. Das wird sich dann aber so über die nächsten Jahre, wird es halt zunehmend schwieriger werden, weil wenn das dann halt benutzt wird, diese Software und Leute halt da ein Haufen Daten reingebacken haben, dann wollen sie halt nicht entdauern so riesen große Änderungen haben. Also von daher, wenn man was fixen will, müsste man es eigentlich jetzt machen. Zu dieser Rückwärtskompatibilität, da gibt es noch sehr unterschiedliche Vorstellungen. Ich habe da mal ein bisschen umgefragt, also in Borgbackup ist hier Nummer 1 genau diese Zielrichtung, was man eigentlich machen wollen. Bei Anwändern von Backup Software gibt es natürlich so ein bisschen die Vorstellung. Ja, also die Software sollte noch perfekt design sein, sie sollte besten fehlerfrei sein. Ich sollte in 10 Jahren die Backups, die ich heute gemacht habe, immer noch zurückspeichen können mit der Version in 10 Jahren dann. Das sind so ein bisschen die Wunschvorstellungen, allerdings habe ich die Befürchtung, wenn man das realisieren will, wenn man Arten so ein Riesenaufwand beten, wenn man den Code immer drin lässt, der die alten Versionen verarbeiten konnte, das Projekt auch immer komplexer irgendwo. Und von daher ist das nicht so ganz das, was ich eigentlich machen will. Ich will eigentlich vielleicht das eher so halten, dass halt so die Patch-Releases und die Minor-Releases, die sollen halt kompatibel sein. Und wenn man mal irgendwas ändern muss, weil es halt einfach besser ist oder weil es alte irgendwie nicht so das macht, was es soll, dann will ich also die Kompatibilität eigentlich auch brechen können. Und dann würde man halt eine neue Major-Release machen und das halt in die Change-Lock reinstreben. Ja, hallo, benutzt euer altes Ding zum Alte rücksichern und das neue können wir dann ab jetzt benutzen. Also können wir auch gerne noch ein bisschen darüber diskutieren. Das ist halt so, wenn man es zu konservativ hätte, das Ganze hätte man gleich bei einem anderen bleiben können. Was ich so im Plänen habe und auch ein paar andere Leute, also ich habe zwar gerade die größte Programmier-Aktivität gehabt, aber ich habe auch Bullyquests von einigen anderen Leuten gemirrscht, die da schon etwas länger rum lagen. Also was ich verbessern will ist die Skalierbarkeit von dem Ding. Momentan sieht es ein bisschen so aus, dass wenn man sehr große Datenmengen hat und grundsätzlich wenig RAM, also so ein typisches NAS-Divise, halbes Wiegarbeit RAM, aber 20TB Blattentran, da gibt es ein bisschen Probleme, weil der halt relativ viel RAM pro gesicherter Datenmenge braucht. Also das will ich verbessern. Die Geschwindigkeit habe ich schon deutlich verbessert. Also das in meinem Experiment branscht, das läuft so ungefähr 3-mal so schnell wie das originale Ethik und ich bin noch nicht ganz fertig. In der Architektur will ich ein paar Sachen ändern. Bestens vielleicht auf dem Isytracker mal nachgucken. Was auch noch ein bisschen problemisch Ethik bzw. Borg macht, push Backups. Also ich habe auf dem Rechner, wo ich es sichern will, den Ethik als klein laufen und ich habe irgendwie ein Remote Server, wo ich meine Daten draufschiebe und dann geht mal der Kleint her und push die halt auf diesen Remote Backup Server. Jetzt ist der Kleinen, wenn das der Produktion Server ist, wenn sich da einer rein hackt und diesen Server ohnt dann hat er natürlich auch meinen Borg oder Ethik zu verfügen und dann könnte er mit diesem Backup Tool hergehen und auf den Backup Server die ganzen Backups remote löschen. Da stelle ich dann so ein bisschen der Gau, das will man eigentlich nicht haben. Die erste Idee, wo da kam, ja wir machen Poolbackups. Und bei, wenn man sich es genau überlegt, ist es besser. Da hat man nur das umgekehrte Problem, wenn jemand den Backup Server hackt, dann hat der Zugriff auf alle Server, die von dort geback abwerfen. Weil man in der Regel halt hohe Zugriff braucht, dass man alles rankommt. Also ist das auch nicht so wirklich die tolle Lösung. Also da ist noch ein bisschen offen, wie man das einigem Besten lösen will. Also eine Idee wäre halt, dass man so ein Create Only Modus hat, wo man zwar neue Backups anlegen kann, aber keine alten löschen sind. Das ist allerdings momentan nicht ganz trivial machbar, weil der Backup Store, weil es einfach so ein Key Value Store ist. Also der weiß im Prinzip nicht wirklich, was der Remote Server da tut. Der weiß nur, ah der hat jetzt gerade den Key raus gelesen oder der hat den Value reingespeichert. Aber zu welchem Zweck ist halt auf der Ebene nicht wirklich klar. Also da ist noch ein bisschen Diskussionsbedarf. Dann so einfache Sachen, besseres Logging, besseres Exception Handling, hab ich schon. Was man auch machen könnte, sind mehr Backends. Momentan gibt es also halt so das lokale, ein Frenzweilsystem rein oder halt das über SSH auf den anderen Server. Man könnte sich natürlich auch vorstellen, dass man irgendwie über FDP was macht oder auf Google Cloud oder Amazon oder was auch immer. Also da gäbe es noch etwas Backend Bedarf. Dann andere Plattformen, andere Architekturen. Also POSIX ist eigentlich schon ziemlich gut bedient. Das tut sogar auf Raspberry Pi und so. Seit Kurzem tut es sogar auch auf älteren ARMZ POS. Das hat auch Original Auto gefixt. Da gab es ein bisschen Alignment Probleme. Auf Windows so etwas durchwachsen halt mit Sidewin geht es irgendwie so ein bisschen. Aber es ist nicht so wirklich toll. Also die ganzen Windows Spezialfeatures oder so was kann es nicht. Also falls sich da immer berufen fühlt, könnte man da vielleicht auch was machen. Manche Leute haben auch schon nach GUI gefragt. Wobei da muss ich sagen, ich bin nicht der GUI Typ. Also das müsste jemand anders dann machen, der sich da berufen fühlt. Man könnte vielleicht auch eine vorhandene GUI umstricken, dass das auch mit Baureich bzw. Ethik funktioniert. Also ich weiß bei Ubuntu gibt es so ein kleines Dressortings. Ich weiß, dann kennt es jemand intern. Also das ist so relativ einfach, hat sie mit so ein paar Knöpfe. Ja, ich will Backup und ja, ich will das irgendwie umordeln. Und es gibt natürlich auch viele andere Ideen, die man einbauen könnte. Was ihr helfen könntet, wenn ihr Lust habt, ihr könntet z.B. Skalierbarkeit testen. Also ich habe nur relativ wenig Massenspeiche. Also das begrenzt sich so wenige Terabyte, wo ich so benutze. Also falls ihr irgendwo einen dicken Server sitzt, wo ihr auch mal Testrauf haben könnt und mal halt 100 Terabyte sichern könnt, könntet euch mal gucken, ob das funktioniert. Ja, es gab so ein paar Issues im Ethikissue Tracker, wo z.B. jemand von Data Corruption geredet hat. Sie ist aber nie so wirklich klar geworden, ob vielleicht einfach dem sei Ram ein Problem hatte, oder seine Platte oder was auch immer, oder ob das wirklich ein Softwareproblem ist. Ja, also wenn ihr da Tests machen könntet, die das entweder bestätigen oder halt regelmäßig was durchlaufen, oder was bringen. Generell ein bisschen vorsichtig sein, insbesondere wenn ein Experimental Code von mir benutzt. Dann halt Bugs reinschmeißen, Dokum verbessern, könntet ihr gerne mal Kulrigwest reinschmeißen. Wenn es euch gefällt, weiter sagen natürlich und direkt später auch irgendwann, wenn ihr alle so euren Lieblings-Linux habt, brauchen wir auch irgendwann Linux Pakete. Also von Ethik gibt es diese Pakete, die muss man allerdings auch mit Vorsicht genießen, weil die sind oft ein bisschen älter, nur will eigentlich eher die Neustelle-Linux benutzen, nicht die von vor zwei Jahren, aber da gäbe es also auch einiges zu tun. Die Homepage liegt momentan auf GitHub.io und der Borg-Backup. Es gibt da ein IRC-Channel. Beim IRC-Channel sind momentan absichtlich zwei Routen, weil die Bürokratie von Freenouten mit irgendwie beantragen, da habe ich noch nicht gemacht. Da wollte ich erst mal noch ein bisschen gucken, wie sich das so ergibt. Fragen oder Feedback können wir gern kurz jetzt machen. Was ich dann danach noch, solange die Zeit reicht, bis wann haben wir, bis 24 glaube ich, gell? Wir können anschließend entweder so ein bisschen Demo machen. Das ist allerdings nichts Weltbewegendes. Also könnt ihr auch relativ einfach selber machen. Es steht alles in der Hand. Oder wir können noch ein bisschen über Interna und Ideen reden. Das wäre vielleicht so für die Hacker vielleicht interessanter. Also können wir gerne kurz abstimmen. Wer hat lieber eine Demo um das mal praktisch zu sehen? Eins, zwei, drei, vier, fünf. Wer will internae Sachen und Ideen diskutieren? Eins, zwei, drei, vier, fünf, sechs, fast gleich. Internae und Ideen. Also nur mal so ganz kurz das wird nachher einfach auf den Folien stehen. Das ist halt, das ist jetzt relativ kompliziert weil das praktisch auf den Git Code drauf geht. Aber selten nachher in den Folien ich stelle die Folien dann auch ins Internet. Und nur mal so als Beispiel. Also der Oberstelltefehle zum Beispiel du halt Backup mit Positorie anlegen. Der zweite Befehl macht einen Backup. Also es ist relativ simpel. Er ist kein Hexenberg. Also so viel dazu. Man kann halt Backups anlegen, Backups löschen, Backups auflöschen, Backups restorn. Also das mit Simpel ist nicht übertrieben. Das ist wirklich relativ einfach. Machen wir mal die interessanteren Dinge. Das ist auch so eins der Dinger, die ich vorhab. Ich weiß nicht wer kennt Pfeifen, wer programmiert den Pfeifen. Hi, 4 Leute. Also die, wo Pfeifen in Multifredding läsen, die werden wahrscheinlich ein bisschen zucken. Weil Pfeifen ist eigentlich bekannt dafür, dass es da ein bisschen Probleme gibt. Da gibt es einen sogenannten Global Interpreter Log. Und das bedeutet halt einfach, wenn ein Fretter grad im Python Interpreter halt drinsteckt und irgendwie Python Code interpretiert, dann darf das nicht im Zweiten Gleichzeitig machen, weil sie sich sonst irgendwo in die Quere kommen, und dazu ist dieses Interpreter Log da, um das zu verhindern. Aber, was man noch dazu wissen muss, sobald Python eine I.O.-Operation anstößt, also wenn ich sage, File.read, File.write, File.fsync und das macht so ein Beckerproduktool natürlich dauernd mit vielen Gigabytes, Terabytes, sobald er in die I.O. reinläuft, wird das Global Interpreter Log freigegeben. Das heißt, bis die Daten kommen oder bis die Daten weggeschrieben sind, kann parallel wirklich was anderes laufen. Und das macht es automatisch, dann muss man gar nichts zu tun. Was man aufwissen muss, ist, sobald man in eine C-Extension reingeht, dann läuft er im Prinzip in C programmierter Code ab, zum Beispiel in OpenSSL. Das kriegt er irgendwelche Daten reingeschmissen, so da hast du Daten, verschlüsselt die bitte. Und dann arbeitet er das OpenSSL-Intern und während es tut, fummelt es nicht in irgendwelchen Python-Daten-Strukturen rum. Das heißt, auch da gibt es eigentlich kein Problem. Das Einzige, was man beachten muss, ist natürlich, dass bevor das wirklich in den C-Code reingeht, muss man halt das Global Interpreter Log im Zweifelsfall selber freigegeben, wenn es das nicht eh schon macht, also die Library, die man benutzt. Aber es ist im Prinzip möglich, also das Hashing, zum Beispiel, wird in der Standard-Programmatik einfach freigegeben bis Global Interpreter Log, sobald ich sage, rechnen wir den SHA256 von diesen Daten, macht er den Log frei. Kompression genauso, sobald ich in Zlib reingehe, sage ich hier schon megabyte Daten, bitte einmal komprimieren, macht er das Interpreter Log frei. Das heißt, ich habe, obwohl es Python ist, doch ein relativ gutes Multifredding, weil der eigentlich fast die ganze Zeit in irgendwelchen C-Codes drinsteckt oder irgendwelche I.O. macht. Der Python-Code ist ja nur so das Highlight-Bezeug. Was man noch tun muss in dem Bereich, ist der Reader Chunker, also da, wo das Ding zerhackt. Da sind zwar auch I.O.-Operationen dabei, die sind allerdings nicht in Python gestehen, sondern im C-Code. Und ich habe da keinen Log frei gegeben gesehen. Also den müsste man einfach noch einbauen. Genauso im Encryption-Code, da wo es Richtung OpenSSL geht, habe ich bisher auch nichts gesehen, dass der Log frei gegeben wird, müsste man genauso machen. Aber sobald man die zwei Sachen noch gefixt hat, müsste das Ding eigentlich ziemlich gut werden, dann im Multifredding. Ich habe mit dem vorhandenen Code gibt es ein extra Feature-Planche dafür, Multifredding. Da habe ich mal ein bisschen Experimente gemacht. Also mit dem normalen Borg hatte er also 30-80%-CPU-Lasche hingekriegt. Ist klar, der Rest von der Zeit hat er einfach gewartet für eine Ausgabe-Operation. Und die 30-80% sind bezogen auf einen einzelnen Core. Also wenn man da zwei Cores plus Hyper-Fredding hat, war das meist eigentlich gelangbar dargelegen. Ich habe dann den Code mit Multifredding getestet und der ist immerhin auf 300% gekommen. Kommt halt durch die Kompression, da gibt es eigentlich genug zu tun, Krypto und so weiter. Und er hat halt keine Zeit mehr damit verblämmert, indem er einfach gewartet hat, bis es Daten kommen oder bis Daten weggeschrieben waren. Was mir allerdings auch vielen in dem Ganzen war, ich habe auf die CPU-Zeit, die er insgesamt für einen bestimmten Job gebraucht hat, geguckt. Und mir ist aufgefallen, für diesen Backup-Job, der das normale Ethik hat praktisch 12 Sekunden CPU-Zeit verbraten und mein Multifredded Code war irgendwie bei 18 Sekunden oder so keine CPU-Zeit. Der Multifredded Code war trotzdem schneller fertig, weil diese 18 CPU-Sekunden sind dadurch auf 2-4 CPUs verteilt haben. Aber ich habe es trotzdem gewundert, was hat er in diesen 6 Sekunden getan, die er mehr verbraten hat? Weil er hatte eigentlich die gleichen Datenmengen zu Backupen. Es ist klar, so ein bisschen Overhead ist da, ich habe da so ein paar Cues, die da verwaltet werden müssen, aber ich hätte jetzt eigentlich nicht erwartet, dass es 50% Overhead sind. Also wenn da noch eine Idee hat, das versuche ich noch rauszukriegen. Aber wenn es... Irgendwelche Cache-Effekte können ich sagen. Also wenn verschiedene Fahrzeuge für deine Daten zu breit sind, dass die Cache so konzentriert werden müssen. Von der CPU-Cache? Ja, können das sein? Steckt es direkt in die CPU-Zeit rein? Ja, das kannst du mal in die Zukunft sehen. Die Sache ist, dass er da im Prinzip ein Speicher zu verpacken und alles was als Speicher zu zählen, wo er im Prinzip auf Speicher wartet. Das sehen wir als Zeit, dass es auch recht ist. Ja, das könnte es vielleicht nicht sein. Ja, das ist vielleicht eine Idee. Ich hatte so ein bisschen das Gefühl, vielleicht irgendwelche Semaphore wo irgendwie gepolt werden oder irgendwie so was. Ich weiß noch nicht, ob es das macht. Bei New Text kann es halt sein, dass der manchmal so ein Busybrake am Anfang macht, um halt zu gucken, ob sie überhaupt lohnt, jetzt in den Siebsteil zu gehen. Meiner Meinung nach sollte es sein. Ja, was ich gemerkt habe übrigens beim Programmieren könnte, ich denke, dass jeder, der schon mal multifredig war und programmiert hat, der nicht trivial war. Man muss natürlich ein bisschen auf Freizeit-Safety aufpassen, da kann man sie richtig leicht ins Knie schießen und so nette, tolle Race-Conditions kriegt man dann auch, die man vorher nicht hatte. Ich habe es aber dann mit so diversen Cues und so relativ gut hingekriegt, also momentan fliegt einem das Ding aber ist allerdings immer noch als experimentell zu betrachten. Also das ist noch nicht so ganz fertig. Was ich auch noch so ein bisschen als Forschungsbereich sehe im Ethik wurde halt SHA-256 verwendet. Und wer schon mal so diverse Haschfunktionen ausprobiert hat, wird wahrscheinlich wissen, das ist so eher eine von den Langsame. Selbst SHA-512 ist übrigens sobald ihr eine 64-bit CPU habt. Also ihr könnt, wenn ihr quasi ein 256-bit Hasch haben wollt, könnt ihr alpharen 512-bit Hasch rechnen und die Hälfte wegschmeißen, ihr seid schneller, wie wer in den Kürzenden genommen hättet. Also das ist einfach durch die CPU-Architektur bedingt. Und von daher ist die kliniale Optimierung halt, in den längeren zu nehmen und die Hälfte wegzuschmeißen. Was auch Borel, bzw. Ethik macht, das tut bevorst das Zeug in Storage reinschmeißen, nochmal eine CRC32 über alles drüber rechnen. Also über die eigenen Daten, wo es wegspeigert, plus die Hether, was dann zusätzlich generiert. Ich habe gesehen im Profile das CRC32-Zeug ist auch nicht so besonders schnell und es ist auch eine CRC32, wo nicht über CPU Instruktionen von Intel optimierbar ist, sondern gerade andere. Also von daher gibt es also Ideen, so ein Poly1305IS als MAC zu verwenden. C-Pesh ist wohl auch recht schnell. Das ist das, was Python allerdings intern verwenden hat übrigens den Haken. Da kommen nur 64 Bit raus. Das ist für so Backup-Daten ein bisschen wenig. Also weil der dritte Teil, dann das Geburtstagsparadox schon so ab 2.30 Uhr Chance auf und das ist meine Gegend, wo man wirklich hinkommt in der Praxis. Play2 ist auch ein relativ modernes Verfahren und die sind halt alles schneller, wie das, was wir da oben haben. XX-Hesh, das ist aus der gleichen Ecke wie das LZ4-Kompressionsverfahren. Also es schafft also auf ein Hunderte Megabyte pro Sekunde bis Gigabyte pro Sekunde Level. Das ist auch viel schneller. Ist allerdings kein kryptografischer Hesh, da muss man also aufpassen, wo man das genau verwendet. Sagt der Schaf 512 und wenn man den CRC32 ungefähr beibehalten wollte, dann würde man das CRC32C nehmen. Da gibt es eine intensive Instruktion dafür mit etwas Glück, wie wird es sogar genutzt. Dann wäre es also auch schon schneller, wo es eigentlich fast das Gleiche macht. Das ist noch eine Frage. Wie wissen die, warum da ein CRC32 verwendet wird, wenn auch sowieso für alle sehr... Ich habe genau zu dem Thema Ishyura eingeschmissen in den Ethic Tracker, weil die mich genauso gewundert haben, weil er hat so begründet, wenn man die Krypto anmacht, wird ein H-Mag und Verschlüsselung gemacht. Um den H-Mag zu kontrollieren, braucht man auch den Key dafür. Wenn ein Key nicht hat, kann man nicht kontrollieren, ob das Zeug okay ist. Wenn ich jetzt also praktisch eine serverseitige Depository Prüfung machen wollte, könnte ich nicht den H-Mag nehmen, weil der Server hat den Schlüssel nicht. Deshalb hat er wohl den CRC32 genommen, weil er den hat auf dem Server checken kann, aber ich habe bisher kein Code gesehen, wo das wirklich so auf diese Art macht. Normalerweise geht es alles eher um klein drüber. Also ich denke mal, das könnte man vielleicht ein bisschen unstrukturieren, dass es nicht alles doppelt Check-Summen drüberzieht. Also wenn er sich mit so Hashes auskennt, da wäre ich auch um eine Diskussion froh, zur Krypto noch exaktisch alles authenticated in Kryption associated data. Was Ethic standardweise macht, IS Counter-Mode plus dieser H-Mag und dazu verwendet er halt OpenSSL und die Python Standard Bibliothek. Es gibt schnellere Methoden, die eine habe ich schon implementiert, das GCM, das ist im Experimental-Panch drin und das ist ein Benchmark, das ist wirklich schneller wegen diesem Single Pass halt. Das IS GCM ist auch in OpenSSL drin, von daher war das einfach. Aber da gibt es einen kleinen Haken, ich habe einen Paper gefunden, wo einer GCM kritisiert, weil es wohl sehr, sehr selten, also wenn man Kies zufällig generiert, kann man wohl sehr, sehr selten ein Kie kriegen, der schwach ist. Und eigentlich, wenn man es genau nimmt, müsste man quasi die Kies in der Prüfung unterziehen, bevor man sie benutzt, um das Risiko völlig auszuschließen. Es ist aber wohl so selten, dass es wohl keine Bedeutung hat, aber es ist natürlich ein bisschen schlechtes Gefühl, irgendwo in der Magengegend. Wobei das halt nichts mit Ethik oder Borg zu tun, das ist vom GCM Verfahren generell. Also da ist so ein kleiner Haken, dann für die ganze Krypto brauchen wir immer so ein Initialisierungsvektor. Ich habe ja vorhin erwähnt, dass Ethik beziehungsweise Borg immer sich diesen Counter merken muss. Und da gab es auch etwas Kritik, wenn jetzt nämlich das Backup läuft und der Crest, bevor er fertig ist, dann hat er praktisch Krypto-Daten möglicherweise übers Internet geschickt und mit bestimmten Counter-Values verschlüsselt. Wenn der aber am Schluss sein Counter nicht speichert, weil der Crest, dann wird er vielleicht immer das Backup wiederholen, dann doch die gleichen Counter-Values noch mal benutzen. Und das könnte halt vielleicht Angräfer auch ausmützen und von daher machen. Und da gibt es halt zwei Entsätze, entweder Zufalls-Counter zu nehmen, also Zufalls-Initialisierungsvektoren, wobei da hat man dann andere Probleme, weil die muss man dann halt lang genug machen, sonst läuft man dann in Geburtstagsparadoxen wieder rein. Oder was man auch machen könnte, das ist seit ja die beste Idee, dass man Sessionkeys verwendet. Dass man nicht seinen Master-IS-Spüssel nimmt, um die Backups zu verspüssen, um einfach pro Backup, und vielleicht sogar pro Worker-Fred, wenn man Multithreading hat, ein Session-Key generiert und mit diesem Session-Key nur dieses eine Backup macht. Und dann kann man mit dem Counter immer bei Nullen anfangen, weil das ist jedes Mal ein neuer Key. Dann habe ich dieses Counter-Management nicht. In den Session-Key würde ich halt einfach mit den Daten dazuspeichern und halt mit meinem Master-Key verschlüsseln. Also, hört das sich ganz gut an, die Idee müsste man aber auch noch machen. Was ich auch noch vorhabe, ich habe es vorhin erwähnt, bei Krypto-Modus hat es ja zwei Modemen. Man kann einmal mit Passphrase arbeiten, da wird einfach der Key direkt von der Passphrase abgeleitet mit DWKTF2. Problem, wie vorhin schon erwähnt ist, ich kann meinen Passphrase da nicht ändern, weil sonst meine ganze Backups nicht mehr zugreifbar sind. Meine Idee ist, wo das Key-File benutzt, da funktioniert das so. Ich habe auf der lokalen Platte, auf dem Client habe ich ein Key-File liegen und nur das Key-File wird mit der Passphrase entschlüsselt und da stehen halt einfach irgendwelche Random Keys drin, die ich aber auch mit einem neuen Passphrase schützen könnte. Die Idee war jetzt einfach die, dass man dieses Key-File nicht auf dem Client speichert, sondern auf dem Server. Dass man das auf dem Client speichert, hat ja den netten Effekt von wegen ich habe es nicht aus der Hand gegeben, der Client gehört mir, der Remote Server gehört vielleicht in den Provider oder so, wo jemand anders dann rumfindet und ich brauche zusätzlich noch die Passphrase, also ich habe zwei so Sicherheitsfaktoren, einmal das Key-File, einmal die Passphrase. Wenn ich jetzt aber von vornherein sage, ich will nur eine Passphrase verwenden, ich will gar kein Key-File benutzen, dann habe ich eigentlich nur die Passphrase als einzelne Faktor. Und dann könnte ich genauso gut hergehen und ein Key-File beim Providerspeichern, also auf dem Back-Up-Server und das mit der Passphrase schützen. Dann habe ich genauso viel Sicherheit wie vorher. Hätte aber den Vorteil, dass ich die Passphrase ändern kann, weil die wirklichen Kliesen Key-Files stehen. Also das dachte ich, dass man das vielleicht ändern könnte und dass man diesen alten Passphrase mal das einfach raus schmeißt und nur die Location vom Key-File einmal halt lokal hat, oder halt wahlweise auf dem Server. Wenn man übrigens das Key-File lokal geback-upten Maschine hat, muss man dafür sorgen, dass man das Key-File separat back-upt. Wenn man das nicht macht, hat man zwar nachher ein Back-up, aber man kann es nicht entschlüsseln. Das wäre also blöd. Von daher, vielleicht lieber, diesen Alternativ-Modus, wo das Key-File auf dem Server liegt, da hat man dann dieses Problem hier nicht. Auch noch ein Problem im aktuellen Code und das sollte man auch erwähnen. Ich habe es vorhin schon angesprochen, ganz schlecht ist, wenn ihr ein Gerät habt mit wenig Ram und viel Platte dran, wenn ihr das back-upen wollt. Ich habe mal mit so diversen Daten ausgerechnet, wie man so den ungefähren Ramverbrauch von dem Ding berechnen kann. Und die Ausgangsbasis von allen ist also der Junk Count, also wie viele dieser Häppchen habe ich wahrscheinlich. Und das ist halt einfach die Gesamtmenge von Daten, die ihr back-upen wollt durch die mittlere Junkgröße, und dann kann man einfach berechnen, wie groß dieser Reboindex wird. Das ist halt einfach dieser Count mal 40 bytes. Man kann berechnen, wie groß der Junk Cache wird. Das ist auch der gleiche Count mal 44 bytes. Und der Files Cache da spielt dann die File Anzahl noch eine Rolle rein. Mal 240 bytes, bis der Junk Count mal 80 bytes. Und das alles zusammen geregnet ist ungefähr der Ramverbrauch von Borg. Das hört sich jetzt nicht nach viel an, weil da überall nur von bytes die Rede ist, aber das Problem ist halt, die haben tera bytes an Daten möglicherweise, und die haben vielleicht Millionen von Files. Und wenn du das dann da mal ausrechnet, Ups, falsche Richtung. Dann kann da also ein, eine Million Files, ein tera byte Daten, macht 2,8GB weiter. Wenn das jetzt ein normaler Service, dann egal. Aber wenn du ein NAS-Device habt, wo du da ein bisschen sparsam bestückt bist, dann kann halt sein, dass euch das RAM schon mal überläuft. Und dass der entweder halt's Wochen anfängt, was dann die Sache auch nicht schneller macht oder vielleicht gar gegen die Wand fährt, wenn halt einfach der virtuelle Speicher alle ist. Ja. Das sind mehrere Faktoren. Also der Regoindex, das ist einfach, dass er, wenn er eine JunkID hat, dass er weiß, in welcher Datei genau ist es drin, weil es wird auch so in größere Dateien geblockt. Und dann weiß er dann halt, wie heißt die Datei, welche Nummer ist es und an welchem Offset. Also in den Reboindex brauchen wir so oder so, dann guckt man schlecht dran vorbei. Der Junk's Cache, der dient dazu, dass die Software erkennen kann, was hab ich schon und was muss ich noch. Und da steht dann praktisch drin, die ID halt von dem Junk, die Größe, die komprimierte Größe und der Referenzcounter. Also der dient gleichzeitig auch dazu, die Referenzen zu zählen. Also da kommt auch ja die schlecht dran vorbei. Man könnte halt die Caches allenfalls einstatt im Rahmen halbe Flatte veranstalten, aber das macht es halt auch nicht schneller. Und der letzte, das ist der einfachste, den hab ich auch schon optional gemacht, also den könnt er abschalten, wenn er sieht, was für Dateien haben sich nicht geändert. Weil wenn ihr es mal ausprobiert, da hat die America das erste Backup da oben ein bisschen, wenn ihr aber direkt danach nochmal ein Backup anstattet, dann macht es fupp und nach ein paar Sekunden ist der fertig. Und es liegt dann in diesem Falscache, wenn der da halt drinnen steht, hat dieser Pfad, hat diese M-Time, hat diese I-Node, hat diese, was aber noch alles drin, die Größe hat er auch noch drin und die Junkliste hat er auch noch drin. Das heißt, der kann auf allen Blick schon an den Metadaten der Dateien erkennen, die hab ich schon, die muss ich nicht nochmal investieren. Und deshalb, wenn sich relativ wenig geändert hat, ist der Rasen schnell fertig. Also, incrementelle Backups sind wirklich ein Wohltat bei dem Tool. Und wenn ihr halt diesen Cash abschaltet, dann würdet ihr halt wirklich jede Datei nochmal zu hacken und erst bei dem Hack gehackten dann ach, das hab ich alles schon. Aber das ist dann halt längsamer, weil ihr halt einmal komplett mit Daten liest. Aber man kann da ja ziemlich viel sparen, weil da halt relativ große Faktoren dran sind. Also, wenn ihr wirklich so ein Nass-Divis habt und das verträgt das Ding nicht, dann habt ihr das momentan als Option halt diesen Falscache auszuschalten. Ja. Ja, das muss ich vielleicht noch dazu sagen. Das hat sich vielleicht ein bisschen falsch angehört. Also, es ist nicht so, dass es dann Vollbackup gibt und ein differenzielles Backup oder sowas. Das Konzept ist mehr so ein Snapshot-Konzept. Ich hab alsch immer komplette Snapshots. Ja. Und dass es halt zufällig der Überschneidungen gibt. Ja. Das hat jetzt nichts, das hängt halt an den Daten selber. Die wird halt auch einfach referenziert. Das ist nicht so, dass ich einmal das volle habe und einmal noch die Unterschiede obendrauf. Ja, ich hab praktisch immer das volle und nur die Referenzen auf die Datenplöcke sind halt teilweise auf die gleichen Datenplöcke. Also, ich hab jedes Backup ist ein voll Backup. Ich kann jedes Backup löschen und ich hab trotzdem alles andere immer noch da. Und erst wenn praktisch dieser Referenz kaum auf null geht, erst dann sagt das Tool, okay, ich kann diesen Backup löschen. Und praktisch, da werden ja auch die Referenzen gezählt. Nur, dass es halt unterhalb der Datei-Ebene ist auf diesen Chans. Also, das muss man ein bisschen im Auge behalten, wenn man halt so asymmetrische, sag ich jetzt mal, Systeme hat wenig Ram, viel Platte. Wenn ihr normales Server habt, habt ihr das Problem vielleicht nicht durch normale Clients. Was man halt machen kann, wenn man so ein System hat, halt gucken vielleicht, dass man ausreichend einen Pop hat oder halt diesen Filescash abschalten. Was man auch machen kann, ist natürlich nicht ein Riesenrepo produzieren mit Unterdrechnern drin, sondern halt, wenn man so ein System hat, hat dafür halt vielleicht extra Webpository machen und nur der eine drin ist. Einfach, dass die Chancanzahl nicht zu arg hochgeht. Was ich demnächst vorhab, ist diese Chancgröße noch zu modifizieren. Ihr habt ja in der Formel gesehen. Der Chanccount beschieren einigen Stellen drin. Also drei Stellen taucht der auf. Und wenn man die Chancgröße einfach größer macht, wenn man da nicht 64k nimmt, so ein halt megabyte, was ja heutzutage jetzt auch nicht wahnsinnig groß ist, dann geht es halt um Faktor 16 runter an der Stelle. Das heißt, diese Teile der Gleichung halt, die hinten dann viel weniger Einfluss, was nicht weggehen würde, ist natürlich ein Chanccount steht. Das kriege ich damit nicht weg. Aber überall, wenn Chanccount steht, das könnte ich also readyflake um Faktor 16 runterbringen. Hätte nur die Auswirkung, dass die Deplizierung ein klein bisschen schlechter wird, weil er halt einfach auf gröberem Niveau arbeitet. Aber ich habe es mal ausprobiert. In meinen Experimenten war es jetzt nicht so wild, dass man es von vornherein sagen würde, das will ich niemals haben oder so. Was wir auch machen können, ist, das ist ja praktisch der Hash-Wert vom Chanc, wenn ich dann Schad 256 nehme, ist klar, dann habe ich immer diese 256 Bit als Output. Also 32 Byte, mal vielen Chancs, was mir das Ramp füllt. Wenn ich da jetzt zum Beispiel von ISGCM diesen G-Hash nehmen, der hat nur 128 Bit Output, dann bräuchte er nur die halbe Menge in Ramm. Und 128 Bit ist noch genug, um dann Sicherheitsmarchen noch zu haben, dass wir da keine Kollisionen ums Versäne auftreten bei normalen Daten mingen. Also 2 hoch 64 als Chanczahl wäre praktisch so da, wo das Geburtstagsparadox ein anfingender Problem zu werden. Also das wäre praktisch genug. Das sind noch ein paar andere Ideen, was man machen könnte. Also man könnte vielleicht auch einfach andere Datenstrukturen nehmen. Momentan sind es einfach Hash-Tables, die im Ramm liegen. Hier ist im Prinzip der Hash-Wert vom Chunk in alle Regeln. Und der Weltyoword drin steht, sind halt so ein paar Integers. Also dadurch kommen diese 40 Bytes zustande. Wenn man da irgendwas finden würde, was mit deutlich weniger Daten im Ramm effizient arbeiten kann, können wir euch auch einfach eine andere Datenstruktur und ein 3D Rhythmus sehen. Oder man könnte diesen Ramm-Inhalt Memory-Mapen in die Datei rein, dass der quasi nur die Pages einlädt, die ihr gerade braucht. Da muss ich allerdings dazu sagen, das war vor einiger Zeit, war das in Ethics so. Und der Ethic-Augur hat es rausgenommen aufgrund von zu viel I.O. Also das Memory-Mapen scheint wohl nur der Theorie ganz toll zu sein und in der Praxis ist es irgendwie weniger toll. Also der hat es als Performance-Optimierung sogar explizit rausgenommen, obwohl er es eigentlich schon hatte. Was wir auch machen können, ist halt On-Disk-Code schreiben. Aber da habe ich halt die Befürchtung, dass es dann doch eher langsam wird, wenn man das versucht. Ja, das waren so die Interna. Ja, bin ich so weit durch mit den Folien. Wenn ihr noch Fragen habt oder so, dann können wir noch eine Frage untermachen, solange du stoppst. Die Zeitwerte ist ja relativ rum, aber wir haben zumindest keinen Vortrag gemacht. Also gerade als den On-Disk-Code weg eigentlich gibt es doch ein bisschen Freude von. Denn wenn mein nächstes Mal so ein System hat, was eben so Schweiterbegrenzt ist, und das mit 512 oder wenn Leute knuskig sind, gibt es ja noch weniger Schweiter. Dann hat man nicht als viele Alternativen die eine Variante ist, eben Swap-File zu haben. Das hat halt den Nachteil, dass das Programm bekommt und nicht mit, dass jetzt auf der Festplatte gearbeitet wird und so eine Festplatte, wenn man da die richtigen Zukunftsmuster hat, das ist halt immer noch größer und öfter langsamer als Schweiter, aber eben wahrscheinlich schneller, als wenn man denkt, da hängt irgendein Kamm hinter und da könnte man dann eben aufruppen, was sind jetzt Sachen, die nicht so zeitberechtig sind oder die man irgendwie anders lösen könnte, wenn man das zum Beispiel sagen könnte, jedenfalls mal für eine kurze Zeit zum Beispiel die Duplicierung implementieren und einfach mal alles auf die Platte schreiben und dann die Duplicierung im Prinzip hinterher machen, wenn wir wenigstens zu tun haben und Zeit haben, dann wäre das weg, hab ich zum Beispiel schon mal gemacht und dann geht man im Prinzip hinterher über und konfirmiert dann und dann wäre da zum Beispiel auch Performance eben eine Sache, wo man so das eine Gegner das andere abwägen kann. Mir fehlt übrigens eins noch ein, das habe ich vorhin vergessen in meinen Folien, was wir natürlich immer machen können, also angenommen, ich habe so ein Nass-Device, wo mittelig Ramm hat und viel platte, ich kann dadurch eine andere Kiste nehmen und das Mountain, was da drauf liegt und dann die andere Kiste des Back-Up ausführen lassen, das hat natürlich die Auswirkung, dass das natürlich alles einmal mehr übers Netz geht, aber ich habe dafür das Rammproblem nicht, weil jedes andere Gerät deutlich mehr Ramm in aller Regel hat. Also das wäre auch eine Möglichkeit, was man machen könnte. Also nachträglich detoblizieren, das ist vielleicht auch eine Idee, ich muss mal überlegen, ob das irgendwie sinnvoll machen kann mit der Krypto, wird es dann halt ein Problem? Ja, die Krypto darf nicht mehr leben und es ist eine Sache, die man auf jeden Fall sofort machen kann und nicht verschieben kann. Aber dann ist es so, wo jetzt im Prinzip die Worte zu uns da mal auch mal so ein bisschen vielleicht die Goldfahrer analysieren was weiß ich, irgendwie jeeper auf oder so Tuber laufen lassen, wo hakt es denn überhaupt? Also diese Chunk Caches, die wir noch nicht sehr oft benutzt, weil sobald er ein Hash von seinem Ding berechnet hat, will er halt wissen, hab ich's schon, hab ich's nicht und da bringt er jetzt irgendwie einer hat schon mal vorgeschlagen, ja, man könnte so ein LRU-Cache machen Ja, gut, das bringt mir aber nichts, weil die Hashes, die streuen einfach wild, da hab ich kein Last-Recent-U ist Pattern in aller Regel, also da würde ich das genau gar nichts bringen. Die LRU-Cache hat vor allem den Nachteil, wenn man halt so ein Backup macht, geht man halt einmal alles durch und im Prinzip schien sich das dann einfach die ganze Zeit mal weiter und da geht dann der LRU-Cache nichts. Ja. Ich kann mir vielleicht ganz vorstellen, wie am Ende das Backup aussieht, dass da ein Detail nicht in the directory geht. Es ist in the directory und da gibt's ein Rhythmie drin, wo er einfach drinstellt, ja, das ist ein Beug-Repository, da gibt's die Config-Datei, wo so ein paar harmlose Werte drinstehen, also wie viele Segmenten pro directory ich haben will, wie groß mein Segment ist und eine Repository ID, also eine Unique ID quasi, so ein Wert ist, der immer gleich bleibt. Und dann gibt's ein Data-Verzeugnis, unterhalb vom Data-Verzeugnis gibt's einfach durchnummerierte Verzeugnisse von 0 bis N und in jedem dieser Verzeugnisse liegen wieder M-Segment-Datei drin, die jede 5 MB groß sind und die einfach so lange gefüllt werden, bis sie die Größe haben und dann wird die nächste angefangen. Also diese Chance, wo der rein speichert, wird immer in so Segmenten gesammelt bis er 5 MB hat und dann fängt das nächste Segment an. Also man sieht da im Endeffekt gar nichts, man sieht nicht mal, welche Dateien Größen oder Namen oder irgendwas, also das ist eigentlich schon recht nett. Und auch wenn man so eine Repository mal durch die Gegend kopieren will und mit whatever Copy oder so, ist natürlich auch geschickt, dass diese Datei nicht so riesig groß sind. Das sind schön handlich. Die kommen so schön eine nach der anderen kopieren und gibt's auch keine Probleme mit. Das heißt, wenn er jetzt die Repository machen will, dann wird er weg. Das passiert schon vorher. Das hat mit diesen Segmenten hat es nichts zu tun. Ja. Wir rechnen ja in den Hash-Wert und unter, habe ich sie irgendwo an der Cash-Wert in einem Repo? Ja, genauer gesagt, das erkennt er schon an seinem Lokal. Also er hatte einen lokalen Cash, wo er genau weiß, im Prinzip, was er schon hat. Und wenn er den Cash nicht hat, übrigens baut er sich auf anhand von Repo-Daten. Und diese Prüfung macht er eigentlich immer mit seinem lokalen Cash. Das heißt, das liegt auch noch, ne? Das liegt lokal. Und daran weiß der sofort, wenn er diesen Hash berechnet hat, weiß der sofort, habe ich den im Repo oder habe ich ihn nicht. Zu dem Repo-Daten wenn ich einen letzten Wecker lösche und der Chef hier anscheint, muss jetzt gelöscht werden. Wie wird denn gelöscht? Also wie kommt geblieben, dass er mit 5 Megawatt in einem Reference-Counter macht? Ja, der macht das glaubt so. Das habe ich noch nicht so ganz genau angeguckt. Aber ich glaube, er macht Folgendes. Also der Referenz-Counter wird dann halt auf null geben, wenn da also gar keine andere Referenz mehr auf dieses Häppchen da ist. Und wenn er das merkt, macht er sich glaube in so eine Hinsdatei, ein Hinweis rein. Ja, also dieses eine Segment, wo das halt drin liegt, das könnte wir vielleicht mal neu aufbauen oder irgendwie beim nächsten Gelegenheit würde er das komplette Ding lesen und dann Neues erzeugen und das Alte dann wegschmeißen. Also der tut es quasi klar, dann einmal umkopieren. Ich weiß nicht, ob er es andauern macht oder nur so ab und zu mal, aber irgendwie so eine ARD-Fragmentierungsfunktion da drin. Aber generell erfasst das Alte nur in so weit an, als dass es einmal liest, die lücken dann halt quasi weglässt, also die, wo auf null sind dann ein neues aufbaut. Also so ungefähr erarbeitet ist. Wer ist denn bei uns die Frage? Ja, aber die Frage, ich kann es in der Praxis vorstellen, dass es gut funktioniert. Ich meine, ich glaube, wir haben es schon eingefagiert, weil da sind die irgendwelche Leute rausgegeben aus dem Dreck ab. Man könnte es ja sagen, dass es durch die hälschsten Prinzip quer durch sämtliche auf dem Server oder so etwas auszortieren. Ich weiß aber nicht, ob er das sofort macht. Also wie gesagt, den Bericht vom Code haben wir jetzt so genau angeguckt. Es kann auch sein, er sammelt erstmal ein Paar und macht es dann erst zurück. Wenn sie es lohnt. Es ist ja nicht nach hälschzortiert, das heißt, es ist halt wahrscheinlich dann nicht so. Es ist einfach so, der Reihe nach. Ja, okay, wenn dann einer Treiber aufkriegt, ist der wahrscheinlich, dass die der Treiber hauptsächlich eine also dadurch könnte es auch sein, dass es vielleicht sich häuft so ein bisschen. Weil halt, das ist wahrscheinlich ursprünglich halt wirklich eine Datei war, nicht nur ein Junk, der irgendwie rausfiel und dann wird es sich da wahrscheinlich sogar lokal ein bisschen hauptsächlich nicht weidstreuen. Aber ich habe es schon probiert, ich habe schon Backups rausgelöscht, also das Wurstshut halb kurz und ist fertig, also das ist kein großes Problem. Das Tool hat übrigens auch eine nette Grundfunktion, wo man sagen kann, ich habe auch über den Tag quasi den letzten 24 Stunden meine stündlichen Backups, also wenn ich welche mache, ja, und die letzten sieben Tage bitte die täglichen aufheben und die letzten 50 Wochen bitte die wöchentlichen aufheben und die letzten fünf Jahre bitte die monatlichen aufheben. Also das kann man in praktisch einem Kommentor sagen, so will ich es haben und dann geht er her und tut es praktisch automatisch auszudem, dass es diesen Regeln entspricht. Also es ist sehr komfortabel an der Stelle. Dann haben wir die Einregungen. Wer programmiert nochmal ein Python und will jetzt mitmachen oder Security Redues, wir haben auch gern gesehen, dass sich jetzt jemand mal noch mit den weiteren Paar Augen anguckt. Also gibt es viel zu tun. Ja, wenn nichts mehr ist, würde ich sagen, schaut es einfach mal an. Entweder Attic oder Borg, je nach Lüschten, Laune, probiert es mal aus. So, die paar Problemen, die aufdrehen können, wisst ihr jetzt. Aber sagen wir so, solange du nicht allzu große Backups habt, werdet ihr wahrscheinlich die nicht haben. Also da ist es erst so im Tera-Arbeitbereich, wo man reinläuft, dass wenn man es nur sein Laptop backappen will, hat man wahrscheinlich das Problem noch nicht. Und wie gesagt, es wird auch gelöst werden. Also ich werde da einfach die junkgröße hochsetzen, dann ist das erstmal eine Weile weg, bis man eine bessere Lösung hat. Danke und viel Spaß noch.