dbatools 2.8.4 erweitert `Invoke-DbaDbLogShipping`, sodass eine Secondary zu einer bestehenden Log-Shipping-Konfiguration hinzugefügt werden kann. Das reduziert manuelle Arbeit für Reportingkopien, Migrationsziele oder einen weiteren Recovery-Standort. Risikofrei wird die Erweiterung dadurch nicht: Die neue Secondary braucht einen konsistenten Startzustand und muss sich in Jobs und Monitoring einfügen, die bereits Produktion schützen.
Bedeutung für den Betrieb
Die Planung beginnt mit dem Zweck der zusätzlichen Kopie. Standby-Reporting, verzögerte Wiederherstellung, Migration und Disaster Recovery benötigen unterschiedliche Restoreverzögerung, Betriebsart, Frequenz, Aufbewahrung und Zugriffsregeln. Netz- und Share-Kapazität müssen einen weiteren Empfänger tragen, ohne die vorhandene Secondary zu verzögern oder Logdateien über das gewünschte RPO hinaus aufzustauen.
Die Initialisierung wird mit realer Datenbankgröße geprobt. Basisbackup erstellen, sicher übertragen, im richtigen Zustand restaurieren, Copy- und Restorejobs ergänzen und die Erkennung durch den Monitorserver bestätigen. Credentials, Proxykonten, Share-Berechtigungen, Schlüssel und SQL-Agent-Verantwortung werden auf jeder beteiligten Instanz validiert.
Der erste erfolgreiche Restore ist nur der Anfang. Gemessen werden Copy- und Restorelatenz, Alarmschwellen, Cleanup, Netzunterbrechung, Job-Retry und das Verhalten bei Wartung der Primary. Ein kontrollierter Recovery- oder Rollentest beweist die Nutzbarkeit. Automation muss die Belege liefern, die Operatoren benötigen, statt nur abgeschlossene Konfigurationsbefehle zu melden.
Praktische Konsequenz
Die praktische Konsequenz: Eine zusätzliche Secondary erweitert den Recovery-Vertrag. Automation senkt Konfigurationsfehler, doch Initialisierung, Durchsatz, Monitoring, Security und Recovery-Verhalten werden vollständig geprüft. Ein zweites Ziel erhöht Resilienz erst, wenn es Logs innerhalb des Ziels erhält und das Team es unter Druck einsetzen kann.