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:
Wie ist denn unter den Aspekten denn die S3-Unterstützung von PBS zu verstehen? Von einen PBS-Bug wäre die gleichermaßen betroffen, andererseits gibt es ja sonst nur die Möglichkeit vma-Backups ohne PBS zu erzeugen und richtung S3 zu pumpen, was deutlich mehr Storage frisst. Oder innerhalb der VM mit einen Standard-Backuptool (borgbackup, restic etc) die entsprechenden Daten zu sichern, also die VMs so zu behandeln wie einen realen physikalischen Server.
zfs send/receive ist cool, aber leider gibt es dafür so gut wie keine Cloud-Storageanbieter (außer rsync.net), es sei denn man holt sich dafür einen vergleichsweise teuren Vserver/dedicated Server mit genügend Speicherplatz.
zfs send/receive ist cool, aber leider gibt es dafür so gut wie keine Cloud-Storageanbieter (außer rsync.net), es sei denn man holt sich dafür einen vergleichsweise teuren Vserver/dedicated Server mit genügend Speicherplatz.
Gut dann haben wir das ja jetzt geklärt.
Du kannst jetzt natürlich weiter Wortklauberei betreiben und mich absichtlich nicht verstehen wollen.Ein Air gapped System, pullt keine Backups
Zumindest zeitweise, ist das System nicht air gapped. Ob dabei gepullt oder gepushed wird, ist egal.
Und nein, es ist nicht egal ob gepullt oder gepusht wird. Wenn du pushst, hat der PVE grundsätzlich erst einmal irgendwie Zugriff auf das Backup-Target. Ja klar, man kann diesen Zugriff einschränken, etwa mit API-Keys mit limitierten Berechtigungen. Aber was, wenn etwas falsch konfiguriert ist oder es einen "Flaw" in der API gibt, den ein Angreifer ausnutzen kann? Wäre es dann nicht besser, wenn Proxmox VE überhaupt keinen Zugriff auf das Backup-Target hätte?
Mit „air-gapped“ meine ich hier, dass sich der Server, der die Backups speichert, in einem eigenen abgeschotteten Netzwerksegment befindet, aus dem heraus er nur auf Proxmox VE zugreifen kann. Umgekehrt hat Proxmox VE aber keinerlei Zugriff auf das Backup-Target. Dieses ist also für Proxmox VE komplett unsichtbar.
Nun, es geht aber natürlich immer noch besser.Und für viele gut genug
Aber ja, Ich würde es auch nicht so machen, wenn ich nur ein einziges Backup-Target habe, weil ich dann den Komfort verlieren würde, VMs direkt über die Web-UI von Proxmox VE wiederherstellen zu können. Deshalb meine Aussgae, dass man dafür dann zwei Proxmox Backup-Server bräuchte:
- Proxmox VE → Push-Backup auf Proxmox Backup Server 1
- Proxmox Backup Server 2 ist abgeschottet bzw. „air-gapped“ und für PBS1 nicht erreichbar und pullt die Backups von PBS1.
Alternativ könnte man statt eines zweiten PBS auch eine ZFS-Pull-Replikation vom ersten Backup-Server verwenden. Dann hätte man zusätzlich noch eine zweite Backup-Technologie beziehungsweise ein anderes Medium, laut der Definition, die wir jetzt etabliert haben.
Mit einer reinen ZFS-Pull-Replikation ginge das prinzipiell sogar auch mit nur einem Backup-Target: Sprich ein ZFS-System repliziert direkt vom PVE. Damit würde allerdings, wie gesagt, der Komfort verloren gehen, Backups direkt über die Web-UI von Proxmox VE wiederherstellen zu können.
Und ja, Offsite-Backups brauchst du natürlich egal mit welcher Variante trotzdem. Und ja, Da wird es mit pullen etwas schwieriger, weil man dafür wieder Ports öffnen müsste oder VPN oder irgendetwas nutzen. Deshalb halte ich da Push auf S3 mit eingeschränkten Berechtigungen und Lifecyclemanagement auch für relaistischer/sinnvoller.
EDIT:
Und ja, mit PVE -> PBS -> S3 ist 3-2-1 erfüllt. Aber imho nicht unbedingt 3-2-1-1-0. Oder nicht so richtig gut imho.
Last edited: