snap shots Backup script
- Thread starter hackmann
- Start date
Unter „immutable“ verstehe ich, dass dieses Target nicht direkt erreichbar ist, also quasi das „offline 1“ in der 3-2-1-1-0-Regel. Das geht mit einem einzelnen Proxmox Backup Server nicht, weil Proxmox VE die Backups ja an den PBS senden muss bzw. der PBS keine VM-Backups von Proxmox VE pullen kann.
Ein zweiter Proxmox Backup Server könnte dann aber diese Rolle übernehmen. Den könnte man dann weitgehend airgappen bzw. so abschotten, dass er nur den ersten PBS erreichen kann, und selbst nur sehr eingeschränkt aus einem dedizierten Management-Netz erreichbar ist. Ich denke, das qualifiziert durchaus als "Offline"-Kopie und ist definitiv besser als eine externe Festplatte, die man manuell an- und abstöpseln muss. Manuelle Prozesse sind nie ideal, weil die gehen vergessen usw. (EDIT: Und ja, technisch gesehen wäre es dann 4-2-1-1-0, wenn beide Proxmox Backup Server onsite sind und zusätzlich noch ein Offsite-Target existiert oder 4-1-1-1-0, wenn man das nicht als unterschiedliche Medien zählt.)
Ob zwei Proxmox-Backup-Server als zwei verschiedene Medien zählen, kann man natürlich diskutieren bzw. ob diese Regel überhaupt noch sinnvoll ist. Zwei tatsächlich unterschiedliche Medientypen verwenden heutzutage wohl die wenigsten, ausser man sagt, HDDs und SSDs seien unterschiedliche Medien. Bandlaufwerke sind ja, wie du selbst sagst, von „früher“ und werden immer seltener genutzt, und CDs/DVDs brennt heute wohl auch kaum noch jemand. Es ist also wahrscheinlich, dass am Ende alle Backup-Ziele in der Kette entweder HDDs oder SSDs verwenden.
Und ob man an die Regel noch ein „0“ anhängen muss – naja, eigentlich sollte selbstverständlich sein, dass Backups nur dann nützlich sind, wenn man sie auch fehlerfrei wiederherstellen kann. Aber wenn es die Leute daran erinnert, ihre Backups tatsächlich zu testen, ist das sicher keine schlechte Sache.
Last edited:
Das ist aber nicht die Bedeutung von immutable
Immutable heisst nicht veränderbar. Das geht schon. PVE einfach nur Backup Rechte einräumen und sonst nix.
Oder S3 bucked mit lifecycle oder versioning versehen, dass vom API user nicht angefasst werden kann.
S3 kann also auch "immutable" sein, auch wenn es ganz und gar nicht offline ist.
Ich würde sagen, definitiv nicht. Beim zwei Medien Ding, geht es darum, dass ein Medium einen Fehler haben könnte.
Das Magnetband hat nur Käse geschrieben? Kein Problem gibt noch das S3.
Wenn PBS einen üblen Bug hat, nützt mir ein zweiter PBS vermutlich auch nix.
IMHO heisst die 2 nicht "zwei Festplatten", "zwei S3" oder "zwei PBS".
Also nicht Stückzahl zwei Medien, sondern zwei unterschiedliche Medien.
"PBS & S3", "PBS & ZFS" usw.
Last edited:
Da hast du recht, aber ein air-gapped System, das die Backups pullt, hat einen ähnlichen Effekt, womit wir wieder bei einer Pull-Replikation auf Basis von ZFS wären. Kommt halt auch darauf an, wovor und vor wem man die Backups schützen will. Am besten kombiniert man verschiedene Ansätze.Das ist aber nicht die Bedeutung von immutable
Und wirklich absolut immutable ist am Ende sowieso fast nichts. Viele sogenannte „immutable“ Lösungen lassen sich mit Root- oder Admin-Zugriff doch wieder löschen oder entsperren, wenn die Immutability nur auf Software- oder Dateisystem-Ebene umgesetzt ist. Wirklich schwer manipulierbar wird es erst, wenn die Unveränderbarkeit auf Storage-Ebene erzwungen wird und selbst Root sie während der Retention-Zeit nicht aufheben kann, was aber wohl bei allen hier besprochenen Lösungen nicht wirklich gegeben ist.
Ja das wäre eine weitere Möglichkeit.
Das ist mir klar, und nichts anderes habe ich gesagt. Die Frage ist, ob S3, ZFS und PBS als unterschiedliche Medien zählen oder nicht, denn am Ende des Tages speichern die alle auf SSDs oder HDDs. Ist wohl eine Frage wie man unterschiedliche Medien definiert.
Last edited:
Das ist keine Frage. Sie sind defintiv zwei unterschiedliche Medien.
Das ist aber eben nicht der entscheidende Punkt. Dann hast du die Definition von Medien im modernen Kontext nicht verstanden.
Ein ZFS send mache ich mit ZFS. Hat der ZFS code einen Bug, ist eventuell mein ZFS backup wertlos.
Ein S3 backup zu AWS mache ich mit einer API. Hat die API Implementierung von Proxmox ein bug, ist mein S3 Backup wertlos.
Das "Endlager Medium" könnte dabei egaler nicht sein.
Wenn die Festplatte von AWS abraucht (und angenommen dadurch wäre AWS futsch), ist mir das egal, weil ich mit ZFS send ein zweites Medium habe.
Wenn das ZFS send einen bug hat oder die ZFS destination abraucht, ist mir das egal, weil ich mit S3 ein zweites Medium habe.
Mann muss die 2 Medien Regel unter Früher (TM) verstehen.
Ich mach mal ein Beispiel.
Ich habe ein Windows Server. Der macht mittels Veeam ein Backup auf ein LTO Tape. Die Tapes rotieren, ich nehme sie täglich auf das Bankschliessfach. BTW, ja das war einer der Lehrlingsaufträge
Ich habe also nicht nur 2 Tapes, sondern sogar 5! Für jeden Wochentag eines. Das gilt aber nicht als zwei Medien!
Warum? Nun beim Tape writer ist der Fan ausgefallen. Dadurch blinkt auf dem teil eine Orange LED. Eine Notification auf dem Server ist nicht eingerichtet. Nun schiebe ich seit Monaten Tapes rein, aber da passiert überhaupt nix, weil das Tapelaufwerk defekt ist.
Es kommt zum Totalausfall. Wir wollen restoren.
Wir stellen fest:
Damit hast du mehrere single point of failure ausgeschlossen. Das Tape Laufwerk war nur ein Beispiel, es könnte auch Veeam verbuggt gewesen sein, selbes Resultat.
Ein Air gapped System, pullt keine Backups
Zumindest zeitweise, ist das System nicht air gapped. Ob dabei gepullt oder gepushed wird, ist egal.
Klar. Aber mit der gleichen Logik könnte ich behaupten, rotierende Backup Festplatten sind nicht immutable, weil eine Platte am Server angeschlossen ist und die andere Platte bei dir im Auto. Ich muss also als Angreifer nur Zugriff auf dein Auto & deinen Server haben
Ein S3 bucket, welches mit einem public key geschrieben wird und der Lifecycle nur von einem admin user mit 2FA geändert werden kann, ist da schon sehr nahe dran, bezüglich Sicherheit. Nicht gleich, aber nah. Und für viele gut genug
bereits besser als 99% was ich im KMU Umfeld so antreffe.
Last edited: