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:
Das war nur ein Beispiel. PVE kann ja kein S3.
Wenn du also mehrere Medien auf PVE möchtest, wären das PBS, VZDUMP, vermutlich Veeam, oder halt in der VM selbst irgendwie wegsichern.
Gut, das könnte ich dir vorwerfen, wenn du behauptest ein S3 bucket oder ein PBS mit nur write access wäre nicht immutableDu kannst jetzt natürlich weiter Wortklauberei betreiben und mich absichtlich nicht verstehen wollen.
Klar. Darum ist auch echte physische Trennung besser als VLAN. VLAN könntest du falsch konfigurieren
Nur will das (fast) niemand haben in der Praxis.
Stimmt schon. Ist hald ein ziemlicher Hardware invest für wenig Gewinn.
Einverstanden, das würde IMHO viel mehr bringen, als zwei PBS.
Mein Tipp: IPv6.
Bekommst du Millionen von statischen IPs kostenlos. Dann kann eine Firewall staticIPv6_PVE to staticIPv6_PBS auf Port X erlauben. Ist einfacher, schneller und sicherer als ein VPN IMHO.
Last edited:
Gut dann haben wir das ja jetzt geklärt.
Du kannst jetzt natürlich weiter Wortklauberei betreiben und mich absichtlich nicht verstehen wollen.
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.
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:
Falls also entweder Proxmox VE oder PBS1 kompromittiert würde, könnte ein Angreifer nicht auf PBS2 „pivoten“, weil PBS2 aus deren Sicht gar nicht erreichbar ist.
- 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.
Das hilft einen aber nicht bei einem Bug im PBS, mit dem bereits das initiale Backup vor dem zfs sync kaputt gemacht wurde.
Für solche Szenarien gibt es ja auch noch pve-zsync, was einen die VMs und lxcs direkt auf einen anderen PVE (oder anderen Server mit ZFS-unterstützung) repliziert. Das kann laut https://pve.proxmox.com/wiki/PVE-zsync auch pull, aus der Seite geht aber leider nicht hervor, wie flexibel man da die Retention einstellen kann.
PBS aber schon, womit man aber wieder von potentiellen PBS-Bugs betroffen sind.
Das würde ich so nicht unterschreiben. Wenn der zweite Backupserver vom ersten nicht erreichbar ist, dann ist es z.B. für Ransomware ja unmöglich da was an den alten Backups kaputtzumachen. Und je nach Situation ist die Hardware (z.B. durch einen alten Server, den man für normale Workloads nicht mehr verwenden kann da der da nicht mitkommt) ja schon vorhanden oder eingepreist.
Einfacher und schneller sehe ich ein, aber sicherer als "keine Verbindung möglich" würde ich so nicht teilen
Also eigentlich ging es mir ja nur darum zu sagen, dass ZFS Repplikation eine valide Art ist um Backups zu machen und, dass wenn man ZFS Pull Repplikationen macht, man im Prinzip das zusätzliche 1 für offline oder unveränderbar, quasi gratis mit dabei hat, auch wenn ich mit "immutable" hier nicht die korrekte Terminologie verwendet habe.
Ich würde sogar sagen, ein per Pull repliziertes, abgeschottetes ZFS-Ziel erfüllt dieses „1“ oft besser als ein normales Push-Backup, welches vom Hersteller als "immutable" verkauft wird, weil der produktive Server das Backup-Ziel gar nicht sehen oder erreichen kann.
Aber ja, natürlich haben Proxmox Backup Server und selbst ein einfacher VZDump erhebliche Vorteile. Nur schon weil ein Backup über Proxmox Backup Server nicht nur die virtuelle Disk, sondern auch die VM-Konfiguration mitsichert, und wegen dem bequemen Restore direkt aus der Web-UI von Proxmox VE.
Aber je nach Bedrohungsmodell reicht das allein eben nicht. Ransomware-Gruppen wissen natürlich auch, dass du vermutlich nicht bezahlen wirst, wenn du funktionierende Backups hast. Deshalb versuchen sie oft zuerst, die Backup-Infrastruktur mit zu kompromittieren oder zu löschen. Ob ihnen das gelingt, hängt stark davon ab, wie dein Setup aufgebaut ist.
Wenn du zum Beispiel nur ein einziges Backup-Ziel hast, das von Proxmox VE oder PBS direkt beschrieben werden kann, besteht immer zumindest theoretisch das Risiko, dass ein Angreifer sich dorthin weiterbewegt. Mit einem zweiten, abgeschotteten Serverm, etwa PBS2 oder einem separaten ZFS-System, das die Daten nur pullt, reduzierst du dieses Risiko deutlich. Die Alternative mit einer externen HDD, die man nur kurz anschliesst und danach wieder trennt, ist technisch ebenfalls wirksam. Aber in der Praxis macht man das nicht oft genug. Wenn dann der eigentliche Backup-Server kompromittiert wird und das letzte wirklich isolierte Backup schon über eine Woche alt ist, sieht die Entscheidung, ob man die "Ransom" bezahlen will, plötzlich wieder ganz anders aus
Und ja: Viele Wege führen nach Rom, und Proxmox VE -> PBS -> S3 ist bereits sehr gut und wahrscheinlich besser abgesichert, als es viele kleine Unternehmen oder Homelabs haben, und genügt in vielen Szenarien vielleicht auch vollkommen.
Entscheidend ist am Ende die konkrete Risikoabwägung: Wer hat Zugriff auf Proxmox VE und PBS? Liegen die Admin-Oberflächen in einem separaten Management-VLAN? Haben nur du und eine Vertretung Zugriff? Oder greift die „halbe Firma“ oder mehrere Administratoren darauf zu? Ist die Management-Oberfläche vielleicht sogar vom normalen Firmennetz erreichbar?
Je mehr Personen, Systeme und Netzwerke Zugriff haben, desto mehr lohnt sich ein Pull-Backup auf von einemn zweiten, isoliertes Zielsystem.
Ich würde sogar sagen, ein per Pull repliziertes, abgeschottetes ZFS-Ziel erfüllt dieses „1“ oft besser als ein normales Push-Backup, welches vom Hersteller als "immutable" verkauft wird, weil der produktive Server das Backup-Ziel gar nicht sehen oder erreichen kann.
Aber ja, natürlich haben Proxmox Backup Server und selbst ein einfacher VZDump erhebliche Vorteile. Nur schon weil ein Backup über Proxmox Backup Server nicht nur die virtuelle Disk, sondern auch die VM-Konfiguration mitsichert, und wegen dem bequemen Restore direkt aus der Web-UI von Proxmox VE.
Aber je nach Bedrohungsmodell reicht das allein eben nicht. Ransomware-Gruppen wissen natürlich auch, dass du vermutlich nicht bezahlen wirst, wenn du funktionierende Backups hast. Deshalb versuchen sie oft zuerst, die Backup-Infrastruktur mit zu kompromittieren oder zu löschen. Ob ihnen das gelingt, hängt stark davon ab, wie dein Setup aufgebaut ist.
Wenn du zum Beispiel nur ein einziges Backup-Ziel hast, das von Proxmox VE oder PBS direkt beschrieben werden kann, besteht immer zumindest theoretisch das Risiko, dass ein Angreifer sich dorthin weiterbewegt. Mit einem zweiten, abgeschotteten Serverm, etwa PBS2 oder einem separaten ZFS-System, das die Daten nur pullt, reduzierst du dieses Risiko deutlich. Die Alternative mit einer externen HDD, die man nur kurz anschliesst und danach wieder trennt, ist technisch ebenfalls wirksam. Aber in der Praxis macht man das nicht oft genug. Wenn dann der eigentliche Backup-Server kompromittiert wird und das letzte wirklich isolierte Backup schon über eine Woche alt ist, sieht die Entscheidung, ob man die "Ransom" bezahlen will, plötzlich wieder ganz anders aus
Und ja: Viele Wege führen nach Rom, und Proxmox VE -> PBS -> S3 ist bereits sehr gut und wahrscheinlich besser abgesichert, als es viele kleine Unternehmen oder Homelabs haben, und genügt in vielen Szenarien vielleicht auch vollkommen.
Entscheidend ist am Ende die konkrete Risikoabwägung: Wer hat Zugriff auf Proxmox VE und PBS? Liegen die Admin-Oberflächen in einem separaten Management-VLAN? Haben nur du und eine Vertretung Zugriff? Oder greift die „halbe Firma“ oder mehrere Administratoren darauf zu? Ist die Management-Oberfläche vielleicht sogar vom normalen Firmennetz erreichbar?
Je mehr Personen, Systeme und Netzwerke Zugriff haben, desto mehr lohnt sich ein Pull-Backup auf von einemn zweiten, isoliertes Zielsystem.
Last edited: