!!! NOTFALL !!! -flat.vmdk Dateien weg

[ente]

Hallo,

habe ein riesiges Problem zu lösen ... wollte eigentlich nur einen virtuellen Server von einem vSphere (ESXi 4.0) auf einen anderen Host mit Veeam Backup und FastSCP 3.01 verschieben ... dachte zuerst die kleinen Dateien und dann die großen ... nach dem das Verschieben der kleinen (zusammen ca. 500 kb) fertig war, waren auch die großen weg.
Ich bin völlig erschrocken ... was tun, natürlich kein Image oder Backup des Servers gemacht ... jetzt ist Polen offen ...

Hat jemand einen Tip, wie ich wieder an die VMDK´s rankommen kann?
Bin einfach mit meinen Latein am Ende ...

Gruß Heiko
dervölligaufgeregtistundzittert

[irix]

Moin,

nimm erstmal Baldrian und beruhige dich. Dann oeffnest du die Konsole ueber die "unsupported" Methode und und guckst was in /vmfs/volumes/NAME_DES_DES/vmname/ noch drin steht und pastest mal ein "ls -al" hier rein.

Gruss
Joerg

[ente]

Vielen Dank Jörg für Deine schnelle Antwort,

kann ich das auch per remote machen, bin nicht in der Firma?
Am liebsten würde ich mit jemanden telefonieren wollen ... bin zu aufgeregt.
Ich habe hier fast die gleiche Maschine (siehe Signatur) zum üben/testen der Schritte.
Notfalls muß ich morgen früh um ca. 6:45 dort auf der Matte stehen und den Rest lokal machen.
Was mir noch ein wenig Hoffnung gibt:
Der Datastore sagt mir, das noch 42GB frei sind von 232GB - was nach Speicheraktualisierung auf 212GB frei, angestiegen ist. Kein gutes Omen ...
Bin für Tools, die vmfs3-FS-System wiederherstellen können dankbar ...
Also Tastatur und Monitor mitnehmen und mich dort vor dem Rack setzen ...
oh Gott, die reißen mir den Kopf ab ...

Gruß Heiko

[irix]

Wenn bereits SSH freigeschaltet ist oder der Server eine Remote Karte hat dann geht das auch aus der Ferne.

Allerdings wenn er nun schon freien Speicher anzeigt sinken die Chancen erstmal gewaltig,. Evtl solltest du mit Ulli Kontakt aufnehmen. Schau mal unter http://www.sanbarrow.com/sickbay.html nach und fuelle den Help-Request aus und mail ihm das. Hier im Forum hat er den Namen "continuum".

Gruss
Joerg

[ente]

Danke Jörg,

genau das habe ich schon getan, ich fahre jetzt in die Firma und melde mich vom Rack aus wieder ... habe ne Knoppix mit und diverse ander Dinge im Gepäck, ich vermute mal es wird auf Kroll hinauslaufen ...
Mal sehen, wenn Ulli sich meldet, die Hoffnung stirbt ja bekanntlich zuletzt ...
Firma ist auch schon informiert ... Ehrlichkeit ist wichtig ... die Worte vom Chef ...
Bis denne

Gruß Heiko
der1StundeSchlafhatte

[deathrow]

wollte eigentlich nur einen virtuellen Server von einem vSphere (ESXi 4.0) auf einen anderen Host

Wolltest Du den Host wechseln oder das Storage? Oder beides Gleichzeitig?

[ente]

so, ich bin vorOrt ... habe jetzt SSH und Telnet aktiviert ...

wollte den kompletten Host wechseln, welcher natürlich auch den Storage beinhaltet.
Ist halt ne kleine Firma - Hardwareplanung sieht so aus:
ganz alter echter Server Dell PE-sc420 (Service-TAG: , suboptimal eingerichtet, keine Domäne usw.)
neuer Server bei Dell bestellt PE T610 (Service-TAG: ) mit ordentlicher Hardwareausstattung und voller VM-Wareunterstützung.
32GB RAM, 8x 160GB HDD davon sind schon 2 ersetzt worden durch 1TB (Spiegelsatz)
die übrigen 6 HD´s sind als RAID5 konfiguriert, da sollte das System drauf.
Die ganze Technik hängt an einer SMART-UPS SUA3000RM2I
während der Wartezeit auf dem neuen Server und der Büroumbaumaßnahmen habe ich dem Kunden einen Leihhost hingestellt: Dell Precision 470 mit 6GB RAM und zwei 250GB HD´s (einzeln konfiguriert)
Habe dann mit dem Converter den alten echten Server virtualisiert und im ESXi 4.0 weiterlaufen gelassen ...
das ist schon ne Weile her ... der neue Server kam und wurde mit dem ESXi4.0 auf dem integrierten SD-Modul eingerichtet, hat alles super funktioniert
Auf dem neuen Host sollte dann alles rauf.
Darauf habe ich dann eine VM mit XPpro zur Verwaltung / Adminmaschine installiert.
Dann noch einen virtuellen W2K3Std-Srv inst. der als Datenspeicher dienen soll.
jetzt sollte eigentlich der Leihhost abgeholt werden (natürlich ohne Daten) ... also sollte per VeeamBackup&FastSCP 3.01 der Inhalt des gesamten alten Host auf den neuen übertragen werden ... das waren 3 Win XPpro und 1 W2k3Std.
Die WinXPpro haben problemlos geklappt, aber bei dem W2k3 ist was schief gelaufen.
Hatte noch vor der ganzen Aktion im Gast eine Defragmentierung der virtuellen Platten durchgeführt, was auch geklappt hatte.
Habe im Gastordner die Dateien umbenannt, weil sie auf dem neuen Host der dortigen Ordnung entsprechen sollten (alt: vBaier-S04 neu: 04 vBaier-S04)
Natürlich habe ich die Namensangaben in den entsprechenden Konfig-Dateien auch geändert/angepaßt. Dann zum Schluss den Ordner umbenannt.
Ich habe zuerst die kleinen Dateien aus dem Gast-Ordner verschoben, was problemlos geklappt hat. Nach dem er fertig war, hatte ich mich nur gewundert, das die *-flat.vmdk Dateien auch weg waren (20GB, 70GB, 100GB=die wichtigste, wobei darin bloß ca. 10GB Daten lagen = Name: herzstueck-LW-F-flat.vmdk)

Hier mal der Bildschirminhalt nach Jörg seinen Befehl:

Code: Alles auswählen

login as: root
root@192.168.0.198's password:
You have activated Tech Support Mode.
...
~ # ls
altbootbank    etc            pkgdb.tgz      scratch        var
bin            lib            proc           store          vmfs
bootbank       locker         productLocker  tmp            vmupgrade
dev            opt            sbin           usr
~ # cd vmfs
/vmfs # cd volumes
/vmfs/volumes # ls
4a83e936-cfd8e651-255a-000f1f86f755  Hypervisor2
4a83e938-9abd0224-3e86-000f1f86f755  Hypervisor3
4a83e939-de1baff8-acfd-000f1f86f755  datastore1
53cc92eb-5326110e-6194-a0c34fc4fe34  datastore2
7cfc25ed-9e7abe3b-92b0-4b92d4cdeb1e  efd8efe3-03bc1cbf-15e0-080efd9e7379
Hypervisor1
/vmfs/volumes # cd datastore2
/vmfs/volumes/4a83e939-de1baff8-acfd-000f1f86f755 # ls
Festplatten   Netzwerk old
/vmfs/volumes/4a83e939-de1baff8-acfd-000f1f86f755 # cd "Netzwerk old"
/vmfs/volumes/4a83e939-de1baff8-acfd-000f1f86f755/Netzwerk old # ls
vBaier-S04
/vmfs/volumes/4a83e939-de1baff8-acfd-000f1f86f755/Netzwerk old # cd "vBaier-S04"/vmfs/volumes/4a83e939-de1baff8-acfd-000f1f86f755/Netzwerk old/vBaier-S04 # ls
herzstueck-LW-F.vmdk  vBaier-S04.vmxf       vmware-13.log
vBaier-S04.nvram      vBaier-S04_1.vmdk     vmware-14.log
vBaier-S04.vmdk       vmware-10.log         vmware-9.log
vBaier-S04.vmsd       vmware-11.log         vmware.log
vBaier-S04.vmx        vmware-12.log
/vmfs/volumes/4a83e939-de1baff8-acfd-000f1f86f755/Netzwerk old/vBaier-S04 # ls -al
drwxr-xr-x    1 root     root               2240 Oct  7 22:17 .
drwxr-xr-x    1 root     root                420 Oct  8 01:02 ..
-rw-------    1 root     root                476 Oct  7 20:42 herzstueck-LW-F.vmdk
-rw-------    1 root     root               8684 Oct  7 20:42 vBaier-S04.nvram
-rw-------    1 root     root                470 Oct  7 22:11 vBaier-S04.vmdk
-rw-------    1 root     root                  0 Oct  7 20:42 vBaier-S04.vmsd
-rw-------    1 root     root               2972 Oct  7 22:31 vBaier-S04.vmx
-rw-------    1 root     root                268 Oct  7 22:17 vBaier-S04.vmxf
-rw-------    1 root     root                452 Oct  7 22:14 vBaier-S04_1.vmdk
-rw-------    1 root     root              62889 Oct  7 20:42 vmware-10.log
-rw-------    1 root     root              57656 Oct  7 20:42 vmware-11.log
-rw-------    1 root     root              87027 Oct  7 20:42 vmware-12.log
-rw-r--r--    1 root     root              22406 Oct  7 22:04 vmware-13.log
-rw-r--r--    1 root     root              19858 Oct  7 22:09 vmware-14.log
-rw-------    1 root     root              90689 Oct  7 20:42 vmware-9.log
-rw-r--r--    1 root     root              21986 Oct  7 22:17 vmware.log
/vmfs/volumes/4a83e939-de1baff8-acfd-000f1f86f755/Netzwerk old/vBaier-S04 #


so gerade hat Ulli angerufen, ich baue jetzt hier die Kiste ab und nimm sie mit,

ich werde nachher diesen Post noch ergänzen ... muß erst mal mein Kinder in die Kita schaffen ...

Gruß Heiko

[continuum]

Heiko - ich bin jetzt wieder zuhause

[barabone]

Heiko - ich bin jetzt wieder zuhause

mich würde mal interessieren wie ihr dieses Problem lösen konntet.



Gruß
André

[continuum]

Leider haben wir derzeit noch keine Loesung - auch eine Recovery-Firma die sich den Fall angesehen hat hat aufgegeben.

Wir koennen nur teilweise Roh-daten recovern - das was wir am dringendsten suchten ist (noch ?) nicht dabei

Falls sich noch was ergibt poste ich es hier

[McStarfighter]

Mensch, da muß ja echt was im Argen liegen ...

Mal ernsthaft: Was ist denn (in kurzen Worten) passiert? Ich habe das nicht so ganz verstanden. Und ich würde doch gerne auch mal dazulernen ...

[continuum]

Oh mann - das ist sehr schwierig.

Ein obskures Problem mit Veeam hat dazu gefuehrt das drei *-flat.vmdks aus dem VMFS-journal verschwunden sind innerhalb Sekunden - OHNE das der user irgendeine Loeschaktion veranlasst hat.

Wir haben uebrigens mittlerweile erste Spuren von den wichtigen Dateien - wissen aber noch nicht ob diese noch verwertbar sind

[McStarfighter]

Oh ...

Das mit Veeam Backup scheint ja doch ein mehr als ernsthaftes Problem zu sein. Da hat wohl die Qualitätskontrolle geschlafen ...

[maxmarschall]

Das klingt echt schrecklich, und auch wenns DIR nicht mehr hilft - kleiner Tip aus der Praxis:

- Ich kopiere alles direkt von der CLI von einem zum anderen Datastore über SCP bzw. wenns möglich ist (gleiches SAN) dann per cp von einem zum anderen Datastore.

Viel Glück beim weiteren Recovery (und wenns dich tröstet - das wäre dann wohl jedem passiert).

Gruß...
Max

[Dayworker]

Das klingt echt schrecklich, und auch wenns DIR nicht mehr hilft - kleiner Tip aus der Praxis:

- Ich kopiere alles direkt von der CLI von einem zum anderen Datastore über SCP bzw. wenns möglich ist (gleiches SAN) dann per cp von einem zum anderen Datastore.

Viel Glück beim weiteren Recovery (und wenns dich tröstet - das wäre dann wohl jedem passiert).

Gruß...
Max

Er hatte halt FastSCP verwendet und dann war Feierabend.

Weder im VMTN noch bei Veeam gibts bisher eine Lösung. gostev hat wohl einige Test gemacht und bisher keine Probleme gehabt.

[continuum]

gostev hat wohl einige Test gemacht und bisher keine Probleme gehabt.

Hehe - als ich das im Veeam forum gepostet hatte - hat gostev noch gesagt dass er von einer Nutzung von Fastscp bei ESX4 i abraet ...
Als er dann sah dass ich das Problem auch im VMTN gepostet hatte - hiess es dann auf einmal "uns ist kein Problem bekannt"

Was ich mir dabei denke behalte ich jetzt mal fuer mich

[Dayworker]

Please make sure you have the latest FastSCP release (3.0.1 build 266 released on July 7th) - as previous versions of FastSCP do not support vSphere at all. To lookup build number, right-click the VeeamShell.exe file, go to Properties and see the full build number on the Version tab.

Naja. Hast du in der Zwischenzeit mal die genaue Veeam-Version rausfinden können?
Nicht das man gostev nachher doch noch eine ältere Version mitteilen muß, als das gewünschte Release inklusive Build-Version...

[continuum]

Na ja - eine aeltere Version als 3.0.1 wuerde ja gar nicht funktionieren ...
Also es ging schon um die 3.0.1 version

[Dayworker]

Mir gehts ja nur darum, daß er das Build 266 extra erwähnt. Das assoziiert für mich, daß es mehrere Builds an diesem Tag gab.
Fände ich zwar dumm, weil irgendwer muß dann bei den ja gepennt und das falsche in den Downloadbereich gestellt haben. Leider bekommt man das immer nur schlecht heraus, Verzeichnisauflistung über FTP ist meistens gesperrt.