Es gibt Upgrades, die neue Features bringen. Und es gibt Upgrades, die neue Features bringen und damit Dinge sichtbar machen, von denen niemand wusste, dass sie da sind. Der Sprung auf Veeam Backup & Replication 13.1 gehört bei mir gerade in die zweite Kategorie.
Kurzfassung vorab: 13.1 erkennt PostgreSQL-Instanzen jetzt auch auf Windows-Gästen – und findet dabei eingebettete Datenbanken, die als Backend ganz anderer Produkte laufen. Wer dafür keine Credentials hat (und bei vendor-managed Instanzen hat man die nie), bekommt eine Warnung im Job. Den Workaround habe ich vom Veeam Support bekommen, inklusive Freigabe zur Veröffentlichung. Die Kurzversion steht bereits im Veeam Community Resource Hub – hier die ausführliche Fassung mit etwas mehr Kontext und Betriebs-Perspektive.
Symptom
Nach dem Upgrade einer Kundenumgebung auf 13.1 lief ein bis dahin völlig unauffälliger Backup-Job plötzlich mit Warnung durch. Betroffen war ein VM-Backup eines Exchange-Servers mit aktiviertem Application-Aware Processing (AAP).
Wichtig für die Einordnung: Es spielt keine Rolle, ob VBR unter Windows oder die Veeam Software Appliance (VSA) im Einsatz ist. Das Verhalten hängt am Guest Processing, nicht an der Plattform des Backup-Servers.
Das Exchange-Processing selbst war einwandfrei – VSS lief, die Datenbanken waren applikationskonsistent, Truncation funktionierte. Die Warnung bezog sich auf eine PostgreSQL-Instanz auf demselben Gastsystem.
Und genau hier wird es interessant: Diese PostgreSQL-Instanz „gehört“ dem Kunden nicht wirklich. Sie ist eine eingebettete Komponente (in diesem Falll von Trellix/McAfee Email Security). Vendor-managed, keine Credentials, kein direkter Weg zur Administration. Klar, Berechtigung bzw. Instanz modifizieren via postgresql.conf, pg_hba.conf oder pg_ident.conf wären noch eine Option gewesen, sehen aber diverse 3rd-Party Lösungen dann auch nicht so gerne.
Veeam kann sich also nicht authentifizieren – und quittiert das mit einer Warnung im Session Log. Derselbe Job lief auf der Vorversion sauber durch. Nichts an der VM, nichts am Job, nichts an den Credentials hatte sich geändert.
Was sich geändert hat
Die Antwort des Veeam Support war eindeutig:
With version v13.1, Veeam can now detect PostgreSQL configuration files during guest processing, including embedded application databases.
Bis dahin war PostgreSQL-Processing im Veeam-Kontext im Wesentlichen ein Linux-Thema – über den Veeam Agent for Linux und die dort dokumentierten Mechanismen. Auf Windows-Gästen wurde schlicht nicht danach gesucht.
Mit Update auf Version v13.1 scannt das Guest Processing nun auch auf Windows nach den typischen PostgreSQL-Konfigurationsdateien.
Warum das mehr Umgebungen trifft als man denkt
Embedded PostgreSQL ist inzwischen extrem verbreitet. Ein paar Kandidaten, die einem im Enterprise-Umfeld regelmäßig begegnen:
- Trellix / McAfee Email & Web Security
- Esri ArcGIS (das Beispiel taucht sogar in der Support-Antwort auf)
- diverse Monitoring-Suiten
- Security- und EDR-Konsolen
- Backup- und Archivkataloge von Drittherstellern
- diverse DMS- und Ticketsysteme
Gemeinsames Muster: Die Datenbank ist Implementierungsdetail des Herstellers. Sie wird beim Setup mitinstalliert, läuft unter einem eigenen Dienstkonto, hat ein generiertes Passwort, das ggfs. nirgends dokumentiert ist – und der Hersteller-Support wird ungemütlich, wenn man daran schraubt. Und genau diese Konstellation kollidiert jetzt mit der erweiterten Erkennung.
Warum die naheliegende Lösung nicht funktioniert
Mein erster Reflex war der offensichtliche: In den AAP-Settings die PostgreSQL-Verarbeitung für diese VM abschalten und den Rest normal weiterlaufen lassen – aber wir wissen leider: Das geht nicht!
In den Job-Settings gibt es keinen Schalter, der eine einzelne erkannte Applikation oder eine ganze Datenbank-Engine von der Verarbeitung ausnimmt, während AAP für den restlichen Gast aktiv bleibt. Die verfügbaren Optionen laufen faktisch hinaus auf:
- AAP an – inklusive PostgreSQL-Discovery und der resultierenden Warnung, oder
- AAP aus – keine Warnung, aber auch kein applikationskonsistentes Exchange-Backup.
Letzteres ist bei einem Exchange-Server ganz klar keine Option. Damit war klar: Die Lösung muss außerhalb des Jobs liegen.
Der Workaround: Discovery gezielt aussperren
Der Hebel liegt (aktuell noch) im zu sichernden Gastsystem, über eine Konfigurationsdatei des PostgreSQL-Agents. Damit lassen sich Verzeichnisse gezielt von der Discovery ausschließen.
Hier die Antwort des Supports im Original-Wortlaut:
The clean way to keep SQL AAIP and bypass the embedded PostgreSQL instance is to exclude the PostgreSQL configuration directory from PostgreSQL discovery.
On the affected VM, identify the embedded PostgreSQL configuration/data folder that contains the PostgreSQL configuration files, for example the folder that contains postgresql.conf, pg_hba.conf, or pg_ident.conf.
Then follow the steps below:
- On the affected guest VM, create the folder C:\ProgramData\Veeam\Backup\PostgreSqlConfig\ on Microsoft Windows machines.
- In that folder, create or edit the file VeeamPostgreSQLAgent.xml.
- Add a single-line XML configuration that excludes the embedded PostgreSQL configuration directory from PostgreSQL scanning.
<config ExcludeConfigDirs=“C:\Program Files\PostgreSQL\“ />Note: Adjust the path to match the embedded PostgreSQL folder on the affected VM.
If there are multiple embedded PostgreSQL configuration directories, list them in the same ExcludeConfigDirs value separated by commas, for example: <config ExcludeConfigDirs=“C:\Path\To\ArcGIS\PostgreSQL1\,C:\Path\To\ArcGIS\PostgreSQL2\“ />.
Run the backup job again with Application-Aware Processing still enabled for the VM. This should allow Veeam to continue Microsoft SQL guest processing while skipping PostgreSQL discovery under the excluded directory.
Das richtige Verzeichnis finden
Bevor man die Exclusion setzt, muss man wissen, was man ausschließt. Zwei praktikable Wege unter Windows:
- Über den Dienst – schnell und zuverlässig, weil embedded Instanzen sich meist als Windows-Dienst registrieren und das Datenverzeichnis per -D im Binary-Pfad mitgeben:
Get-CimInstance Win32_Service | Where-Object { $_.PathName -match ‚postgres‘ } | Select-Object Name, DisplayName, State, PathName | Format-List
- Über die Konfigurationsdatei – langsamer, aber vollständig:
Get-ChildItem -Path C:\ -Filter postgresql.conf -Recurse -ErrorAction SilentlyContinue | Select-Object -ExpandProperty DirectoryName
Der zweite Weg findet auch Instanzen, die nicht als Dienst laufen oder von einem Wrapper-Prozess gestartet werden! So war es in meinem Szenario der Fall.
Anschließend die gefundenen Pfade in die <config ExcludeConfigDirs=“hier“ /> eintragen und bei mehreren Pfaden entsprechend kommasepariert, siehe Beispiel vom Support weiter oben!
Einordnung für den Betrieb
Der Mechanismus ist nicht neu. VeeamPostgreSQLAgent.xml mit ExcludeConfigDirs für Instanzen an ungewöhnlichen Orten – ist für den Veeam Agent for Linux seit Längerem dokumentiert. Neu ist die Anwendung auf Windows-Guests. Den Windows-Pfad habe ich in der öffentlichen Dokumentation (noch) nicht gefunden; er stammt aus der Support-Antwort.
Konfiguration innerhalb des Gast-Systems (kein Job-Setting). Das hat eine unangenehme Konsequenz: Die Datei überlebt keinen VM-Rebuild und kein Re-Deployment aus dem Template. Sie gehört damit ins Konfigurationsmanagement – GPO, Ansible, Intune, Golden Image, je nachdem, was bei euch im Einsatz ist.
Skalierung bedenken! Wenn eine Security- oder Monitoring-Suite flottenweit ausgerollt ist, betrifft das nicht eine VM, sondern potenziell hunderte. Nach dem 13.1-Upgrade lohnt ein gezielter Vergleich der Job-Historie: Welche Jobs zeigen neue Warnungen, die vorher nicht da waren?
Konsistenz und Restorability. Die Warnung betrifft die nicht erfolgte applikationskonsistente Verarbeitung der PostgreSQL-Instanz. Das VSS-basierte Processing für Exchange (in meinem Fall) läuft davon unabhängig weiter, und der VM-Snapshot selbst ist nach wie vor konsistent auf Dateisystemebene. Die embedded PostgreSQL-Instanz landet also crash-consistent im Backup. Ob das ausreicht, ist eine Frage an den jeweiligen Applikationshersteller, nicht an Veeam. PostgreSQL ist grundsätzlich robust gegen unsaubere Zustände – ein crash-consistent Snapshot ist in der Regel wiederherstellbar. Trotzdem: Bei geschäftskritischen embedded Datenbanken würde ich das explizit mit dem Hersteller klären und im Zweifel einen produkteigenen Export-Mechanismus zusätzlich einplanen!
Man kann die Warnung auch bewusst stehen lassen (ich bin kein Freund von „ja die Warnings und Errors sind normal“). Sie dokumentiert einen realen Sachverhalt: Im Gast existiert eine Datenbank, die nicht applikationskonsistent gesichert wird. Das ist eine Information, die in einem Backup-Report durchaus sinnvoll ist – nur eben nicht als wiederkehrender Alarm. Wer sein Monitoring strikt auf „grün oder Eskalation“ ausgelegt hat, hat diese Freiheit praktisch nicht.
Danke an den Veeam Support für die schnelle Antwort und die Freigabe zur Veröffentlichung – und an Fabian aka @Mildur, der das Verhalten parallel im Lab nachgestellt und im R&D Forum eingeordnet hat.
Weiterführende Links