ukulele-7
Goto Top

Veeam Application Aware Backup mit MySQL bzw. PostgreSQL

Mahlzeit,

ich habe jetzt meine dritte Linux VM ins Backup aufgenommen, eine BookStack-Instanz die ich teste und nutzen will. Da drauf läuft MySQL, auf einer anderen VM ein PostgreSQL. Für MSSQL gibt es bei Veeam ja das Application Aware Processing, das macht auch eine Log truncation.

Die BookStack Appliance kann ich mit disable application processing erfolgreich sichern. Aber reicht das auch? Was wäre hier best practice?

Content-Key: 2887284996

Url: https://administrator.de/contentid/2887284996

Printed on: May 21, 2024 at 20:05 o'clock

Member: mbehrens
Solution mbehrens Apr 17, 2024 at 15:14:07 (UTC)
Goto Top
Zitat von @ukulele-7:

ich habe jetzt meine dritte Linux VM ins Backup aufgenommen, eine BookStack-Instanz die ich teste und nutzen will. Da drauf läuft MySQL, auf einer anderen VM ein PostgreSQL. Für MSSQL gibt es bei Veeam ja das Application Aware Processing, das macht auch eine Log truncation.

Das gibt es auch für diese beiden Datenbanksysteme.

Die BookStack Appliance kann ich mit disable application processing erfolgreich sichern. Aber reicht das auch? Was wäre hier best practice?

Irgendwie muss man die Datenbank in einen konsistenten Zustand bringen. Durch einen Snapshot der Maschine weißt sie ja nichts von ihrem Glück.

Also bleiben eigentlich nur diese Methoden
  • Maschine vor dem Backup herunterfahren
  • Datenbanksystem vor dem Backup stoppen
  • Datensicherung des Datenbanksystems in der Maschine vor dem Backup
  • Application Aware
Member: regnor
Solution regnor Apr 17, 2024 at 16:28:32 (UTC)
Goto Top
Was spricht dagegen, auch für den PostgreSQL Server Application Aware Processing zu konfigurieren?

https://helpcenter.veeam.com/docs/backup/vsphere/backup_job_vss_postgres ...
Member: ukulele-7
ukulele-7 Apr 18, 2024 at 08:11:15 (UTC)
Goto Top
Zitat von @regnor:

Was spricht dagegen, auch für den PostgreSQL Server Application Aware Processing zu konfigurieren?
Vermutlich nichts face-smile Also außer die PostgreSQL Instanz (die ist von Ciphermail), da habe ich schon mal versucht einen User anzulegen um Zugriff zu erlangen und bin irgendwo gescheitert. Ich brauche aber einen User in der DB richtig?

Muss ich generell davon ausgehen das eine DB inkonsistent werden kann, wenn sie nicht Application Aware gesichert wird? Also z.B. auch, wenn grade gar keine Transaktionen statt finden während der Sicherung?
Member: regnor
regnor Apr 18, 2024 at 13:45:34 (UTC)
Goto Top
Genau, Rechte auf die Datenbank wären notwendig; hier gibt es verschiedene Möglichkeiten aber eventuell kann der Hersteller da weiterhelfen?

Also inkonsistent kannst du alles sichern ;)
Ob das die Datenbank oder Anwendung verträgt ist ein anderes Thema. Deswegen sollte man so konsistent wie möglich sichern, oder, wenn das nicht geht, speziell bei Datenbanken Dienste stoppen oder einen DB dump durchführen. Entscheidet aber ansonsten auch der Hersteller oder Anwendungsbetreuer.
Member: ukulele-7
ukulele-7 Apr 18, 2024 at 14:25:28 (UTC)
Goto Top
Ja das ist halt Open Source ne face-smile

Aber ich werde ich mal darum bemühen. Bisher haben Widerherstellungen immer gut geklappt aber darauf ankommen lassen will ich es ja auch nicht.

Im Fall von Ciphermail interessiert mich die DB sowieso zu Auswertungszweceken, mit SQL arbeite ich gerne. Bei BookStack wird es wohl irgendwie gehen, das ist vermutlich nicht gehärtet. Die dritte VM ist ein privates Roon, da hab ich noch gar keinen Plan wie es da mit Datenbank aussieht.
Member: regnor
regnor Apr 18, 2024 at 19:26:02 (UTC)
Goto Top
Im Prinzip muss es auch nicht zu einem Problem kommen, wenn man nur crash-consistent sichert.
Aber es kann immer zu Problemen kommen und deswegen sollte man das im Hinterkopf behalten.
Member: ukulele-7
ukulele-7 Apr 19, 2024 at 06:59:17 (UTC)
Goto Top
Okay dann werde ich mich da um einen Datenbankzugriff kümmern.