WEBVTT

00:00.000 --> 00:02.000
Working-Draft-Revision 551.

00:30.000 --> 00:35.000
Diese Revision von Working-Draft wird euch präsentiert von Hörerinnen und Hörern wie euch.

00:35.000 --> 00:39.000
Auf patreon.com slashworkingdraft könnt ihr uns ein paar Euro in den Hut werfen.

00:39.000 --> 00:46.000
Aus euren Beiträgen und unseren gelinglichen Werbeeinnahmen bezahlen wir allerlei teure Software-Abus und das Honorar unserer Audio-Producerin.

00:46.000 --> 00:51.000
Wenn ihr euch auch beteiligen wollt, könnt ihr das unter patreon.com slashworkingdraft sehr gerne machen.

00:51.000 --> 00:54.000
Wir danken euch tausendfach für die Unterstützung und fürs weitere Zuhören.

00:54.000 --> 01:02.000
Hallo und herzlich willkommen zu Working-Draft Nummer 551.

01:02.000 --> 01:04.000
Heute sind am Start der Hans.

01:04.000 --> 01:05.000
Ja, hallo.

01:05.000 --> 01:10.000
Meine Wenigkeit der Peter und wir haben einen Gast zu Gast, nämlich den Alex. Moin Alex.

01:10.000 --> 01:12.000
Moin zusammen.

01:12.000 --> 01:15.000
Alex, du bist zum ersten Mal hier in der Sendung.

01:15.000 --> 01:18.000
Das heißt, du hast die Ehre, dich unserer zahllosen Hörerschaft mal eben kurz vorzustellen.

01:18.000 --> 01:20.000
Wer bist du? Was machst du dir? Wer hat dich reingelassen?

01:20.000 --> 01:26.000
Ich bin Alexander Neumann. Ich wohne in Aachen und ich habe mir 2014 mal überlegt, dass es eigentlich mal ganz cool wäre,

01:26.000 --> 01:28.000
einen gescheites Backup-Programm zu haben.

01:28.000 --> 01:32.000
Und weil es da nichts gescheites gab, habe ich eins implementiert.

01:32.000 --> 01:37.000
Es gab kein einziges gescheites Backup-Programm, diesseits der Baikal-Amur-Magistrale.

01:37.000 --> 01:40.000
Das dachte ich zumindest früher.

01:40.000 --> 01:44.000
Mittlerweile habe ich herausgefunden, es hätte eines gegeben und hätte ich gesucht.

01:44.000 --> 01:46.000
Ordentlich hätte ich das wahrscheinlich auch gefunden.

01:46.000 --> 01:48.000
Das hieß Ethik damals.

01:48.000 --> 01:54.000
Aber es gibt viele Backup-Programme und jedes hat seine eigenen Spezialitäten und Vor- und Nachteile.

01:54.000 --> 01:58.000
Und ich habe zwischendurch auch seit 2014 mal gesammelt, was es alles am Backup-Programm gibt.

01:58.000 --> 02:00.000
Das ist eine riesen Liste mittlerweile.

02:00.000 --> 02:02.000
Und es gibt nichts, was es nicht gibt.

02:02.000 --> 02:04.000
Aber damals gab es nichts gescheites, dachte ich.

02:04.000 --> 02:06.000
Okay.

02:06.000 --> 02:10.000
Dann wollen wir doch einfach mal so bei den Basics anfangen, oder?

02:10.000 --> 02:13.000
Also, weil wenn ich jetzt mal so mich so umgucke in meiner Umgebung hier.

02:13.000 --> 02:16.000
Und ich frage irgendwie so die ersten fünf Leute, die mir mal weglaufen.

02:16.000 --> 02:18.000
Jo, was hältst du von Backups?

02:18.000 --> 02:20.000
Dann sagen die, aha, ja.

02:20.000 --> 02:24.000
Vor zwei Monaten habe ich hier mal irgendwie die wichtigsten Dokumente auf diesen USB-Stick gezogen.

02:24.000 --> 02:26.000
Zählt das tatsächlich schon als Backup?

02:26.000 --> 02:28.000
Oder ist das mehr so eine Verzweiflungstat?

02:28.000 --> 02:30.000
Was würdest du sagen?

02:30.000 --> 02:32.000
Das Verzweiflungstat klappt schon ganz gut.

02:32.000 --> 02:39.000
Ich hatte auch schon im Bekannten- und Familienkreis Leute, die ihre Masterarbeit wirklich nur auf einer Festplatte eines Laptops abgespeichert haben.

02:39.000 --> 02:41.000
Und dann war die plötzlich weg.

02:41.000 --> 02:43.000
Und das war ein Riesendrama.

02:43.000 --> 02:45.000
So ähnlich ist das ja dann da auch.

02:45.000 --> 02:50.000
Also das Problem an Backup ist, dass ja eigentlich eigentlich niemand Backup, alle wollen Restore.

02:50.000 --> 02:55.000
Weil das Backup ist ja das nervige, was alle immer versuchen, möglichst weit von sich wegzuschieben.

02:55.000 --> 02:58.000
Aber wenn ich es dann mal brauche, das ist dann der Punkt, wo es interessant wird.

02:58.000 --> 03:01.000
Und da ist dein USB-Stick von vor drei Monaten.

03:01.000 --> 03:03.000
Wo ist denn der?

03:03.000 --> 03:05.000
Kann man die Daten noch lesen?

03:05.000 --> 03:09.000
Hast du eine Ahnung, welche Revision deines Dokuments das denn ist, die da drauf ist?

03:09.000 --> 03:13.000
Ist in den letzten drei Monaten irgendetwas Relevantes passiert, möglicherweise?

03:13.000 --> 03:16.000
Ja, genau. Hast du weitergeschrieben? Hast du nicht weitergeschrieben?

03:16.000 --> 03:19.000
War das bevor du den Kaffee über deinen Laptop gekippt hast?

03:19.000 --> 03:20.000
Oder danach?

03:20.000 --> 03:22.000
Oder bevor die Katze über die Tastatur gelaufen ist?

03:22.000 --> 03:24.000
Das sind alles so Fragen.

03:24.000 --> 03:27.000
Da muss man sich schon ein bisschen mit beschäftigen.

03:27.000 --> 03:30.000
Und das geht uns am Ende des Tages, geht uns IT-Worker das irgendwie alle an.

03:30.000 --> 03:35.000
Und ja, klar kann man sagen, wenn ich jetzt hier meinen Code entwickelt, dann habe ich ein Gitre-Pository.

03:35.000 --> 03:39.000
Aber wenn ich das Lösche noch nicht gepusht habe, dann ist das trotzdem ungünstig.

03:39.000 --> 03:43.000
Weil das wäre jetzt tatsächlich so mein erster Ansatz.

03:43.000 --> 03:47.000
Ich tatsächlich betrachte diese Gitre-Positories in meiner persönlichen Backup-Strategie,

03:47.000 --> 03:50.000
also zumindest mal ein Baustein.

03:50.000 --> 03:55.000
Also ich habe halt so ein ganz normales Backup, wo mir halt so das in Ubuntu eingebaute Dingen

03:55.000 --> 03:58.000
mehr da was auf eine andere Festplatte spiegelt und so ähnliches.

03:58.000 --> 04:02.000
Aber ich denke halt eben so gemäß des Eichhörnchen-Prinzips ist es ja zumindest nicht verkehrt,

04:02.000 --> 04:08.000
wenn man halt Git und ähnliches hat, um, sagen wir mal, Redundanz einfach sozusagen

04:08.000 --> 04:11.000
jetzt nicht komplett versehentlich herzustellen.

04:11.000 --> 04:16.000
Aber sozusagen dem Zufallsfaktor irgendwo wird sich das dann schon verteilen.

04:16.000 --> 04:19.000
Zumindest Raum gibt und das auch ein bisschen mit einplanet.

04:19.000 --> 04:22.000
Ist das Teil einer validen Backup-Strategie oder bild ich mir was ein?

04:22.000 --> 04:25.000
Nee, auf jeden Fall. Das ist auf jeden Fall Teil einer Backup-Strategie.

04:25.000 --> 04:29.000
Das Problem ist, wenn dein Server gerade nicht erreichbar ist, weil bei OVH das Rechenzentrum abbrennt

04:29.000 --> 04:33.000
und du dann den Kaffee über deinen Laptop kippst, dann ist das trotzdem ungünstig.

04:33.000 --> 04:38.000
Also es gibt da ja immer, das Leben, es gibt nichts, was es nicht gibt, das Leben findet immer einen Weg,

04:38.000 --> 04:41.000
dir im Zweifelsfall den Weg zu deinen Backups zu erschweren.

04:41.000 --> 04:45.000
Und das Projekt, was wir gestartet haben, das heißt RESTIC,

04:45.000 --> 04:49.000
und da haben wir auch so ein bisschen gesammelt, was Leuten schon alles passiert ist.

04:49.000 --> 04:54.000
Und es ist ganz erstaunlich, wie viel hart wer doch kaputt geht, wenn man mal genauer hinschaut.

04:54.000 --> 04:58.000
So die Festplatte, auf die man das vor drei Monaten noch geschoben hat,

04:58.000 --> 05:01.000
wenn die nicht mehr lesbar ist, weil die Festplatte einfach den Geist aufgegeben hat,

05:01.000 --> 05:03.000
dann ist das auch sehr ungünstig.

05:03.000 --> 05:08.000
Ja, also ich glaube, es kennt jeder diesen Anwendungsfall irgendwie,

05:08.000 --> 05:11.000
man hat vermeintlicherweise doch irgendwo ein Backup.

05:11.000 --> 05:15.000
Ich habe das auch noch von irgendeiner, keine Ahnung, Musik von früher,

05:15.000 --> 05:20.000
aber wenn ich jetzt heute die Festplatte anschließe, funktioniert irgendwie gar nichts.

05:20.000 --> 05:23.000
Wir haben jetzt aber über verschiedene Sachen gesprochen.

05:23.000 --> 05:27.000
Einmal so Code, den wir halt über GitHub pflegen

05:27.000 --> 05:34.000
und da mit irgendwie so eine Art Backup by Design oder verteiltes Backup by Design machen irgendwie so.

05:34.000 --> 05:40.000
Wir haben über Files gesprochen, wie jetzt mein Word-Dokument mit der Masterarbeit,

05:40.000 --> 05:47.000
was wir auf die Festplatte, Entschuldigung, oder externe Festplatte oder USB-Stick ziehen.

05:47.000 --> 05:51.000
Und dann fällt mir halt auch noch so was ein, wie Daten in der Datenbank,

05:51.000 --> 05:57.000
die man halt irgendwie auch ständig mal updaten oder Backupen möchte,

05:57.000 --> 06:05.000
um da halt ein valides Datensatz zu haben, den ich im Notfall, was ja schon gesagt, restoring kann.

06:05.000 --> 06:09.000
Jetzt, was ich mich so frage, ist das alles das Gleiche?

06:09.000 --> 06:11.000
Ist Backup gleich Backup?

06:11.000 --> 06:14.000
Oder was sind so da die Unterschiede?

06:14.000 --> 06:16.000
Das ist eigentlich eine sehr gute Frage.

06:16.000 --> 06:18.000
Am Ende des Tages sind es ja alles Daten.

06:18.000 --> 06:23.000
Das Problem ist so ein bisschen, dass unterscheidet sich dann in den Feinheiten dann doch,

06:23.000 --> 06:28.000
weil so eine SQL-Datenbank, da kann ich zwar die Dateien sichern, auf die der SQL Server das geschrieben hat,

06:28.000 --> 06:33.000
manche von diesen Programmen sind aber nicht besonders glücklich, wenn man denen einfach die Dateien wiedergibt.

06:33.000 --> 06:38.000
Da wäre es besser, wenn man erstmal eine SQL-Damp macht, das dann sichert und das dann wiederherstellt.

06:38.000 --> 06:44.000
Bei den Familienfotos ist es eigentlich egal, die sichere ich als Dateien, kann sie als Dateien wiederherstellen.

06:44.000 --> 06:48.000
Da ist eher dann interessant, was sind die Metadaten zu diesen Dateien?

06:48.000 --> 06:50.000
Wann habe ich die gemacht, wann habe ich die verändert?

06:50.000 --> 06:55.000
Das Word-Dokument, das ist die Masterarbeit, das ist dann nochmal so ein bisschen was anderes,

06:55.000 --> 06:59.000
weil das ein einziges Dokument ist, was sich die ganze Zeit verändert.

06:59.000 --> 07:01.000
Es gibt auch noch viel mehr Daten.

07:01.000 --> 07:04.000
Also wenn man jetzt auf einem Linux-System, auf irgendeinem Server mal schaut,

07:04.000 --> 07:09.000
dann hat man ja ganz viele Daten, wo man eigentlich denkt, die wären gar nicht so spannend zu sichern,

07:09.000 --> 07:13.000
weil welche Programme ich da jetzt installiert habe, die kann ich ja jederzeit wieder installieren.

07:13.000 --> 07:15.000
Ist ja überhaupt kein Problem.

07:15.000 --> 07:19.000
Aber wenn ich es dann in der Praxis doch tun muss, dann ist das doch schon ganz schön viel Arbeit.

07:19.000 --> 07:24.000
Also gerade wenn ein Server nicht mehr erreichbar ist und auch nicht mehr wiederhergestellt werden kann,

07:24.000 --> 07:28.000
dann from scratch zu starten, das ist doch schon erheblich aufwendig.

07:28.000 --> 07:33.000
Und am Ende des Tages läuft es immer darauf hinaus, was man sichern müsste, sind dann halt die Daten,

07:33.000 --> 07:35.000
also die Inhalte, aber auch die Metadaten.

07:35.000 --> 07:43.000
Welcher Dateiname, mit welchem Modifikationszeitpunkt, mit welchen Berechtigungen war, in welchem Verzeichnis abgelegt.

07:43.000 --> 07:47.000
Wenn man das nachher nicht mehr hat, das hat jeder kennt das, der schon mal versucht hat,

07:47.000 --> 07:50.000
Fotos von einer kaputten SD-Karte zu kratzen.

07:50.000 --> 07:55.000
Da gibt es Fotorecovery-Software, die stellt aber nur die Inhalte wieder her und nicht die Dateinamen.

07:55.000 --> 07:58.000
Wenn man das dann nachher zuordnen muss, das ist eine heiten Arbeit.

07:58.000 --> 08:00.000
Das will man eigentlich auch nicht.

08:00.000 --> 08:05.000
Das heißt ja eigentlich, für unterschiedliche Szenarien braucht man auch unterschiedliche Strategien,

08:05.000 --> 08:10.000
wie man Daten backup, also was mir so irgendwie sofort in den Sinn kommt.

08:10.000 --> 08:14.000
Ich bin hier Mac-Nutzer, da schließe ich halt mein Time Machine Backup an

08:14.000 --> 08:19.000
und dann im Idealfall musste ich nicht nochmal die ganze Festplatte runterziehen,

08:19.000 --> 08:21.000
sondern macht halt ein inkrementelles Backup.

08:21.000 --> 08:25.000
Das bedeutet gehen wir wahrscheinlich jetzt gleich mal noch drauf ein im Detail,

08:25.000 --> 08:30.000
sodass halt nur die Sachen, die Änderungen sozusagen gespeichert werden.

08:30.000 --> 08:32.000
Wenn ich mir mal angucke, wie ganz viele Moderne,

08:32.000 --> 08:38.000
sagen wir mal online Tools, wo ich irgendwelche Texteschreibe oder ähnliches, Datenbackup,

08:38.000 --> 08:42.000
dann kann ich auch immer durch die, du hast es vorhin schon angesprochen, Revisionen skippen.

08:42.000 --> 08:46.000
Und für meine Datenbank will ich das vielleicht genauso machen,

08:46.000 --> 08:52.000
wo ich das so sage, gibt es überhaupt andere Möglichkeiten oder will ich überhaupt was anderes?

08:52.000 --> 08:56.000
Eigentlich willst du dir ja um Backup möglichst wenig Gedanken machen.

08:56.000 --> 08:58.000
Und das ist eigentlich so der zentrale Kernpunkt,

08:58.000 --> 09:01.000
weil im Endeffekt nachher sind es ja nur Bytes, die du irgendwie sicherst.

09:01.000 --> 09:03.000
Da gibt es cool, da gibt es Metadaten dazu.

09:03.000 --> 09:06.000
Und es sollte vielleicht auch irgendwie Speichereffizient sein,

09:06.000 --> 09:09.000
aber abgesehen davon finde ich es eigentlich das allerwichtigste,

09:09.000 --> 09:12.000
das sollte so automatisiert wie möglich sein.

09:12.000 --> 09:16.000
Weil ich habe mich früher immer, es ist jetzt früher, ist jetzt 2014 aber auch davor,

09:16.000 --> 09:19.000
ich habe mich immer gefragt, wie kann ich das so machen,

09:19.000 --> 09:22.000
dass selbst ich, ich bin faul, da gebe ich zu.

09:22.000 --> 09:24.000
Ich bin nicht sonst Entwickler auch teilweise,

09:24.000 --> 09:26.000
denn wir Entwickler sind ja alle auch immer dazu geneigt,

09:26.000 --> 09:30.000
den Weg des geringsten Widerstands zu gehen, das kennt ihr ja auch sicher.

09:30.000 --> 09:35.000
Und ein Backup muss, das muss flutschen, weil sonst mache ich das nicht.

09:35.000 --> 09:39.000
Und da gehört halt alles Mögliche dazu, da gehört dazu nur die nötigsten Daten zu sichern

09:39.000 --> 09:41.000
und das auf eine Weise, die möglichst effizient ist.

09:41.000 --> 09:44.000
Dazu gehört aber auch, wenn ich irgendwo im Urlaub bin

09:44.000 --> 09:47.000
und am Code Weiter Bastel, das habe ich ja auch schon gemacht,

09:47.000 --> 09:49.000
wenn ich vielleicht irgendwie nur so das schäppige Hotelwifi,

09:49.000 --> 09:52.000
dann soll das vielleicht trotzdem einfach schnell gehen.

09:52.000 --> 09:55.000
Und ich möchte mir gar nicht so viele Gedanken darum machen,

09:55.000 --> 09:57.000
ich möchte jetzt ein Backup machen.

09:57.000 --> 09:59.000
Okay, ich muss diesem Snapshot jetzt einen Namen geben.

09:59.000 --> 10:01.000
Hm, welchen nehme ich denn da?

10:01.000 --> 10:03.000
Das ist zu viel, das muss einfach, das muss einfach flutschen.

10:03.000 --> 10:06.000
Ich starte mein Skript, es sichert das und alles prima

10:06.000 --> 10:09.000
und ich habe nachher trotzdem irgendwie die Metadaten.

10:09.000 --> 10:13.000
Weil wenn man das Backup, wenn der Backup selber als Vorgang zu viel Reibung hat,

10:13.000 --> 10:15.000
dann machen es Leute nicht.

10:15.000 --> 10:18.000
Das heißt, ich bin eigentlich damit gestartet,

10:18.000 --> 10:21.000
wenn man irgendein Programm, irgendein Tool entwickelt,

10:21.000 --> 10:24.000
das muss eigentlich dieser Vorgang Backup, der blöd ist,

10:24.000 --> 10:26.000
der muss so reibungslos wie möglich sein

10:26.000 --> 10:28.000
und der muss so schnell wie möglich sein,

10:28.000 --> 10:30.000
damit es Leute machen.

10:30.000 --> 10:33.000
Weil je mehr Reibung, desto weniger Leute machen das.

10:33.000 --> 10:36.000
Ja, also das ist auch so was, was ich mir denke.

10:36.000 --> 10:39.000
Also am allereinfachsten ist es ja sozusagen,

10:39.000 --> 10:41.000
du musst dir gar keine Gedanken machen,

10:41.000 --> 10:44.000
irgendwo läuft eine Art Skript, wie du sagst,

10:44.000 --> 10:46.000
per Groundjob wird es ausgeführt sozusagen.

10:46.000 --> 10:48.000
Und jetzt nehme ich wieder meinen Time Machine Backup,

10:48.000 --> 10:52.000
wenn ich hier zu Hause bin und schließ halt meine externe Festplatte an,

10:52.000 --> 10:56.000
dann wird das Backup halt gemacht auf diese Platte.

10:56.000 --> 10:58.000
Dann musst du die Platte aber erstmal physisch anschließen

10:58.000 --> 11:00.000
und du musst physisch zu Hause sein.

11:00.000 --> 11:02.000
Das gehört zu deiner Strategie dann dazu.

11:02.000 --> 11:05.000
Genau, und das ist halt ein Riesenproblem,

11:05.000 --> 11:08.000
weil ich habe es in der Vorbesprechung schon kurz gesagt,

11:08.000 --> 11:10.000
die Platte liegt hier neben dem Computer.

11:10.000 --> 11:14.000
Nein, jetzt worst case angenommen, ich gehe raus,

11:14.000 --> 11:16.000
mein Computer wird mit der Platte geklaut

11:16.000 --> 11:20.000
oder es entzündet sich ein kleines Feuer

11:20.000 --> 11:23.000
oder es gibt einen Strom Kurzschluss oder wie auch immer,

11:23.000 --> 11:25.000
und die Geräte gehen kaputt.

11:25.000 --> 11:28.000
Es ist ja sozusagen worst case, ja.

11:28.000 --> 11:30.000
Dann ist ja beides weg.

11:30.000 --> 11:33.000
Genau, d. h. Daten und das Backup.

11:33.000 --> 11:37.000
Genau, d. h. eigentlich ist meine Backup-Strategie

11:37.000 --> 11:40.000
in dem Fall ja überhaupt nicht ausreichend.

11:40.000 --> 11:42.000
Dann könntest du dir ja überlegen,

11:42.000 --> 11:45.000
eine Version deines Backups in die Cloud zu legen.

11:45.000 --> 11:51.000
Irgendwo AWS S3 oder Google Drive oder Dropbox oder sonst was.

11:51.000 --> 11:53.000
Das Problem ist, das willst du ja vielleicht

11:53.000 --> 11:56.000
mit der Masterarbeit, könnte ich mir das gut vorstellen.

11:56.000 --> 11:58.000
Das sind ja meistens keine so wahnsinnig geheimen

11:58.000 --> 12:00.000
Forschungsinformationen, aber wenn es da um

12:00.000 --> 12:02.000
deine privaten Fotos geht, dann willst du das ja

12:02.000 --> 12:04.000
vielleicht nicht unbedingt.

12:04.000 --> 12:06.000
Und das ist so der Punkt, da bin ich damals gestartet.

12:06.000 --> 12:09.000
Ich hatte auch so Festplatten, die ich neben dem Rechner

12:09.000 --> 12:11.000
in so einem Einsteck SATA Gehäuse,

12:11.000 --> 12:13.000
wo man die immer nicht ein- und ausbauen muss.

12:13.000 --> 12:16.000
Und dann habe ich mir überlegt, das ist vielleicht gar nicht so gut,

12:16.000 --> 12:18.000
weil dann, wenn die Festplatte doch mal im Hierunter fällt,

12:18.000 --> 12:20.000
dann ist es ja blöd.

12:20.000 --> 12:22.000
Dann haben wir uns mit mehreren Leuten zusammengetan,

12:22.000 --> 12:23.000
irgendwo einen kleinen Server gemietet,

12:23.000 --> 12:24.000
und dann war halt das Problem.

12:24.000 --> 12:26.000
Da gab es natürlich auch noch andere Leute,

12:26.000 --> 12:27.000
die administrativen Zugriff hatten.

12:27.000 --> 12:30.000
Und dann habe ich mir überlegt, ja, das ist ja vielleicht nicht so schön,

12:30.000 --> 12:32.000
wenn da andere Leute dann Zugriff auf meine Daten haben.

12:32.000 --> 12:35.000
Weil ich will mir ja genau vorher keine Gedanken machen müssen,

12:35.000 --> 12:38.000
welche inkriminierenden Bilder sind denn da jetzt dabei?

12:38.000 --> 12:40.000
Oder habe ich da irgendwie doch mal in meiner Shell History

12:40.000 --> 12:42.000
einen besonders dummen Befehl ausgeführt,

12:42.000 --> 12:44.000
den man nachher dann da sehen könnte.

12:44.000 --> 12:46.000
Und irgendjemand hat da Spaß dran.

12:46.000 --> 12:48.000
Und das ist dann der andere Punkt,

12:48.000 --> 12:50.000
dass ein Backup-Programm so gebaut sein muss,

12:50.000 --> 12:52.000
dass es auf der einen Seite Safety gibt.

12:52.000 --> 12:54.000
Also ich kann meine Daten wiederherstellen.

12:54.000 --> 12:58.000
Und auf der anderen Seite aber auch Security gibt,

12:58.000 --> 13:00.000
dass niemand anders außer mir an diese Daten rankommt,

13:00.000 --> 13:03.000
obwohl das vielleicht in irgendeinem Clouddeals liegt.

13:03.000 --> 13:07.000
Ja, und der Punkt, den du gerade so beiläufig gesagt hast,

13:07.000 --> 13:09.000
dann haben wir uns mal eben so ein Server besorgt.

13:09.000 --> 13:11.000
Ist natürlich jetzt auch was,

13:11.000 --> 13:14.000
dass so die in diesem Call versammelt und sicherlich hinkriegen würden.

13:14.000 --> 13:16.000
Aber da sind wir, glaube ich, die Ausnahme.

13:16.000 --> 13:20.000
Ja, man kann natürlich auch fertige Dienste benutzen.

13:20.000 --> 13:22.000
Also Dropbox zum Beispiel ist ein gutes Beispiel.

13:22.000 --> 13:24.000
Das kann man sich ja einfach fertig klicken.

13:24.000 --> 13:26.000
Und dann macht man da halt seine Backups drauf.

13:26.000 --> 13:28.000
Aber das muss dann auch wieder so sein,

13:28.000 --> 13:30.000
dass das irgendwie in ein Prozess eingebettet ist,

13:30.000 --> 13:32.000
dass man immer sagt, okay, immer abends,

13:32.000 --> 13:35.000
immer top ausmache, da schiebe ich einmal meine Daten in die Dropbox.

13:35.000 --> 13:37.000
So, das könnte man machen.

13:37.000 --> 13:40.000
Aber das sollte idealerweise ja auch automatisiert sein.

13:40.000 --> 13:43.000
Und auch Dropbox ist natürlich als amerikanische Firma.

13:43.000 --> 13:45.000
Die sind natürlich auch, das ist nicht garantiert,

13:45.000 --> 13:47.000
dass da nicht mal jemand anderes Zugriff drauf hat.

13:47.000 --> 13:49.000
Das heißt, eigentlich wäre es cool, wenn man da was hinlegt,

13:49.000 --> 13:51.000
das auch sicher zu verschlüsseln.

13:51.000 --> 13:56.000
Ja, cool beziehungsweise überhaupt durch zu argumentieren.

13:56.000 --> 13:58.000
Also ich sage das hier als in einem Haushalt

13:58.000 --> 14:01.000
mit einer im Medizinbereich tätigen Person sitzen,

14:01.000 --> 14:03.000
die an einer ja nicht Abschlussarbeit,

14:03.000 --> 14:05.000
aber sowas vergleichbaren werkelt.

14:05.000 --> 14:07.000
Und immer wenn ich halt eben sage, ja, Backup,

14:07.000 --> 14:10.000
aufwendig und anstrengend mit dem Computer und so.

14:10.000 --> 14:14.000
Da klickt ihr halt diesem Dienst, kostet nicht viel, ja, aber Datenschutz.

14:14.000 --> 14:16.000
Und das stimmt ja alles auch,

14:16.000 --> 14:18.000
weil das würde ich halt jetzt noch so in diesem Katalog

14:18.000 --> 14:20.000
von Anforderungen dazu packen.

14:20.000 --> 14:22.000
Das muss nicht nur alles so da sein,

14:22.000 --> 14:25.000
im Sinne von verschlüsselt und redundant und was nicht alles,

14:25.000 --> 14:29.000
sondern halt eben auch noch vertrauenswürdig muss es halt sein,

14:29.000 --> 14:31.000
also dir auch glaubt, dass du das bist.

14:31.000 --> 14:33.000
Und das wäre jetzt eben jetzt so, in deinem Szenario,

14:33.000 --> 14:34.000
ich kann dich da jetzt sitzen sehen.

14:34.000 --> 14:36.000
Hinter dir ist jetzt kein Man in Black zu sehen.

14:36.000 --> 14:38.000
Okay, sicherlich.

14:38.000 --> 14:40.000
Aber das ist halt relativ schwierig bei den meisten Softwareprodukten,

14:40.000 --> 14:42.000
die halt ein Landing-Page sind.

14:42.000 --> 14:44.000
Auf jeden Fall, ja.

14:44.000 --> 14:47.000
Da sollte eigentlich das System so im Design das drin haben,

14:47.000 --> 14:50.000
dass du sichere Verschlüsselung da drin hast,

14:50.000 --> 14:53.000
dass du dir da nicht so viel Gedanken drum machen musst,

14:53.000 --> 14:56.000
dass aber auch beim Wiederunterladen von Daten geprüft wird,

14:56.000 --> 14:58.000
sind die unmodifiziert hatte oder hat da irgendjemand dran rumgespielt.

14:58.000 --> 15:01.000
Das gehört alles eigentlich zu der guten Software mit dazu.

15:01.000 --> 15:03.000
Ja, und das wäre ja zum Beispiel so was,

15:03.000 --> 15:05.000
wo ich jetzt, wenn man Apple-Nutzer wäre,

15:05.000 --> 15:07.000
bei so was bei Time Machine sagen würde,

15:07.000 --> 15:09.000
das ist da ja gewährleistet,

15:09.000 --> 15:11.000
weil das kommt ja alles aus einer Hand.

15:11.000 --> 15:13.000
Das macht die Firma, die auch deinen Computer macht.

15:13.000 --> 15:15.000
Das heißt, wenn die dir was übelst will, hast du eh verloren.

15:15.000 --> 15:17.000
Also kannst du davon ausgehen,

15:17.000 --> 15:19.000
dass du diesen Trade-Off schon gemacht hast

15:19.000 --> 15:21.000
und einfach sagst, ja, das geht.

15:21.000 --> 15:23.000
Und das geht ja alles aus einer Hand.

15:23.000 --> 15:25.000
Hans hat ja den Workflow beschrieben.

15:25.000 --> 15:27.000
Das funktioniert ja alles relativ gut.

15:27.000 --> 15:29.000
Und das ist ja jetzt noch besser als Time Machine.

15:29.000 --> 15:33.000
Indem man im Prinzip bei Git abguckt,

15:33.000 --> 15:35.000
so bin ich da zumindest gestartet.

15:35.000 --> 15:38.000
Ich habe mir überlegt, man hat Daten, man hat Metadaten.

15:38.000 --> 15:40.000
Ich möchte ordentliche Verschlüsselung haben

15:40.000 --> 15:42.000
und es soll möglichst gut flutschen.

15:42.000 --> 15:44.000
Es soll möglichst einfach auch sein.

15:44.000 --> 15:46.000
Und da habe ich mir dann 2014 überlegt,

15:46.000 --> 15:48.000
ich wollte Ihnen ein Projekt haben,

15:48.000 --> 15:50.000
um mal die Programmiersprache Go zu lernen.

15:50.000 --> 15:52.000
Nicht das besser, als wenn man dann ein Projekt hat.

15:52.000 --> 15:54.000
Und dachte mir, ich baue mir das jetzt mal

15:54.000 --> 15:56.000
und ich rede auch mal mit meinen Kollegen.

15:56.000 --> 15:58.000
Ich arbeite als Penetrationstester.

15:58.000 --> 16:00.000
Und da ist es immer ganz gut,

16:00.000 --> 16:01.000
wenn man so in der Mittagspause

16:01.000 --> 16:03.000
dann mit ein paar Leuten mal zusammen brainstormt.

16:03.000 --> 16:05.000
Was wäre denn eigentlich nett?

16:05.000 --> 16:07.000
Und im Prinzip bin ich da hergegangen

16:07.000 --> 16:09.000
und habe erst mal gesagt, okay, es gibt Dateien,

16:09.000 --> 16:10.000
die enthalten Daten.

16:10.000 --> 16:12.000
Das ist eigentlich immer das, ob das jetzt ein SQL-Dump ist

16:12.000 --> 16:13.000
oder Familienfotos,

16:13.000 --> 16:15.000
ist eigentlich immer Dateien mit Daten drin.

16:15.000 --> 16:17.000
Es wäre ja eigentlich schon mal ganz schön,

16:17.000 --> 16:19.000
wenn man sich wenig überlegen müsste

16:19.000 --> 16:21.000
und nicht erst immer überlegen müsste,

16:21.000 --> 16:22.000
möchte ich jetzt ein Vollbackup

16:22.000 --> 16:24.000
oder ein inkrementelles Backup machen.

16:24.000 --> 16:26.000
Das ist das, was zu dem Zeitpunkt immer

16:26.000 --> 16:28.000
die Programme so unterschieden haben.

16:28.000 --> 16:30.000
Das heißt, bisher war es dann so,

16:30.000 --> 16:32.000
dass ein Programm ein Backup gemacht hat.

16:32.000 --> 16:34.000
Es hat alle Dateien in der irgendwo gesichert.

16:34.000 --> 16:36.000
Das macht auch Time-Machine so.

16:36.000 --> 16:38.000
Und wenn man das ein zweites Mal anstößt

16:38.000 --> 16:40.000
und sagt, ich will nur die Unterschiede sichern,

16:40.000 --> 16:42.000
dann werden immer nur die Dateien neu gespeichert,

16:42.000 --> 16:44.000
die sich seitdem verändert haben.

16:44.000 --> 16:46.000
Das ist ganz prima, weil es eben Speicherplatz spart.

16:46.000 --> 16:49.000
Ich brauche nicht jedes Mal die kompletten Dateien überall haben.

16:49.000 --> 16:51.000
Das hat den Nachteil aber,

16:51.000 --> 16:53.000
dass es bei einem Restore dann so ist,

16:53.000 --> 16:55.000
dass ich erst das letzte Vollbackup runterladen muss

16:55.000 --> 16:57.000
und dann seitdem alle inkrementellen Backups.

16:57.000 --> 16:59.000
Wenn ich einen Bild habe,

16:59.000 --> 17:01.000
was ich einmal abgespeichert habe,

17:01.000 --> 17:03.000
den nächsten Tag habe ich es bearbeitet,

17:03.000 --> 17:05.000
dann ist da eine Kopie von, dann habe ich es nochmal bearbeitet,

17:05.000 --> 17:07.000
dann ist da wieder eine Kopie davon,

17:07.000 --> 17:09.000
dann muss ich, wenn ich das komplett ein Verzeichnis wiederherstellen will,

17:09.000 --> 17:11.000
erst das Vollbackup runterladen, dann alle Dateien.

17:11.000 --> 17:13.000
Das fand ich irgendwie so konzeptuell.

17:13.000 --> 17:15.000
Das ist zwar schon ein Fortschritt gegenüber

17:15.000 --> 17:17.000
immer einem Vollbackup machen,

17:17.000 --> 17:19.000
aber da muss es ja noch irgendwas Besseres gehen.

17:19.000 --> 17:21.000
Dann habe ich mir überlegt,

17:21.000 --> 17:23.000
wie ist das denn mit Daten an sich?

17:23.000 --> 17:25.000
Die kann ich ja, wenn ich eine große Datei habe,

17:25.000 --> 17:27.000
dann kann ich die ja zum Beispiel in viele kleine Stückchen schneiden

17:27.000 --> 17:29.000
und die Stückchen einzeln abspeichern.

17:29.000 --> 17:31.000
Und wenn ich diese Stückchen irgendwo nochmal wiederfinde,

17:31.000 --> 17:33.000
dann würde ja eigentlich auch eine Referenz

17:33.000 --> 17:35.000
auf diese Stückchen reichen.

17:35.000 --> 17:37.000
Dann habe ich mal so ein bisschen rumgeguckt

17:37.000 --> 17:39.000
und habe einen ziemlich coolen Algorithmus gefunden.

17:39.000 --> 17:41.000
Der ist von einem Herrn namens Rabin

17:41.000 --> 17:43.000
damals entwickelt worden

17:43.000 --> 17:45.000
und das läuft auf sogenanntes Content-Defined-Chunking hinaus.

17:45.000 --> 17:47.000
Das ist jetzt schon mal ein ganz schöner Zungenbrecher.

17:47.000 --> 17:49.000
Die Idee dabei ist,

17:49.000 --> 17:51.000
dass man Dateien nicht als Ganzes sichert,

17:51.000 --> 17:53.000
sondern die in Stückchen auseinanderschneidet

17:53.000 --> 17:55.000
und dann diese Stückchen einzeln sichert.

17:55.000 --> 17:57.000
Und der Clou in der Sache ist,

17:57.000 --> 17:59.000
wenn ich vorne an so eine Datei 5-byte anhänge,

17:59.000 --> 18:01.000
dann ist das in meinem alten Backup-System

18:01.000 --> 18:03.000
mit vollen Inkrementell-Backup

18:03.000 --> 18:05.000
muss ich die Datei komplett nochmal sichern.

18:05.000 --> 18:07.000
Wenn man die Datei statisch

18:07.000 --> 18:09.000
in zum Beispiel ein megabyte große Stückchen teilt,

18:09.000 --> 18:11.000
dann sind alle Stückchen verändert,

18:11.000 --> 18:13.000
weil eben alle Grenzen sich um die 5-byte,

18:13.000 --> 18:15.000
die ich vorher vorne dran gehangen habe,

18:15.000 --> 18:17.000
verschoben haben.

18:17.000 --> 18:19.000
Und wenn man jetzt aber diese Schnittmarken

18:19.000 --> 18:21.000
dynamisch sucht und findet

18:21.000 --> 18:23.000
mit diesem Algorithmus,

18:23.000 --> 18:25.000
dann kann man halt erkennen,

18:25.000 --> 18:27.000
dass da am Anfang zwar 5-byte dazugekommen sind,

18:27.000 --> 18:29.000
aber ein megabyte weiter

18:29.000 --> 18:31.000
hinten diese Schnittmarke,

18:31.000 --> 18:33.000
die ist dann eben um 5-byte verschoben,

18:33.000 --> 18:35.000
da hat sich nur der erste Block geändert.

18:35.000 --> 18:37.000
Und das ist schon die erste Grundlage.

18:37.000 --> 18:39.000
Das heißt, der RESTIC, das Programm,

18:39.000 --> 18:41.000
geht her und schneidet alle Dateien

18:41.000 --> 18:43.000
in diese Stücke und speichert die einzeln ab.

18:43.000 --> 18:45.000
Die werden dann natürlich wieder zu größeren Dateien

18:45.000 --> 18:47.000
zusammen gesammelt

18:47.000 --> 18:49.000
und die werden auch sicher verschlüsselt

18:49.000 --> 18:51.000
und werden dann abgelegt.

18:51.000 --> 18:53.000
Und der zweite Teil, die Metadaten,

18:53.000 --> 18:55.000
werden im Prinzip als

18:55.000 --> 18:57.000
JSON-Dokumente, das kennen die Entwickler unter euch jetzt auch wieder,

18:57.000 --> 18:59.000
da wird dann abgelegt,

18:59.000 --> 19:01.000
da gibt es eine Datei, die heißt Test

19:01.000 --> 19:03.000
und da sind folgende Stückchen drin.

19:03.000 --> 19:05.000
Und dieses Stückchen identifiziert man einfach

19:05.000 --> 19:07.000
anhand der Schad 256-Hash

19:07.000 --> 19:09.000
von dem Inhalt.

19:09.000 --> 19:11.000
Das war jetzt ein bisschen technisch,

19:11.000 --> 19:13.000
aber im Prinzip ist das

19:13.000 --> 19:15.000
ein Interressable Storage.

19:15.000 --> 19:17.000
Das heißt, ich habe Daten, die werden adressiert

19:17.000 --> 19:19.000
aufgrund ihres Inhalts

19:19.000 --> 19:21.000
und dann sage ich einfach,

19:21.000 --> 19:23.000
die Datei besteht aus diesen Stückchen.

19:23.000 --> 19:25.000
Und schon hatten wir ein relativ gutes System,

19:25.000 --> 19:27.000
was gar keinen Unterschied mehr braucht

19:27.000 --> 19:29.000
zwischen Voll- und Inkrementellen-Backup.

19:29.000 --> 19:31.000
Was jedes Mal einfach nur hergeht,

19:31.000 --> 19:33.000
ein Dateibaum durchgeht

19:33.000 --> 19:35.000
und sagt, okay, den muss ich jetzt hier sichern

19:35.000 --> 19:37.000
und guckt, was liegen dafür Dateien drin?

19:37.000 --> 19:39.000
Was sind die Stückchen,

19:39.000 --> 19:41.000
diese Schnipsel dieser Dateien?

19:41.000 --> 19:43.000
Dann muss ich die neu speichern

19:43.000 --> 19:45.000
und anschließend Metadaten schreibt

19:45.000 --> 19:47.000
und sagt, in diesem Verzeichnis

19:47.000 --> 19:49.000
zu diesem Zeitpunkt lagen diese Dateien,

19:49.000 --> 19:51.000
die aus folgenden Schnipseln bestanden.

19:51.000 --> 19:53.000
Ja, das war's.

19:53.000 --> 19:55.000
Und das ist im Prinzip diese Idee.

19:55.000 --> 19:57.000
Dieses Chunking macht doch glaube ich

19:57.000 --> 19:59.000
so Zeug wie Dropbox auch,

19:59.000 --> 20:01.000
oder hat das dann nicht diese floating

20:01.000 --> 20:03.000
Chunkmarker?

20:03.000 --> 20:05.000
Da bin ich mir nicht sicher.

20:05.000 --> 20:07.000
Als ich da mal reingeguckt habe,

20:07.000 --> 20:09.000
haben sie glaube ich so feste Blöcke von,

20:09.000 --> 20:11.000
das ist aber relativ alt,

20:11.000 --> 20:13.000
also R-Sync hat das populär gemacht.

20:13.000 --> 20:15.000
Aber wenn man mit R-Sync eine Datei,

20:15.000 --> 20:17.000
das ist ein Tool auch für Linux Unix,

20:17.000 --> 20:19.000
eine Datei überträgt, wo sich

20:19.000 --> 20:21.000
in der Mitte irgendwas geändert hat,

20:21.000 --> 20:23.000
dann wird R-Sync feststellen

20:23.000 --> 20:25.000
auf beiden Seiten der Übertragung.

20:25.000 --> 20:27.000
Ich habe schon die Daten, ich muss nur das geändert übertragen.

20:27.000 --> 20:29.000
Da kommt ein sehr ähnlicher Algorithmus zum Einsatz.

20:29.000 --> 20:31.000
Wenn du jetzt sagst, dieser Algorithmus

20:31.000 --> 20:33.000
ist schon gut abgehangen.

20:33.000 --> 20:35.000
Was treibt denn andere Backup-Systeme dazu,

20:35.000 --> 20:37.000
den nicht auch zu verwenden?

20:37.000 --> 20:39.000
Das ist eine interessante Frage.

20:39.000 --> 20:41.000
Mittlerweile gibt es eine Reihe

20:41.000 --> 20:43.000
von Backup-Systemen, die das genauso machen.

20:43.000 --> 20:45.000
Die auch erkannt haben,

20:45.000 --> 20:47.000
dass das eine gute Idee ist.

20:47.000 --> 20:49.000
Ein großer Nachteil davon ist natürlich

20:49.000 --> 20:51.000
die etwas erweiterte Komplexität.

20:51.000 --> 20:53.000
Weil eine Datei in ein Megabyte Schnipsel

20:53.000 --> 20:55.000
auseinanderzuschneiden, ist natürlich viel einfacher,

20:55.000 --> 20:57.000
als die erst durchzugehen,

20:57.000 --> 20:59.000
um zu gucken, wo sind meine Schnippmarken.

20:59.000 --> 21:01.000
Das ist natürlich softwares Komplexitätsmäßig,

21:01.000 --> 21:03.000
könnte man sagen, ist das erhöhte Komplexität.

21:03.000 --> 21:05.000
Und es ist natürlich auch etwas

21:05.000 --> 21:07.000
aufwendiger, wenn man so eine Datei durchgeht,

21:07.000 --> 21:09.000
um Schnippmarken zu finden.

21:09.000 --> 21:11.000
Das dauert länger, als wenn man die einfach

21:11.000 --> 21:13.000
in statische Blöcke auseinander teilt.

21:13.000 --> 21:15.000
Aber ich vermute mal,

21:15.000 --> 21:17.000
dass bei so Sachen wie Komplexität

21:17.000 --> 21:19.000
und Performance dir da an der Stelle

21:19.000 --> 21:21.000
auch die Wahl deiner spezifischen

21:21.000 --> 21:23.000
Programmiersprache für das Projekt

21:23.000 --> 21:25.000
ziemlich entgegen kommt.

21:25.000 --> 21:27.000
Das könnte man so sagen,

21:27.000 --> 21:29.000
das hat von Anfang an sehr gut performt.

21:29.000 --> 21:31.000
Auf meiner damaligen Hardware,

21:31.000 --> 21:33.000
X220, Laptop von Lenovo,

21:33.000 --> 21:35.000
da hat das schon,

21:35.000 --> 21:37.000
ohne dass ich das jetzt groß optimiert habe,

21:37.000 --> 21:39.000
hat das schon mehrere hundert Megabyte

21:39.000 --> 21:41.000
Durchsatz gemacht,

21:41.000 --> 21:43.000
allein also dieser Algorithmus,

21:43.000 --> 21:45.000
um diese Schnittmarken zu finden.

21:45.000 --> 21:47.000
Weil das ist ja das, was als Allererstes

21:47.000 --> 21:49.000
immer auf alle Daten drauf muss,

21:49.000 --> 21:51.000
um zu gucken, welche Schnipsel habe ich,

21:51.000 --> 21:53.000
wo muss ich, welche muss ich noch speichern.

21:53.000 --> 21:55.000
Und das ging erstaunlich schnell dafür,

21:55.000 --> 21:57.000
dass das eine garbage-collectede Sprache ist

21:57.000 --> 21:59.000
und dafür, dass sich da auf einem sehr hohen Level

21:59.000 --> 22:01.000
unterwegs sein kann,

22:01.000 --> 22:03.000
um das C implementieren zu müssen.

22:03.000 --> 22:05.000
Weil das war auch ein Ziel,

22:05.000 --> 22:07.000
das auf jeden Fall nicht in C

22:07.000 --> 22:09.000
oder einer Manual Memory Management Sprache

22:09.000 --> 22:11.000
oder sowas zu schreiben.

22:11.000 --> 22:13.000
Also Rust gab es damals noch nicht,

22:13.000 --> 22:15.000
das war noch vor der 1. oder 1. Version von Rust

22:15.000 --> 22:17.000
und Go war gerade raus

22:17.000 --> 22:19.000
und da brutz sich das eigentlich an.

22:19.000 --> 22:21.000
Das hat sich als eine sehr gute Wahl erwiesen.

22:21.000 --> 22:23.000
Das war auch das, worauf ich eigentlich hinaus wollte.

22:23.000 --> 22:25.000
Also Performance, das eine, das andere natürlich auch.

22:25.000 --> 22:27.000
Unter dem Sicherheitsaspekt

22:27.000 --> 22:29.000
möchte man da nicht das Risiko eingehen,

22:29.000 --> 22:31.000
das ist egal, wie kompetent man ist,

22:31.000 --> 22:33.000
einem da irgendwie der Speicherabhanden kommt

22:33.000 --> 22:35.000
und dann kann der Evil Attacker

22:35.000 --> 22:37.000
Gott weiß was lesen.

22:37.000 --> 22:39.000
Ja, interessanterweise ist es auch gar nicht so sehr,

22:39.000 --> 22:41.000
also das, was das Projekt

22:41.000 --> 22:43.000
Rustic das Backup-Programm ausmacht,

22:43.000 --> 22:45.000
ist interessanterweise gar nicht so sehr,

22:45.000 --> 22:47.000
die Sprache.

22:47.000 --> 22:49.000
Ja gut, da wir jetzt Go genommen haben,

22:49.000 --> 22:51.000
das war natürlich sehr nett,

22:51.000 --> 22:53.000
weil man dadurch, dass das jetzt auch ein Hype war,

22:53.000 --> 22:55.000
die letzten Jahre, haben wir natürlich

22:55.000 --> 22:57.000
sehr viele Leute gefunden, die da mit dran entwickeln.

22:57.000 --> 22:59.000
Aber eigentlich, das allerwichtigste

22:59.000 --> 23:01.000
ist diese Spezifikation,

23:01.000 --> 23:03.000
wie sind die Daten abgelegt?

23:03.000 --> 23:05.000
Da gibt es tatsächlich bei uns einen Textdokument,

23:05.000 --> 23:07.000
wo das Repository-Format

23:07.000 --> 23:09.000
wirklich eins zu eins ziemlich ausführlich

23:09.000 --> 23:11.000
dokumentiert ist, außerhalb des Codes.

23:11.000 --> 23:13.000
Weil wenn jetzt in 20 Jahren,

23:13.000 --> 23:15.000
dann gibt es vielleicht Go nicht mehr oder sowas,

23:15.000 --> 23:17.000
wenn in 20 Jahren jemand herkommt und sagt hier,

23:17.000 --> 23:19.000
ich habe von meinem Vater irgendwie so ein Repository,

23:19.000 --> 23:21.000
ich habe da das Passwort noch, die Implementierung gibt es aber nicht mehr,

23:21.000 --> 23:23.000
dann soll der in der Lage sein,

23:23.000 --> 23:25.000
das auch wieder herstellen zu können, ohne die konkrete Implementierung zu haben.

23:25.000 --> 23:27.000
Und das ist auch wieder so ein bisschen,

23:27.000 --> 23:29.000
so eine User-Interface-Sache,

23:29.000 --> 23:31.000
dass wenn jemand sagt,

23:31.000 --> 23:33.000
er möchte ein Backup machen,

23:33.000 --> 23:35.000
dann möchte er eigentlich ja restoring können

23:35.000 --> 23:37.000
und das auch in 20 Jahren noch.

23:37.000 --> 23:39.000
Und da muss man mit dem Format,

23:39.000 --> 23:41.000
mit dem Speicherformat auch sehr vorsichtig sein

23:41.000 --> 23:43.000
und da sehr mit Bedacht ran gehen,

23:43.000 --> 23:45.000
wenn man da Änderungen macht.

23:45.000 --> 23:47.000
Aber das würde natürlich jetzt heißen,

23:47.000 --> 23:49.000
wenn das Repository-Format, also im Prinzip

23:49.000 --> 23:51.000
am Ende das Herz des Backups

23:51.000 --> 23:53.000
so sauber spezifiziert ist,

23:53.000 --> 23:55.000
dann kann ich ja theoretisch hingehen

23:55.000 --> 23:57.000
und mit meinen eigenen Rastic-Kompatiblen

23:57.000 --> 23:59.000
klein basteln, der das spricht und liest

23:59.000 --> 24:01.000
und alles.

24:01.000 --> 24:03.000
Das haben auch Leute schon gemacht,

24:03.000 --> 24:05.000
da gibt es so drei oder vier,

24:05.000 --> 24:07.000
das ist aber hauptsächlich mal so als Fingerübung

24:07.000 --> 24:09.000
oder so.

24:09.000 --> 24:11.000
Ich weiß von mehreren Implementierungen,

24:11.000 --> 24:13.000
die da auch schon mal Daten dann einfach wieder hergestellt haben,

24:13.000 --> 24:15.000
einfach um zu gucken, wie funktioniert denn das.

24:15.000 --> 24:17.000
Da haben wir dann natürlich auch Lücken in der Spezifikation gefunden,

24:17.000 --> 24:19.000
weil ihr kennt das ja,

24:19.000 --> 24:24.000
das ist ja auch so ein Rastic-Kompatibler.

24:24.000 --> 24:26.000
Jetzt denke ich noch mal so in

24:26.000 --> 24:28.000
Use-Cases für mich.

24:28.000 --> 24:31.000
Wir haben jetzt viel am Anfang schon mal gesprochen,

24:31.000 --> 24:33.000
wir haben unsere normalen Files,

24:33.000 --> 24:35.000
die wir irgendwo ablegen,

24:35.000 --> 24:37.000
auch mal dickere Files oder sowas.

24:37.000 --> 24:39.000
Und ich denke halt,

24:39.000 --> 24:41.000
diesen Datenbank-File, den ich vorhin angesprochen habe.

24:41.000 --> 24:43.000
Klar, wir können eine Datenbank

24:43.000 --> 24:45.000
auch die Files nutzen,

24:45.000 --> 24:47.000
da hast du schon auf die Probleme hingewiesen.

24:47.000 --> 24:49.000
Wenn wir die Files auf einen SQL-Datenbank machen,

24:49.000 --> 24:52.000
vielleicht haben wir aber eine relativ große Datenbank,

24:52.000 --> 24:54.000
die halt irgendwie auch noch verteilt

24:54.000 --> 24:57.000
auf mehreren Charts liegt oder so.

24:57.000 --> 25:00.000
Man muss es halt irgendwie die Daten

25:00.000 --> 25:02.000
so redundant halten,

25:02.000 --> 25:04.000
dass du,

25:04.000 --> 25:06.000
dass du halt auch wenn ein Server,

25:06.000 --> 25:08.000
du hast ja den Fall von vorhin auch genannt,

25:08.000 --> 25:11.000
einen Datenzentrum brennt ab oder so.

25:11.000 --> 25:14.000
Und trotzdem wollen wir unsere Daten weiterhin haben.

25:14.000 --> 25:17.000
Könnte ich das mit RESTIC

25:17.000 --> 25:19.000
auch implementieren

25:19.000 --> 25:21.000
oder gibt es dafür schon

25:21.000 --> 25:23.000
Beispiele?

25:23.000 --> 25:25.000
Oder ist das überhaupt sinnvoll?

25:25.000 --> 25:27.000
Was meinst du denn genau, dass du mehrere Charts hast

25:27.000 --> 25:29.000
und die Daten, die ja

25:29.000 --> 25:31.000
auf allen Charts jeweils sicherst,

25:31.000 --> 25:33.000
damit du möglichst viel Redundanz da hast

25:33.000 --> 25:35.000
oder was meinst du genau?

25:35.000 --> 25:38.000
Ja, also einfach wie sichere ich große Datenmengen,

25:38.000 --> 25:41.000
die beispielsweise verteilt liegen sollen.

25:41.000 --> 25:43.000
Also ich gebe mal ein Beispiel,

25:43.000 --> 25:46.000
ich habe irgendwie meinen Online-Shop

25:46.000 --> 25:48.000
mit Bestellungen.

25:48.000 --> 25:50.000
Der ist aber immer so unter Volllast,

25:50.000 --> 25:52.000
dass ich den halt irgendwie über drei,

25:52.000 --> 25:54.000
keine Ahnung, so Amazon,

25:54.000 --> 25:56.000
zum Spaß jetzt mal,

25:56.000 --> 25:58.000
das kleine Amazon.

25:58.000 --> 26:00.000
Ich möchte da jetzt mal Backups

26:00.000 --> 26:02.000
für meine Datenbank von dem Online-Store

26:02.000 --> 26:05.000
ca. 2.000 Jahre oder so was haben

26:05.000 --> 26:07.000
und würde jetzt schon RESTIC

26:07.000 --> 26:09.000
zur Verfügung haben.

26:09.000 --> 26:11.000
Wie würde ich das denn machen mit solchen Daten

26:11.000 --> 26:13.000
und das gar kein Use Case,

26:13.000 --> 26:15.000
den man mit RESTIC jetzt abbilden würde?

26:15.000 --> 26:17.000
Das ist ein Use Case,

26:17.000 --> 26:19.000
der erfordert es aber,

26:19.000 --> 26:21.000
dass du da noch was drumherum hast.

26:21.000 --> 26:23.000
Das große Problem bei so großen Datenmengen,

26:23.000 --> 26:25.000
die sich auch noch die ganze Zeit ändern,

26:25.000 --> 26:27.000
weil wenn du jetzt deine Familienfoto sicherst,

26:27.000 --> 26:29.000
wenn du jetzt gerade keine neuen hinzufügst

26:29.000 --> 26:31.000
und dann nicht aktiv dran arbeitest,

26:31.000 --> 26:33.000
dann ist das ein statisches Datenset.

26:33.000 --> 26:35.000
Das kannst du ohne Weiteres sagen,

26:35.000 --> 26:37.000
ich mache jetzt ein Backup

26:37.000 --> 26:39.000
und dann ist es irgendwann fertig

26:39.000 --> 26:41.000
und dann ist es fertig.

26:41.000 --> 26:43.000
Zum Beispiel,

26:43.000 --> 26:45.000
hast du das große Problem,

26:45.000 --> 26:47.000
dass sich die ganze Zeit was tut

26:47.000 --> 26:49.000
und dann hast du auch zum Beispiel,

26:49.000 --> 26:51.000
wenn du einen Server hast,

26:51.000 --> 26:53.000
wo ja Lockdaten geschrieben werden,

26:53.000 --> 26:55.000
wo vielleicht das Dataisystem

26:55.000 --> 26:57.000
aufgeräumt wird, wo Benutzer drauf sind

26:57.000 --> 26:59.000
und eigentlich musst du als Voraussetzung

26:59.000 --> 27:01.000
für jegliche Art von Backup

27:01.000 --> 27:03.000
erst mal einen Zustand schaffen,

27:03.000 --> 27:05.000
dass sich die Daten für eine Weile nicht verändern,

27:05.000 --> 27:07.000
zumindest in deiner Sichtweise.

27:07.000 --> 27:09.000
Man kann sich dieses Laufwerk erzeugen

27:09.000 --> 27:11.000
und möchte da die Daten einfach sichern

27:11.000 --> 27:13.000
und diese Schattenkopie,

27:13.000 --> 27:15.000
da stellt das Betriebssystem sicher,

27:15.000 --> 27:17.000
das während des Backupvorgangs

27:17.000 --> 27:19.000
sich da nichts dran ändert.

27:19.000 --> 27:21.000
Das hat RESTIC sogar eingebaut für Windows,

27:21.000 --> 27:23.000
da kann man einfach minus, minus Us,

27:23.000 --> 27:25.000
minus VSS oder sowas sagen,

27:25.000 --> 27:27.000
dann erstellt er im Hintergrund eine Schattenkopie,

27:27.000 --> 27:29.000
wenn er die richtigen Berechtigungen hat.

27:29.000 --> 27:31.000
Sicher hat das Laufwerk

27:31.000 --> 27:33.000
und anschließend wird die Schattenkopie auch wieder entfernt.

27:33.000 --> 27:35.000
Das gibt es für Unix,

27:35.000 --> 27:37.000
da kann man dann auch ein Datasystem manchmal.

27:37.000 --> 27:39.000
Man kann zum Beispiel bei ZFS,

27:39.000 --> 27:43.000
das ist ein sehr gut abgehangenes Server-Dateisystem,

27:43.000 --> 27:45.000
kommt eigentlich aus der FreeBSD-Ecke,

27:45.000 --> 27:47.000
wenn ich richtig informiert bin

27:47.000 --> 27:49.000
und da kann man sagen, man erstellt einen Snapshot

27:49.000 --> 27:51.000
von einem gewissen Dateibaum,

27:51.000 --> 27:53.000
kann den dann noch mal woanders mounten

27:53.000 --> 27:55.000
und kann dann da ganz entspannten Backup drauf machen,

27:55.000 --> 27:57.000
während der Server normal weiterläuft

27:57.000 --> 27:59.000
und das musst du im Prinzip sicherstellen für deine Datenbank.

27:59.000 --> 28:01.000
Manche Leute machen das,

28:01.000 --> 28:03.000
indem sie ein Dump der Datenbank sozusagen,

28:03.000 --> 28:05.000
ein MySQL-Dump oder PG-Dump

28:05.000 --> 28:07.000
oder was auch immer man da für eine Datenbank hat,

28:07.000 --> 28:09.000
die im Prinzip die gesamten Inhalte

28:09.000 --> 28:11.000
als Textdateien rausliefert,

28:11.000 --> 28:13.000
dass man die erzeugt

28:13.000 --> 28:15.000
und direkt auf Standard in RESTIC übergibt,

28:15.000 --> 28:18.000
dass der dann da seine Diplikationsmagie drauf macht

28:18.000 --> 28:20.000
und die Daten dann sichert.

28:20.000 --> 28:22.000
Und so dann quasi über das Datenbank-System,

28:22.000 --> 28:24.000
da muss natürlich dann sichergestellt sein,

28:24.000 --> 28:26.000
dass dieser Dump auch irgendwie atomar ist,

28:26.000 --> 28:28.000
dass da nicht am Anfang der vielleicht

28:28.000 --> 28:30.000
einen Benutzernamen irgendwie sichert

28:30.000 --> 28:32.000
und während des Backups ändert

28:32.000 --> 28:34.000
ein Benutzernamen und dann passt der Dump

28:34.000 --> 28:36.000
nicht zusammen intern in sich.

28:36.000 --> 28:38.000
Das muss man natürlich sicherstellen

28:38.000 --> 28:40.000
und darüber allein nachzudenken

28:40.000 --> 28:42.000
ist schon eine erhebliche Komplexität.

28:42.000 --> 28:44.000
Okay, aber da wohnt die Komplexität

28:44.000 --> 28:46.000
ja sozusagen in dem initialen

28:46.000 --> 28:48.000
Daten aus der Datenbank rauskratzen

28:48.000 --> 28:50.000
und sobald ich das so hingekriegt habe,

28:50.000 --> 28:52.000
dass ich die wirklich sauber

28:52.000 --> 28:54.000
und in sich konsistent und atomar habe,

28:54.000 --> 28:56.000
übergebe ich die dann an die weitere Software

28:56.000 --> 28:58.000
und die beregelt das dann

28:58.000 --> 29:00.000
mit den von uns besprochenen Qualitäten.

29:00.000 --> 29:02.000
Genau.

29:02.000 --> 29:04.000
Also da würde ich halt auch annehmen,

29:04.000 --> 29:06.000
dass dieses Daten daraus exfiltrieren

29:06.000 --> 29:08.000
sehr stark von der Datenbank abhängig ist,

29:08.000 --> 29:10.000
was man da machen möchte.

29:10.000 --> 29:12.000
Also ich nehme an von der Technologie

29:12.000 --> 29:14.000
einerseits, andererseits halt auch von der Größe.

29:14.000 --> 29:16.000
Also Hans-Szenario mit seinen vielen verteilten Scharzt

29:16.000 --> 29:18.000
ist da sicherlich ein bisschen anspruchsvoller,

29:18.000 --> 29:20.000
als ich habe mein WordPress

29:20.000 --> 29:22.000
und dann mag das da auch so lange

29:22.000 --> 29:24.000
schon bestehen wie es auch sein mag,

29:24.000 --> 29:26.000
aber trotzdem sind das endlich viele Daten,

29:26.000 --> 29:28.000
selbst wenn da irgendwie ein paar Tausend Posts drin sind.

29:28.000 --> 29:30.000
Dann geht das wahrscheinlich rein.

29:30.000 --> 29:32.000
Was ich mich halt Frage so ist,

29:32.000 --> 29:34.000
also wir haben unsere Cloud-Provider,

29:34.000 --> 29:36.000
die bieten mir halt das Backup

29:36.000 --> 29:38.000
mit einem Häkchen an

29:38.000 --> 29:40.000
und dann muss ich da halt irgendwie noch

29:40.000 --> 29:42.000
ein paar Euro mehr zahlen

29:42.000 --> 29:44.000
und dann machen die, kümmern die sich da drum.

29:44.000 --> 29:46.000
Nur wenn ich jetzt sagen möchte,

29:46.000 --> 29:48.000
ich möchte das alles selber bauen zum Beispiel,

29:48.000 --> 29:50.000
dann muss ich mir auch über das Thema Backup

29:50.000 --> 29:52.000
jetzt in jeglicher Form Gedanken machen.

29:52.000 --> 29:54.000
Und da ist die Art und Weise,

29:54.000 --> 29:56.000
wie du es gerade aufgeholt hast,

29:56.000 --> 29:58.000
natürlich auf jeden Fall viel komplexer

29:58.000 --> 30:00.000
und man hat viel mehr zu tun,

30:00.000 --> 30:02.000
als wenn man jetzt einfach

30:02.000 --> 30:04.000
sein lokales System

30:04.000 --> 30:06.000
Backup so.

30:06.000 --> 30:08.000
Aber es ist halt notwendig,

30:08.000 --> 30:10.000
um sicherzustellen,

30:10.000 --> 30:12.000
dass deine Daten halt nicht verloren gehen.

30:12.000 --> 30:14.000
Manchmal haben wir auch,

30:14.000 --> 30:16.000
meine Anwendungsfall war,

30:16.000 --> 30:18.000
ich wollte möglichst schnell und elegant

30:18.000 --> 30:20.000
mein Arbeitsverzeichnis sichern.

30:20.000 --> 30:22.000
Das war damals ungefähr,

30:22.000 --> 30:24.000
keine Ahnung, 30 Gigabyte oder sowas

30:24.000 --> 30:26.000
und habe ich angefangen, das zu entwickeln.

30:26.000 --> 30:28.000
Dann haben Leute das benutzt.

30:28.000 --> 30:30.000
Dann sind mehr Leute dazugekommen,

30:30.000 --> 30:32.000
die mitgewirkt haben.

30:32.000 --> 30:34.000
Dann ist das Ganze größer geworden

30:34.000 --> 30:36.000
und irgendwann kam jemand zu uns ins Forum.

30:36.000 --> 30:38.000
Wir haben so ein Support-Forum,

30:38.000 --> 30:40.000
wo sich Leute gegenseitig helfen können

30:40.000 --> 30:42.000
und meinte dann so, hey, hier,

30:42.000 --> 30:44.000
das CERN hat einen Vortrag

30:44.000 --> 30:46.000
über RESTIC.

30:46.000 --> 30:48.000
Ich dachte mir, hey, das CERN,

30:48.000 --> 30:50.000
das ist doch diese Institution in der Schweiz.

30:50.000 --> 30:52.000
Was habe ich da kurz reingeguckt

30:52.000 --> 30:54.000
und ich glaube, das ist der Fall,

30:54.000 --> 30:56.000
dass wir das CERN, das CERN,

30:56.000 --> 30:58.000
das CERN, das CERN, das CERN laufen,

30:58.000 --> 31:00.000
weil das sind ja wirklich sehr,

31:00.000 --> 31:02.000
sehr viele Daten,

31:02.000 --> 31:04.000
sondern es ging tatsächlich

31:04.000 --> 31:06.000
um die Benutzerverzeichnisse der Benutzer

31:06.000 --> 31:08.000
auf den Rechenklustern.

31:08.000 --> 31:10.000
Ja, und tatsächlich setzt das CERN

31:10.000 --> 31:12.000
RESTIC ein dafür.

31:12.000 --> 31:14.000
Das fand ich schon sehr beeindruckend.

31:14.000 --> 31:16.000
Zum Thema, wie viele Datenmengen man da sichern kann.

31:16.000 --> 31:18.000
Allerdings haben sie es so gemacht,

31:18.000 --> 31:20.000
dass die Pro-Benutzer ein eigenes Repository haben,

31:20.000 --> 31:22.000
und wenn man dazu viel auf einmal

31:22.000 --> 31:24.000
in ein Repository reintut,

31:24.000 --> 31:26.000
dann ist das irgendwann sehr schwierig.

31:28.000 --> 31:30.000
Ja, also auch selbst das CERN

31:30.000 --> 31:32.000
verwendet das und zwar mit

31:32.000 --> 31:34.000
nicht zu wenigen Daten, wie du sagst.

31:34.000 --> 31:36.000
Vielleicht kannst du ja einfach mal erklären,

31:36.000 --> 31:38.000
auch noch ein bisschen mehr zu RESTIC.

31:38.000 --> 31:40.000
Also, vielleicht hast du ein paar Zahlen

31:40.000 --> 31:42.000
für uns, keine Ahnung,

31:42.000 --> 31:44.000
wie sich das so bemisst.

31:44.000 --> 31:46.000
Oder vielleicht hast du noch ein paar coole

31:46.000 --> 31:48.000
Geschichten, so wie die vom CERN jetzt.

31:48.000 --> 31:50.000
Und was natürlich auch total interessant ist,

31:50.000 --> 31:52.000
wie ist das mit der Community?

31:52.000 --> 31:54.000
So ein Tool lebt ja einfach auch davon,

31:54.000 --> 31:56.000
dass es Contributions aus der Community gibt,

31:56.000 --> 31:58.000
dass man die Software

31:58.000 --> 32:00.000
verbessern kann dadurch.

32:00.000 --> 32:02.000
Also, eine Geschichte,

32:02.000 --> 32:04.000
die mich so ein bisschen

32:04.000 --> 32:06.000
vom Focker gehauen hat, ist jemand,

32:06.000 --> 32:08.000
der kam an einem Freitagabend, glaube ich,

32:08.000 --> 32:10.000
kam der ins Forum und sagte,

32:10.000 --> 32:12.000
okay, oder bei GitHub, ich weiß nicht mehr,

32:12.000 --> 32:14.000
ich habe hier ein Bug,

32:14.000 --> 32:16.000
ich kann irgendwas nicht funktionieren,

32:16.000 --> 32:18.000
ich kann nicht wieder herstellen,

32:18.000 --> 32:20.000
habe ich gesagt, okay, ich gucke mir das an,

32:20.000 --> 32:22.000
habe dann tatsächlich einen Bug gefunden,

32:22.000 --> 32:24.000
habe einen Patch gemacht und habe ihm gesagt,

32:24.000 --> 32:26.000
ob er es ausprobieren kann.

32:26.000 --> 32:28.000
Und dann schrieb er mir irgendwann eine E-Mail

32:28.000 --> 32:30.000
und meinte so, ja, das wäre ja total nett.

32:30.000 --> 32:32.000
Er könnte es aber leider nicht ausprobieren,

32:32.000 --> 32:34.000
weil er wird ja ablegen.

32:34.000 --> 32:36.000
Und ich habe zurückgeschrieben und dachte mir,

32:36.000 --> 32:38.000
okay, ablegen, was meint er denn dann,

32:38.000 --> 32:40.000
und ob ich ihm nicht irgendwie

32:40.000 --> 32:42.000
das als kleinen Patch irgendwo zur Verfügung

32:42.000 --> 32:44.000
stellen könnte, weil er wird ja ablegen.

32:44.000 --> 32:46.000
Und dann habe ich mich recht erinnert von der

32:46.000 --> 32:48.000
University of Washington,

32:48.000 --> 32:50.000
die auf einer Arktis-Mission

32:50.000 --> 32:52.000
mit Rastic ihre Forschungsdaten sichern wollten.

32:52.000 --> 32:54.000
Und er war halt leider schon

32:54.000 --> 32:56.000
an der Deadline, war quasi schon auf dem Weg zum Schiff

32:56.000 --> 32:58.000
und hatte dann da aber,

32:58.000 --> 33:00.000
weil Arktis nur Satelliten-Internet,

33:00.000 --> 33:02.000
was sehr, sehr langsam war.

33:02.000 --> 33:04.000
Also haben wir noch versucht, eben diesen Patch

33:04.000 --> 33:06.000
so klein wie möglich zu machen.

33:06.000 --> 33:08.000
Und wenn ich mich recht erinnere,

33:08.000 --> 33:10.000
hat das auch alles soweit gut geklappt,

33:10.000 --> 33:12.000
dass sie damit ihre Sachen sichern konnten.

33:12.000 --> 33:14.000
Das ist eine Mini-O-Cluster gesichert.

33:14.000 --> 33:16.000
Das ist so ein S3-Kompatibler Storage-Server.

33:16.000 --> 33:18.000
Und haben da dann ihre Forschungsdaten

33:18.000 --> 33:20.000
mitgesichert, während dieser Mission

33:20.000 --> 33:22.000
die mehrere Wochen dauerte.

33:22.000 --> 33:24.000
Das fand ich auf jeden Fall auch mal ganz spannend,

33:24.000 --> 33:26.000
dass so aus der Community dann

33:26.000 --> 33:28.000
Leute dann auch kommen und sagen,

33:28.000 --> 33:30.000
okay, wir vertrauen euch so sehr,

33:30.000 --> 33:32.000
dass wir unsere wichtigen Forschungsdaten

33:32.000 --> 33:34.000
damit sichern wollen.

33:34.000 --> 33:36.000
Das finde ich auf jeden Fall ziemlich gut.

33:36.000 --> 33:38.000
Was war denn das für ein Backer?

33:38.000 --> 33:40.000
Oh, das weiß ich nicht mehr.

33:40.000 --> 33:42.000
Aber es war auch irgendwas,

33:42.000 --> 33:44.000
dass da Benutzer mit Verzeichnissenamen

33:44.000 --> 33:46.000
um die Ecke kamen,

33:46.000 --> 33:48.000
was nicht so gut funktioniert hat.

33:48.000 --> 33:50.000
Also irgendwas auf jeden Fall,

33:50.000 --> 33:52.000
dass das Backup selber nicht funktioniert hat,

33:52.000 --> 33:54.000
nicht das Restore.

33:54.000 --> 33:56.000
Weil das, glaube ich, nicht so sehr getestet,

33:56.000 --> 33:58.000
wie das vielleicht interessant gewesen wäre.

33:58.000 --> 34:00.000
Ansonsten, das Projekt hat es selber,

34:00.000 --> 34:02.000
also es besteht im Prinzip aus der Github-Seite,

34:02.000 --> 34:04.000
der Projektseite.

34:04.000 --> 34:06.000
Das habe ich von Anfang an auch von meinem

34:06.000 --> 34:08.000
persönlichen Account soweit getrennt,

34:08.000 --> 34:10.000
also auch als Community-Projekt aufziehen wollte.

34:10.000 --> 34:12.000
Weil es kann nicht sein,

34:12.000 --> 34:14.000
dass so ein essentielles Tool

34:14.000 --> 34:16.000
im Prinzip von mir alleine als Person abhängt.

34:16.000 --> 34:18.000
Das finde ich blöd.

34:18.000 --> 34:20.000
Und es gibt das Forum,

34:20.000 --> 34:22.000
das ist ganz hilfreich,

34:22.000 --> 34:24.000
wo sich Leute gegenseitig helfen.

34:24.000 --> 34:26.000
Es gibt den Twitter-Account.

34:26.000 --> 34:28.000
Mittlerweile hat das Projekt,

34:28.000 --> 34:30.000
ich gucke jetzt gerade mal,

34:30.000 --> 34:32.000
18.600 Sternchen auf Github.

34:32.000 --> 34:34.000
Es ist also kein so ganz kleines Projekt mehr.

34:34.000 --> 34:36.000
Und es gibt über 300, 350 Leute,

34:36.000 --> 34:38.000
aus so einer Kerngruppe

34:38.000 --> 34:40.000
von 3, 4, 5 Leuten so ungefähr,

34:40.000 --> 34:42.000
die da hauptsächlich dran entwickeln.

34:42.000 --> 34:44.000
Okay, das heißt,

34:44.000 --> 34:46.000
das hat jetzt also auch schon den Massen-Appil.

34:46.000 --> 34:48.000
Das heißt so,

34:48.000 --> 34:50.000
dass ganz gänzlich unbenutzbare

34:50.000 --> 34:52.000
g