dbatools 2.8.4 behebt Verhalten in `Restore-DbaDatabase` bei Copy-only-Point-in-Time-Restoreketten. Die Änderung erinnert daran, dass einzelne Backupdateien gültig sein können, während ein automatisierter Restore trotzdem die falsche Reihenfolge auswählt. Recovery-Vertrauen entsteht durch die Ausführung der gesamten Kette und nicht durch den Nachweis, dass nächtliche Jobs Dateien erzeugt haben.
Bedeutung für den Betrieb
Copy-only-Full-Backups setzen die Differentialbasis bewusst nicht zurück. Copy-only-Log-Backups erhalten die normale Logfolge und bedienen zugleich einen unabhängigen Zweck. Das ist für Migration, Tests und Ad-hoc-Recovery nützlich, erzeugt aber mehr Metadaten, die Automation interpretieren muss. Für das gewünschte `STOPAT`-Ziel sind das richtige Full, Differential und die korrekte Logfolge auszuwählen.
Ein wiederholbarer Testsatz enthält reguläre Full- und Differentialbackups, Transaktionslogs, ein Copy-only-Full und Recovery-Ziele vor und nach dieser Datei. Getestet wird mit demselben Repository-Layout, Naming, derselben Verschlüsselung, denselben Credentials und derselben dbatools-Version wie in Produktion. Die gewählte Kette wird protokolliert und die Daten am Zielzeitpunkt fachlich geprüft.
Modulupgrades gehören in den Recovery-Change-Prozess. Freigegebene dbatools-Versionen werden auf Automation Hosts fixiert, Restore-relevante Release Notes geprüft und repräsentative Ketten vor der Promotion erneut ausgeführt. Der zugrunde liegende T-SQL-Recoveryweg bleibt dokumentiert, damit eine Modulregression während eines Vorfalls nicht den einzigen Betriebsweg blockiert.
Praktische Konsequenz
Die praktische Schlussfolgerung: Copy-only-Semantik muss per Restore bewiesen werden. Kettenauswahl, `STOPAT`, Verschlüsselung und Ergebnisdaten werden nach jeder relevanten Werkzeugänderung validiert. Gültige Backups sind notwendig; Point-in-Time-Recovery existiert erst, wenn die konkrete Kombination aus Dateien und Automation den benötigten Zustand wiederhergestellt hat.