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 da nicht nur die virtuelle Disk, sondern auch die VM-Konfiguration mitsichert wird, 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 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 Server, 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 funktionierende Backup schon über eine Woche alt ist, sieht die Entscheidung, ob man die "Ransom" bezahlt, 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, 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“ 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, isolierten 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 da nicht nur die virtuelle Disk, sondern auch die VM-Konfiguration mitsichert wird, 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 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 Server, 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 funktionierende Backup schon über eine Woche alt ist, sieht die Entscheidung, ob man die "Ransom" bezahlt, 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, 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“ 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, isolierten Zielsystem.
Last edited:
Meine damit eher den Gewinn verglichen mit einem zweiten Medium. Ein ZFS send liesse sich für ähnliche Hardware Kosten einrichten, würde aber massiv mehr bringen.
Gut, aber VPN ist nun mal nicht "keine Verbindung". In der Praxis ist es vermutlich ein:Einfacher und schneller sehe ich ein, aber sicherer als "keine Verbindung möglich" würde ich so nicht teilen
- Allow all incoming UDP traffic on port 30000 to Wireguard
vs.
- Allow incoming TCP traffic from static_IPv6_PVE on port 30000 to PBS
Port öffnen ist bei beiden
Mir fehlt gerade die Fantasie, warum das viel bringen sollte. Was ist an einem pull so viel sicherer als ein push?
Bei TrueNAS mit ZFS send und root Gedönds könnte ich es mir noch irgendwie vorstellen, weil es leider ziemlich mächtige root Zugriffe braucht für das mounting (irgendwie würde man es bestimmt schöner hinbekommen, war auch schon paar mal Diskussion dort im Forum).
Aber bei PBS?
Fair enough
Gut, aber VPN ist nun mal nicht "keine Verbindung". In der Praxis ist es vermutlich ein:
- Allow all incoming UDP traffic on port 30000 to Wireguard
vs.
- Allow incoming TCP traffic from static_IPv6_PVE on port 30000 to PBS
Port öffnen ist bei beiden
Ja, aber der Witz ist ja, dass das nur in eine Richtung geht, der remote PBS ist (Firewall passend konfiguriert vorausgesetzt) bleibt ja unerreichbar. Und nur per VPN erreichbar ist schon was anders als wenn das ganze Internet darauf kommt, vor allen weil man auf VPN-Ebene ja auch noch separieren kann, dass z.B. nur ein Management-Client/Admin-Notebook auf das Webinterface des offsite-PBS drauf kommt. Plus dass rein technisch man diese Freischaltungen (gilt freilich so auch für deinen Vorschlag) ja auch automatisieren könnte, also wenn z.B. der sync-job zwischen 0:00 und 04:00 Uhr stattfindet, dass man um 23:50 Uhr per cronjob/systemd-timer o.ä. die Freigabe aktiviert und um 4:10 wieder rausnimmt.
Es benötigt keinen (weder lesend- noch schreibend) Zugriff vom lokalen PBS auf den remote PBS. Ein Server, der nicht erreichbar ist, kann auch nicht kompromittiert werden. Das schlimmste was passieren kann, wäre also dass neue (kaputte/kompromittierte) Backups erzeugt werden und der remote PBS die sich dann auch zieht. Macht aber nichts, da ja beim pull die neuen Chunks nur hinzugefügt, alte aber weder bearbeitet noch gelöscht werden (solange man remove vanished nicht aktiviert, was man aber eh nicht tun sollte). Setzt man die prune-Werte auf dem remote-PBS hoch genug, sollte man immer noch Backups haben, die alt genug sind, dass sie nicht kompromittiert wurden, selbst wenn der remote-PBS nun auch kompromittierte Backups enthält. Tatsächlich bin ich persönlich kein großer Fan davon, dass push-syncs beim PBS eingeführt wurden, ich halte das sicherheitstechnisch für einen Rückschritt. Aber für den S3-Support geht es natürlich nicht ohne, ich hätte es aber besser gefunden, wenn sie nur dort möglich wären. Hätte aber natürlich die UI wieder komplizierter für Newbies gemacht ("Warum ist das dort denn anders?").
Sichern tun viele Leute fleißig. Geht nach Initialsicherung ja auch mit mickrigen Leitungen flott. Ein evtl. nötiges Restore wird aber leider oft nicht bedacht. Im digitalen Neuland Deutschland habe ich, mitten in Hamburg, nicht wenige Kunden mit einer 100/30MBit-Anbindung. Da fehlt mir wieder massiv eine Funktionalität im PBS um z.B. die letzte Sicherungen per Klick auf eine USB-Disk als vzdump-files exportieren zu können um diese per Kurier/Post zu verschicken. Funktioniert bislang nur, wenn ich am Standort des Pull-PBS einen PVE laufen habe, auf den ich per script gewünschte VMs wiederherstellen muss nur um sie anschließend als vzdump auf eine externe USB-Disk zu schieben.
Von hinten durch die Brust ins Auge, obwohl die Funktionalität sogar vorhanden ist.
Von hinten durch die Brust ins Auge, obwohl die Funktionalität sogar vorhanden ist.
Last edited:
Mit der statischen IPv6 lässt du eben nicht das ganze internet drauf, sondern genau ein Host.
Das Argument ist also genau umgedreht, während du dem ganzen Internet die Möglichkeit gibst dein VPN anzugreifen, ist hat bei mir nur PVE nach PBS eine write only Verbindung
Naja, wenn PBS pullt, muss der ja irgendwie auf PVE kommen.
Also muss PVE erreichbar sein.
Dann könnte PVE kompromitiert werden.
Fände ich übler als mein PBS erreichbar zu machen und von PVE nach PBS zu pushen.
Last edited:
Bei pull-syncs greifen PBS NIE auf den PVE zu, sondern immer nur auf andere PBS. Sprich die Kette sieht so aus:
- Lokales LAN mit PVE und PBS, PVE kann auf PBS Backups erzeugen, aber nicht löschen oder bearbeiten (Permissions passend setzen). Lokaler PVE und PBS können NICHT auf den remote PBS zugreifen (wird durch Firewallregeln UND Permissions im RemotePBS verhindert)
- Offsitelocation (Cloud, anderes RZ, Wohnung von Freunden oder Familienmitgliedern): Der dortige PBS darf auf Port 8007 und IP des lokalen PBS zugreifen, wer mag kann noch zusätzlich über einen haproxy diesen Zugriff auf die API beschränken: https://forum.proxmox.com/threads/u...-pbs-exposition-to-api-endpoints-only.182188/ da würde man dann natürlich das über einen anderen Port machen. Der offsite-PBS zieht sich die Backups dann mit einen pull-sync
- Zugriff auf den Offsite-PBS ist vom lokalen PBS und PVE nur für restore-Zwecke vorgesehen und muss temporär im Bedarfsfall eingerichtet werden, um die Backups auf dem offsite-PBS in den lokalen PBS zu pullen oder im PVE zu restoren
Die Frage ist doch, wie weit man auf die Fähigkeiten vom PROXMOX-Team vertraut, um port 8007 in den Ring zu stellen. Offenem SSH traue ich sogar mit starken Psswörtern, Obwohl ich auch dort inzwischen konsequent auf MFA setze. Wenn eine fette API dahinterhängt, werde ich noch skeptischer. Da hilft es auch nicht, die WebGUI partiell abzuhängen oder Standardports zu ändern.
Last edited:
Dass es zustätzlich sinnvoll ist den Zugriff per vpn für alle Zugriffe und 2F2 für den Adminzugriff einzuschränken, habe ich nie bestritten
Habe ich ja auch nie behauptet. Vertrauen kann man in meinen Augen nur Diensten, die man ohne Zahnschmerzen im Inet feilbieten kann, statt sie im VPN zu "verstecken". Da habe ich leider nur wenige Kandidaten.Dass es zustätzlich sinnvoll ist den Zugriff per vpn für alle Zugriffe und 2F2 für den Adminzugriff einzuschränken, habe ich nie bestritten