Beantwoord

[Windows] Herinstallatie BUO blijft dagenlang hangen op "Even geduld Uw systeem wordt geconfigureerd"!

  • 4 januari 2017
  • 51 reacties
  • 1421 keer bekeken


Toon eerste bericht

51 reacties

Reputatie 3
Badge
Ja, daarom moet het ook speciaal naar die schijf. Ik ga het gewoon proberen vanavond. En dan hoor je wel of het kan 🙂.
Reputatie 7
Hi Richard,

TOUCHÉ, dat is de enige goede manier om het te doen, denk ik.

Echter, de versie die wij hebben, maakt voor het back-uppen geen connectie met netwerk shares! Wellicht kun je - voor alleen het RESTOREN - de boel een beetje naar je eigen hand zetten, door BUO te laten denken dat de originele disk die je op je andere PC wilt gaan aanmaken als 'share' een interne schijf of DAS is? Kan dat uberhaupt in Windows?

Man, wat een project is dit geworden voor je! Ik zal zelf zo direct ook even in Windows gaan en wat testjes voor je doen.

Succes en houdt ons op de hoogte van je voortgang!

PS check mijn PB!
Reputatie 7
Badge +11
Wellicht kun je - voor alleen het RESTOREN - de boel een beetje naar je eigen hand zetten, door BUO te laten denken dat de originele disk die je op je andere PC wilt gaan aanmaken als 'share' een interne schijf of DAS is? Kan dat uberhaupt in Windows?Het is mogelijk in windows, een "mapped networkdrive". Back-up Online heeft echter wel door dat het een netwerklocatie is. Mogelijk is dat bij het restoren ook het geval.

Succes Richard, hopelijk kom je eruit!
Reputatie 3
Badge
Voorlopig kom ik nog niet zo ver. Ik heb nu eerst weer het initiële probleem: buo die niet wil doorstarten. Hij is nu eerst weer de index aan het bijwerken. Vorige keer duurde dat meer dan 10 dagen, hopelijk is het nu sneller.
Reputatie 7
Badge +11
Hi Richard,
in PB heb ik je nog een idee aangegeven. Misschien is het een optie om BUO te verwijderen om eerst de bestanden te herstellen.
Reputatie 3
Badge
Als je C:-drive vol raakt, kan BUO in de problemen komen doordat zijn index bestanden op die drive staan. Samen met nog enkele andere bestanden staan deze index bestanden in een sub folder van %programdata%\KPN\KPN Back-up Online\storage\. Via de user interface is deze locatie niet te veranderen. Van de leverancier van de software heb ik echter aanwijzingen gekregen waarmee je deze locatie wel kan veranderen. Dus als je C:-drive structureel vol is maar je hebt nog voldoende ruimte op een andere disk in je systeem, dan kun je deze bestanden daar naar toe verplaatsen.

Dit zijn de stappen die je moet uitvoeren om de index en tijdelijke bestanden van Backup Online te verplaatsen:
- open de folder C:\Program Files\KPN Back-up Online\
- open het bestand config.ini in je favoriete text-editor, bijvoorbeeld notepad.
- Voeg onder het kopje [General] onderstaande 2 nieuwe regels toe (zorg dat er geen lege regels tussen het kopje en de nieuwe regels staan. Bij mij is er voldoende ruimte op mijn E:-drive, vervang de drive letter en de folder namen door het pad naar de locatie waar jij je bestanden wil plaatsen).
PathToLocalStorage=E:\KPN_BR
TempDir=E:\KPN_BR\temp
- sla het bestand op de originele locatie op (lukt dit niet vanwege te weinig rechten, sla het dan eerst elders op en verplaats daarna je nieuwe bestand over het oude bestand heen).
- start services.msc
- zoek in de lijst met services naar de regel met naam "KPN Back-up Online SC"
- Klik rechts op die naam en kies in het menu voor "Opnieuw starten"
Wanneer je nu BUO opstart zal hij ontdekken dat de index bestanden niet op de aangegeven locatie staan en deze zal hij eerst opnieuw aanmaken. Afhankelijk van hoe lang je al BUO gebruikt op deze machine kan dit een tijd duren (varierend van enkele seconden tot in extreme gevallen enkele dagen). Zodra dit klaar is, kun je weer gebruik maken van BUO. En wanneer je hebt gecontroleerd dat alles naar wens werkt, kun je de oude bestanden op je C:-drive verwijderen. Mogelijk kun je de oude bestanden ook verplaatsen naar de nieuwe locatie en zo het wachten op het opnieuw opbouwen van de index bestanden vermijden, maar als je bestanden corrupt zijn geraakt zoals bij mij het geval was, dan kost je dit alleen maar extra ruimte. Ik heb het in ieder geval op bovenstaande manier gedaan. Mocht iemand proberen de bestaande bestanden te verplaatsen, geef dan even in een reactie aan hoe het gegaan is.

Ter controle: De inhoud van je config.ini bestand ziet er na het toevoegen van de nieuwe regels ongeveer als volgt uit (de cijfer en letterreeksen zijn bij iedereen anders):
[General]
InteractiveConfigurationRequired=0
InstallationId=1234567890abcdef1234
User=1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF
Password=1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF
PathToLocalStorage=E:\KPN_BR
TempDir=E:\KPN_BR\temp

[HttpServer]
HttpServerPort=5000

[WebUI]
WebUIAuthenticationTokenSecret=12345678-90ab-cdef-1234-567890abcdef
Reputatie 7
Als je C:-drive vol raakt, kan BUO in de problemen komen doordat zijn index bestanden op die drive staan. Samen met nog enkele andere bestanden staan deze index bestanden in een sub folder van %programdata%\KPN\KPN Back-up Online\storage\. Via de user interface is deze locatie niet te veranderen. Van de leverancier van de software heb ik echter aanwijzingen gekregen waarmee je deze locatie wel kan veranderen. Dus als je C:-drive structureel vol is maar je hebt nog voldoende ruimte op een andere disk in je systeem, dan kun je deze bestanden daar naar toe verplaatsen.

Dit zijn de stappen die je moet uitvoeren om de index en tijdelijke bestanden van Backup Online te verplaatsen:
- open de folder C:\Program Files\KPN Back-up Online\
- open het bestand config.ini in je favoriete text-editor, bijvoorbeeld notepad.
- Voeg onder het kopje [General] onderstaande 2 nieuwe regels toe (zorg dat er geen lege regels tussen het kopje en de nieuwe regels staan. Bij mij is er voldoende ruimte op mijn E:-drive, vervang de drive letter en de folder namen door het pad naar de locatie waar jij je bestanden wil plaatsen).
PathToLocalStorage=E:\KPN_BR
TempDir=E:\KPN_BR\temp
- sla het bestand op de originele locatie op (lukt dit niet vanwege te weinig rechten, sla het dan eerst elders op en verplaats daarna je nieuwe bestand over het oude bestand heen).
- start services.msc
- zoek in de lijst met services naar de regel met naam "KPN Back-up Online SC"
- Klik rechts op die naam en kies in het menu voor "Opnieuw starten"
Wanneer je nu BUO opstart zal hij ontdekken dat de index bestanden niet op de aangegeven locatie staan en deze zal hij eerst opnieuw aanmaken. Afhankelijk van hoe lang je al BUO gebruikt op deze machine kan dit een tijd duren (varierend van enkele seconden tot in extreme gevallen enkele dagen). Zodra dit klaar is, kun je weer gebruik maken van BUO. En wanneer je hebt gecontroleerd dat alles naar wens werkt, kun je de oude bestanden op je C:-drive verwijderen. Mogelijk kun je de oude bestanden ook verplaatsen naar de nieuwe locatie en zo het wachten op het opnieuw opbouwen van de index bestanden vermijden, maar als je bestanden corrupt zijn geraakt zoals bij mij het geval was, dan kost je dit alleen maar extra ruimte. Ik heb het in ieder geval op bovenstaande manier gedaan. Mocht iemand proberen de bestaande bestanden te verplaatsen, geef dan even in een reactie aan hoe het gegaan is.

Ter controle: De inhoud van je config.ini bestand ziet er na het toevoegen van de nieuwe regels ongeveer als volgt uit (de cijfer en letterreeksen zijn bij iedereen anders):
[General]
InteractiveConfigurationRequired=0
InstallationId=1234567890abcdef1234
User=1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF
Password=1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF
PathToLocalStorage=E:\KPN_BR
TempDir=E:\KPN_BR\temp

[HttpServer]
HttpServerPort=5000

[WebUI]
WebUIAuthenticationTokenSecret=12345678-90ab-cdef-1234-567890abcdef

Lees ik het goed, dat je de volledige data-set van je back-up op deze manier heb kunnen restoren?

KUDO's voor IASO!
Reputatie 3
Badge
Helaas, zover is het nog niet. Ik ben nog bezig om mijn index bestanden bij te werken. De reden waarom dit bij mij zo lang duurt is nog niet boven water/weggenomen. Maar het opbouwen van de index bestanden loopt nu in ieder geval weer door.
Reputatie 7
Badge +11

Lees ik het goed, dat je de volledige data-set van je back-up op deze manier heb kunnen restoren?

KUDO's voor IASO!

Geweldige post, bedankt voor het delen Richard!!
Ik ben ook heel erg benieuwd of je al iets hebt kunnen restoren? 🙂
Reputatie 7
Badge +11
Helaas, zover is het nog niet. Ik ben nog bezig om mijn index bestanden bij te werken. De reden waarom dit bij mij zo lang duurt is nog niet boven water/weggenomen. Maar het opbouwen van de index bestanden loopt nu in ieder geval weer door.
Cross post :D
Afwachten dus, in ieder geval goed nieuws.
Reputatie 3
Badge
Op http://localhost:5000/logs/app kun je de log bekijken van wat de service aan het doen is. Hij heeft eerst slices gedownload en weggeschreven in verschillende .d files, waarna hij voor elk van die .d files .x files ging aanmaken. De sc.d file -die 68GB groot is bij mij- had hij in ongeveer een uur gedownload en aangemaakt, maar nu is hij bezig om de bijbehorende sc.x aan te maken. In het begin ging dat vrij snel, maar hij is nu ongeveer 12GB groot en nu komen er nog maar tergend langzaam steeds wat kilobytes bij.

Een paar relevante stukjes uit mijn log files:

[2017-03-14 19:02:20.748919] [d] [06752] [Component Synchronizer] Updating index component sc.x: inconsistent, removing.

---- 8< ----- 8< ----

[2017-03-14 19:02:21.962040] [d] [06752] [CodeBase] File Find Error Opening File (-64) file4open (90615) [E:\KPN_BR\reg\sc.x] [] []
[2017-03-14 19:02:21.962040] [d] [06752] [`anonymous-namespace'::DetermineIndexMode] [sc] Index file could not be opened (-64)
[2017-03-14 19:02:21.962040] [d] [06752] [`anonymous-namespace'::CreateIndexInfo] [sc] Index would be opened in binary mode
[2017-03-14 19:02:21.962040] [d] [06752] [`anonymous-namespace'::CreateIndexInfo] [sc] Tag "NOV2_ta#", expression "ASCEND(NodeId)+ASCEND(Ordinal)+DESCEND(Version)", filter "NodeId > 0 .AND. .NOT. DELETED()"
[2017-03-14 19:02:21.962040] [d] [06752] [`anonymous-namespace'::CreateIndexInfo] [sc] Tag "SlcHsh_ta#", expression "SUBSTR(SliceHash,1,4)", filter "NodeId > 0 .AND. .NOT. DELETED()"
[2017-03-14 19:02:21.962040] [d] [06752] [`anonymous-namespace'::CreateIndexInfo] [sc] Tag "Cab2_ta#", expression "ASCEND(CabinetId)", filter "NodeId > 0 .AND. .NOT. DELETED()"
[2017-03-14 19:02:21.962040] [d] [06752] [CodeBase] File Find Error Opening File (-64) file4open (90615) [E:\KPN_BR\reg\sc.x]

En dat is de laatste melding over de sc.x file waar hij nu nog steeds mee bezig is. Blijkbaar is hij er om 2017-03-14 19:02:21.962040 achter gekomen dat de index file hersteld moest worden, en is hij daar 2017-03-14 19:02:21.962040 aan begonnen. En zo duurt het opbouwen van deze ene index file nu al weer 42 uur. Bij de andere files varieert de verhouding tussen de .d- en .x-files tussen de 1.5 en 6. In het meest optimistische geval wordt deze sc.x file dan ook 11GB groot en dan ben ik bijna klaar. Maar in het meest pessimistische geval wordt hij 47GB groot en dan ben ik nog lang niet klaar als de snelheid zo blijft afnemen als hij dat nu doet. In ieder geval heb ik een aardig idee waar de bottleneck zit.
Reputatie 7
Bedankt weer voor je uitvoerige post in dit interessante draadje, Richard! Die [http://localhost:5000/logs/app] link is ook weer een super goede aanvulling, om ons als gebruikers ook weer veel meer inzicht te geven in de werking - onder de motorkap - van Back-up Online.
Reputatie 3
Badge
Sneller dan verwacht is hij klaar met het herstellen van de index bestanden. In de log files:

[2017-03-17 18:24:37.888734] [d] [06752] [Component Synchronizer] Sealing component sc.d.
[2017-03-17 18:24:37.904334] [d] [06752] [Component Synchronizer] Sealing component sc.x.
[2017-03-17 18:24:37.904334] [d] [06752] [Component Synchronizer] Sealing component p.d.
[2017-03-17 18:24:37.904334] [d] [06752] [Component Synchronizer] Sealing component p.x.
[2017-03-17 18:24:37.904334] [d] [06752] [Component Synchronizer] Sealing component sca.d.
[2017-03-17 18:24:37.904334] [d] [06752] [Component Synchronizer] Sealing component sca.x.
[2017-03-17 18:24:37.904334] [d] [06752] [Component Synchronizer] Updating data component c.d: inconsistent, downloading safe copy.
[2017-03-17 18:24:38.044735] [d] [06752] [MultiTiers] Multi-tier operation succeeded on tier "BackupServer".
[2017-03-17 18:24:38.044735] [d] [06752] [RemoteBackupRegisterSliceManipulator] Downloading slice "c.d_000E_00000000_00000000_V_85B2E4FE" ...
[2017-03-17 18:24:38.075935] [d] [06752] [RemoteBackupRegisterSliceManipulator] Downloaded slice "c.d_000E_00000000_00000000_V_85B2E4FE".


Na nog wat meer bestanden was hij eindelijk klaar en werd ik gevraagd om mijn zelf bedachte wachtwoord in te vullen. Daarna nog de vraag beantwoord met 'alleen herstellen' en ik kan gaan beginnen met restoren! 🆒
Reputatie 7
Super Richard! Samenvattend kun je na de herstel procedure - als je daar natuurlijk ook de tijd voor hebt - er in ieder geval een hele mooie wiki post van maken!

Bedankt voor je update, ik wens je een goed weekeinde.
Reputatie 7
Badge +11
Hi Richard,

Nu we weer een paar dagen verder zijn, ben ik benieuwd of het is gelukt om de belangrijke bestanden te restoren? 🙂
Reputatie 3
Badge
Hij is nog aan het restoren. 7,5TB restoren met ongeveer 100Mbit/s, dat duurt ongeveer een week. Nog ongeveer 2 dagen te gaan is de schatting die BUO geeft. Tot dusver gaat het nog steeds voorspoedig en wat al is gerestored ziet er goed uit.

Toch blijft het opvallend om te zien dat hij in omgekeerd alfabetische volgorde restored, van Z naar A dus. Het was me al eens eerder opgevallen en er zal best een verklaring voor zijn maar ik kan geen reden verzinnen waarom je dit zou doen. Het is natuurlijk niet erg maar het lijkt gewoon een beetje onlogisch. 🙂
Reputatie 7
Hij is nog aan het restoren. 7,5TB restoren met ongeveer 100Mbit/s, dat duurt ongeveer een week. Nog ongeveer 2 dagen te gaan is de schatting die BUO geeft. Tot dusver gaat het nog steeds voorspoedig en wat al is gerestored ziet er goed uit.
Geweldig Richard! Ben erg benieuwd naar je uiteindelijke restore, heb je de mogelijkheid om het aantal files te vergelijken? Zullen we zaterdag dan maar alvast in de agenda zetten voor koffie met applegebak? ;)

Toch blijft het opvallend om te zien dat hij in omgekeerd alfabetische volgorde restored, van Z naar A dus. Het was me al eens eerder opgevallen en er zal best een verklaring voor zijn maar ik kan geen reden verzinnen waarom je dit zou doen. Het is natuurlijk niet erg maar het lijkt gewoon een beetje onlogisch. :-)
Leuke vraag, ben ook wel benieuwd naar het antwoord hierop.
Reputatie 3
Badge
Ben erg benieuwd naar je uiteindelijke restore, heb je de mogelijkheid om het aantal files te vergelijken?
Ik doe een restore omdat alles weg was, dus vergelijken met het origineel lukt me in ieder geval niet. Wat had je hiermee willen controleren?

Zullen we zaterdag dan maar alvast in de agenda zetten voor koffie met applegebak? ;)
Ik ben al blij als de restore straks gelukt is. Als jij dan ook nog appelgebak komt brengen... Dan kan mijn geluk echt niet meer op. 😃
Reputatie 7
Ben erg benieuwd naar je uiteindelijke restore, heb je de mogelijkheid om het aantal files te vergelijken?
Ik doe een restore omdat alles weg was, dus vergelijken met het origineel lukt me in ieder geval niet. Wat had je hiermee willen controleren?

Ik was in de veronderstelling dat je op bestandsniveau (register) een vergelijking kon maken, foute aanname dus.:$

Zullen we zaterdag dan maar alvast in de agenda zetten voor koffie met applegebak? ;)
Ik ben al blij als de restore straks gelukt is. Als jij dan ook nog appelgebak komt brengen... Dan kan mijn geluk echt niet meer op. :D

Deal! 🆒
Reputatie 3
Badge
Ik heb al een tijdje niet van me laten horen, dus bij deze nog maar eens een update. De restore is inmiddels helemaal gelukt. Ik heb al mijn belangrijke bestanden weer terug. Dank voor alle hulp hierbij.

We hadden in eerste instantie bedacht om -nadat de restore gelukt was- opnieuw te beginnen met een schoon account. Dat zou er dan voor zorgen dat de bestanden in de reg folder niet meer zo groot zouden zijn. Na enige tijd daarover te hebben nagedacht leek me dit echter toch niet zo'n goed idee: het opnieuw uploaden van de grote hoeveelheid data op mijn schijven zou weer een flinke tijd gaan duren. De download duurde ruwweg een week en mijn download snelheid is ongeveer 10 keer zo groot als mijn upload snelheid, dus even aannemend dat ik alles opnieuw zou moeten uploaden met 1/10 van de snelheid van het downloaden, dan zou het zeker 10 weken gaan duren voordat ik weer een volledige backup heb. Zou ik echter binnen die tijd weer een keer ransomware o.i.d. op mijn machine krijgen (het is immers al 2 keer gebeurd, dus waarom zou het niet opnieuw kunnen gebeuren), dan zou ik nog geen nieuwe backup weer hebben. Dat risico wilde ik liever niet lopen, dus ik heb BUO laten teruggaan vanuit de 'alleen herstellen'-modus naar de normale modus om weer nieuwe backups te kunnen gaan maken van mijn systeem. Ik heb een nieuwe backup opdracht gestart, maar tot nu toe gebeurt er al een kleine week niets meer in de interface. In de appl;ication log (http://localhost:5000/logs/app) kan ik nu echter wel zien of hij nog aan het werk is, en zelfs wat hij aan het doen is. Ik zie zo dat hij nu de index bestanden in de reg folder aan het opschonen is. Ook dit duurt natuurlijk weer erg lang maar nu weet ik tenminste waar ik op wacht, dus ik wacht gewoon geduldig af wanneer BUO klaar is met het opschonen van alle obsolete slices en nodes en mijn nieuwe backup gaat lopen.
Reputatie 7
Hallo Richard, super dat je restore helemaal is gelukt! Als we dit draadje doorspitten heb je - mij in ieder geval - ons een heel nieuw inzicht gegeven over de werking van Back-up Online "onder de motorkap" en hoe we doormiddel van de localhost applicatie log deze info's kunnen ontsluiten en inzien. Buitengewoon leerzaam op z'n minst.

Mag ik je vragen - als je tijd en zin hebt natuurlijk - jouw draadje in de vorm van een sticky samen te willen vatten, zodat we deze prominent op het forum aandacht kunnen geven? Dan blijft het resultaat van jouw noeste arbeid ook voor anderen goed zichtbaar en bruikbaar als mogelijke oplossing.
Reputatie 7
Badge +11
Helemaal eens met Berend. Bedankt @Richard Rozema voor het uitgebreide verslag along the way. Fijn om te horen dat het gelukt is om de belangrijke bestanden te restoren! Nu inderdaad op naar een stabiele werkbare Back-up Online configuratie. Op de server zie ik nog niet terug dat er weer een succesvolle back-up is gemaakt, hopelijk is hij snel klaar en werkt de dienst daarna zonder issues.
Absoluut was dit een leerzaam proces voor ons allen. 🙂
Reputatie 7
Hi @Tim en @Richard Rozema,

Graag even jullie mening/suggesties mbt het volgende?

Zou het beschikbaar stellen van de optie, om in volumes in de tab Voorkeuren > Geavanceerd, een externe HDD/SSD te kunnen selecteren voor het opslaan van tijdelijke bestanden - voor back-up en/of herstel - een goed alternatief kunnen zijn?



Het lijkt me niet meer werk dan het tweaken van een setting in het configuratiebestand voor Back-up Online? Ik hoor graag jullie mening en/of andere suggesties.
Reputatie 7
Hi @Richard Rozema,

Ik ga er vanuit dat het maken van je back-ups - na je laatste bericht - verder goed verloopt, ik markeer jouw topic dan ook als zijnde beantwoordt. Ik hoop eigenlijk nog wel stiekem, dat je toch nog tijd vrij kunt maken om van je eigen topic een mooie samenvatting te maken. 🆒

Succes!
Reputatie 3
Badge
Zoals al eerder gebleken is, duurt alles wat langer als je een grote backup set hebt 🙂 Inmiddels heb ik er inderdaad een eerste volledige backup op zitten. Van al mijn bestanden zijn weer de laatste versies veilig gesteld: de backup doet het weer.

Echter, het lijkt er op dat elke keer dat mijn machine herstart is, BUO opnieuw de index bestanden gaat opbouwen. De applicatie toont dan weer het gewraakte scherm "Backup Service wordt geinitialiseerd, wacht alstublieft"


Dit duurt telkens enkele dagen. De inhoud van de log toont dat het weer om de sc.x gaat:
------------- >8 --------------- >8 ---------------
[2017-04-27 16:47:27.447375] [d] [03052] [Component Synchronizer] Sealing component n.d.
[2017-04-27 16:47:27.448376] [d] [03052] [Component Synchronizer] Sealing component n.x.
[2017-04-27 16:47:27.449376] [d] [03052] [Component Synchronizer] Sealing component nn.e.
[2017-04-27 16:47:27.450377] [d] [03052] [Component Synchronizer] Sealing component nn.d.
[2017-04-27 16:47:27.451377] [d] [03052] [Component Synchronizer] Sealing component nn.x.
[2017-04-27 16:47:27.451377] [d] [03052] [Component Synchronizer] Sealing component nr.d.
[2017-04-27 16:47:27.452378] [d] [03052] [Component Synchronizer] Sealing component nr.x.
[2017-04-27 16:47:27.456380] [d] [03052] [Component Synchronizer] Updating data component sc.d: partial consistent, index must be rebuilt.
[2017-04-27 16:47:27.456380] [d] [03052] [Component Synchronizer] Updating index component sc.x: inconsistent, removing.
[2017-04-27 16:47:27.597450] [d] [03052] [Component Synchronizer] Updating data component p.d: consistent.
[2017-04-27 16:47:27.597450] [d] [03052] [Component Synchronizer] Updating index component p.x: consistent.
[2017-04-27 16:47:27.597450] [d] [03052] [Component Synchronizer] Updating data component sca.d: consistent.
[2017-04-27 16:47:27.598451] [d] [03052] [Component Synchronizer] Updating index component sca.x: consistent.
[2017-04-27 16:47:27.687495] [d] [03052] [`anonymous-namespace'::DetermineIndexMode] [p] Index tag "CAB2_TA#" uses binary naming convention
[2017-04-27 16:47:27.687495] [d] [03052] [`anonymous-namespace'::CreateIndexInfo] [p] Index would be opened in binary mode
[2017-04-27 16:47:27.687495] [d] [03052] [`anonymous-namespace'::CreateIndexInfo] [p] Tag "NOV2_ta#", expression "ASCEND(NodeId)+ASCEND(Ordinal)+DESCEND(Version)", filter "NodeId > 0 .AND. .NOT. DELETED()"
[2017-04-27 16:47:27.687495] [d] [03052] [`anonymous-namespace'::CreateIndexInfo] [p] Tag "SlcHsh_ta#", expression "SUBSTR(SliceHash,1,4)", filter "NodeId > 0 .AND. .NOT. DELETED()"
[2017-04-27 16:47:27.687495] [d] [03052] [`anonymous-namespace'::CreateIndexInfo] [p] Tag "Cab2_ta#", expression "ASCEND(CabinetId)", filter "NodeId > 0 .AND. .NOT. DELETED()"
[2017-04-27 16:47:27.723513] [d] [03052] [`anonymous-namespace'::DetermineIndexMode] [sca] Index tag "NOV2_TA#" uses binary naming convention
[2017-04-27 16:47:27.731517] [d] [03052] [`anonymous-namespace'::CreateIndexInfo] [sca] Index would be opened in binary mode
[2017-04-27 16:47:27.731517] [d] [03052] [`anonymous-namespace'::CreateIndexInfo] [sca] Tag "NOV2_ta#", expression "ASCEND(NodeId)+ASCEND(Ordinal)+ASCEND(Version)", filter "NodeId > 0 .AND. .NOT. DELETED()"
[2017-04-27 16:47:27.834569] [d] [03052] [CodeBase] File Find Error Opening File (-64) file4open (90615) [E:\KPN_BR\reg\sc.x] [] []
[2017-04-27 16:47:27.834569] [d] [03052] [`anonymous-namespace'::DetermineIndexMode] [sc] Index file could not be opened (-64)
[2017-04-27 16:47:27.834569] [d] [03052] [`anonymous-namespace'::CreateIndexInfo] [sc] Index would be opened in binary mode
[2017-04-27 16:47:27.834569] [d] [03052] [`anonymous-namespace'::CreateIndexInfo] [sc] Tag "NOV2_ta#", expression "ASCEND(NodeId)+ASCEND(Ordinal)+DESCEND(Version)", filter "NodeId > 0 .AND. .NOT. DELETED()"
[2017-04-27 16:47:27.834569] [d] [03052] [`anonymous-namespace'::CreateIndexInfo] [sc] Tag "SlcHsh_ta#", expression "SUBSTR(SliceHash,1,4)", filter "NodeId > 0 .AND. .NOT. DELETED()"
[2017-04-27 16:47:27.834569] [d] [03052] [`anonymous-namespace'::CreateIndexInfo] [sc] Tag "Cab2_ta#", expression "ASCEND(CabinetId)", filter "NodeId > 0 .AND. .NOT. DELETED()"
[2017-04-27 16:47:27.834569] [d] [03052] [CodeBase] File Find Error Opening File (-64) file4open (90615) [E:\KPN_BR\reg\sc.x] [] []
------------- >8 --------------- >8 ---------------

Zodra dit gelukt is, kan ik weer backups maken. Maar daar moet ik dus wel geduld voor hebben...

Ik heb een theorie wat er aan de hand is. Wellicht kan Tim informeren bij IASO of dit klopt en of er iets aan gedaan kan worden...

Volgens de log bestanden is op de achtergrond de service bezig om mijn index bestanden op te schonen: de log file staat dan namelijk vol met meldingen over "[Cleaning]" en "slice is obsolete" en dit blijft maar doorgaan. Maar de files sc.d en sc.x worden nooit kleiner. Mijn theorie is dat het sc.x bestand door het opschoon proces niet goed wordt afgesloten als ik mijn windows afsluit en dat daardoor telkens de index weer corrupt lijkt te zijn als mijn machine weer opgestart wordt. Kan IASO er misschien voor zorgen dat het opschoonproces de bestanden in een consistente staat afsluit wanneer Windows wordt afgesloten?

Reageer