Backup Strategy #20
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
Hardware
Infrastruktur
Service
Software
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: hsmr/hackspace#20
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Wie sieht denn die Backup-Strategie für die neue hsmr Infra aus (Keycloak, Git, etc.)?
Ich persönlich verwende auf meinem Server ein Dateisystem mit Snapshot Funktionalität und kopiere diese täglich auf einen zweiten Server. Nach einer gewissen Zeit, werden sie automatisch gelöscht.
Bei Interesse, könnte ich für unseren portunus Server mal ein Konzeot erstellen.
@leisefuxx
Konzepte und Ideen sind immer gerne gesehen und willkommen.
zur Zeit ist es so, dass Portunus nicht wirklich backups macht. ich mach (un-)regelmäßig snapshots bei Hetzner von der gesamten Maschine. Snapshots erzeugen monatlich wiederkehrende Kosten von 0,01309 €/GB/Monat und die aktuellen Snapshots sind 4,77 GB Groß... 4.77GB * 0.01309€/GB/Monat = 0.0624393 €/Monat pro Snapshot... 6 Cent tut mir jetzt nicht wirklich weh... kann ich gerne einmal die Woche anstoßen und machen lassen... sollte es kritischer werden natürlich auch öfters... Nachteil: man bekommt die Snapshots bei hetzner nicht raus... mit den haus-eigenen Mitteln sind die im vendor-lockin
ich würde das ganze gerne später perspektivisch Richtung S3 bewegen, evtl. sogar bei mir zu Hause minio S3-kompatibel installieren und dann einfach die gesamte maschine regelmäßig raustragen und nochmal spiegeln... das NAS steht bei mir zu Hause, idlet eh vor sich hin und macht nicht viel... paar TB sind auch noch frei... oder bei hetzner s3 buchen (gibt 1TB für 6€) und nach Hause spiegeln (nachteil: doppelter Traffic)
sollten wir Richtung S3 gehen, dann mit veeam (bevorzugt) oder ähnlichem (kopia, restic, duplicati, borg, $PROGRAMMNAME) als Software. Bin da aber flexibel.
ich bin da für alles und jeden offen...
zur Zeit ist es halt "noch" nur ein single-docker-node mit wenig bis keinem richtigen (lies: kritischen) workload... sollten wir uns richtung matrix und emails bewegen, sollten wir vorher definitiv die backup-Frage klären.
sollten wir uns von docker weg bewegen und das setup komplexer gestalten (ja kubernetes, ich schaue dich gerade an), kommen wir um s3 nicht mehr herum...
@fix wollte sich an Infra auch beteiligen... @fix sach mal watt
Top, dass es bereits Sicherungen für 6ct gibt! Dann können wir in Ruhe ein langfristiges Konzept ausarbeiten :)
Dann lass uns doch gerne gleich von Beginn an Kubernetes mit bedenken, ist so vermutlich nicht wirklich mehr Aufwand ;)
Wie sieht das bei Kubernetes denn grob aus? Hinterlegt man dort S3 Zugangsdaten, wählt eine Backup and Retention Policy und der Rest wird automatisch von Kubernetes erledigt?
Oder nutzt Kubernetes selbst S3 als Storage-Backend und wir können einfach davon Backups ziehen?
Wenn man ein Kubernetes Cluster hat, wird das vollständig von den Helm-Charts, Secrets und Volumes beschrieben? Also können wir das analog wie docker-compose Files, Docker-Secrets und Docker-Volumes behandeln? D.h.: Helm-Charts liegen im Git, von Secrets und Volumes werden Backups erstellt - that's it? Die laufenden Container selbst sind (von den Volumes abgesehen) stateless und müssen daher nicht gesichert werden. Dockerfiles zu allen Containern sind anderweitig (in Git) vorhanden?
backups und kubernetes sind nochmal ein ganz eigenes Paar Schuhe...
grundsätzlich kann Kubernetes seinen Zustand der datenbank in s3 ablegen, ja.
die Nutzlast (aka "Daten der Anwendung") sind damit aber nicht gesichert. Das kann man zum beipsiel via velero machen oder rancher oder oder oder...
grundsätzlich ist bei dem ganzen Unterfangen erstmal die Frage zu klären: bleiben wir grundsätzlich bei Docker, oder nehmen wir kubernetes? zur Zeit sind (glaube ich) nur @oleander, @fix und ich in der Lage, kubernetes sicher und fließend zu bedienen... die lernkurve ist dort sehr steil und die Bereitschaft im Space sehe ich da gerade nicht...
Docker ist sehr gut dokumentiert und für viele einfacher zugänglich... ich würde sagen, wir bleiben bei Docker und ich bastel uns da ein 3-2-1-backup zusammen aus hetzner controller vm-snapshots, datei-backups und export in irgendein cooles (günstiges...) Speicherformat (:
FYI: heute wieder snapshots von mail.marburg.chat und portunus.h4xx0r.club erstellt