[SOLVED] auf gleichem PBS (v3) langsamen Storage zum langzeit Archivieren verwenden

[crmspezi]

Ok, der Auslagerungsstorage ist damit also für einen Angreifer erreichbar. Ich sehe keinen Mehrwert in den Setup, weder in Sachen Sicherheit vor Angreifern noch vor sonstigen Fehlern (etwa durch einen Hardwareschaden) aber vor allen: Von welchen Datenmengen reden wir denn? Kannst du mal bitte ein Log der garbage-collection posten? Daraus geht dann hervor, um welche Datenmengen und (vor allen) wieviele Chunks es eigentlich geht. Bei sehr großen Datenmengen könnten diese eine Erklärung sein (und dann wird das Rausnehmen der stündlichen Backups auch nichts helfen), sonst wäre meine Vermutung dass mit der Anbindung des Auslagerungsstorage (ganz unabhängig wie man das Setup grundsätzlich bewertet ) was nicht stimmt.

Der Auslagerungsstorage ist genau, wie auch bei Dir, mit dem Masterstorage für Angreifer erreichbar, wenn er an ist und wenn man es schafft "einzubrechen". Es geht hier ausschließlich nur um die Datenauslagerung, Gründe auch immer. Das war die Fragestellung zu Beginn und meine Bitte an euch um Hinweise, wie man dies anders, als ich bereits habe, lösen könnte. Offensichtlich bin ich nicht der einzige der hier andere Wege sucht, wie Chris oben schreibt.

Ich bedanke mich für die Beteiligung von euch allen und hoffe auch auch die "Wunschliste" https://bugzilla.proxmox.com/show_bug.cgi?id=6781

Viele Grüße

 

[Johannes S]

Der Auslagerungsstorage ist genau, wie auch bei Dir, mit dem Masterstorage für Angreifer erreichbar, wenn er an ist und wenn man es schafft "einzubrechen".

Nein, ist er nicht. Mein "Auslagerungsstorage" ist auf einen anderen Server, für den man andere Zugangsdaten braucht. Außerdem kann der auch so konfiguriert werden, dass er für den primären PBS gar nicht erreichbar ist. Ich mache das aktuell zwar aus Bequemlichkeitsgründen nicht (und weil es nur mein Homelab ist), aber sollte ich damit Geld verdienen würde ich das so konfigurieren:
- PrimärPBS erlaubt Auslagerungs-PBS Zugriff auf Port 8007 für einen pull-sync
- SekundärPBS hat den Port 8007 dicht, außer für das zur Administration genutzte Notebook (und auch das kommt nur per VPN darauf)

Ein Angreifer, der es also schafft den PrimärPBS zu übernehmen, kann damit trotzdem nicht die bereits existierenden Backups auf den SekundärPBS kompromittieren, nur neue (logischerweise). Hat man den Zeitraum für potentiell kompromittierte Backups also eingegrenzt, kann man das neueste nicht kompromittierte Backup vom SekundärPBS wieder einspielen, dafür würde man dann halt eine temporäre Freischaltung einrichten.

Dein Auslagerungsstorage ist dagegen, solange er an ist für deinen PBS verfügbar zum Schreiben und damit auch für einen potentiellen "ungebetenen Gast" auf dem System.
Das gc-Log würde mich trotzdem interessieren, sobald wir wissen um welche Datenmengen und Anzahl Chunks es geht kann man auch die Dauer des Prunens und der gc besser einordnen.

 

[crmspezi]

Nein, ist er nicht. Mein "Auslagerungsstorage" ist auf einen anderen Server, für den man andere Zugangsdaten braucht. Außerdem kann der auch so konfiguriert werden, dass er für den primären PBS gar nicht erreichbar ist.

Bitte lese doch nochmal. Ich habe genau wie Du einen sekundären PBS, der pullt mit anderen Prune/GC Einstellungen, auch extrem abgesichert. Hier geht es um die vernüftige Speicherumlagerung des Masters (teurer Platz/billiger Platz - das ist sehr relevant bei riesigen Speichergrößen). Wenn Dein Master angegriffen wird, ist es das gleiche, als wenn mein Master (Haupt und Nebengerät) angegriffen wird, nur das das Risiko bei mir 10% im Vergleich zu Dir liegt, da das Nebengerät nur 3 von 30 Tagen läuft. Der Sekundäre PBS existiert ja noch zusätzlich in einem anderen Brandabschitt. Ich weiss wirklich nicht wie ich es noch besser kommunizieren kann.

 

[Falk R.]

Bitte doch nochmals lesen! Es gibt einen sekundären PBS (Version 4.x), der ganz woanders steht und hier nichts mit zu tun hat und nur angeführt wurde, weil das Argument Sicherheit angeführt wurde.

Wir reden nur vom primären PBS (Version 3.x), der aus zwei großen 4HE Einheiten besteht, 1x sehr schneller Masterstorage und 1x Auslagerungsstorage. Ziel ist, die alten Backups auf den Auslagerungsstorage zu verschieben. Und Ja, prune dauert auch schon Stunden, GC dann 2-4 Tage.

Da hast du aber irgendein richtiges Problem.
Selbst die PBS mit vielen langsamen HDDs und 200TB+ Daten drauf brauchen maximal eine halbe Stunde für den Prune. GC dann gern mal 4-18 Stunden. Und das ist schon das langsamste Setup was ich betreue.
Verify ist aus Gründen auf diesem Server nicht aktiviert.

Und klar kann dein Setup funktionieren, aber der Effekt ist eventuell nicht so groß.
Wenn du extrem viel Änderungsrate hast, bringt das echt was sonst nicht wirklich.
Ich baue daher lieber die Sekundär PBS dicker und lasse die Langzeitbackups da liegen. Finde ich einfacher in der Handhabung.

 

[Johannes S]

Verify ist aus Gründen auf diesem Server nicht aktiviert.

Wie stellt man dann sicher, dass die Backups nicht kaputt gehen? Ich verstehe ja, dass die potentielle Dauer der verify-jobs einen davon Abstand nehmen lassen, aber ohne mögliches restore bringen die einen doch nichts.

 

[Johannes S]

Bitte lese doch nochmal. Ich habe genau wie Du einen sekundären PBS, der pullt mit anderen Prune/GC Einstellungen, auch extrem abgesichert. Hier geht es um die vernüftige Speicherumlagerung des Masters (teurer Platz/billiger Platz - das ist sehr relevant bei riesigen Speichergrößen). Wenn Dein Master angegriffen wird, ist es das gleiche, als wenn mein Master (Haupt und Nebengerät) angegriffen wird, nur das das Risiko bei mir 10% im Vergleich zu Dir liegt, da das Nebengerät nur 3 von 30 Tagen läuft. Der Sekundäre PBS existiert ja noch zusätzlich in einem anderen Brandabschitt. Ich weiss wirklich nicht wie ich es noch besser kommunizieren kann.

Ja und das Sekundärbackup deines Masters würde ich halt eher auf einen eigenen Server packen, ich bezog mich auf folgenden Teil:

Wir reden nur vom primären PBS (Version 3.x), der aus zwei großen 4HE Einheiten besteht, 1x sehr schneller Masterstorage und 1x Auslagerungsstorage. Ziel ist, die alten Backups auf den Auslagerungsstorage zu verschieben. Und Ja, prune dauert auch schon Stunden, GC dann 2-4 Tage.

Ich finde es wenig schlüssig im Master extra viel Platz als Sekundärbackup vorzuhalten, wenn man für den Katastrophenfall (Feuer, Ransomware etc) doch die Kopien des Nebengeräts benötigt. Da würde es sich in meinen Augen doch anbieten, den Auslagerungsstorage mit viel Platz dann beim zweiten PBS zu haben, damit man im Ernstfall noch die älteren Kopien verfügbar hat.

 

[crmspezi]

Danke nochmals allen für die Beteiligungen und Bewertungen. MeinThema mit rießigen Datengrößen und auch sehr vielen VMs ist bestimmt vielseitig bewertbar und auch budgetabhängig. Ich schließe dies nun erstmal ab.

Viele Grüße

 

[Falk R.]

Wie stellt man dann sicher, dass die Backups nicht kaputt gehen? Ich verstehe ja, dass die potentielle Dauer der verify-jobs einen davon Abstand nehmen lassen, aber ohne mögliches restore bringen die einen doch nichts.

Der Verify wird auf dem Primär PBS gemacht und der zweite ist nur eine zusätzliche Absicherung die niemals benutzt werden sollte. Da ein Sync zwischen den PBS nix kaputt macht, vertrauen wir erst einmal und in größeren Abständen werden auch mal Restores einzelner VMs getestet.
Im Endeffekt ist der genau so sicher wie jede andere Handelsübliche Backupsoftware, die auch alle kein Verify machen.

 

[Johannes S]

Im Endeffekt ist der genau so sicher wie jede andere Handelsübliche Backupsoftware, die auch alle kein Verify machen.

Das mag für proprietäre Backuptools zutreffen, da kenne ich mich nicht mitaus. Bei restic kann man sowohl ein verify machen, als auch mit --read-data oder --read-data-subset einen vollständigen restore simulieren. Für birgbackup, kopia und Duplikate hat Google mir auch vergleichbares ausgespuckt.
Fehlt das echt bei den ganzen "Enterprise"-Lösungen, das wäre doch ein schlechter Witz?!?

 

[Falk R.]

Das mag für proprietäre Backuptools zutreffen, da kenne ich mich nicht mitaus. Bei restic kann man sowohl ein verify machen, als auch mit --read-data oder --read-data-subset einen vollständigen restore simulieren. Für birgbackup, kopia und Duplikate hat Google mir auch vergleichbares ausgespuckt.
Fehlt das echt bei den ganzen "Enterprise"-Lösungen, das wäre doch ein schlechter Witz?!?

Naja bei echt Enterprise nicht, aber dann hast du echte Enterprise Preise die sich niemals ein Mittelständler leisten kann.
Die normalen Bezahllösungen können es fast alle nicht.