Mit Gast Alexander Neumann (Github), seines Zeichens Entwickler der FOSS-Backup-Software Restic quatschen wir über Backups, Backup-Strategien und Backup-Fails.

Schaunotizen

[00:00:58] Backups!
Unsere Einstiegsfrage ist: Was ist überhaupt ein Backup? Ist Backup gleich Backup? Wir beleuchten unterschiedliche Backup-Strategien (für den Alltag und für Spezialfälle wie Datenbanken) und kommen über den Vergleich von Restic mit der Konkurrenz vom morschen Obstbaum zu technischen Praxisfragen rund ums Backup. Über Fragen des Wie und Warum von inkrementellen Backups kommen wir zu Themen rund ums Backup-Rückgrat – Content Defined Chunking (im Falle von Restic via chunker), den Volume Shadow Copy Service, ZFS, etc. Jenseits der schieren Technik ist bei Backups aber auch der Faktor Mensch relevant und wir kommen nicht umhin, Restore-Complacency und Backup-auch-wirklich-machen-Strategien zu besprechen. Konkret am Beispiel von Restic sprechen für über Überlegungen zu Verschlüsselung und Sicherheit, Redundanz, Forward Error Correction, Kompression und Multi-Device-Backups. Zum Schluss geht’s natürlich auch ein wenig um OSS-Themen wie die Zukunftsplanung von Restic und das Community-Management.
Transkript
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.
Liked it? Take a second to support Peter on Patreon!