[SOLVED] Rotation einstellen pro VM

[Oachkatze]

Hallo liebe Community,

ich habe eine kurze Frage, bei der ihr mir bestimmt weiterhelfen könnt.

Ich habe 2–3 Datenbank-Server, die ich gerne länger auf dem PBS aufbewahren möchte als die restlichen VMs.
Aktuell habe ich im PVE bei der Rotation „Keep All“ eingestellt, da der PBS ja sonst alle Backups über alle VMs hinweg verwaltet.

Wäre es möglich, im PVE einen zweiten PBS-Eintrag anzulegen, bei dem ich für VMs und für die DB-Server jeweils eine eigene Rotation hinterlegen kann, und dass der Prune-Job dies dann entsprechend an den PBS übergibt?
Oder liege ich hier mit meinem Ansatz komplett falsch?

Danke schon mal für eure Hilfe!

 

[Falk R.]

Hallo liebe Community,

ich habe eine kurze Frage, bei der ihr mir bestimmt weiterhelfen könnt.

Ich habe 2–3 Datenbank-Server, die ich gerne länger auf dem PBS aufbewahren möchte als die restlichen VMs.
Aktuell habe ich im PVE bei der Rotation „Keep All“ eingestellt, da der PBS ja sonst alle Backups über alle VMs hinweg verwaltet.

Wäre es möglich, im PVE einen zweiten PBS-Eintrag anzulegen, bei dem ich für VMs und für die DB-Server jeweils eine eigene Rotation hinterlegen kann, und dass der Prune-Job dies dann entsprechend an den PBS übergibt?
Oder liege ich hier mit meinem Ansatz komplett falsch?

Danke schon mal für eure Hilfe!

Natürlich geht das. Am einfachsten legst du dir im PBS einen extra Namespace an und auf dem richtest du eine andere Retention ein. Vorsicht bei vererbter Retention von root den Datastores.
Diesen NS legst du im PVE als weiteren PBS Datastore an und sicherst da hin.

 

[Oachkatze]

Natürlich geht das. Am einfachsten legst du dir im PBS einen extra Namespace an und auf dem richtest du eine andere Retention ein. Vorsicht bei vererbter Retention von root den Datastores.
Diesen NS legst du im PVE als weiteren PBS Datastore an und sicherst da hin.

Achhhh stimmt ab und zu braucht man einfach ein denk Anstoß! Danke

 

[TErxleben]

Entweder so wie Falk geschrieben hat oder auch nur unterschiedliche Backupjobs anlegen.
Ich frage mich allerdings, warum man alte Datenbanken aufheben möchte.
Eine alte DB ist doch schlimmer als die Tageszeitung von gestern.

 

[Falk R.]

Entweder so wie Falk geschrieben hat oder auch nur unterschiedliche Backupjobs anlegen.
Ich frage mich allerdings, warum man alte Datenbanken aufheben möchte.
Eine alte DB ist doch schlimmer als die Tageszeitung von gestern.

Dann frage mal DB Admins, die versuchen müssen, eine Inkonsistenz in einer Datenbank zu fixen und am besten mit den richtigen Zahlen.
Die sind dann extrem dankbar wenn man noch alte Backups und in vernünftiger Granularität hat.

 

[TErxleben]

Da brauche ich niemanden zu fragen, denn ich bin DB-Entwickler. Natürlich hebt man DBs vor Strukturänderungen offline auf. Sonst tut je nach Umgebung schon eine Stunde Verlust sehr weh. Man fixed eben auch mit den modernsten verfügbaren Backupdaten. Spiel mal ein Monat(e) altes System zurück, welches von 100 Leuten mit Daten befüllt wird und warte auf die Reaktionen und rufe am besten gleich deine Versicherung an. Deine geliebte Clustertechnik stammt übrigens ursprünglich aus dem Datenbankbereich.

Vernünftige Granularität bedeutet eben so modern wie auch immer nur möglich.

 

[Falk R.]

Also was du schreibst, klingt für mich nicht nach DB Admin.
Ich habe selbst schon einmal für DB Admins ganz viele Versionen von einer Tabelle restoren müssen, bis die den Zeitpunkt gefunden haben wo der Fehler passiert ist und dann mussten alle darauf aufbauenden Folgebuchungen nachberechnet werden. Das ganze hat mehrere Tage gedauert, aber die Db war nachher wieder Konsistent, zumindest stimmte die Bilanz in der Buchhaltung wieder überein.

Das geht nur wenn man viele Versionen behält. Ist aber kein alltägliches Problem, zum Glück.

 

[TErxleben]

Das nenne ich dann schlechtes DB-Design. Findet sich leider auch häufig. Normalerweise trennt man Eingaben und Auswertungen strikt. Eingaben landen in physisch wenigen Tabellen und Auswertungen werden per joins in stored procedures abgehandelt. Da muss nichts nachberechnet werden. Sofern ich eine Fehlbuchung korrigieren muss, reicht die laufende DB-Instanz, in der der Fehler gesucht werden kann. Erst wenn das nicht möglich ist, muss ich wohl oder übel auf alte Versionen zurückgreifen.

 

[Falk R.]

Das war ein richtiger Konsistenzfehler, Der Server ist mit ECC Fehlern aufgefallen, die VMs wurden wegmigriert und dann wurden CPU und RAM getauscht.
Dann hat die Buchhaltung einige Tage später festgestellt, dass Salden nicht mehr passen.
Also sind die Daten vorher schon in CPU oder RAM korrupt gegangen, wie willst du soetwas mit DB Design abfangen?