7
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?
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?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2887284996
Url: https://administrator.de/contentid/2887284996
Ausgedruckt am: 18.12.2024 um 21:12 Uhr
7 Kommentare
Neuester Kommentar
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
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 ...
https://helpcenter.veeam.com/docs/backup/vsphere/backup_job_vss_postgres ...
Zitat von @regnor:
Was spricht dagegen, auch für den PostgreSQL Server Application Aware Processing zu konfigurieren?
Vermutlich nichts Was spricht dagegen, auch für den PostgreSQL Server Application Aware Processing zu konfigurieren?
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?
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.
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.
Ja das ist halt Open Source ne
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.
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.
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.
Aber es kann immer zu Problemen kommen und deswegen sollte man das im Hinterkopf behalten.
Okay dann werde ich mich da um einen Datenbankzugriff kümmern.
