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: