I/O fouten op niet bestaand device in WS2019

[rene037]

Beste lezers...

samenvatting

Ik heb I/O fouten in het logboek op devices die ik niet kan vinden. Ze gebeuren bij het begin van de geplande back-up om 2:00 ’s-Nachts. De back-up lijkt echter succesvol, zowel volgens de eventlog als bestanden die terug te zetten zijn van de dag ervoor.
De back-up gaat naar een iSCSI-device, een WD EX2 Ultra NAS. (In WS2019 lokale adapter MS iSCSI-initiator/standaard/<ip-adres>/3260, CHAP-aanmelding en verbonden)
Het gekke is dat er steeds twee devicenummers in de log staan, maar elke dag andere.
Hoewel het geen logisch verband lijkt, noem ik het toch: In de logfile van back-up staan geen bestanden genoemd, alleen ‘Back-up van volume D: is geslaagd.’

Events

Dit zijn de events:
02:00:08 Disk 153 Er is opnieuw een poging gedaan voor de IO-bewerking op logisch blok 0x8000 voor schijf 4 (PDO-naam: \Device\000000a2).
Details: \Device\Harddisk4\DR27
\Device\000000a2
0F01040004002C0000000000990004800000000000000000000000000000000000000000000000000002048A
(3x herhaald, zelfde timestamp)
02:00:23 Disk 153 Er is opnieuw een poging gedaan voor de IO-bewerking op logisch blok 0x8000 voor schijf 4 (PDO-naam: \Device\000000a4).
Details: \Device\Harddisk4\DR28
0F01040004002C0000000000990004800000000000000000000000000000000000000000000000000002048A
(3x herhaald, zelfde timestamp)
Elke dag is het devicenummer anders. (Dag eerder \Device\0000009e, \Device\Harddisk4\DR26 & \Device\0000009c, \Device\Harddisk4\DR25
Waar het verband mee kan houden is een eerder event dat ik had en nu niet meer voorkomt (Ook bij start van een succesvolle back-up):
MSiSCSI 108 Status 0x00001069 geeft aan dat apparaatinterface \\?\{8e7bd593-6e6c-4c52-86a6-77175494dd8e}#MsVhdHba#1&3030e83&0&01#{2accfe60-c130-11d2-b082-00a0c91efb8b} geen ondersteuning biedt voor iSCSI WMI-interfaces. Als het apparaat geen iSCSI-HBA is, kan deze fout worden genegeerd.
Die foutmelding heb ik opgelost door enkele firewall regels toe te passen (Gevonden op internet):
netsh advfirewall firewall set rule "iSCSI Service (TCP Out)" new enable=yes
(Echter, die regel zie ik niet, ook niet met TCP-OUT – met ‘-‘)
set rule "iSNS Server (TCP Out)" new enable=yes
set rule "iSNS Server (TCP In)" new enable=yes
Ook in de firewall iSCSI-service toestemming gegeven
(iSCSI Target group stond wel aan, iSCSI-service niet.)

Vanaf dat moment heb ik event 153…
Af en toe heb ik ook event 140: Er kunnen geen gegevens worden geleegd naar het transactielogboek. Er kunnen beschadigingen optreden in volume-id: \\?\Volume{e5a7c652-822a-4d2e-8449-20929bb31203}, apparaatnaam: \Device\HarddiskVolume32.
({Schrijfbeveiligingsfout}
Er kunnen geen gegevens naar de schijf worden geschreven omdat deze tegen schrijven is beveiligd. Verwijder de schrijfbeveiliging van het volume %hs in het station %hs.)
Maar ook dat device kan ik niet vinden/thuisbrengen. Bij deze melding varieert het volume nummer ook.
Van MSiSCSI zie ik heel af en toe event 121: De firewalluitzondering voor het toestaan van iSNS-clientfunctionaliteit (Internet Storage Name Server) is niet ingeschakeld. iSNS-clientfunctionaliteit is niet beschikbaar.
Weet niet of dat een hint is. Dit event komt niet als de back-up start
Event 27 van VolSnap zie ik ook heel soms: De schaduwkopieën van volume \\?\Volume{e5a7c652-822a-4d2e-8449-20929bb31203} zijn afgebroken tijdens de detectie omdat een essentieel controlebestand niet kan worden geopend.

Configuratie

Schijf 0, D-drive, waar de back-up van gemaakt wordt
Schijf 1, Boot disk met herstel, EFI en bootpartitie (C:)
Schijf 2, iSCSI waar back-up heen gaat, geen driveletter toegekend, in back-up selecteer je ‘Back-up maken op harde schijf die voor back-ups is gereserveerd’.
Schijf 3, iSCSI met wel een driveletter (E:), maak ik handmatig af en toe van meer statische zaken back-up.

GWMI -namespace root\cimv2 -class win32_volume | FL -property DriveLetter, DeviceID

DriveLetter :
DeviceID : \\?\Volume{783950bd-566f-4e4a-999f-47fd7a27a0ab}\

DriveLetter : C:
DeviceID : \\?\Volume{368e8fe3-53cd-4ede-bbd2-a48a007fe623}\

DriveLetter : D:
DeviceID : \\?\Volume{716cb68f-1ec6-4f61-bd00-7386c920a8e3}\

DriveLetter : E:
DeviceID : \\?\Volume{f16aa813-e590-4f61-b09c-7f3df6ffe73c}\

DriveLetter :
DeviceID : \\?\Volume{7b3962f0-34df-45a3-b59e-4706e74c7075}\

DriveLetter :
DeviceID : \\?\Volume{fd7c565d-b5e5-4bcb-b03c-c9813907c4d4}\

Ik probeer mijn eventlog zo ‘schoon’ mogelijk te houden zoals je begrijpt.
Iemand een idee?

[rene037]

Kleine bump dan maar... Niemand een idee waar ik het moet zoeken?

[Lucas2067]

Probeer eens op ghosted devices te zoeken op internet.
Er is een remove ghosted device script die alle niet meer bestaande hardware kan verwijderen.
Dit is veel gebruikt bij fysical 2 virtual migraties

[rene037]

Beste Lucas,
Dank voor je reactie. Omdat reacties uitbleven heb ik de server opnieuw geïnstalleerd. Niet aan VSS gedaan, nog geen tijd gehad om daar mee te experimenteren. De events zijn er niet meer. Ergens zit er iets in de combinatie VSS/volume of directory back-up. Ik heb nu incremental back-up van twee folders geselecteerd, maar toch wordt er elke dag een volledige back-up gemaakt. Ik krijg echter wel lijst met bestanden in de log.
Bij de vorige versie had ik VSS aan en back-up van volume, toen kreeg ik wel incremental backup, maar bleven de logfiles leeg. Welk van de verschillen welk effect heeft ben ik nog niet uit.
Na reboot van de server krijg ik nog wel
Event 70: r is een fout opgetreden tijdens het verwerken van de iCSCSI-aanmeldingsaanvraag. De aanvraag is niet opnieuw uitgevoerd. Zie de dumpgegevens voor de foutstatus.
en
Event 1: De initiator kan geen verbinding maken met het doel. Het IP-adres van het doel en het TCP-poortnummer worden vermeld in de dumpgegevens.
Maar ik denk dat dat voorbarig is, de doelen zijn gewoon verbonden en de back-up gaat goed. Het staat alleen irritant. Wellicht dat iSNS instellen helpt, maar voor één iSCSI-target een beetje onzinnig.