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
grüner Text auf schwarz zum Brunt

34:52.000 --> 34:54.000
reines Nerd-Programm,

34:54.000 --> 34:56.000
ist es dann auch nicht mehr, oder?

34:56.000 --> 34:58.000
Ja, doch schon, ich würde schon sagen,

34:58.000 --> 35:00.000
du musst schon ein bisschen Kommando-Zeile bedienen können,

35:00.000 --> 35:02.000
um das zu benutzen.

35:02.000 --> 35:04.000
Es gibt keine GUI, bisher hat sich niemand gefunden,

35:04.000 --> 35:06.000
aber es ist ja schon eingegreifen,

35:06.000 --> 35:08.000
der eine machen wollte.

35:08.000 --> 35:10.000
Und es ist schon eher so,

35:10.000 --> 35:12.000
für, ich sag mal, die Backend-Benutzer.

35:12.000 --> 35:14.000
Mein Vater benutzt es auch,

35:14.000 --> 35:16.000
der ist aber selber Nerd von daher zählt das nicht.

35:16.000 --> 35:18.000
Aber das ist schon,

35:18.000 --> 35:20.000
man muss schon die Kommando-Zeile selber aufrufen können.

35:20.000 --> 35:22.000
Es geht aber relativ einfach.

35:22.000 --> 35:24.000
Okay, das heißt, es reicht auch,

35:24.000 --> 35:26.000
wenn man jemanden kennt, der das kann.

35:26.000 --> 35:28.000
Ja, also wenn man jemanden kennt,

35:28.000 --> 35:30.000
der mal einen Wetsch-Script oder den Shell-Script zusammenzimmern kann,

35:30.000 --> 35:32.000
der das einmal aufruft,

35:32.000 --> 35:34.000
dann hat man dann schon viele Backups entsorgt.

35:34.000 --> 35:36.000
Nach einer Weile,

35:36.000 --> 35:38.000
dann hat man damit eigentlich schon ziemlich viel gewonnen.

35:38.000 --> 35:40.000
Und wie bastelt man da seine Verschlüsselung rein?

35:40.000 --> 35:42.000
Gar nicht.

35:42.000 --> 35:44.000
Das hat das Programm von Anfang an schon direkt mit drin.

35:44.000 --> 35:46.000
Das heißt, du sagst so ähnlich wie bei Git am Anfang.

35:46.000 --> 35:48.000
Ich initialisiere einen Repository.

35:48.000 --> 35:50.000
Das befindet sich

35:50.000 --> 35:52.000
bei Backblaze auf S3,

35:52.000 --> 35:54.000
auf diesem per SSH

35:54.000 --> 35:56.000
erreichbaren Server

35:56.000 --> 35:58.000
oder auch in diesem Verzeichnis auf meiner lokalen Platte,

35:58.000 --> 36:00.000
die neben meinem Rechner steht.

36:00.000 --> 36:02.000
Und dieses Passwort ist im Prinzip

36:02.000 --> 36:04.000
dein Master-Key sozusagen.

36:04.000 --> 36:06.000
Da gibt es auch bisher nur ein Passwort.

36:06.000 --> 36:08.000
Wir haben da noch nicht experimentiert

36:08.000 --> 36:10.000
mit so asymmetrischer Verschlüsselung oder sowas.

36:10.000 --> 36:12.000
Und entweder du hast das Passwort,

36:12.000 --> 36:14.000
dann kommst du an deine Daten nicht dran.

36:14.000 --> 36:16.000
Und wenn du das Passwort nicht hast,

36:16.000 --> 36:18.000
dann haben wir sichergestellt,

36:18.000 --> 36:20.000
dass da auch niemand anders dran kommt.

36:20.000 --> 36:22.000
Auch nicht mal du selber.

36:22.000 --> 36:24.000
Das ist ja dieser ganz berühmte Test,

36:24.000 --> 36:26.000
der Mud-Puddle-Test.

36:26.000 --> 36:28.000
Ich weiß nicht, ob ich das was sagt.

36:28.000 --> 36:30.000
Dann lass deine Geräte in eine Matschfütze fallen.

36:30.000 --> 36:32.000
Rutsch in der Matschfütze aus,

36:32.000 --> 36:34.000
sodass du dir den Kopf an Haus und das Passwort nicht mehr weißt.

36:34.000 --> 36:36.000
Wenn du dann deine Daten wieder bekommst,

36:36.000 --> 36:38.000
dann waren sie nicht komplett gesichert.

36:38.000 --> 36:40.000
Okay, das hört sich jetzt noch

36:40.000 --> 36:42.000
einem sehr aufwendigen Verfahren an.

36:42.000 --> 36:44.000
Aber du hast ja auch gesagt,

36:44.000 --> 36:46.000
du bist Pentester.

36:46.000 --> 36:48.000
Also von daher, ich nehme an, du hast das schon

36:48.000 --> 36:50.000
öfter mal ausprobiert bei den Providern

36:50.000 --> 36:52.000
oder bei den Kunden, für die du arbeitest.

36:52.000 --> 36:54.000
Ja, wir sehen ja

36:54.000 --> 36:56.000
in unserer Arbeit

36:56.000 --> 36:58.000
sehr viele Systeme und sehen auch,

36:58.000 --> 37:00.000
wo Systeme, also wo so

37:00.000 --> 37:02.000
neureilige Punkte sind, wo Systeme

37:02.000 --> 37:04.000
gerne auseinanderbrechen, wo es knirscht.

37:04.000 --> 37:06.000
Und wir haben versucht jetzt für Rastic

37:06.000 --> 37:08.000
insbesondere die Kropographie,

37:08.000 --> 37:10.000
die da drunter ist.

37:10.000 --> 37:12.000
Da hat sogar mal ein Audit von jemandem gegeben.

37:12.000 --> 37:14.000
Das war ganz spannend, die Kropographie,

37:14.000 --> 37:16.000
die da drunter ist, so zu machen,

37:16.000 --> 37:18.000
dass da möglichst wenig passieren kann.

37:18.000 --> 37:20.000
Und das bedeutet in der Security-Szene

37:20.000 --> 37:22.000
eigentlich immer, dass man versucht,

37:22.000 --> 37:24.000
so wenig wie möglich zu tun,

37:24.000 --> 37:26.000
die Komplexität so weit zu reduzieren,

37:26.000 --> 37:28.000
dass man gar nicht ganz abgefahrene Verfahren

37:28.000 --> 37:30.000
oder irgendwas super Neues nimmt,

37:30.000 --> 37:32.000
sondern eigentlich das Zeug, was super abgehangen ist.

37:32.000 --> 37:34.000
Und dann auch ein Benutzer-Interface

37:34.000 --> 37:36.000
macht, wo man nicht dem Benutzer sagt,

37:36.000 --> 37:38.000
hier, okay, welches Cypher-Suite

37:38.000 --> 37:40.000
für TLS willst du denn?

37:40.000 --> 37:42.000
ECDHE oder mit RSA

37:42.000 --> 37:44.000
oder möchtest du Viblofisch haben

37:44.000 --> 37:46.000
oder RC4, weil das kann einfach jemand,

37:46.000 --> 37:48.000
der in der Thematik nicht so tief drinsteckt,

37:48.000 --> 37:50.000
der kann das überhaupt nicht entscheiden.

37:50.000 --> 37:52.000
Das ist auch was, Rastic ist ein Projekt,

37:52.000 --> 37:54.000
das ist sehr opinionated, würde man sagen.

37:54.000 --> 37:56.000
Das heißt, wir haben in der Regel

37:56.000 --> 37:58.000
ein Primitiv für irgendeine Aufgabe,

37:58.000 --> 38:00.000
einen Krypto-Algorithmus,

38:00.000 --> 38:02.000
einen MAC-Algorithmus,

38:02.000 --> 38:04.000
einen Algorithmus, um aus dem Passwort

38:04.000 --> 38:06.000
einen Krypto-Key zu machen.

38:06.000 --> 38:08.000
Und wir benutzen genau den.

38:08.000 --> 38:10.000
Du hast nicht die Möglichkeit da jetzt irgendwie einzustellen,

38:10.000 --> 38:12.000
wie will ich RSA oder ED25519

38:12.000 --> 38:14.000
oder irgendwas, sondern du kannst Rastic benutzen.

38:14.000 --> 38:16.000
Und es gibt genau diese eine Art, wie man das macht.

38:16.000 --> 38:18.000
Und wenn sich irgendwann rausstellen sollte,

38:18.000 --> 38:20.000
dass das unsicher ist, dann würden wir eher

38:20.000 --> 38:22.000
eine neue Version des Programms machen,

38:22.000 --> 38:24.000
eine neue Version des Repository-Formats definieren,

38:24.000 --> 38:26.000
als dann dem Benutzer zu viele Fragen zu stellen,

38:26.000 --> 38:28.000
die der nicht beantworten kann.

38:28.000 --> 38:30.000
Weil wenn ich erst

38:30.000 --> 38:32.000
einen jahrlangen Kryptografie mehr angucken muss,

38:32.000 --> 38:34.000
um zu entscheiden, welcher Krypto-Algorithmus

38:34.000 --> 38:36.000
für meinen Anwendungsfall der beste ist,

38:36.000 --> 38:38.000
dann mache ich keine Backups währenddessen.

38:38.000 --> 38:40.000
Das funktioniert nicht.

38:42.000 --> 38:44.000
Du hast noch eine Frage zu dem Initialisieren,

38:44.000 --> 38:46.000
das ganzen Prozess, wie du es beschrieben hast.

38:46.000 --> 38:48.000
Kann ich das auch ganz einfach so

38:48.000 --> 38:50.000
an mehrere Endpunkte schicken?

38:50.000 --> 38:52.000
Also ich habe hier ein Backup,

38:52.000 --> 38:54.000
und das soll hier und dort drüben hin auch noch?

38:56.000 --> 38:58.000
Das haben wir bisher nicht implementiert.

38:58.000 --> 39:00.000
Du kannst aber, weil das eine hohe Komplexität hat,

39:00.000 --> 39:02.000
weil diese Backup-Pipeline sozusagen,

39:02.000 --> 39:04.000
also Dateien lesen, auseinanderschneiden,

39:04.000 --> 39:06.000
verschlüsseln, abspeichern,

39:06.000 --> 39:08.000
das hat eine sehr hohe Komplexität.

39:08.000 --> 39:10.000
Und das ist ja der Kern des Ganzen.

39:10.000 --> 39:12.000
Und da wollten wir jetzt nicht nochmal

39:12.000 --> 39:14.000
die Möglichkeit so direkt einbauen,

39:14.000 --> 39:16.000
dass man das auf mehrere Senken sozusagen,

39:16.000 --> 39:18.000
auf mehrere Datenspeicherhalten verteilen kann.

39:18.000 --> 39:20.000
Man kann aber im Nachhinein,

39:20.000 --> 39:22.000
wenn man ein Backup gemacht hat,

39:22.000 --> 39:24.000
ein Snapshot gemacht hat,

39:24.000 --> 39:26.000
kann man den dann mit allen zugehörigen Daten

39:26.000 --> 39:28.000
von einem ein anderes Repository reinkopieren.

39:28.000 --> 39:30.000
Bei ganz oft ist wieder das Problem,

39:30.000 --> 39:32.000
dass man seine Daten, die man speichern möchte,

39:32.000 --> 39:34.000
erst mal ja so lange konstant halten muss,

39:34.000 --> 39:36.000
wie das Backup selber läuft.

39:36.000 --> 39:38.000
Und das ist an sich schon schwierig genug.

39:38.000 --> 39:40.000
Und dann lieber im Nachgang direkt am zweiten Schritt

39:40.000 --> 39:42.000
diese Daten woanders rüber kopieren.

39:42.000 --> 39:44.000
Okay, sprich dieser Schritt

39:44.000 --> 39:46.000
kann man jetzt an verschiedene Senken,

39:46.000 --> 39:48.000
wie du sagst, das ist sozusagen einfach aus

39:48.000 --> 39:50.000
RESTIC selber rausdefiniert,

39:50.000 --> 39:52.000
weil das andere Programme ausreichend gut machen können.

39:52.000 --> 39:54.000
Und wenn der eine Snapshot einmal getan ist.

39:54.000 --> 39:56.000
Ja, nicht ganz.

39:56.000 --> 39:58.000
Wir haben schon eine eigene Kopierfunktionalität.

39:58.000 --> 40:00.000
Das ist schon in RESTIC eingebaut,

40:00.000 --> 40:02.000
weil RESTIC macht die Duplikation.

40:02.000 --> 40:04.000
Das heißt, jeder Snapshot,

40:04.000 --> 40:06.000
jeder Stand ein von Daten,

40:06.000 --> 40:08.000
der ist für sich erst mal unabhängig.

40:08.000 --> 40:10.000
Der verweist ja auf die ganzen Datenschnipsel aus den Dateien,

40:10.000 --> 40:12.000
was ich vorhin erklärt habe.

40:12.000 --> 40:14.000
Man kann jetzt hergehen und sagen,

40:14.000 --> 40:16.000
okay, ich habe jetzt in einem Repository verschiedene Daten.

40:16.000 --> 40:18.000
Ich habe die Familienfotos,

40:18.000 --> 40:20.000
ich habe meine Aufnahmen,

40:20.000 --> 40:22.000
die ich mit der Band im Proberaum gemacht habe.

40:22.000 --> 40:24.000
Ich habe da aber auch meinen Code drin.

40:24.000 --> 40:26.000
Und diese Fotos und diese Bandaufnahmen sind mir gar nicht so wichtig,

40:26.000 --> 40:28.000
aber die Snapshots, die meinen Code betreffen,

40:28.000 --> 40:30.000
die möchte ich jetzt in ein anderes Repository nochmal kopieren.

40:30.000 --> 40:32.000
Dann hat ja RESTIC als Programm die Information,

40:32.000 --> 40:34.000
welche Daten sind denn dafür dann nötig?

40:34.000 --> 40:36.000
Weil die Familienfotos, die brauche ich dann nicht,

40:36.000 --> 40:38.000
aber die Daten, die den Code betreffen, schon.

40:38.000 --> 40:40.000
Und deswegen ergibt es Sinn,

40:40.000 --> 40:42.000
das in so einem Programm in RESTIC drin zu haben.

40:42.000 --> 40:44.000
Und nicht als extra Programm,

40:44.000 --> 40:46.000
weil wenn du das extern machst,

40:46.000 --> 40:48.000
also das Repository am Ende des Tages sind ja auch nur Dateien,

40:48.000 --> 40:50.000
da kannst du zwar nichts mit anfangen,

40:50.000 --> 40:52.000
weil die verschlüsselt sind.

40:52.000 --> 40:54.000
Aber du könntest ja die auch einfach mit Ersynk

40:54.000 --> 40:56.000
oder was auch immer irgendwo anders hin kopieren.

40:56.000 --> 40:58.000
Dann müsstest du aber das gesamte Repository kopieren,

40:58.000 --> 41:00.000
weil du von außen keine Ahnung hast,

41:00.000 --> 41:02.000
welche Daten wo liegen.

41:02.000 --> 41:04.000
Ja, was bei einer gewissen Größe

41:04.000 --> 41:06.000
und einer gewissen Dünnhalt der Leitung dann schon lästig ist.

41:06.000 --> 41:08.000
Auf jeden Fall, ja.

41:08.000 --> 41:10.000
Aber andersrum,

41:10.000 --> 41:12.000
was worauf wir jetzt noch gar nicht eingegangen sind,

41:12.000 --> 41:14.000
ist so der Restore-Prozess.

41:14.000 --> 41:16.000
Weil in meinem Vorgespräch

41:16.000 --> 41:18.000
hatte ich eben gesagt,

41:18.000 --> 41:20.000
die philosophische Frage ist ja,

41:20.000 --> 41:22.000
ist ein Backup wirklich ein Backup,

41:22.000 --> 41:24.000
wenn ich es noch nie eingespielt habe?

41:24.000 --> 41:26.000
Und wie lange darf ich mit Zeit lassen,

41:26.000 --> 41:28.000
mit dem wieder einspielen,

41:28.000 --> 41:30.000
bis ein Backup kein Backup mehr ist?

41:30.000 --> 41:32.000
Ja eben, also das ist ja eigentlich so die Fragestellung.

41:32.000 --> 41:34.000
Wie häufig mache ich eigentlich mein Backup?

41:34.000 --> 41:36.000
Ich habe es eben gesagt,

41:36.000 --> 41:38.000
ich komme nach Hause oder

41:38.000 --> 41:40.000
weiß ich nicht, wenn der Laptop hier ist,

41:40.000 --> 41:42.000
dann ist das irgendwie angesteckt

41:42.000 --> 41:44.000
und ab und an wird da mal ein Backup gemacht.

41:44.000 --> 41:46.000
Manchmal vergesse ich es auch und dann habe ich irgendwie

41:46.000 --> 41:48.000
nach 10 Tagen kriege ich dann vom Back gesagt,

41:48.000 --> 41:50.000
hier willst du nicht mal wieder ein Backup machen

41:50.000 --> 41:52.000
und dann denke ich mir, oh, morgen vielleicht so.

41:52.000 --> 41:54.000
Aber das Problem ist ja jetzt,

41:54.000 --> 41:56.000
wenn die Platte übermorgen kaputt ist

41:56.000 --> 41:58.000
und ich habe diese 11 Tage

41:58.000 --> 42:00.000
jetzt kein Backup gemacht

42:00.000 --> 42:02.000
oder 12,

42:02.000 --> 42:04.000
dann ist es sehr ärgerlich.

42:04.000 --> 42:06.000
Ich habe versucht mir mittlerweile

42:06.000 --> 42:08.000
andere Mechanismen irgendwie dafür

42:08.000 --> 42:10.000
zu erschaffen, sprich ich habe ganz viel

42:10.000 --> 42:12.000
in der Cloud einfach, der Code sowieso

42:12.000 --> 42:14.000
und ich meine,

42:14.000 --> 42:16.000
alles was irgendwie

42:16.000 --> 42:18.000
online stattfindet

42:18.000 --> 42:20.000
ist sowieso automatisiert.

42:20.000 --> 42:22.000
Backup, irgendwelche Notizen oder was weiß ich.

42:22.000 --> 42:24.000
Aber trotzdem ist ja genau

42:24.000 --> 42:26.000
diese 10 Tage, die dir dann fehlen,

42:26.000 --> 42:28.000
das ist ja das ärgerliche

42:28.000 --> 42:30.000
und meistens willst du ja genau die Daten

42:30.000 --> 42:32.000
von dann haben.

42:32.000 --> 42:34.000
Und wie kriegt man es hin

42:34.000 --> 42:36.000
diesen Zeitraum halt so klein wie möglich

42:36.000 --> 42:38.000
zu halten, das ist ja die große

42:38.000 --> 42:40.000
Fragestellung.

42:40.000 --> 42:42.000
Ja, das ist das, das ist eine der beiden

42:42.000 --> 42:44.000
großen Fragen, tatsächlich.

42:44.000 --> 42:46.000
Was ich Leuten empfehle, die fragen,

42:46.000 --> 42:48.000
ja, wann soll ich den Backup machen, sage ich, ja, jeden Tag.

42:48.000 --> 42:50.000
Weil dann musst du nicht überlegen,

42:50.000 --> 42:52.000
habe ich gestern oder ist morgen erst wieder dran,

42:52.000 --> 42:54.000
sondern macht das einfach jeden Tag.

42:54.000 --> 42:56.000
Und was für mich gut funktioniert,

42:56.000 --> 42:58.000
das muss natürlich nicht heißen,

42:58.000 --> 43:00.000
dass das für alle gut funktioniert ist,

43:00.000 --> 43:02.000
wenn ich einen Rechner ausmache,

43:02.000 --> 43:04.000
dann mache ich den nicht aus, sondern ich starte

43:04.000 --> 43:06.000
das Backup-Skript, was ihn anschließend ausmacht.

43:06.000 --> 43:08.000
Sodass das einfach so die Routine ist,

43:08.000 --> 43:10.000
wenn ich irgendwo an einem Open Source Projekt

43:10.000 --> 43:12.000
geschraubt habe und dann habe ich keine Lust mehr,

43:12.000 --> 43:14.000
dann starte ich mein Skript, das macht ein Backup

43:14.000 --> 43:16.000
und anschließend fährt es den Rechner runter.

43:16.000 --> 43:18.000
Das wiederum unterstellt ja,

43:18.000 --> 43:20.000
dass du einen manuellen Schritt machen musst.

43:20.000 --> 43:22.000
Also was bei mir so das Ding ist,

43:22.000 --> 43:24.000
ich bin fertig,

43:24.000 --> 43:26.000
ich klappe das Ding zu.

43:26.000 --> 43:28.000
Und im Idealfall geht es ja dann automatisiert

43:28.000 --> 43:30.000
sozusagen los.

43:30.000 --> 43:32.000
Oder nachts um 0 Uhr

43:32.000 --> 43:34.000
oder noch ein bisschen später,

43:34.000 --> 43:36.000
keine Ahnung, wie lange ihr manchmal am Rechner sitzt,

43:36.000 --> 43:38.000
dann startet sich das Skript automatisiert

43:38.000 --> 43:40.000
und du musst eigentlich nichts machen,

43:40.000 --> 43:42.000
sondern es läuft

43:42.000 --> 43:44.000
einfach.

43:44.000 --> 43:46.000
Das ist ja auch das, wie Time Machine funktioniert,

43:46.000 --> 43:48.000
dass die sagen, okay, ich mache halt ständig

43:48.000 --> 43:50.000
alle zwei Stunden oder was weiß ich,

43:50.000 --> 43:52.000
habe ich eine Kopie und je älter die Dinger dann sind,

43:52.000 --> 43:54.000
desto weniger

43:54.000 --> 43:56.000
häufig habe ich irgendwie eine Kopie deiner Daten

43:56.000 --> 43:58.000
oder die

43:58.000 --> 44:00.000
den Unterschied zu deinen Daten gespeichert.

44:00.000 --> 44:02.000
Das ist ja eigentlich

44:02.000 --> 44:04.000
das, was man doch erreichen möchte,

44:04.000 --> 44:06.000
so wenig wie möglich manuelle Schritte.

44:06.000 --> 44:08.000
Ja klar, so automatisiert wie möglich, klar.

44:08.000 --> 44:10.000
Ich habe jetzt aber auch nicht jeden Tag

44:10.000 --> 44:12.000
auf meinen Rechner an, von daher

44:12.000 --> 44:14.000
kann ich da wenig auf so automatisiertes

44:14.000 --> 44:16.000
Tools setzen

44:16.000 --> 44:18.000
und der hat auch nicht immer Netzwerk, wenn ich den an habe

44:18.000 --> 44:20.000
und so, deswegen ist das natürlich

44:20.000 --> 44:22.000
auf einem Server, es ist einfacher, da habe ich ein System Detail,

44:22.000 --> 44:24.000
der das einfach macht.

44:24.000 --> 44:26.000
Die andere Frage ist auch, wenn du jetzt

44:26.000 --> 44:28.000
Backups hast mit Time Machine,

44:28.000 --> 44:30.000
wann hast du die zuletzt mal zurückgespielt,

44:30.000 --> 44:32.000
geht das überhaupt?

44:32.000 --> 44:34.000
Ja, also tatsächlich muss man sagen,

44:34.000 --> 44:36.000
dass dieser Prozester

44:36.000 --> 44:38.000
mit Time Machine extrem smooth

44:38.000 --> 44:40.000
in der Vergangenheit war.

44:40.000 --> 44:42.000
Also wenn man mal irgendwie den, der Rechner

44:42.000 --> 44:44.000
ist mal abgeraucht, wie man so schön sagt

44:44.000 --> 44:46.000
und dann hat man was nicht funktioniert,

44:46.000 --> 44:48.000
das war noch vor Flash-Speicherzeiten,

44:48.000 --> 44:50.000
also dann mit der HDD, wenn die dann

44:50.000 --> 44:52.000
wirklich mal hinüber war

44:52.000 --> 44:54.000
und dann hat man halt irgendwann

44:54.000 --> 44:56.000
eine neue Hard Drive bekommen

44:56.000 --> 44:58.000
und hat dann sein Backup

44:58.000 --> 45:00.000
eingespielt. Da erinnere ich mich noch dran,

45:00.000 --> 45:02.000
das hat immer sehr smooth funktioniert.

45:02.000 --> 45:04.000
Mittlerweile muss ich sagen

45:04.000 --> 45:06.000
und das macht es auch so einfach

45:06.000 --> 45:08.000
nachlässig zu sein in den Backups,

45:08.000 --> 45:10.000
hat man das Gefühl, man braucht das

45:10.000 --> 45:12.000
nicht mehr unbedingt, weil halt

45:12.000 --> 45:14.000
viel ausgelagert, auf irgendwie in die Cloud

45:14.000 --> 45:16.000
und auf der anderen, also

45:16.000 --> 45:18.000
Fotos, also ich habe gar keine Fotos

45:18.000 --> 45:20.000
mehr auf meinem Laptop.

45:20.000 --> 45:22.000
Das finde ich jetzt vielleicht speziell.

45:22.000 --> 45:24.000
Manche Leute wollen das nicht mit ihren

45:24.000 --> 45:26.000
privaten Daten, ist klar.

45:26.000 --> 45:28.000
So, dann macht man das ein bisschen anders.

45:28.000 --> 45:30.000
Aber bei mir ist es jetzt zum Beispiel so

45:30.000 --> 45:32.000
und deswegen ist es für mich dann auch so,

45:32.000 --> 45:34.000
wenn mich dann mein Laptop erinnert,

45:34.000 --> 45:36.000
ja du solltest mal wieder seit 10 Tagen

45:36.000 --> 45:38.000
oder was weiß ich, 15 Tagen einen Backup

45:38.000 --> 45:40.000
machen oder 50 Tagen einen Backup

45:40.000 --> 45:42.000
machen, ja.

45:42.000 --> 45:44.000
Ja, whatever, wenn es halt weg ist, ist es weg.

45:44.000 --> 45:46.000
Das ist doch die wichtigen Sachen,

45:46.000 --> 45:48.000
sind doch eh alle gesaved.

45:48.000 --> 45:50.000
Das ist noch zu

45:50.000 --> 45:52.000
2010,

45:52.000 --> 45:54.000
15, 20er Jahren,

45:54.000 --> 45:56.000
20 nicht, aber so

45:56.000 --> 45:58.000
post COVID sagen wir einfach mal.

45:58.000 --> 46:00.000
Ja, aber das ist doch total prima,

46:00.000 --> 46:02.000
weil wenn das für dich funktioniert,

46:02.000 --> 46:04.000
ist doch optimal.

46:04.000 --> 46:06.000
Es muss ja nur, wenn du dir mal Gedanken

46:06.000 --> 46:08.000
gemacht hast, wie du das dann

46:08.000 --> 46:10.000
machst, das ist doch schon mal der

46:10.000 --> 46:12.000
wichtigste Schritt eigentlich.

46:12.000 --> 46:14.000
Aber Alex, weißt du, ich glaube, das Schlimme

46:14.000 --> 46:16.000
ist ja, dass du erst, wenn du in die

46:16.000 --> 46:18.000
Konstanz lernst, was du alles vergessen

46:18.000 --> 46:20.000
hast in deiner Strategie, ja,

46:20.000 --> 46:22.000
das ist ja das Dove.

46:22.000 --> 46:24.000
Und deswegen dieser Automatismus, den ich denke,

46:24.000 --> 46:26.000
der ja eigentlich so

46:26.000 --> 46:28.000
notwendig ist,

46:28.000 --> 46:30.000
weil wenn du es halt einfach

46:30.000 --> 46:32.000
nicht machst, nachlässig geworden bist,

46:32.000 --> 46:34.000
das ist keine Strategie.

46:34.000 --> 46:36.000
Das ist einfach

46:36.000 --> 46:38.000
ja,

46:38.000 --> 46:40.000
ein Fehler sozusagen, eigentlich in deiner Strategie.

46:40.000 --> 46:42.000
Was sagen Sie?

46:42.000 --> 46:44.000
Ich würde sagen, es ist tatsächlich ein

46:44.000 --> 46:46.000
Konflikt. Ich will einerseits nicht drüber

46:46.000 --> 46:48.000
nachdenken müssen, aber sobald ich das diesen

46:48.000 --> 46:50.000
Punkt erreicht habe, weiß ich halt nicht,

46:50.000 --> 46:52.000
ob es funktioniert, wenn es dann wirklich hart

46:52.000 --> 46:54.000
auf hart kommt.

46:54.000 --> 46:56.000
Ja, genau. Das kann man, das kann man ganz

46:56.000 --> 46:58.000
gut machen, wenn man einen neuen Laptop

46:58.000 --> 47:00.000
bekommt. Ich weiß, dass das Apple-Universum

47:00.000 --> 47:02.000
hat da auch ganz tolle Migrationstools von

47:02.000 --> 47:04.000
der einen auf die andere Maschine.

47:04.000 --> 47:06.000
Was ich aber ganz hilfreich fand,

47:06.000 --> 47:08.000
von der Weile mal habe ich einen neuen Laptop

47:08.000 --> 47:10.000
bekommen und dann habe ich dann wirklich

47:10.000 --> 47:12.000
mir mal ein wenig heggegangen und habe gesagt,

47:12.000 --> 47:14.000
das ist mein neues Gerät, das Alt ist nicht

47:14.000 --> 47:16.000
mehr da, es stand noch daneben, aber das Alt

47:16.000 --> 47:18.000
ist nicht mehr da. Komme ich jetzt an meine

47:18.000 --> 47:20.000
Daten oder nicht?

47:20.000 --> 47:22.000
Und da haben sich in meiner Backup-Strategie

47:22.000 --> 47:24.000
einige Löcher aufgetan, die ich danach dann

47:24.000 --> 47:26.000
angegangen bin. Was ich eben aber meinte

47:26.000 --> 47:28.000
ist, wenn du jetzt deine Daten oder deine

47:28.000 --> 47:30.000
Backups, deinen Code in der Cloud

47:30.000 --> 47:32.000
speicherst, deine Familienfotos oder so

47:32.000 --> 47:34.000
was,

47:34.000 --> 47:36.000
woher weißt du denn, dass die da unmodifiziert

47:36.000 --> 47:38.000
sind? Und damit meine ich nicht jetzt, dass

47:38.000 --> 47:40.000
irgendwie man dem Cloud-Dienst nicht vertraut,

47:40.000 --> 47:42.000
seine Daten modifiziert. Keine Frage,

47:42.000 --> 47:44.000
weil wenn du das jetzt in Frage stellen würdest,

47:44.000 --> 47:46.000
würdest du die da nicht hinschieben.

47:46.000 --> 47:48.000
Aber es hat vor kurzem jetzt Hinweise gegeben,

47:48.000 --> 47:50.000
dass Google Fotos anscheinend einige Fotos

47:50.000 --> 47:52.000
verändert hat, dass da irgendwie

47:52.000 --> 47:54.000
Falschfarben drin sind, die haben das

47:54.000 --> 47:56.000
vermutlich irgendwie im Hintergrund nochmal

47:56.000 --> 47:58.000
versucht mehr zu komprimieren oder so was.

47:58.000 --> 48:00.000
Und sowas ähnliches gibt es ja auch,

48:00.000 --> 48:02.000
wenn du jetzt entscheidest, ich nehme jetzt

48:02.000 --> 48:04.000
irgendwie AWS S3

48:04.000 --> 48:06.000
als Backup-Location oder ich nehme irgendwie

48:06.000 --> 48:08.000
Backblaze, was so ein Backup-Provider auch

48:08.000 --> 48:10.000
ist, die sind ziemlich günstig.

48:10.000 --> 48:12.000
Aber

48:12.000 --> 48:14.000
wenn da jetzt, wenn man jetzt Daten hinschiebt,

48:14.000 --> 48:16.000
dann müsste man eigentlich diese Daten auf

48:16.000 --> 48:18.000
regelmäßig lesen, um zu gucken, sind die

48:18.000 --> 48:20.000
unverändert. Also gerade bei so Sachen,

48:20.000 --> 48:22.000
wenn du als Verschlüsselung einsetzt, ist das

48:22.000 --> 48:24.000
große Problem, dass man da an den Daten

48:24.000 --> 48:26.000
selber was kaputt geht, wenn da irgendein

48:26.000 --> 48:28.000
Bit flippt, dann kann ich die auch nicht

48:28.000 --> 48:30.000
wieder sauber entschlüsseln. Das ist bei

48:30.000 --> 48:32.000
Design so, weil ich will ja genau

48:32.000 --> 48:34.000
sicherstellen, dass bevor ich versuche, die

48:34.000 --> 48:36.000
zu entschlüsseln, muss ich sicherstellen,

48:36.000 --> 48:38.000
da kommen immer wieder Leute, die sagen

48:38.000 --> 48:40.000
ja, RESTIC ist total amist, der

48:40.000 --> 48:42.000
steigt hier immer mit Fehlermeldungen aus,

48:42.000 --> 48:44.000
irgendwas von wegen Yesypatext, Modification

48:44.000 --> 48:46.000
Detected oder irgendwas.

48:46.000 --> 48:48.000
Und das sind die abstrusesten

48:48.000 --> 48:50.000
Backreports, weil

48:50.000 --> 48:52.000
wir uns erst immer nicht erklären können, was

48:52.000 --> 48:54.000
ist denn da passiert. Und ganz oft stellt sich raus,

48:54.000 --> 48:56.000
dass da einfach Hardware-Defekt ist.

48:56.000 --> 48:58.000
Und das geht von, meistens

48:58.000 --> 49:00.000
ist es der Speicher desjenigen, der

49:00.000 --> 49:02.000
den RESTIC-Prozess ausführt, also so

49:02.000 --> 49:04.000
ein Server-System, was man zu Hause hat,

49:04.000 --> 49:06.000
der Laptop, auf dem ich das laufen lasse,

49:06.000 --> 49:08.000
wo dann irgendwo zwischendurch im Speicher

49:08.000 --> 49:10.000
was kaputt geht. Und das kommt viel

49:10.000 --> 49:12.000
öfter vor, als man so denkt. Das hat mich

49:12.000 --> 49:14.000
massiv erschreckt. Also ich dann nochmal,

49:14.000 --> 49:16.000
wir haben dann Label bei GitHub eingefügt

49:16.000 --> 49:18.000
für so Hardware-Defekt

49:18.000 --> 49:20.000
ja, Backreports.

49:20.000 --> 49:22.000
Und es ist erstaunlich, wie oft das vorkommt.

49:22.000 --> 49:24.000
Und das

49:24.000 --> 49:26.000
detectiert RESTIC, weil es mehrere Ebenen

49:26.000 --> 49:28.000
hat, wo es immer wieder so

49:28.000 --> 49:30.000
Safety-Checks macht. Das heißt, ich lese

49:30.000 --> 49:32.000
eine Datei, lese ein Schnipsel aus einer Datei.

49:32.000 --> 49:34.000
Das erste, was gemacht wird, ich mache da

49:34.000 --> 49:36.000
den SHA-2-Hash von, also eine

49:36.000 --> 49:38.000
kriptografische Hash-Funktion. Ich kriege also

49:38.000 --> 49:40.000
quasi sozusagen den Fingerabdruck von diesem Schnipsel.

49:40.000 --> 49:42.000
Das mache ich als allererstes.

49:42.000 --> 49:44.000
Und dann werden die Daten abgespeichert

49:44.000 --> 49:46.000
und verschlüsselt und so weiter und so weiter.

49:46.000 --> 49:48.000
Und nachher kann ich sagen, ich habe jetzt da

49:48.000 --> 49:50.000
meine tollen Backup-Daten, die liegen jetzt irgendwo

49:50.000 --> 49:52.000
in der Cloud. Und ich möchte jetzt bitte mal

49:52.000 --> 49:54.000
random ein Zehntel der Daten runterladen

49:54.000 --> 49:56.000
und checken, ob das alles in Ordnung ist.

49:56.000 --> 49:58.000
Und dann kann ich das machen,

49:58.000 --> 50:00.000
kann ich versuchen zu entschlüsseln und dann kann ich

50:00.000 --> 50:02.000
wieder diesen Fingerabdruck mir angucken

50:02.000 --> 50:04.000
und kann sehen, okay ja, der Fingerabdruck

50:04.000 --> 50:06.000
zu den Daten, der passt noch. Und dann kann

50:06.000 --> 50:08.000
ich schon mal sehen, das hat alles soweit

50:08.000 --> 50:10.000
funktioniert. Und das ist ein Prozess, den kann

50:10.000 --> 50:12.000
man automatisieren, weil ich eben nicht

50:12.000 --> 50:14.000
entscheiden muss, ich restore jetzt einen

50:14.000 --> 50:16.000
bestimmten Snapshot, habe da dann wieder

50:16.000 --> 50:18.000
mein Verzeichnis mit Daten. Und dann muss

50:18.000 --> 50:20.000
ich nicht manuell vergleichen, ist der Code, den

50:20.000 --> 50:22.000
ich da jetzt erwarte, der da auch liegt.

50:22.000 --> 50:24.000
Sondern ich kann eben den Programm sagen,

50:24.000 --> 50:26.000
entschlüssel meine Daten, lad die mir runter,

50:26.000 --> 50:28.000
vielleicht ein Zehntel der Daten random

50:28.000 --> 50:30.000
und guck einfach nach, ist da alles in Ordnung.

50:30.000 --> 50:32.000
Und wenn der Fingerabdruck sagt,

50:32.000 --> 50:34.000
es ist nicht alles in Ordnung, weil

50:34.000 --> 50:36.000
da möglicherweise die Hardware wirklich

50:36.000 --> 50:38.000
irgendwo mal ein Bit geflippt hat?

50:38.000 --> 50:40.000
Dann kann man einigermaßen

50:40.000 --> 50:42.000
sehen, je nachdem, wo das im Prozess

50:42.000 --> 50:44.000
passiert, wo vielleicht

50:44.000 --> 50:46.000
das Problem liegt. Also

50:46.000 --> 50:48.000
bei RESTIC ist es so, ich lese ein Datei,

50:48.000 --> 50:50.000
habe diesen Schnipsel, bildet meinen Fingerabdruck.

50:50.000 --> 50:52.000
Und nachher ist dann immer

50:52.000 --> 50:54.000
dieses Stückchen Daten, dieser Schnipsel

50:54.000 --> 50:56.000
mit immer anhand des Fingerabdrucks identifiziert.

50:56.000 --> 50:58.000
Und der wird dann, wenn ich den speichern muss,

50:58.000 --> 51:00.000
dann packe ich den dann verschlüssel ich den,

51:00.000 --> 51:02.000
packe den mit anderen Daten zusammen

51:02.000 --> 51:04.000
in eine Datei. Und diese Datei, die

51:04.000 --> 51:06.000
bekommt als Dateiname, bevor sie irgendwo

51:06.000 --> 51:08.000
hochgeladen wird, bekommt sie wieder den

51:08.000 --> 51:10.000
Schad 256-Hash

51:10.000 --> 51:12.000
von ihrem Inhalt. Das heißt, ich mache

51:12.000 --> 51:14.000
nochmal ein Fingerabdruck, diesmal von den

51:14.000 --> 51:16.000
verschlüsselten Daten. Und dann kann man sich

51:16.000 --> 51:18.000
zum Beispiel auf dem Server auch angucken, ohne

51:18.000 --> 51:20.000
dass man die Daten entschlüsseln muss, kann man

51:20.000 --> 51:22.000
regelmäßig mit einem Skript einfach gucken,

51:22.000 --> 51:24.000
wenn ich diese Daten hier lese von meiner

51:24.000 --> 51:26.000
Datei und den Schad 256-Hash

51:26.000 --> 51:28.000
davon bilde, entspricht er dem Dateinamen

51:28.000 --> 51:30.000
oder nicht? Und dann kann ich schon mal

51:30.000 --> 51:32.000
sehen, ist es eher der Speicherort,

51:32.000 --> 51:34.000
wo es kaputt gegangen ist?

51:34.000 --> 51:36.000
Oder ist das eher vielleicht die Festplatte,

51:36.000 --> 51:38.000
wo es kaputt gegangen ist? Weil jetzt mein

51:38.000 --> 51:40.000
Name passt nicht mehr zum Hash.

51:40.000 --> 51:42.000
Und wenn das der Fall ist, dann ist es meistens

51:42.000 --> 51:44.000
so, dass dann der Ort, wo die Daten

51:44.000 --> 51:46.000
liegen, ein Problem hat. Das ist

51:46.000 --> 51:48.000
ganz oft so ein altes Nass irgendwo

51:48.000 --> 51:50.000
im Keller bei einem Kumpel oder so was.

51:50.000 --> 51:52.000
Und wenn man da merkt, da werden die Daten

51:52.000 --> 51:54.000
dann nicht mehr so gelesen, dann kann

51:54.000 --> 51:56.000
man da schon ganz gut drauf schließen.

51:56.000 --> 51:58.000
Wenn das aber andersrum ist, dass man

51:58.000 --> 52:00.000
das erste Mal, dass man Daten gelesen hat

52:00.000 --> 52:02.000
und da einen Fingerabdruck berechnet hat

52:02.000 --> 52:04.000
und der nachher nicht mehr zusammenpasst,

52:04.000 --> 52:06.000
aber die Krypto drumherum und auch der Speicherort

52:06.000 --> 52:08.000
und so weiter, alles passt, dann kann man

52:08.000 --> 52:10.000
eher darauf schließen, dass das System, was

52:10.000 --> 52:12.000
das Backup ursprünglich gemacht hat, wo also

52:12.000 --> 52:14.000
Rastic draufläuft, ein Problem hat.

52:14.000 --> 52:16.000
Aber jetzt jenseits von der Diagnose sozusagen

52:16.000 --> 52:18.000
der Ursache, das Bit ist jetzt geflippt

52:18.000 --> 52:20.000
da in einem meiner zahlreichen Fotos.

52:20.000 --> 52:22.000
Stellt sich denn jetzt sozusagen dann der dadurch

52:22.000 --> 52:24.000
verursachte Gesamtschaden für meinen Backup

52:24.000 --> 52:26.000
da?

52:26.000 --> 52:28.000
Das ist eine exzellente Frage und das ist

52:28.000 --> 52:30.000
tatsächlich was, wo wir noch sehr viel Luft

52:30.000 --> 52:32.000
nach oben haben, weil Rastic ist ein

52:32.000 --> 52:34.000
Backup-Programm, was die dupliciert.

52:34.000 --> 52:36.000
Das heißt, es versucht, möglichst speichereffizient

52:36.000 --> 52:38.000
zu sein, so dass jeder Datenschnipsel idealerweise

52:38.000 --> 52:40.000
nur einmal abgelegt wird.

52:40.000 --> 52:42.000
Wenn jetzt ein Bit flippt in deinem Bild,

52:42.000 --> 52:44.000
dann wird dieses Bild ein Defekt haben.

52:44.000 --> 52:46.000
Da kommt man gar nicht drumherum.

52:46.000 --> 52:48.000
Es gibt aber auch

52:48.000 --> 52:50.000
einen Datenschnipsel.

52:50.000 --> 52:52.000
Dieser Datenschnipsel selber, der wird aber

52:52.000 --> 52:54.000
mit hoher Wahrscheinlichkeit nur in exakt diesem

52:54.000 --> 52:56.000
Bild sein.

52:56.000 --> 52:58.000
Oder vielleicht, wenn man da drei Versionen daneben

52:58.000 --> 53:00.000
liegen hat, wo man dann gearbeitet hat.

53:00.000 --> 53:02.000
Trotzdem wird es sehr wahrscheinlich, wenn das

53:02.000 --> 53:04.000
JPEG-Dateien sind, wird es sehr wahrscheinlich

53:04.000 --> 53:06.000
so sein, dass dieser Datenschnipsel nur

53:06.000 --> 53:08.000
bei dem einen Bild passiert.

53:08.000 --> 53:10.000
Der wird nur da bei dem einen Bild verwendet.

53:10.000 --> 53:12.000
Wenn das aber andere Daten sind, wie

53:12.000 --> 53:14.000
ich habe hier eine besonders wichtige

53:14.000 --> 53:16.000
Ziehbibliothek und die habe ich selber geschrieben,

53:16.000 --> 53:18.000
die ist aus 10.000 Zeilen eng optimiert

53:18.000 --> 53:20.000
im C-Assembler-Code.

53:20.000 --> 53:22.000
Und die ist jetzt kaputt.

53:22.000 --> 53:24.000
Aber alle deine Projekte basieren da drauf.

53:24.000 --> 53:26.000
Und diese Datei ist in allen deinen

53:26.000 --> 53:28.000
Projekten drin.

53:28.000 --> 53:30.000
Aber RESTIC hat sie natürlich nur einmal

53:30.000 --> 53:32.000
gespeichert, weil es ja dedipliziert.

53:32.000 --> 53:34.000
Dann ist diese Datei weg.

53:34.000 --> 53:36.000
Und das ist auch ein größeres Problem.

53:36.000 --> 53:38.000
Und deswegen haben viele Leute auch nicht

53:38.000 --> 53:40.000
nur eine Location, wo sie Backups hinschieben,

53:40.000 --> 53:42.000
sondern unabhängig davon.

53:42.000 --> 53:44.000
Die eine vielleicht in der Cloud, die andere

53:44.000 --> 53:46.000
nicht.

53:46.000 --> 53:48.000
Und wenn man jetzt, du hattest vorhin gefragt,

53:48.000 --> 53:50.000
deswegen passt das gerade ganz gut.

53:50.000 --> 53:52.000
Ob RESTIC ist auch unterstützt, dass man

53:52.000 --> 53:54.000
gleichzeitig die Daten, die man gelesen hat,

53:54.000 --> 53:56.000
auf drei verschiedenen Locations verteilt

53:56.000 --> 53:58.000
sozusagen.

53:58.000 --> 54:00.000
Und einer der Gründe, warum wir das nicht so

54:00.000 --> 54:02.000
gerne machen, ist, dass man dann auch,

54:02.000 --> 54:04.000
wenn man RESTIC mehrfach ausführt,

54:04.000 --> 54:06.000
einfach mehrere Kopien auf unterschiedliche

54:06.000 --> 54:08.000
Weise dieser Daten erzeugt.

54:08.000 --> 54:10.000
Das heißt, auch das Lesen findet mehrfach statt.

54:10.000 --> 54:12.000
Und dabei ist dann halt die Chance,

54:12.000 --> 54:14.000
wenn man das nicht so schnell merkt.

54:14.000 --> 54:16.000
Zum anderen aber auch, dass man wirklich eine

54:16.000 --> 54:18.000
komplett unabhängige Stelle hat,

54:18.000 --> 54:20.000
wo die gleichen Daten nochmal liegen.

54:20.000 --> 54:22.000
Die Wahrscheinlichkeit ist einfach viel höher.

54:22.000 --> 54:24.000
Es kann ja auch mal einen Back geben

54:24.000 --> 54:26.000
in RESTIC selber, dass der Daten nicht

54:26.000 --> 54:28.000
richtig speichert. Das lässt sich ja

54:28.000 --> 54:30.000
leider nicht ausschließen.

54:30.000 --> 54:32.000
Und eines der Sachen, die wir auch machen,

54:32.000 --> 54:34.000
ist dieses Dynamisch auseinanderschneiden

54:34.000 --> 54:36.000
von Daten.

54:36.000 --> 54:38.000
Das ist ursprünglich entstanden aus

54:38.000 --> 54:40.000
einer Security-Überlegung, dass man

54:40.000 --> 54:42.000
das Programm installiert.

54:42.000 --> 54:44.000
Deswegen wird dieses auseinanderschneiden

54:44.000 --> 54:46.000
immer anders gemacht.

54:46.000 --> 54:48.000
Also, wenn man ein Repository hat,

54:48.000 --> 54:50.000
das wird initialisiert und ab, dann ist

54:50.000 --> 54:52.000
festgelegt, wie die Daten auseinanderschnitten

54:52.000 --> 54:54.000
werden. Aber für zwei verschiedene

54:54.000 --> 54:56.000
Repositories kann das unterschiedlich sein.

54:56.000 --> 54:58.000
Das heißt auch, wenn du jetzt deine

54:58.000 --> 55:00.000
10.000 Zeilen C-Datei zum Beispiel,

55:00.000 --> 55:02.000
es könnte sein, dass die in dem einen

55:02.000 --> 55:04.000
Repository in drei Stücke auseinanderschnitten

55:04.000 --> 55:06.000
wird, im anderen in vier oder sogar nur in

55:06.000 --> 55:08.000
eins. Und das erzeugt auch nochmal

55:08.000 --> 55:10.000
Variabilität, wie RESTIC-Daten

55:10.000 --> 55:12.000
verarbeitet.

55:12.000 --> 55:14.000
Und das ist auch jetzt sozusagen

55:14.000 --> 55:16.000
ein bewusstes Feature und passiert

55:16.000 --> 55:18.000
nicht wegen irgendwie eines anders

55:18.000 --> 55:20.000
geadeten Seeds auf irgendeine Weise.

55:20.000 --> 55:22.000
Und man nimmt Zeit.

55:22.000 --> 55:24.000
Genau, das ist tatsächlich also aus der

55:24.000 --> 55:26.000
Security-Überlegung, dass man kein Fingerprinting

55:26.000 --> 55:28.000
machen soll, weil wenn man halt

55:28.000 --> 55:30.000
zuschauen kann, wie so ein Repository

55:30.000 --> 55:32.000
wächst zum Beispiel. Und Vermutungen

55:32.000 --> 55:34.000
hat, welche Daten da gesichert werden

55:34.000 --> 55:36.000
könnten, dann könnte man vielleicht

55:36.000 --> 55:38.000
durch Beobachtungen darauf schließen.

55:38.000 --> 55:40.000
Deswegen haben wir ganz zu Anfang gesagt,

55:40.000 --> 55:42.000
wir initialisieren das mit so einem Seed.

55:42.000 --> 55:44.000
Und das ist jedes Mal pro Repository

55:44.000 --> 55:46.000
einfach ein anderer.

55:46.000 --> 55:48.000
Kann man übrigens alles in einem Design

55:48.000 --> 55:50.000
Dokument nachlesen, da gibt es auch unten

55:50.000 --> 55:52.000
das Thread Model. Das heißt, was haben

55:52.000 --> 55:54.000
wir uns gedacht, was sind Angreifer

55:54.000 --> 55:56.000
gegen die RESTIC schützen soll

55:56.000 --> 55:58.000
und Design dafür ist und was sind

55:58.000 --> 56:00.000
Angreifer gegen die kann es vielleicht

56:00.000 --> 56:02.000
nicht schützen. Der Beispiel dafür ist

56:02.000 --> 56:04.000
zum Beispiel, wenn der Administrator

56:04.000 --> 56:06.000
möchte dieses Nass jetzt gerne abfackeln

56:06.000 --> 56:08.000
oder alle deine Daten löschen, dann ist

56:08.000 --> 56:10.000
was da kann RESTIC einfach nichts gegen tun.

56:10.000 --> 56:12.000
Das muss man sich eben bewusst sein, wenn man

56:12.000 --> 56:14.000
seine Daten auf das Nass seines Kumpels

56:14.000 --> 56:16.000
im Keller legt.

56:16.000 --> 56:18.000
Ja, beziehungsweise es gibt ja natürlich

56:18.000 --> 56:20.000
ganz natürlich Szenarien, wo ein

56:20.000 --> 56:22.000
Backup dann nichts mehr hilft. Also Atomkrieg

56:22.000 --> 56:24.000
mit Theoriten-Einschlag, dann ist

56:24.000 --> 56:26.000
halt auch...

56:26.000 --> 56:28.000
Dann ist das halt auch egal, ob man Windows

56:28.000 --> 56:30.000
oder Linux benutzt hat zu Lebzeiten.

56:30.000 --> 56:32.000
Genau, aber das sind Sachen

56:32.000 --> 56:34.000
gerade dieses Problem, was du eben

56:34.000 --> 56:36.000
angesprochen hast, dass wenn ich ein Backup-

56:36.000 --> 56:38.000
Programm habe, was die Duplikation macht, dann

56:38.000 --> 56:40.000
reduziert es die, ja, einfach die Anzahl

56:40.000 --> 56:42.000
Stellen, wo Daten liegen können.

56:42.000 --> 56:44.000
Wenn du jetzt so ein klassisches Backup-

56:44.000 --> 56:46.000
Programm hast, was voll und inkrementell

56:46.000 --> 56:48.000
Backups hat, jedes Vollbackup speichert

56:48.000 --> 56:50.000
alle Daten. Wenn das auf der Platte einfach

56:50.000 --> 56:52.000
zehn Vollbackups sind, dann liegen da zehn

56:52.000 --> 56:54.000
mal nebeneinander die Daten. Das ist nicht

56:54.000 --> 56:56.000
besonders speichereffizient und wenn du eine

56:56.000 --> 56:58.000
kleine Leitung hast und das da in einen

56:58.000 --> 57:00.000
Cloud-Dienst schiebst, dann wirst du da

57:00.000 --> 57:02.000
in eines der Vollbackups kaputt ist und die

57:02.000 --> 57:04.000
Datei in einem anderen noch drin liegt, kannst du die

57:04.000 --> 57:06.000
wieder herstellen. Und ich habe Ideen

57:06.000 --> 57:08.000
dafür, wie man dieses Speicherformat,

57:08.000 --> 57:10.000
was RESTIC benutzt, das Repository,

57:10.000 --> 57:12.000
was sehr ähnlich zu einem Git Repository

57:12.000 --> 57:14.000
aufgebaut ist, wie man das erweitern kann,

57:14.000 --> 57:16.000
dass man nachträglich, nachdem das

57:16.000 --> 57:18.000
Backup gelaufen ist, wieder Redundanz hinzufügt.

57:18.000 --> 57:20.000
Es gibt da so genannte

57:20.000 --> 57:22.000
Forward Error Correcting Codes, FEC,

57:22.000 --> 57:24.000
die sind so...

57:24.000 --> 57:26.000
Also die blähen die Daten wieder auf,

57:26.000 --> 57:28.000
man kann da dann auch einstellen, vielleicht,

57:28.000 --> 57:30.000
man sagt, ich möchte jetzt gerne,

57:30.000 --> 57:32.000
dass meine Daten, die werden jetzt 15% größer,

57:32.000 --> 57:34.000
dafür können bis zu, keine Ahnung,

57:34.000 --> 57:36.000
10% von einer Datei kaputt gehen

57:36.000 --> 57:38.000
und ich kann sie trotzdem wieder herstellen,

57:38.000 --> 57:40.000
eben um so Bitflips im Speicher

57:40.000 --> 57:42.000
von dem komischen Cloud-Dienst

57:42.000 --> 57:44.000
ausgleichen zu können. Oder die

57:44.000 --> 57:46.000
Festplatte hat doch da irgendwie diese 2 Bits

57:46.000 --> 57:48.000
anders zurückgeliefert, als sie sagte.

57:48.000 --> 57:50.000
Oder die gute alte Auto-CD, die hat

57:50.000 --> 57:52.000
doch genau so was, um Kratzer zu

57:52.000 --> 57:54.000
kompensieren. Ja, ganz genau,

57:54.000 --> 57:56.000
daher kommt das auch. Das ist ein sehr einfacher

57:56.000 --> 57:58.000
Job, da gibt es mittlerweile sehr viel mehr.

57:58.000 --> 58:00.000
Das müsste man aber einbauen.

58:00.000 --> 58:02.000
Und was wir gelernt haben, als Projekt,

58:02.000 --> 58:04.000
es ist unglaublich wichtig, dass man sich

58:04.000 --> 58:06.000
weiterentwickelt, aber das muss gerade

58:06.000 --> 58:08.000
so als Backup-Programm sehr kontrolliert

58:08.000 --> 58:10.000
passieren, da muss man es immer sehr gut überlegen.

58:10.000 --> 58:12.000
Und eine der Sachen, die wir sehr lange

58:12.000 --> 58:14.000
nicht hatten, ist, dass

58:14.000 --> 58:16.000
Rastic jetzt bis vor kurzem

58:16.000 --> 58:18.000
keine Kompression unterstützt hat.

58:18.000 --> 58:20.000
Und es gab damals, als ich angefangen

58:20.000 --> 58:22.000
habe, einfach keine gute Kompressions-Library

58:22.000 --> 58:24.000
für Go, die auch irgendwie schnell war

58:24.000 --> 58:26.000
und es gab keine gute Kompressionen, wo man

58:26.000 --> 58:28.000
nicht halt irgendwie 15 Werte erst

58:28.000 --> 58:30.000
einstellen musste, damit das optimal

58:30.000 --> 58:32.000
passt, sondern es gab einfach nichts

58:32.000 --> 58:34.000
Gescheites, also haben wir es erstmal

58:34.000 --> 58:36.000
weggelassen. Wir haben jetzt im Nachhinein

58:36.000 --> 58:38.000
das Storage-Format erweitert, so dass man

58:38.000 --> 58:40.000
mit älteren Rastic-Versionen da zwar nicht

58:40.000 --> 58:42.000
mehr darauf zugreifen kann, aber alte

58:42.000 --> 58:44.000
Daten, die jetzt bei dem Cloud-Dienst

58:44.000 --> 58:46.000
liegen, die sind weiterhin gültig. Das heißt,

58:46.000 --> 58:48.000
ich konnte ein bestehendes Repository, egal

58:48.000 --> 58:50.000
wie groß das war sozusagen, upgraden,

58:50.000 --> 58:52.000
dass danach dann neuere Versionen von

58:52.000 --> 58:54.000
ganzen Daten, die da schon liegen, die bleiben

58:54.000 --> 58:56.000
gültig. Und da hat es

58:56.000 --> 58:58.000
sehr viele Diskussionen gegeben, weil man

58:58.000 --> 59:00.000
auch, es gab einige Stimmen, die gesagt haben,

59:00.000 --> 59:02.000
ja, dann lass uns doch jetzt die Gelegenheit

59:02.000 --> 59:04.000
nutzen, wir definieren jetzt das Storage-Format

59:04.000 --> 59:06.000
komplett neu, das ist nicht rückwärts

59:06.000 --> 59:08.000
kompatibel, dann können wir ganz viel alten

59:08.000 --> 59:10.000
Code wegschmeißen. Beste Idee abzeiten.

59:10.000 --> 59:12.000
Ja, da haben wir uns aber explizit

59:12.000 --> 59:14.000
gegen entschieden, obwohl das halt im Code

59:14.000 --> 59:16.000
dann heißt, dass man ältere Sachen weiter

59:16.000 --> 59:18.000
unterstützen will, aber es kann ja nicht sein,

59:18.000 --> 59:20.000
dass ich einen Backup mache und drei Jahre

59:20.000 --> 59:22.000
lesen kann, weil dann ist es kein Backup.

59:22.000 --> 59:24.000
Und also haben wir eine Möglichkeit gefunden,

59:24.000 --> 59:26.000
wie wir das nachträglich nachrüsten.

59:26.000 --> 59:28.000
Das ist nicht die eleganteste Lösung,

59:28.000 --> 59:30.000
aber es ist eine schöne Lösung, eine eindeutige

59:30.000 --> 59:32.000
Lösung und sie erlaubt es Leuten, ihre Repositories

59:32.000 --> 59:34.000
so ein Stückchenweise zu upgraden und

59:34.000 --> 59:36.000
dann neue Daten schon verschlüsselt

59:36.000 --> 59:38.000
abzuspeichern, aber alte Daten, die da liegen,

59:38.000 --> 59:40.000
auch einfach liegen zu lassen.

59:40.000 --> 59:42.000
Ja, das ist wie Java-Skriptin der Webwelt.

59:42.000 --> 59:44.000
Breaking changes gehen nicht, aber man kann immer

59:44.000 --> 59:46.000
was hinzufügen und bloß manchmal einen syntaktischen

59:46.000 --> 59:48.000
Kunstgriff machen. Ja, sozusagen,

59:48.000 --> 59:50.000
das haben wir dann in ganz klein bei diesem

59:50.000 --> 59:52.000
Repository-Format gemacht. Das ist wirklich

59:52.000 --> 59:54.000
sehr, sehr wenig. Wir mussten da irgendwie

59:54.000 --> 59:56.000
kennzeichnen, welche Dateien verschlüsselte Daten

59:56.000 --> 59:58.000
erhalten und welche nicht. Die Details kann

59:58.000 --> 01:00:00.000
man sich in dem Designdokument mal angucken,

01:00:00.000 --> 01:00:02.000
dass es, ich finde, eigentlich ein ganz schöner

01:00:02.000 --> 01:00:04.000
Workaround, aber es hat da auch Stimmen gegeben,

01:00:04.000 --> 01:00:06.000
die gesagt haben, nee, komm, lass uns jetzt die alten

01:00:06.000 --> 01:00:08.000
Zöpfe abschneiden, aber es kann ja nicht sein,

01:00:08.000 --> 01:00:10.000
dass ich alte Backups nicht mehr lesen kann, das geht

01:00:10.000 --> 01:00:12.000
einfach nicht. Das ist schlecht, ja,

01:00:12.000 --> 01:00:14.000
gerade wenn man darauf angewiesen ist,

01:00:14.000 --> 01:00:16.000
dass man nochmal in fünf Jahre alt

01:00:16.000 --> 01:00:18.000
das Backup oder so reingucken muss.

01:00:18.000 --> 01:00:20.000
Ja, wo das an sich, also ich

01:00:20.000 --> 01:00:22.000
auf Twitter mal hier im Internet Archiv folgen,

01:00:22.000 --> 01:00:24.000
was die halt alles so für Zeug

01:00:24.000 --> 01:00:26.000
wiederherstellen.

01:00:26.000 --> 01:00:28.000
Also da sind ja die Zeithorizonte

01:00:28.000 --> 01:00:30.000
auch nochmal ganz anderer, also

01:00:30.000 --> 01:00:32.000
das eichhörnchen Gehirn eines

01:00:32.000 --> 01:00:34.000
Entwicklers irgendwie so hat von irgendwie

01:00:34.000 --> 01:00:36.000
fünf Jahren ist schon irgendwie Ewigkeiten her.

01:00:36.000 --> 01:00:38.000
Ja, da hast du natürlich recht,

01:00:38.000 --> 01:00:40.000
ich wollte aber nochmal

01:00:40.000 --> 01:00:42.000
auf das Thema Zukunft hinaus,

01:00:42.000 --> 01:00:44.000
nämlich ihr macht das jetzt, oder du

01:00:44.000 --> 01:00:46.000
machst das jetzt acht Jahre irgendwie.

01:00:46.000 --> 01:00:48.000
Ich sag mal dein eigenes Problem

01:00:48.000 --> 01:00:50.000
wahrscheinlich dein Dateien

01:00:50.000 --> 01:00:52.000
zu Backuppen,

01:00:52.000 --> 01:00:54.000
das Problem hast du bestimmt

01:00:54.000 --> 01:00:56.000
sage ich mal zu 99,95% gelöst,

01:00:56.000 --> 01:00:58.000
würde ich mal schätzen.

01:00:58.000 --> 01:01:00.000
Dennoch gibt es ja immer

01:01:00.000 --> 01:01:02.000
wieder Weiterentwicklungen, du hast

01:01:02.000 --> 01:01:04.000
jetzt die Kompression angesprochen.

01:01:04.000 --> 01:01:06.000
Was ist so

01:01:06.000 --> 01:01:08.000
ja für dich,

01:01:08.000 --> 01:01:10.000
für das Tool, aber

01:01:10.000 --> 01:01:12.000
halt auch für sozusagen

01:01:12.000 --> 01:01:14.000
am generellen Backup-Himmel sozusagen.

01:01:14.000 --> 01:01:16.000
Was ist der nächste Step, also

01:01:16.000 --> 01:01:18.000
wo geht's hin?

01:01:18.000 --> 01:01:20.000
Also ein großer

01:01:20.000 --> 01:01:22.000
Step ist auf jeden Fall, dass wir da

01:01:22.000 --> 01:01:24.000
genau die Sache angehen

01:01:24.000 --> 01:01:26.000
werden irgendwann, die ihr

01:01:26.000 --> 01:01:28.000
angesprochen habt mit der Redundanz,

01:01:28.000 --> 01:01:30.000
dass wir also solche Error-Correcting-Codes

01:01:30.000 --> 01:01:32.000
einbauen werden, das auf jeden Fall.

01:01:32.000 --> 01:01:34.000
Wir haben aufgehört, Backends zu

01:01:34.000 --> 01:01:36.000
implementieren, also verschiedene Cloud-Dienste,

01:01:36.000 --> 01:01:38.000
wir haben uns damit R-Clone zusammengetan,

01:01:38.000 --> 01:01:40.000
das ist so ein ganz bekanntes Tool, was halt

01:01:40.000 --> 01:01:42.000
die Cloud-Dienste miteinander synchronisieren kann

01:01:42.000 --> 01:01:44.000
und das kann Rastic als Backend benutzen,

01:01:44.000 --> 01:01:46.000
wo man quasi Daten dann im R-Clone übergibt

01:01:46.000 --> 01:01:48.000
und das sorgt dafür, dass das irgendwo

01:01:48.000 --> 01:01:50.000
auf den Cloud-Dienst kommt.

01:01:50.000 --> 01:01:52.000
Es wird auf jeden Fall eine größere

01:01:52.000 --> 01:01:54.000
Änderung geben demnächst, was die

01:01:54.000 --> 01:01:56.000
Unterstützung von Fuse-Mounts angeht.

01:01:56.000 --> 01:01:58.000
Das bedeutet, ich kann

01:01:58.000 --> 01:02:00.000
mit Rastic mein Repository

01:02:00.000 --> 01:02:02.000
sozusagen mounten, also wer unter Linux

01:02:02.000 --> 01:02:04.000
mal gearbeitet hat, wird das kennen. Ich binde

01:02:04.000 --> 01:02:06.000
das sozusagen als Laufwerk ein und kann

01:02:06.000 --> 01:02:08.000
dann on demand, obwohl das Repository

01:02:08.000 --> 01:02:10.000
in der Cloud liegt, auf meinen Snapshots

01:02:10.000 --> 01:02:12.000
rumbrausen, in der Dateistruktur und kann

01:02:12.000 --> 01:02:14.000
man einzelne Dateien einfach mit

01:02:14.000 --> 01:02:16.000
CP und meinen ganz normalen Kommando-Zahlen

01:02:16.000 --> 01:02:18.000
Tools rausziehen. Und da, das hat sich

01:02:18.000 --> 01:02:20.000
herausgestellt, das ist einfach unter

01:02:20.000 --> 01:02:22.000
Windows nicht so einfach zu implementieren,

01:02:22.000 --> 01:02:24.000
wir unterstützen Windows aber und wollen

01:02:24.000 --> 01:02:26.000
dann da auch nochmal eine Möglichkeit schaffen,

01:02:26.000 --> 01:02:28.000
dass wir da irgendwie auch so eine Art Laufwerk

01:02:28.000 --> 01:02:30.000
einbinden machen. Das ist auf jeden Fall

01:02:30.000 --> 01:02:32.000
was eine GUI wäre schön, da fehlt uns

01:02:32.000 --> 01:02:34.000
noch jemand, der da wirklich

01:02:34.000 --> 01:02:36.000
Lust drauf hat, wobei Rastic

01:02:36.000 --> 01:02:38.000
wirklich so eine Art Kommando-Zahlen-Tool

01:02:38.000 --> 01:02:40.000
ist und es eine ganze Menge Tools gibt,

01:02:40.000 --> 01:02:42.000
die da drumherum

01:02:42.000 --> 01:02:44.000
sozusagen eine GUI gebaut haben,

01:02:44.000 --> 01:02:46.000
dass aber Rastic als Kommando-Zahlen-Tool

01:02:46.000 --> 01:02:48.000
immer noch aufrufen

01:02:48.000 --> 01:02:50.000
intern dann. Und ja,

01:02:50.000 --> 01:02:52.000
das ist so das, was so

01:02:52.000 --> 01:02:54.000
jetzt in nächster Zeit ansteht

01:02:54.000 --> 01:02:56.000
und was dann im weiteren Horizont

01:02:56.000 --> 01:02:58.000
so ein bisschen, also ich träume

01:02:58.000 --> 01:03:00.000
noch davon irgendwann auch nochmal

01:03:00.000 --> 01:03:02.000
asymmetrische Kryptografie einzubauen,

01:03:02.000 --> 01:03:04.000
dass man Konstellationen schaffen kann,

01:03:04.000 --> 01:03:06.000
wo ein System in der Lage ist, ein neues

01:03:06.000 --> 01:03:08.000
Backup zu schreiben, aber nicht alte

01:03:08.000 --> 01:03:10.000
Daten zu lesen. Das Szenario

01:03:10.000 --> 01:03:12.000
dafür ist, das kommt immer wieder auch

01:03:12.000 --> 01:03:14.000
vor, dass man sagt, ich habe hier einen

01:03:14.000 --> 01:03:16.000
Server, der hat Daten, die ändern sich,

01:03:16.000 --> 01:03:18.000
ich möchte davon vielleicht sehr lange

01:03:18.000 --> 01:03:20.000
ein Backup von haben, wenn aber dieser

01:03:20.000 --> 01:03:22.000
Server kompromittiert wird, also der

01:03:22.000 --> 01:03:24.000
Angreiferzugriff auf den Server erlangt

01:03:24.000 --> 01:03:26.000
und auch zu den Zugangsdaten zu einem Repository,

01:03:26.000 --> 01:03:28.000
da soll der bitte keine alten

01:03:28.000 --> 01:03:30.000
Daten lesen können. Und das ist

01:03:30.000 --> 01:03:32.000
eine ganz interessante Herausforderung

01:03:32.000 --> 01:03:34.000
sowas zu implementieren. Das gibt es schon

01:03:34.000 --> 01:03:36.000
in anderen Tools, ist die Frage, ob das

01:03:36.000 --> 01:03:38.000
für RESTIC passend ist.

01:03:38.000 --> 01:03:40.000
Warum soll das nicht sein?

01:03:40.000 --> 01:03:42.000
Weil RESTIC

01:03:42.000 --> 01:03:44.000
eigentlich in dem, was es tut,

01:03:44.000 --> 01:03:46.000
es hat ein Repository, es hat

01:03:46.000 --> 01:03:48.000
ein Passwort, es kann Backups machen, es

01:03:48.000 --> 01:03:50.000
kann Backups wiederherstellen,

01:03:50.000 --> 01:03:52.000
das kann es gut

01:03:52.000 --> 01:03:54.000
und eventuell ergibt es Sinn,

01:03:54.000 --> 01:03:56.000
das einfach auf diesem Stand zu

01:03:56.000 --> 01:03:58.000
lassen und zu sagen, wir machen diesen

01:03:58.000 --> 01:04:00.000
einen Job und den machen wir richtig gut

01:04:00.000 --> 01:04:02.000
und diesen anderen Use Case, den gibt es

01:04:02.000 --> 01:04:04.000
zwar, der wäre auch schön, wenn wir den

01:04:04.000 --> 01:04:06.000
unterstützen, aber vielleicht ist es die

01:04:06.000 --> 01:04:08.000
Komplexität nicht wert.

01:04:08.000 --> 01:04:10.000
Man müsste das Storage Format erweitern,

01:04:10.000 --> 01:04:12.000
man muss das in das Programm selber

01:04:12.000 --> 01:04:14.000
einbauen, aller Code, den wir da

01:04:14.000 --> 01:04:16.000
einbauen, speziell an so neurologischen

01:04:16.000 --> 01:04:18.000
Punkten wie der Verschlüsselung, das

01:04:18.000 --> 01:04:20.000
wird immer auch die Gefahr, dass man da

01:04:20.000 --> 01:04:22.000
versehentlich katastrophale Fehler macht

01:04:22.000 --> 01:04:24.000
und eventuell ist es das nicht wert

01:04:24.000 --> 01:04:26.000
und das ist immer so die Abwägung.

01:04:26.000 --> 01:04:28.000
Auf der anderen Seite, wir sind jetzt so ein

01:04:28.000 --> 01:04:30.000
von vier Leuten, glaube ich,

01:04:30.000 --> 01:04:32.000
die das auch irgendwie

01:04:32.000 --> 01:04:34.000
entwickeln und vor allen Dingen

01:04:34.000 --> 01:04:36.000
supporten müssen und vielleicht können

01:04:36.000 --> 01:04:38.000
wir gleich nochmal so ein bisschen über

01:04:38.000 --> 01:04:40.000
Community und Projektentwicklung reden,

01:04:40.000 --> 01:04:42.000
weil das auch sich komplett anders

01:04:42.000 --> 01:04:44.000
entwickelt hat, als ich gedacht hätte

01:04:44.000 --> 01:04:46.000
und da ist einfach die Frage, können wir

01:04:46.000 --> 01:04:48.000
das leisten, so was zu entwickeln, als

01:04:48.000 --> 01:04:50.000
Open Source Projekt, die das von Leuten,

01:04:50.000 --> 01:04:52.000
die das in ihrer Freizeit machen oder ist

01:04:52.000 --> 01:04:54.000
das vielleicht eher was, das überlassen

01:04:54.000 --> 01:04:56.000
wir dann vielleicht anderen Projekten

01:04:56.000 --> 01:04:58.000
um das Gedanke, dass es möglichst einfach

01:04:58.000 --> 01:05:00.000
sein soll, wenn ich jetzt mir da

01:05:00.000 --> 01:05:02.000
erst mal Gedanken machen muss, wer kann wann,

01:05:02.000 --> 01:05:04.000
welches Backup wiederherstellen, weil wegen

01:05:04.000 --> 01:05:06.000
Kryptografie und so weiter, dann wird's halt

01:05:06.000 --> 01:05:08.000
auch wieder zu komplex und vielleicht ist

01:05:08.000 --> 01:05:10.000
das einfach nicht unser Anwendungsfall.

01:05:12.000 --> 01:05:14.000
Ja, do one thing, do it good

01:05:14.000 --> 01:05:16.000
nach diesem Motto, also

01:05:16.000 --> 01:05:18.000
mach mal lieber eine Sache richtig,

01:05:18.000 --> 01:05:20.000
du hast ja schon

01:05:20.000 --> 01:05:22.000
angesprochen, ihr macht das sozusagen

01:05:22.000 --> 01:05:24.000
in der Freizeit, da sind jetzt

01:05:24.000 --> 01:05:26.000
5 Leute so im Core Team

01:05:26.000 --> 01:05:28.000
irgendwie und drumherum gibt's

01:05:28.000 --> 01:05:30.000
natürlich viele Contributions, wahrscheinlich

01:05:30.000 --> 01:05:32.000
viele Leute, die nach

01:05:32.000 --> 01:05:34.000
Support in den Comments

01:05:34.000 --> 01:05:36.000
oder in den Issues fragen

01:05:36.000 --> 01:05:38.000
oder irgendwie Probleme

01:05:38.000 --> 01:05:40.000
bei der Anwendung haben.

01:05:40.000 --> 01:05:42.000
Wie organisiert ihr euch da?

01:05:42.000 --> 01:05:44.000
Hauptsächlich über

01:05:44.000 --> 01:05:46.000
GitHub selber und über das Forum.

01:05:46.000 --> 01:05:48.000
Ich habe eine Instanz von Discourse

01:05:48.000 --> 01:05:50.000
aufgesetzt, also Discourse ist diese

01:05:50.000 --> 01:05:52.000
ganz bekannte, wie Forum mal in richtig,

01:05:52.000 --> 01:05:54.000
es ist glaube ich ein Hobby geschrieben, von

01:05:54.000 --> 01:05:56.000
den Leuten, die mal Stack Overflow

01:05:56.000 --> 01:05:58.000
gegründet haben, das kann ich sehr empfehlen,

01:05:58.000 --> 01:06:00.000
weil das im Prinzip ein

01:06:00.000 --> 01:06:02.000
Selbstläufer ist. Also man holt

01:06:02.000 --> 01:06:04.000
sich den Container, startet das ganze Ding

01:06:04.000 --> 01:06:06.000
und dann kann man loslegen. Und es gibt

01:06:06.000 --> 01:06:08.000
viele so Moderationsfeatures

01:06:08.000 --> 01:06:10.000
die sie auch von Stack Overflow

01:06:10.000 --> 01:06:12.000
mit übernommen haben, das halt je länger

01:06:12.000 --> 01:06:14.000
ich zum Beispiel lese, desto mehr, desto

01:06:14.000 --> 01:06:16.000
höher habe ich Berechtigungen in dem

01:06:16.000 --> 01:06:18.000
Forum und das bekommt man auch selber schon,

01:06:18.000 --> 01:06:20.000
wenn jemand sehr viel liest, dann bekommt

01:06:20.000 --> 01:06:22.000
man eine Berechtigung bei anderen Leuten

01:06:22.000 --> 01:06:24.000
Tippfehler zu korrigieren, das kennt man ja

01:06:24.000 --> 01:06:26.000
von Stack Overflow selber auch.

01:06:26.000 --> 01:06:28.000
Das hat extrem gut funktioniert.

01:06:28.000 --> 01:06:30.000
Und ich habe ganz von Anfang an sehr drauf geachtet

01:06:30.000 --> 01:06:32.000
dass sowohl in den GitHub Issues

01:06:32.000 --> 01:06:34.000
als auch in dem Forum

01:06:34.000 --> 01:06:36.000
ein sehr pfleglicher Umgangston herrscht

01:06:36.000 --> 01:06:38.000
und habe alle Leute gnadenlos gesperrt

01:06:38.000 --> 01:06:40.000
und rausgeschmissen, die sich da nicht dran gehalten

01:06:40.000 --> 01:06:42.000
haben. Und das hat dazu geführt, dass es

01:06:42.000 --> 01:06:44.000
Leute im Forum gibt, die auch selber gar

01:06:44.000 --> 01:06:46.000
nicht entwickeln, nur in diesem Forum

01:06:46.000 --> 01:06:48.000
aktiv sind und anderen helfen. Mehr machen die

01:06:48.000 --> 01:06:50.000
Leute in diesem Forum.

01:06:50.000 --> 01:06:52.000
Und das ist natürlich großartig, das wünscht

01:06:52.000 --> 01:06:54.000
sich jedes Projekt, das so zu haben.

01:06:54.000 --> 01:06:56.000
Weil normalerweise immer so dieses Support

01:06:56.000 --> 01:06:58.000
Arbeit, das ist halt das so ja, dann guckt

01:06:58.000 --> 01:07:00.000
man halt nochmal rein und schreibt dann

01:07:00.000 --> 01:07:02.000
nochmal kurz was zu, aber es gibt da

01:07:02.000 --> 01:07:04.000
wirklich, wenn jetzt jemand ins Forum

01:07:04.000 --> 01:07:06.000
schreibt, dann ist in der Regel innerhalb

01:07:06.000 --> 01:07:08.000
von ganz kurzer Zeit und maximal so ein halber

01:07:08.000 --> 01:07:10.000
Tag, hat da jemand mal drauf geantwortet,

01:07:10.000 --> 01:07:12.000
hat ihm gesagt, okay, wenn du jetzt irgendwie

01:07:12.000 --> 01:07:14.000
Probleme hast, dann welche Version hast du,

01:07:14.000 --> 01:07:16.000
welches Backend ist das denn?

01:07:16.000 --> 01:07:18.000
Es gibt da auch so gut wie kein Spam.

01:07:18.000 --> 01:07:20.000
Weil sehr schnell, wenn jemand da eine

01:07:20.000 --> 01:07:22.000
Nachricht schreibt und irgendwie nur auf seine

01:07:22.000 --> 01:07:24.000
Seite hinweisen will, dann wird das halt

01:07:24.000 --> 01:07:26.000
markiert, wenn es von zwei oder drei

01:07:26.000 --> 01:07:28.000
Benutzern, egal wie kurz die dabei sind,

01:07:28.000 --> 01:07:30.000
als Spam markiert wird, dann wird es erstmal

01:07:30.000 --> 01:07:32.000
versteckt und dann hat dann nachher ein

01:07:32.000 --> 01:07:34.000
Moderator dann eine Chance das zu machen.

01:07:34.000 --> 01:07:36.000
Wir haben dann da auch zum Teil dann

01:07:36.000 --> 01:07:38.000
nicht öffentliche Posts, wo wir so ein bisschen

01:07:38.000 --> 01:07:40.000
die Entwicklung besprechen, wo wir besprechen

01:07:40.000 --> 01:07:42.000
was sind Features, die demnächst mal

01:07:42.000 --> 01:07:44.000
angegangen werden können, was sind auch Features

01:07:44.000 --> 01:07:46.000
oder Polrequest, die ich mir vielleicht angucken

01:07:46.000 --> 01:07:48.000
soll, als jemand, der da sehr tief

01:07:48.000 --> 01:07:50.000
im Code drin ist.

01:07:50.000 --> 01:07:52.000
Und jetzt aktuell ist es tatsächlich so,

01:07:52.000 --> 01:07:54.000
dass ich gar nicht mehr so viel entwickel.

01:07:54.000 --> 01:07:56.000
Mein Privatleben hat sich ja auch weiter

01:07:56.000 --> 01:07:58.000
entwickelt in den acht Jahren.

01:07:58.000 --> 01:08:00.000
Ich habe mittlerweile zwei kleine Kinder

01:08:00.000 --> 01:08:02.000
und komme abends nicht mehr so häufig dazu.

01:08:02.000 --> 01:08:04.000
Das heißt, ich schreibe weniger Code.

01:08:04.000 --> 01:08:06.000
Aber dafür mache ich dann eher so, ja,

01:08:06.000 --> 01:08:08.000
ich sage mal so Richtungsentscheidungen

01:08:08.000 --> 01:08:10.000
oder so, man könnte in die ein oder andere

01:08:10.000 --> 01:08:12.000
Richtung gehen und irgendjemand muss

01:08:12.000 --> 01:08:14.000
in die Richtung.

01:08:14.000 --> 01:08:16.000
Und wir haben auch noch, glaube ich,

01:08:16.000 --> 01:08:18.000
wir haben noch einen IRC-Kanal, wo man so

01:08:18.000 --> 01:08:20.000
ein bisschen mehr in Echtzeit chatten kann.

01:08:20.000 --> 01:08:22.000
Das ist jetzt alles schon so ein bisschen old-school,

01:08:22.000 --> 01:08:24.000
weil wir gar nicht so sehr in Richtung

01:08:24.000 --> 01:08:26.000
Internet und Discord und was es alles gibt.

01:08:26.000 --> 01:08:28.000
Dafür ist die Infrastruktur, aber bis auf GitHub

01:08:28.000 --> 01:08:30.000
ist die Infrastruktur auch selbst gehostet.

01:08:30.000 --> 01:08:32.000
Also wir haben hier lokal in Aachen

01:08:32.000 --> 01:08:34.000
einen kleinen Internet-Provider,

01:08:34.000 --> 01:08:36.000
einen Hosting-Dienstleister, der da auch

01:08:36.000 --> 01:08:38.000
ein Server bereitgestellt hat und da läuft

01:08:38.000 --> 01:08:40.000
das dann auch alles drauf, dass wir recht

01:08:40.000 --> 01:08:42.000
eigentlich sind jetzt abgesehen von GitHub.

01:08:42.000 --> 01:08:44.000
Aber ich glaube, wenn GitHub kommt,

01:08:44.000 --> 01:08:46.000
kein Open-Source-Projekt dran vorbei.

01:08:46.000 --> 01:08:48.000
Es ist sehr schwierig, ja.

01:08:48.000 --> 01:08:50.000
Außer man holt sich vielleicht seine eigene

01:08:50.000 --> 01:08:52.000
Instanz von GitHub, aber das macht ja

01:08:52.000 --> 01:08:54.000
auch keinen Sinn für so ein

01:08:54.000 --> 01:08:56.000
Open-Source-Projekt, glaube ich.

01:08:56.000 --> 01:08:58.000
Ja.

01:08:58.000 --> 01:09:00.000
Das ist ja auch gar nicht so schlimm.

01:09:00.000 --> 01:09:02.000
Das Wichtige ist ja, dass man bei Bedarf

01:09:02.000 --> 01:09:04.000
wieder weg kommt von GitHub.

01:09:04.000 --> 01:09:06.000
Dann nimmt man seinen Repository und ab dafür

01:09:06.000 --> 01:09:08.000
kein so schlimmer Lock-in-Effekt, glaube ich.

01:09:08.000 --> 01:09:10.000
Das Problem ist, dass da viel drumherum ist.

01:09:10.000 --> 01:09:12.000
Wir nutzen jetzt nur die Issues und das Code-Tracking

01:09:12.000 --> 01:09:14.000
und halt die CI von GitHub.

01:09:14.000 --> 01:09:16.000
Das ist schon sehr angenehm, muss ich sagen.

01:09:16.000 --> 01:09:18.000
Das alles nicht selber hosten zu missen.

01:09:18.000 --> 01:09:20.000
Es gäbe aber auch andere.

01:09:20.000 --> 01:09:22.000
Also ich habe vor kurzem mal GTI aufgesetzt.

01:09:22.000 --> 01:09:24.000
GTI.io, das ist so ein in-go-geschriebener

01:09:24.000 --> 01:09:26.000
GitHub-Klon, die machen das schon sehr gut.

01:09:26.000 --> 01:09:28.000
Ja, also was ich auf jeden Fall

01:09:28.000 --> 01:09:30.000
sehr spannend fand, ist, dass

01:09:30.000 --> 01:09:32.000
man halt wirklich, dass ihr halt

01:09:32.000 --> 01:09:34.000
wirklich eine Engaging-Community habt.

01:09:34.000 --> 01:09:36.000
Also Leute, die halt wirklich auch Bock haben

01:09:36.000 --> 01:09:38.000
bei anderen mal zu reagieren,

01:09:38.000 --> 01:09:40.000
die das Tool halt nutzen

01:09:40.000 --> 01:09:42.000
und dann irgendwie

01:09:42.000 --> 01:09:44.000
aus den Erfahrungen auch gerne teilen.

01:09:44.000 --> 01:09:46.000
Ich glaube, sowas halt hinzubekommen.

01:09:46.000 --> 01:09:48.000
Klar, mit 18.500 Stars auf GitHub

01:09:48.000 --> 01:09:50.000
ist das...

01:09:50.000 --> 01:09:52.000
Da gibt es halt viele Benutzerinnen und Benutzer

01:09:52.000 --> 01:09:54.000
auch einfach, die das Tool täglich im Einsatz haben.

01:09:54.000 --> 01:09:56.000
Und ich glaube, das ist halt das,

01:09:56.000 --> 01:09:58.000
wenn man das schafft, da seine Community

01:09:58.000 --> 01:10:00.000
hinzubekommen.

01:10:00.000 --> 01:10:02.000
Und dann noch, wenn da noch ein pfleglicher Umgang

01:10:02.000 --> 01:10:04.000
heutzutage da vorherrscht, das ist natürlich

01:10:04.000 --> 01:10:06.000
sehr gut. Deswegen auch vielleicht an der Stelle

01:10:06.000 --> 01:10:08.000
mal an die Hörerinnen und Hörer

01:10:08.000 --> 01:10:10.000
der Aufruf guckt euch einfach mal an.

01:10:10.000 --> 01:10:12.000
Das Tool ihr habt ja auch gehört.

01:10:12.000 --> 01:10:14.000
Es wird auch Unterstützung auch im Frontend-Bereich

01:10:14.000 --> 01:10:16.000
zum Beispiel für...

01:10:16.000 --> 01:10:18.000
zum Beispiel eine Oberfläche gesucht.

01:10:18.000 --> 01:10:20.000
Also wenn das...

01:10:20.000 --> 01:10:22.000
wenn ihr jetzt sagt so, hm ja, das Tool

01:10:22.000 --> 01:10:24.000
an sich so von den Gedanken, die du jetzt

01:10:24.000 --> 01:10:26.000
auch geteilt hast, Alex, sagt euch zu,

01:10:26.000 --> 01:10:28.000
dann schaut da einfach mal vorbei

01:10:28.000 --> 01:10:30.000
oder guckt mal in die

01:10:30.000 --> 01:10:32.000
in die Kommentare, die sich so

01:10:32.000 --> 01:10:34.000
was da finden.

01:10:34.000 --> 01:10:36.000
Und ja, werft doch mal wieder

01:10:36.000 --> 01:10:38.000
Limechat oder wie hieß das

01:10:38.000 --> 01:10:40.000
an, um in IRC

01:10:40.000 --> 01:10:42.000
reinzukommen.

01:10:42.000 --> 01:10:44.000
Ja, das sind die ganzen Alten.

01:10:44.000 --> 01:10:46.000
Das Limechat habe ich nie benutzt, aber MIRC

01:10:46.000 --> 01:10:48.000
war so Ende der 90er

01:10:48.000 --> 01:10:50.000
ganz bekannt dafür.

01:10:50.000 --> 01:10:52.000
Ja, es ist tatsächlich auch...

01:10:52.000 --> 01:10:54.000
Wir haben so ein bisschen... Dadurch,

01:10:54.000 --> 01:10:56.000
dass wir in Go-Gesch, also das Restick

01:10:56.000 --> 01:10:58.000
in Go-Geschrieben ist, haben wir so ein bisschen

01:10:58.000 --> 01:11:00.000
so die Popularität dieser Programmiersprache

01:11:00.000 --> 01:11:02.000
auch als eine sehr gute Sprache rausgestellt,

01:11:02.000 --> 01:11:04.000
weil es eben

01:11:04.000 --> 01:11:06.000
ja, ich will nicht sagen, das ist der Gegenentwurf

01:11:06.000 --> 01:11:08.000
zu Rust, aber es liegt auf ganz andere

01:11:08.000 --> 01:11:10.000
Sachen wert. Und eine der Sachen

01:11:10.000 --> 01:11:12.000
ist, also in der Rust-Folge,

01:11:12.000 --> 01:11:14.000
die bei dem Podcast hier letztens

01:11:14.000 --> 01:11:16.000
war, habe ich auch gehört,

01:11:16.000 --> 01:11:18.000
dass Rust zum Beispiel sehr stark

01:11:18.000 --> 01:11:20.000
auf eine sehr dichte Sündung setzt

01:11:20.000 --> 01:11:22.000
und auch auf so Sachen wie

01:11:22.000 --> 01:11:24.000
Macros, die expandiert

01:11:24.000 --> 01:11:26.000
werden. Und dann, das ist auch eine der

01:11:26.000 --> 01:11:28.000
üblichen Kritik an Rust, aber

01:11:28.000 --> 01:11:30.000
in Go ist es halt einfach anders.

01:11:30.000 --> 01:11:32.000
Ich will nicht sagen, dass das

01:11:32.000 --> 01:11:34.000
irgendwie, das eine besser oder schlechter

01:11:34.000 --> 01:11:35.000
ist, aber

01:11:35.000 --> 01:11:37.000
Go-Code kann man eigentlich immer

01:11:37.000 --> 01:11:39.000
ziemlich gut lesen. Selbst wenn man

01:11:39.000 --> 01:11:41.000
selber, also wenn man mal selber in einer Sprache

01:11:41.000 --> 01:11:43.000
entwickelt hat, die geschweifte Klammern benutzt,

01:11:43.000 --> 01:11:45.000
um Blöcke abzutrennen, dann

01:11:45.000 --> 01:11:47.000
kann man das eigentlich ziemlich gut lesen.

01:11:47.000 --> 01:11:49.000
Und wir kriegen, gerade am Anfang, aber

01:11:49.000 --> 01:11:51.000
jetzt auch immer noch, wir kriegen einen Haufen

01:11:51.000 --> 01:11:53.000
Pullrequests, wo so Dinge halt

01:11:53.000 --> 01:11:55.000
einfach gefixt werden, weil sich jemand denkt,

01:11:55.000 --> 01:11:57.000
das sieht aber irgendwie komisch aus, hat

01:11:57.000 --> 01:11:59.000
irgendeinen Problem, guckt kurz in den Code

01:11:59.000 --> 01:12:01.000
und sieht halt irgendeinen Fehler und kann da

01:12:01.000 --> 01:12:03.000
dann ziemlich direkt mitmachen. Das ist

01:12:03.000 --> 01:12:05.000
natürlich was anderes, wenn ich so ein

01:12:05.000 --> 01:12:07.000
Programm mit sehr viel Code jetzt

01:12:07.000 --> 01:12:09.000
aus dem Boden stampfe, als wenn ich halt so

01:12:09.000 --> 01:12:11.000
ein, so ein, ich sag mal, Drive by Pullrequest,

01:12:11.000 --> 01:12:13.000
wo jemand einfach einen Fehler sieht

01:12:13.000 --> 01:12:15.000
und da mal eben das fixen kann.

01:12:15.000 --> 01:12:17.000
Und was mich sehr überrascht hat,

01:12:17.000 --> 01:12:19.000
muss ich sagen, ist,

01:12:19.000 --> 01:12:21.000
ich habe früher auch nie verstanden,

01:12:21.000 --> 01:12:23.000
wie zum Beispiel SQLite das macht.

01:12:23.000 --> 01:12:25.000
Die haben ein Modell, das ihren Code

01:12:25.000 --> 01:12:27.000
im Source zur Verfügung stellen,

01:12:27.000 --> 01:12:29.000
aber keinerlei Contributions annehmen.

01:12:29.000 --> 01:12:31.000
Und das fand ich früher immer ganz komisch.

01:12:31.000 --> 01:12:33.000
Und mittlerweile muss ich sagen, kann ich das

01:12:33.000 --> 01:12:35.000
sehr gut verstehen, weil,

01:12:35.000 --> 01:12:37.000
wenn ich selber was entwickel in meinem Keller

01:12:37.000 --> 01:12:39.000
und ich sitze hier und ich programmier was

01:12:39.000 --> 01:12:41.000
und vielleicht mit ein, zwei anderen Leuten zusammen,

01:12:41.000 --> 01:12:43.000
das ist total einfach.

01:12:43.000 --> 01:12:45.000
Wenn man aber plötzlich 500 Pullrequests

01:12:45.000 --> 01:12:47.000
aufhat, von Leuten, die Features einbauen,

01:12:47.000 --> 01:12:49.000
von Leuten, die Bugs beheben, von Leuten,

01:12:49.000 --> 01:12:51.000
die denken, die Struktur soll anders sein,

01:12:51.000 --> 01:12:53.000
das ist sehr zeitaufwendig,

01:12:53.000 --> 01:12:55.000
sich da einzuarbeiten.

01:12:55.000 --> 01:12:57.000
Und das ist noch viel zeitaufwendiger,

01:12:57.000 --> 01:12:59.000
als wenn man selber den Code schreibt.

01:12:59.000 --> 01:13:01.000
Manchmal denke ich auch, ja,

01:13:01.000 --> 01:13:03.000
vielleicht ist es einfacher,

01:13:03.000 --> 01:13:05.000
diesen Pullrequest jetzt einfach zu schließen

01:13:05.000 --> 01:13:07.000
und es nachher selber zu implementieren,

01:13:07.000 --> 01:13:09.000
weil dann habe ich es verstanden.

01:13:09.000 --> 01:13:11.000
Aber andersrum, wenn ich jemanden da hinführe,

01:13:11.000 --> 01:13:13.000
dass er das Programm weiterentwickeln kann,

01:13:13.000 --> 01:13:15.000
dann habe ich vielleicht jemanden gewonnen,

01:13:15.000 --> 01:13:17.000
der auch später mitarbeitet.

01:13:17.000 --> 01:13:19.000
Und das ist immer eine ganz spannende Abwägung.

01:13:19.000 --> 01:13:21.000
Es ist eine komplizierte

01:13:21.000 --> 01:13:23.000
Open Source Welt definitiv.

01:13:23.000 --> 01:13:25.000
Auf der einen Seite kann man sich

01:13:25.000 --> 01:13:27.000
sehr glücklich schätzen,

01:13:27.000 --> 01:13:29.000
dass man diese Contributions hat

01:13:29.000 --> 01:13:31.000
und Leute da Interesse dran haben.

01:13:31.000 --> 01:13:33.000
Und auf der anderen Seite ist es halt

01:13:33.000 --> 01:13:35.000
sehr zeitaufwendig, intensiv.

01:13:35.000 --> 01:13:37.000
Man muss auch gut Nein sagen können.

01:13:37.000 --> 01:13:39.000
Weil gerade,

01:13:39.000 --> 01:13:41.000
weil ja auch teilweise

01:13:41.000 --> 01:13:43.000
natürlich Firmen auf uns zukommen

01:13:43.000 --> 01:13:45.000
und sagen, hey, wir hätten gerne folgenden

01:13:45.000 --> 01:13:47.000
Metrikdienst und dieses Backend noch

01:13:47.000 --> 01:13:49.000
und könnt ihr nicht malen

01:13:49.000 --> 01:13:51.000
und ich habe euch auch zwei Fulltime Engineers

01:13:51.000 --> 01:13:53.000
für ein halbes Jahr hinstellen,

01:13:53.000 --> 01:13:55.000
die das implementieren, wollt ihr das

01:13:55.000 --> 01:13:57.000
und wir das dann meistens abgelehnt haben

01:13:57.000 --> 01:13:59.000
bisher, weil das dann doch immer

01:13:59.000 --> 01:14:01.000
sehr viel Koordinierungsaufwand ist

01:14:01.000 --> 01:14:03.000
und wenn man sich auch so was einlässt,

01:14:03.000 --> 01:14:05.000
dann immer die implizite Annahme ist,

01:14:05.000 --> 01:14:07.000
dass dann ja auch klar ist,

01:14:07.000 --> 01:14:09.000
dass das nachher dann gemirkt wird.

01:14:09.000 --> 01:14:11.000
Aber es kann sich ja auch einfach rausstellen,

01:14:11.000 --> 01:14:13.000
dass das einfach ein Holzweg ist

01:14:13.000 --> 01:14:15.000
und dann hat die Firma da was investiert

01:14:15.000 --> 01:14:17.000
und möchte dann auch Return of Investment haben.

01:14:17.000 --> 01:14:19.000
Das Problem an Pull Request

01:14:19.000 --> 01:14:21.000
und Code ist ja immer,

01:14:21.000 --> 01:14:23.000
dass wenn ich Nein sage,

01:14:23.000 --> 01:14:25.000
dann ist das eigentlich immer temporär.

01:14:25.000 --> 01:14:27.000
Es kann natürlich in zwei Jahren irgendwie jemand

01:14:27.000 --> 01:14:29.000
das gleiche Feature noch mal bauen,

01:14:29.000 --> 01:14:31.000
einen alten Pull Request wieder aufmachen

01:14:31.000 --> 01:14:33.000
und dann sagen, okay, ja, jetzt passt es.

01:14:33.000 --> 01:14:35.000
Aber wenn ich einmal Ja sage

01:14:35.000 --> 01:14:37.000
und diesen Pull Request nehme,

01:14:37.000 --> 01:14:39.000
dann bin ich mit diesem Code und der Funktionalität,

01:14:39.000 --> 01:14:41.000
muss ich ewig mitschleppen.

01:14:41.000 --> 01:14:43.000
Ich kann nicht einfach Features beschneiden,

01:14:43.000 --> 01:14:45.000
da sind meine Benutzer unglücklich

01:14:45.000 --> 01:14:47.000
und das wollen wir ja alle nicht.

01:14:47.000 --> 01:14:49.000
So haben wir neben dem Thema Backups

01:14:49.000 --> 01:14:51.000
jetzt auch noch ein bisschen was

01:14:51.000 --> 01:14:53.000
über die Community Arbeit gelernt,

01:14:53.000 --> 01:14:55.000
die so ein Tool dann doch mit sich bringt.

01:14:55.000 --> 01:14:57.000
Da auf jeden Fall auch

01:14:57.000 --> 01:14:59.000
Danke für die Einblicke

01:14:59.000 --> 01:15:01.000
in diesen Bereich.

01:15:01.000 --> 01:15:03.000
Jetzt nochmal Peter,

01:15:03.000 --> 01:15:05.000
vielleicht auch an dich nochmal die Frage

01:15:05.000 --> 01:15:07.000
oder auch an dich Alex,

01:15:07.000 --> 01:15:09.000
haben wir beim Thema Backups

01:15:09.000 --> 01:15:11.000
vielleicht noch einen sehr wichtigen Punkt

01:15:11.000 --> 01:15:13.000
jetzt nicht angeschnitten,

01:15:13.000 --> 01:15:15.000
ich habe noch eine Frage.

01:15:15.000 --> 01:15:17.000
Wie macht man das am besten,

01:15:17.000 --> 01:15:19.000
wenn man mehrere, sagen wir mal,

01:15:19.000 --> 01:15:21.000
Computer hat, die so

01:15:21.000 --> 01:15:23.000
als der Hauptarbeitsrechner durchgehen könnten?

01:15:23.000 --> 01:15:25.000
Ich bin halt

01:15:25.000 --> 01:15:27.000
fasenweise viel unterwegs

01:15:27.000 --> 01:15:29.000
und dann ist der Laptop hier die Primärmaschine

01:15:29.000 --> 01:15:31.000
und fasenweise bin ich auch nicht viel

01:15:31.000 --> 01:15:33.000
unterwegs und dann

01:15:33.000 --> 01:15:35.000
ist das halt eben der Rechner,

01:15:35.000 --> 01:15:37.000
der da hinten im Büro im Keller steht,

01:15:37.000 --> 01:15:39.000
die Primärmaschine.

01:15:39.000 --> 01:15:41.000
Also ich sage mal ganz ehrlich, wie ich es im Moment habe,

01:15:41.000 --> 01:15:43.000
obwohl es halt eben eigentlich

01:15:43.000 --> 01:15:45.000
dieser Job, Primärmaschine,

01:15:45.000 --> 01:15:47.000
ein Wechseln da ist,

01:15:47.000 --> 01:15:49.000
behandle ich mehr oder minder den Rechner

01:15:49.000 --> 01:15:51.000
im Keller als die Primärmaschine,

01:15:51.000 --> 01:15:53.000
der die ganze Backup-Infrastruktur um sich umhat

01:15:53.000 --> 01:15:55.000
und der Laptop hier

01:15:55.000 --> 01:15:57.000
zieht sich halt im Prinzip die Daten

01:15:57.000 --> 01:15:59.000
von dort und ist dann halt immer darüber so

01:15:59.000 --> 01:16:01.000
up to date.

01:16:01.000 --> 01:16:03.000
Es hat mal den Hut mal anders,

01:16:03.000 --> 01:16:05.000
aber ich habe kein wirkliches Backup dafür,

01:16:05.000 --> 01:16:07.000
also gibt es da irgendwie so

01:16:07.000 --> 01:16:09.000
Best Practices, wie man so

01:16:09.000 --> 01:16:11.000
Multi-End-Gerätzeug macht.

01:16:11.000 --> 01:16:13.000
Also gibt ja noch Leute, die mehr als nur

01:16:13.000 --> 01:16:15.000
zwei Computer haben, die so die Hauptrechner sein könnten.

01:16:15.000 --> 01:16:17.000
Ja, das ist eine

01:16:17.000 --> 01:16:19.000
sehr gute Frage. Ich wüsste jetzt nicht, dass es da

01:16:19.000 --> 01:16:21.000
irgendwelche Best Practices gäbe.

01:16:21.000 --> 01:16:23.000
Ich kann ja aber mal verraten, wie ich das angehen würde.

01:16:23.000 --> 01:16:25.000
Ich würde nämlich einfach

01:16:25.000 --> 01:16:27.000
beide Rechner,

01:16:27.000 --> 01:16:29.000
beide deine Arbeitsverzeichnisse da

01:16:29.000 --> 01:16:31.000
in das gleiche Restic Backup,

01:16:31.000 --> 01:16:33.000
also in das gleiche Restic Repository

01:16:33.000 --> 01:16:35.000
rein Backup sozusagen.

01:16:35.000 --> 01:16:37.000
Das könnte zum Beispiel auf dem

01:16:37.000 --> 01:16:39.000
Hauptrechner im Keller, könnte das einfach

01:16:39.000 --> 01:16:41.000
als lokales Verzeichnis liegen.

01:16:41.000 --> 01:16:43.000
Und ein Laptop macht da auch seine Backups rein.

01:16:43.000 --> 01:16:45.000
Das hat den Vorteil, dass wenn du mit großen

01:16:45.000 --> 01:16:47.000
Projekten, und sagen wir mal ehrlich, so ein

01:16:47.000 --> 01:16:49.000
Notmodeosverzeichnis kann ja schon sehr groß

01:16:49.000 --> 01:16:51.000
werden, wenn du damit dann zu tun hast,

01:16:51.000 --> 01:16:53.000
dass halt viele Daten einfach schon vorhanden sind.

01:16:53.000 --> 01:16:55.000
Das heißt, dann geht dein Backup einfach sehr schnell.

01:16:55.000 --> 01:16:57.000
Vor allen Dingen, wenn die sich halt viel Daten

01:16:57.000 --> 01:16:59.000
teilen, dann lohnt sich das.

01:16:59.000 --> 01:17:01.000
Da muss man aber auch dann wieder sagen, wenn man

01:17:01.000 --> 01:17:03.000
aus der Security sich dann wieder guckt,

01:17:03.000 --> 01:17:05.000
wenn jetzt dein Laptop

01:17:05.000 --> 01:17:07.000
in die Hände eines Angreifers fällt und der

01:17:07.000 --> 01:17:09.000
da dann die Zugangsdaten zu deinem

01:17:09.000 --> 01:17:11.000
Restic Repository auf deinem Heimrechner

01:17:11.000 --> 01:17:13.000
findet und da dann auch vielleicht das Passwort

01:17:13.000 --> 01:17:15.000
hat, um darauf zuzugreifen, dann kann er

01:17:15.000 --> 01:17:17.000
alle Daten lesen, die in diesem Repository

01:17:17.000 --> 01:17:19.000
drin liegen. Das heißt, wenn du da Daten

01:17:19.000 --> 01:17:21.000
drin hast, die du auf dem Laptop jetzt

01:17:21.000 --> 01:17:23.000
nicht hast, die Familienfotos zum Beispiel,

01:17:23.000 --> 01:17:25.000
könnte da jemand auch darauf zugreifen.

01:17:25.000 --> 01:17:27.000
Ja, die Dinger sind im Prinzip zu 99%

01:17:27.000 --> 01:17:29.000
mit den gleichen Daten ausgestattet,

01:17:29.000 --> 01:17:31.000
weil ich will halt einfach sagen können,

01:17:31.000 --> 01:17:33.000
so ich gehe jetzt und ich mache einfach woanders weiter.

01:17:33.000 --> 01:17:35.000
Also das würde von der Deduplikation natürlich

01:17:35.000 --> 01:17:37.000
schon profitieren. Das wäre ganz nice.

01:17:37.000 --> 01:17:39.000
Ja nee, sicherheitstechnisch mache ich mehr da.

01:17:39.000 --> 01:17:41.000
Bei meinem Laptop keine Sorgen, da bin ich

01:17:41.000 --> 01:17:43.000
unvernünftig paranoid, was das angeht.

01:17:43.000 --> 01:17:45.000
Da kommt hier nix raus.

01:17:47.000 --> 01:17:49.000
Okay, nee, ansonsten

01:17:49.000 --> 01:17:51.000
wäre ich nämlich tatsächlich wunschlos glücklich.

01:17:51.000 --> 01:17:53.000
Das werde ich mir mal überlegen,

01:17:53.000 --> 01:17:55.000
ob das eine

01:17:55.000 --> 01:17:57.000
Lösung wäre und natürlich am Ende des Tages

01:17:57.000 --> 01:17:59.000
die gleiche Frage wie zu Beginn,

01:17:59.000 --> 01:18:01.000
ob es das dann wirklich wert ist.

01:18:01.000 --> 01:18:03.000
Im Worst Case ist es dann immer noch so,

01:18:03.000 --> 01:18:05.000
dass ich halt eben

01:18:05.000 --> 01:18:07.000
vielleicht fünf Tage mal vom

01:18:07.000 --> 01:18:09.000
Kellerrechner weg bin

01:18:09.000 --> 01:18:11.000
und der vielleicht fünf Tage am Stück

01:18:11.000 --> 01:18:13.000
mal aus ist und sobald der mal wieder

01:18:13.000 --> 01:18:15.000
angeschaltet wird, läuft die Dropbox los

01:18:15.000 --> 01:18:17.000
und dann ist man sich wieder darüber einig,

01:18:17.000 --> 01:18:19.000
was wo drauf sein muss.

01:18:19.000 --> 01:18:21.000
Das muss man halt wieder so die,

01:18:21.000 --> 01:18:23.000
das zweidimensionale Netz von Aufwand

01:18:23.000 --> 01:18:25.000
versus Risikoabwägung mal durchgehen

01:18:25.000 --> 01:18:27.000
und gucken, wie man das am besten backupt.

01:18:27.000 --> 01:18:29.000
Prima, schönes Schlusswort.

01:18:29.000 --> 01:18:31.000
Wunderbar, dann machen wir doch auf die

01:18:31.000 --> 01:18:33.000
Revision ein Deckel drauf.

01:18:33.000 --> 01:18:35.000
Alex, tausend Dank, das war

01:18:35.000 --> 01:18:37.000
extrem interessant und ganz, ganz großartig.

01:18:37.000 --> 01:18:39.000
Ja, vielen Dank.

01:18:39.000 --> 01:18:41.000
Prima, ich bin sehr gespannt,

01:18:41.000 --> 01:18:43.000
wenn ihr da jetzt dann auch das,

01:18:43.000 --> 01:18:45.000
die Links damit wieder beilegt,

01:18:45.000 --> 01:18:47.000
dann kann man dann auch das Projekt finden.

01:18:47.000 --> 01:18:49.000
Ja, dann schauen wir mal.

01:18:49.000 --> 01:18:51.000
Oh ja, Links haben wir mehr als genug,

01:18:51.000 --> 01:18:53.000
ich habe alles mitgeschrieben.

01:18:53.000 --> 01:18:55.000
Ja, das war halt super interessant.

01:18:55.000 --> 01:18:57.000
Und wenn ihr Wertehörer schafft,

01:18:57.000 --> 01:18:59.000
dann könnt ihr die Kommentare.

01:18:59.000 --> 01:19:01.000
Oder ansonsten habt ihr ja gehört,

01:19:01.000 --> 01:19:03.000
kann man sich auch direkt an der Community

01:19:03.000 --> 01:19:05.000
beteiligen, mitlesen,

01:19:05.000 --> 01:19:07.000
sich an einem Pull Request versuchen, der allein.

01:19:07.000 --> 01:19:09.000
Ja, wir danken fürs Zuhören.

01:19:09.000 --> 01:19:11.000
Hans, du hast gerade den Überblick,

01:19:11.000 --> 01:19:13.000
wissen wir schon, was nächste Revision

01:19:13.000 --> 01:19:15.000
auf dem Zettel stehen wird.

01:19:15.000 --> 01:19:17.000
Oh ja, ich glaube, das wissen wir.

01:19:17.000 --> 01:19:19.000
Jetzt überspiele ich das mal ganz kurz,

01:19:19.000 --> 01:19:21.000
während ich nachschlage.

01:19:21.000 --> 01:19:23.000
Ich glaube, nächste Woche geht es tatsächlich,

01:19:23.000 --> 01:19:25.000
ah ja, wir wollten mal einen kleinen Ausblick machen.

01:19:25.000 --> 01:19:27.000
Wir sind ja jetzt hier gerade am Ende des Jahres angekommen,

01:19:27.000 --> 01:19:29.000
so vom Veröffentlichungsdatum.

01:19:29.000 --> 01:19:31.000
Und nächste Woche geht das neue Jahr

01:19:31.000 --> 01:19:33.000
ja sozusagen schon los,

01:19:33.000 --> 01:19:35.000
wenn ich hier richtig mit dir vorschaue

01:19:35.000 --> 01:19:37.000
auf unsere Themen informiert bin.

01:19:37.000 --> 01:19:39.000
Und da machen wir einfach mal einen kleinen Ausblick

01:19:39.000 --> 01:19:41.000
über das Jahr 2023.

01:19:41.000 --> 01:19:43.000
Was erwarteten uns eigentlich

01:19:43.000 --> 01:19:45.000
so im Bereich Frontend-Development?

01:19:45.000 --> 01:19:47.000
Das können wir uns dann aber mal anschauen.

01:19:47.000 --> 01:19:49.000
Und das machen wir auch zusammen mit einem Gast.

01:19:49.000 --> 01:19:51.000
Also hört da auch mal rein,

01:19:51.000 --> 01:19:53.000
wenn ihr Bock habt

01:19:53.000 --> 01:19:55.000
und so weit erst mal von meiner Seite.

01:19:55.000 --> 01:19:57.000
Vielen Dank fürs Zuhören.

01:19:57.000 --> 01:19:59.000
Danke auch von meiner Seite.

01:19:59.000 --> 01:20:01.000
Danke auch an Alex. Und tschüss bis zum nächsten Mal.

01:20:01.000 --> 01:20:03.000
Tschau tschau.

01:20:03.000 --> 01:20:05.000
Danke Alex. Macht's gut ihr Lieben.

01:20:05.000 --> 01:20:25.000
Und bis zum nächsten Mal.