V novém roce plný elánu po prodělané nemoci jsem se pustil do dlouhodobých restů. Jedním z nich byly chyby v DPM 2010 serveru. Těch se objevilo hned několik, jednou z nich bylo opětovná deserializace záloh virtuálních mašin na CSV clusteru, předpokládám, že to způsobila instalace posledního DPM rollup hotfixu. Takže si holt do dokumentace píšeme poznámku, že po každém patchování DPM serveru je potřeba pro jistotu kontrolovat nastavení klíče HKLM\SOFTWARE\Microsoft\Microsoft Data Protection Manager\2.0\Configuration\MaxAllowedParallelBackups\Microsoft Hyper-V, které musí obsahovat číslo 1 a nikoliv standardní 3. Další typ chyby, který se projevoval pouze u dvou virtuálních serverů, byl ještě záludnější. Ukázalo se nakonec, že problém je v kolizi Master Boot Record signatur disků.
Každý pokus o provedení kontroly konzistence skončil níže uvedeným chybovým hlášením DPM úlohy:
Affected area: \Backup Using Child Partition Snapshot\server01.domain.local
Occurred since: 6.1.2011 14:47:07
Description: The replica of Microsoft Hyper-V \Backup Using Child Partition Snapshot\server01.domain.local on SCVMM server01.domain.local Resources.vs-vp.servicedomain.local is inconsistent with the protected data source. All protection activities for data source will fail until the replica is synchronized with consistency check. You can recover data from existing recovery points, but new recovery points cannot be created until the replica is consistent.
For SharePoint farm, recovery points will continue getting created with the databases that are consistent. To backup inconsistent databases, run a consistency check on the farm. (ID 3106)
The VSS application writer or the VSS provider is in a bad state. Either it was already in a bad state or it entered a bad state during the current operation. (ID 30111 Details: VssError:The writer experienced a non-transient error. If the backup process is retried,
the error is likely to reoccur.
(0x800423F4))
More information
Recommended action: Please check that the Event Service, the VSS service and the shadow copy provider service is running, and check for errors associated with these services in the Application Event Log on the server S-VP1.servicedomain.local. Please allow 10 minutes for VSS to repair itself and then retry the operation.
For more information on this error, go to http://go.microsoft.com/fwlink/?LinkId=132612.
Synchronize with consistency check.
Run a synchronization job with consistency check...
Resolution: To dismiss the alert, click below
Inactivate alert
Po spuštění úlohy v DPM se v systémovém logu Hyper-V uzlu clusteru, na kterém aktuálně daný virtuál běží, se vždy objevila zpráva o tom, že byla nastartována služba Volume Shadow Copy, což je naprosto v pořádku.
Log Name: System
Source: Service Control Manager
Date: 6.1.2011 14:44:14
Event ID: 7036
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: S-VP1.servicedomain.local
Description:
The Volume Shadow Copy service entered the running state.
A za necelých 11 sekund se objeví varování od partmgr o tom, že disk 8 (server jich má jen 7) má stejnou signaturu jako disk 0 (což je systémový disk uzlu clusteru). Naštěstí jsem zrovna včera četl knihu Windows Server 2008 R2 Hyper-V Insiders Guide to Microsoft’s Hypervisor, ve které je popsaný nástroj diskshadow.exe. Ten dokáže provést VSS snapshot zadaného disku a přimountovat jej jako další disk s písmenkem do operačního systému. Říkal jsem si, že DPM 2010 při zálohování virtuálů bude určitě využívat obdobné schéma. To by totiž vysvětlovalo hlášku o disku 8.
Takže jsem chvíli hledal, až jsem našel tento článek, ve kterém autor popisuje obdobné chování a hlavně postup, kterým dotčená virtuální mašina vznikla – pomocí P2V procesu. Teď už si nevzpomenu, jestli jsme v tomto konkrétním případě využili SC VMM 2008 nebo Disk2VHD, podstatné je, že to zlobí u obou virtuálních mašin, které byly takto převedené.
Utilitka, která pomůže v těchto nesnázích, se jmenuje MBRWiz. Aktuální verze podporuje I W7 a W2008.
http://firesage.com/mbrwizard.php
mbrwiz /list
mbrwiz /Signature=Read
Tím jsem se dozvěděl, že má Disk 0 signature: 0x00000080 (virtuálního serveru), což je naprosto shodná hodnota, kterou mají všechny systémové disky všech uzlů Hyper-V clusteru. Namátkou jsem zkontroloval uzly všech nových clusterů, které máme k dispozici, u všech je signatura stejná. Tak buď za to může instalace Failover cluster role, což se mi moc nezdá, pravděpodobnější je to, že jsme všechny servery instalovali s využitím Dell OpenManage Install Windows startovacího CD.
Oprava spočívá ve vygenerování nové signatury disku virtuálního serveru.
mbrwiz /Signature=Generate
Poté již DPM bez problémů provede VSS snapshot a připojí si jej dočasně k fyzickému uzlu. Paráda. Teď již jen vyřešit poslední chybové hlášení v DPM, které je u dalšího W2008 non-R2 clusteru, na němž běží clusterové DHCP. To ve W2008 sice zazálohovat lze, korektní záloha však projde jen na tom uzlu, na němž DHCP právě běží. U dalších uzlů zahlásí DPM chybu. Opraveno je to údajně ve W2008R2, bohužel to v tomto konkrétním případě znamená kompletní rebuild celého clusteru.