Haikos Blog Blog von Haiko Hertes zu allen Themen rund um Microsoft und Datacenter

28Nov/170

PowerShell: Alte Offline-Backups von Windows Server Sicherung entfernen

Mir ist kürzlich bei einem Server das Sicherungsziel der täglichen Windows Serversicherung gestorben, da dieser (sehr einfache) Hyper-V-Server nur auf eine USB-Disk sichert, deren Speicherplatz per iSCSI an die VMs durchgereicht wird. Dies hat zur Folge, dass die Windows Serversicherung die dort abgelegten Sicherungen für alle Ewigkeit weiterhin anzeigt und mitzählt. Bei dem Versuch einer Wiederherstellung von Daten auf der gestorbenen Platte würde angezeigt werden, dass das Sicherungsziel offline ist und man hätte die – praktisch nicht mehr umsetzbare – Möglichkeit, die Daten verfügbar zu machen.

wsbkp1

Wenn man jetzt die Infos über die nicht mehr vorhandenen Sicherungen löschen will, um eine saubere “Statistik” zu haben, kann man sich eines PowerShell-Cmdlets bedienen: Remove-WBBackupSet.

Der Aufruf dazu sieht so aus:

Remove-WBBackupSet –MachineName SERVERNAME -KeepVersions 4

Der Parameter –KeepVersions gibg dabei an, wieviele der letzten Sicherungen man behalten möchte. Alternativ kann man mit –DeleteOldest die X ältesten Sicherungen entfernen.

wsbkp2

Bei dem Aufruf wird es aber sehr wahrscheinlich zu vielen Fehlern kommen, wie man im Screenshot sieht. Da die Sicherungen nicht mehr erreichbar sind, das Cmdlet aber eigentlich die Files dazu löschen würde, muss man sich hier zusätzlich des –Force Parameters bedienen:

wsbkp3

Dabei wird die Tatsache, dass die Sicherungen auf der ausgefallenen Platte nicht mehr erreichbar sind, ignoriert und nur der Verweis auf diese Sicherungen entfernt.

Mit dem Aufruf Get-WBBackupSet kann man sich nochmal ausgeben lassen, wieviele Sicherungen Windows Server Backup “kennt”:

wsbkp4

11Jun/150

SCDPM meldet “Replikat inkonsistent” wenn man einen Exchange 2013 Server sichert

Beim Versuch die Mailbox-Datenbank(en) eines Exchange 2013 Server zu sichern, kann es vorkommen, dass der System Center Data Protection Manager 2012 R2 meldet:

“Replikat inkonsistent” bzw. “Replica is inconsistent”

Das schaut dann in etwa so aus:

exch_dpm_1

Was kann man nun also dagegen tun?

Zunächst einmal muss sichergestellt sein, dass die Dateien “ese.dll” und “eseutil.exe” vom Exchange Server auf den DPM Server kopiert wurden – und zwar immer in der auf dem Exchange aktuell verwendeten Version – also nach größeren Updates neu kopieren!

Die Dateien befinden sich im Exchange-Verzeichnis unter “Bin”, also z.B. unter “D:\Program files\Microsoft\Exchange Server\V15\Bin” und müssen in den Bin-Pfad vom DPM, also z.B. nach “D:\Program files\Microsoft System Center 2012 R2\DPM\DPM\bin” kopiert werden.

Nach Updates sollte unbedingt die Version bzw. das Dateidatum kontrolliert werden!

exch_dpm_0

Weiterhin muss eine aktuelle Version des “Visual C++ Redistributable for 2012” auf dem Exchange Server installiert sein! Dieses lässt sich z.B. hier herunterladen: https://www.microsoft.com/de-de/download/details.aspx?id=30679 

Zur Sicherheit lässt sich auch eine Reparatur-Installation ausführen. Anschließend ist ein Reboot nötig.

exch_dpm_3 exch_dpm_4

Wenn diese Voraussetzungen geschaffen worden, dann kann entweder nur eine Konsistenzprüfung durchgeführt oder direkt die Sicherung fortgesetzt werden (was dann auch zunächst zu einer Konsistenzprüfung führt).

exch_dpm_5

exch_dpm_6

Wenn diese Abgeschlossen ist (was eine Weile dauern kann), sollte die Schutzgruppe wieder den Zustand “OK” (grün) annehmen.

10Jun/150

SCDPM meldet “Der Schutz kann nicht konfiguriert werden” wenn SQL Server gesichert werden soll

Bei der Version 2012 R2 des System Center Data Protection Managers gibt es ein Problem mit der Sicherung von SQL Servern der Version 2012. Es wird nach Erstellen der Schutzgruppe bzw. beim Versuch der Erstellung eines Replikates die Meldung “Der Schutz kann nicht konfiguriert werden” ausgegeben (Im Englischen: “Unable to configure protection”).

scdpm_sql_00

(Leider hab ich vom Fehler selbst in der Produktiv-Umgebung keinen Screenshot gemacht und ich wollte ihn nicht nochmal nachträglich provozieren – daher ein Shot aus einer englischen Umgebung)

Dieses Problem ist scheinbar bei Microsoft bekannt und auch im TechNet dokumentiert:

https://technet.microsoft.com/de-de/library/dn281948.aspx

Die Lösung ist auch recht einfach, da der Grund ebenso einfach ist: Der Schutz-Agent hat keine SA-Rechte auf der Datenbank, also müssen diese noch vergeben werden!

Dazu startet man auf dem zu sichernden Zielserver einfach das “SQL Server Management Studio”:

scdpm_sql_01

Dort kann man dann in dem Bereich “Sicherheit”, unter “Anmeldungen” das Konto von “NT-AUTORITÄT\SYSTEM” mit einem Rechtklick und der Auswahl von “Eigenschaften” öffnen. Hier muss dann die Rolle “sysadmin” zusätzlich mit ausgewählt werden.

scdpm_sql_03

Danach sollte sich die Sicherung via DPM auch problemlos einrichten und durchführen lassen:

scdpm_sql_04

18Mrz/140

Exchange 2007 lässt sich nicht via Windows Server Sicherung sichern

Hinweis: Bei meinen Recherchen zu dem Thema habe ich festgestellt, dass dieses Problem scheinbar auch bei Exchange 2010 auftritt!

Bei einem Exchange Server 2007 mit LCR trat seit längerem das Problem auf, dass sich dieser nicht sauber (auf Anwendungsebene) sichern ließ. Die Windows Server Sicherung meldete immer

“Abgeschlossen mit Warnungen – Die Anwendung kann aus dieser Sicherung nicht wiederhergestellt werden […]”

exchbkp0

Kurz nach Start der Sicherung findet sich im Ereignisprotokoll folgender Eintrag:

exchbkp2

Anwendungsprotokoll / Ereignis 565 / Quelle Backup / “Fehler bei der Konsistenzprüfung für die Komponente […]”

Eine Überprüfung der Postfachdatenbank sowie der Datenbank für die öffentlichen Ordner und aller Logs mit Hilfe von ESEUtil brachte keinerlei Fehler oder sonstige Probleme.

Als Lösung des Problemes habe ich den Exchange VSS-Writer per Registry deaktiviert.

Dazu ist unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Replay\Parameters ein neuer DWORD-Schlüssel anzulegen, der den Namen “EnableVSSWriter” und den Wert 0 bekommt.

exchbkp3

Danach funktioniert das nächtliche Backup wieder ohne Probleme:

exchbkp4