Collega's,
Iemand toevallig beschikbaar voor een corrupt filesysteem te herstellen op een Ubuntu machine ? Vrij dringend ..
Graag even eventuele ervaringen vermelden !
Collega's,
Iemand toevallig beschikbaar voor een corrupt filesysteem te herstellen op een Ubuntu machine ? Vrij dringend ..
Graag even eventuele ervaringen vermelden !
Xenius.be | Our solutions, our products, your success !
Wat voor filesystem betreft het?
https://www.openworx.nl | Cloud diensten - IT - ERP - Odoo Hosting
Wellicht handig om naast de FS informatie ook uit te leggen wat er (hoogstwaarschijnlijk) is gebeurd en wat je al zelf gedaan hebt.
Die stappen zijn leuk om van te leren en ervaringen mee uit te wisselen (Het doel van dit forum zeg maar)
Het betreft hier een Zimbra server, met een groot aantal mailboxen op, ben er zelf uitgeraakt maar de Zimbra installatie is wel omzeep nu de .msg blobs proberen te recoveren op een ander systeem..
Wat er is gebeurt..
-------------------------
Klant heeft bij ons een oude Zimbra server 7.2.7, overgekomen uit een overname, geen stabiele onderliggende hardware en veroudert. Aangezien deze als dedicated server bij ons staat hebben we de klant een voorstel voor een nieuwe server gedaan en het voorstel om de klant ook te helpen bij de migratie.. (beter niet gedaan :-) ) ..
Op deze nieuwe server hadden we ESXi geinstalleerd met daarop een virtuele machine , initieel was deze gebruikt om een aantal keer te testen en het scenario te doorlopen waardoor ESXi wel handig was.. snapshotje na clean install en je staat zo terug waar je was.. Afgelopen weekend hebben we dan ook de finale migratie gedaan en deze is succesvol verlopen. Echter was ik vergeten dat er nog een snapshot op de machine stond , op zich niet zo'n groot probleem maar door het gigantisch aantal I/O activiteit groeide die snapshot file ook gestaag door en kwam het disk usage op de datastore in gevaar..
Allemaal geen rocket science en ik verwijderen gisteren avond ook zonder verpinken die snapshots ze waren niet meer nodig en snapshots verwijderen dat doen we continu.. Tot hier geen probleem
Omdat het nogal een grote snapshot was die er al enige dagen stond raad ESXi ook aan om de disken te consolideren, geen probleem gisteren avond start ik ook meteen een disk consolidatie. Na een half uur stopt de consolidate met de melding dat er te weinig disk space op de disk is.
Ik stel er mij ook niet direct vragen bij en we mogen de vm van de klant uitzetten om hem dan te consolideren, deze consolidate neemt ettelijke uren in beslag..
Wanneer ik afgelopen nacht de VM terug opstartte merkte ik tijdens de boot al meteen dat er iets niet juist was. Het / volume was RO gemount en tijdens het booten kwam fsck meteen te proppen dat er iets niet juist was.. Kortom: het filesysteem was kapot.. Als ik een ls -l deed op /opt/zimbra dan kreeg ik een hele hoop I/O errors op de zimbra store en logs folders.. niet goed
UIteindelijk geboot in rescue mode en daar via e2fsck de nodige blokken kunnen repairen via de overige superblocks, na een paar uur runnen en repairen startte de server wel mooi op, ik kon opnieuw een ls -l doen op de hierboven genoemde folders zonder problemen dus ik zeer blij.. Echter bij een zmcontrol status bleek dat een aantal services waaronder mailbox niet gestart waren omdat mysql niet draaide.. Deze kreeg ik ook niet gestart, bij het bekijken van de log files bleek dat er een hele hoop tables kapot zijn waarop een crash recovery niet mogelijk is..
Heb dan even een case bij Zimbra geopend hiervoor en conclusie daaruit is dat het volledig naar de H*L is en er niet meer veel van te redden valt..
We zijn van de belangrijkste mailboxen de *.MSG blob files aan het exporteren en deze dan in restore mailboxen aan het kijlen op een tijdelijke omgeving...
Wat er nu echt gebeurt is en waarom die corruptie is opgetreden is mij een vraag, onderliggende hardware problemen sluit ik uit want de hypervisor die ook op dezelfde disken draait draait perfect en geeft geen kick..
Heeft iemand dit nog al eens gezien ? Os is trouwens Ubuntu 14.04.
Xenius.be | Our solutions, our products, your success !
Tja, ... niet om vervelend te zijn, maar dat is inmiddels niet meer te repareren.
Als je snapshots consolideert en tijdens de consolidatie je uit vrije diskruimte loopt dan heb je een vrij serieus probleem.
Vanaf dat moment heb je een expert nodig om dit te herstellen en kansen op volledig herstel zijn dan al niet zo heel groot meer.
Als je dan zelf door gaat met automatische herstel acties dan komt het er eigenlijk op neer dat je het zal moeten doen met wat daaruit komt.
Dus helaas, in mijn opinie niet meer te herstellen, je zal terug moeten naar de laatste backup.
Overigens, wat je nog kan proberen is om een vSphere data recovery specialist in the schakelen, misschien dat die nog ergens een kansje ziet.
Op dit moment heb je vrij weinig aan mensen hier op het forum vrees ik.
De beste daarin - mijn mening - is Ulli, hier wat meer info:
https://communities.vmware.com/people/continuum
(stuur hem een bericht via skype)
Laatst gewijzigd door wila; 22/09/16 om 14:58.