14
Festplatte gelöscht. Kann man die wiederherstellen?
Guten Abend.
Ich habe folgendes Problem.
Ich benutze eine VmWare ESXi Server in version 4.0.
Dort habe ich eine VM laufen, welche laut den Einstellungen
eine Festplatte (GarExc-000001.vmdk) benutzt.
Da der Datenspeicher nun voll war
Meldung 1:
"Meldung zu GAREXC: There is no more space for
virtual disk GarExc-000001.vmdk. You may be
able to continue this session by freeing disk space
on the relevant partition, and clicking Retry.
Otherwise, click Abort to terminate this session.
Info
08.06.2010 20:09:36
User"
und die VM nicht mehr booteten wollte, dachte ich mir lösche ich die nicht benötigten Snapshots, die in der VM enthalten waren.
Nachdem die Snapshots entfernt waren reichte der Platz wieder nicht. Auffällig waren noch zwei weitere virtuelle Festplatten (GarExc-000003.vmdk und GarExc-000005.vmdk) im Datenspeicher enthalten, welche ich dann bekloppterweise löschte.
Diese werden nun aber zum Start der VM benötigt.
Gibt es irgendeine Möglichkeit die gelöschten Platten wiederherzustellen?
Danke für Eure Hilfe.
Gruß anfaengerglueck
Ich habe folgendes Problem.
Ich benutze eine VmWare ESXi Server in version 4.0.
Dort habe ich eine VM laufen, welche laut den Einstellungen
Da der Datenspeicher nun voll war
Meldung 1:
"Meldung zu GAREXC: There is no more space for
virtual disk GarExc-000001.vmdk. You may be
able to continue this session by freeing disk space
on the relevant partition, and clicking Retry.
Otherwise, click Abort to terminate this session.
Info
08.06.2010 20:09:36
User"
und die VM nicht mehr booteten wollte, dachte ich mir lösche ich die nicht benötigten Snapshots, die in der VM enthalten waren.
Nachdem die Snapshots entfernt waren reichte der Platz wieder nicht. Auffällig waren noch zwei weitere virtuelle Festplatten (GarExc-000003.vmdk und GarExc-000005.vmdk) im Datenspeicher enthalten, welche ich dann bekloppterweise löschte.
Diese werden nun aber zum Start der VM benötigt.
Gibt es irgendeine Möglichkeit die gelöschten Platten wiederherzustellen?
Danke für Eure Hilfe.
Gruß anfaengerglueck
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 144421
Url: https://administrator.de/contentid/144421
Ausgedruckt am: 26.11.2024 um 06:11 Uhr
14 Kommentare
Neuester Kommentar
Hallo
Hast du zufällig eine Kopie, image oder ähnliches?
Sonst geht bei physikalischen medien Recuva von Piriform recht gut
Was war eigentlich drauf?
Gruss
Switcher
Hast du zufällig eine Kopie, image oder ähnliches?
Sonst geht bei physikalischen medien Recuva von Piriform recht gut
Was war eigentlich drauf?
Gruss
Switcher
Sicherung von vor 2 Wochen vorhanden als Acronis Image.
Aber was meinst Du mit bei physikalischen Medien. Die vmdk sind doch virtuelle Platten...da greift das Tool doch gar nicht...
Gruß anfaengerglueck
Aber was meinst Du mit bei physikalischen Medien. Die vmdk sind doch virtuelle Platten...da greift das Tool doch gar nicht...
Gruß anfaengerglueck
Hi
beim großen ESX4 ist dafür das DataRecovery mit dabei (ist eine eigene CentOS VM Session welche direkten Zugriff auf den ESX bietet), du du Linux mit der VMFS drauf hast (erstes hat schon keine guten Recoverychancen, beim zweiten wirds dann echt dunkel). Deine Gar... waren die erweiterten Chunks einer großen VMDK....
Um der Unix lehre zu folgen: klar kann man die wieder bekommen: richtiges Tape einlegen, restore nutzen, da ist sie.
Gruß
Sam
beim großen ESX4 ist dafür das DataRecovery mit dabei (ist eine eigene CentOS VM Session welche direkten Zugriff auf den ESX bietet), du du Linux mit der VMFS drauf hast (erstes hat schon keine guten Recoverychancen, beim zweiten wirds dann echt dunkel). Deine Gar... waren die erweiterten Chunks einer großen VMDK....
Um der Unix lehre zu folgen: klar kann man die wieder bekommen: richtiges Tape einlegen, restore nutzen, da ist sie.
Gruß
Sam
ursprünglichen eintrag zurückgezogen, da thema verfehlt.
Hi
dir ist aufgefallen das der Betroffene einen ESXi im Einsatz hat, also eigenes OS (naja nur ein abgespecktes RHEL5_x64 aber schon sehr eigener Kernel), eigenes Filesystem? Kroll hat solche Fälle bisher immer bei uns abgelehnt (vielleicht boten wir aber nur zu wenig Geld).
Gruß
Sam
dir ist aufgefallen das der Betroffene einen ESXi im Einsatz hat, also eigenes OS (naja nur ein abgespecktes RHEL5_x64 aber schon sehr eigener Kernel), eigenes Filesystem? Kroll hat solche Fälle bisher immer bei uns abgelehnt (vielleicht boten wir aber nur zu wenig Geld).
Gruß
Sam
Hi,
ich kann mich denen, die begriffen haben was Du im Einsatz hast nur anschließen. Das VMFS bietet Dir keine direkte Möglichkeit zur Datei-Wiederherstellung. Es gibt einige Dateien, die man sichern kann, um ein komplett zerstörtes VMFS-Datei-System zu retten, die hätte man aber vorher sichern müssen.
Kurz gesagt: Nein, selbst unter der Service Console des ESX hättest Du verschwindend geringe Chancen.
Zur Vollständigkeit noch, damit Du Dich nicht verrückt machst:
- Mach Dir keine Gedanken um Hintergrund-Defragmentierung. Du hast da nen Hypervisor der macht das nicht. Der Hypervisor benutzt VMFS, das braucht das nicht.
- Recuva ist toll. Für Windows. Falls jemand erklären kann, wie man damit Dateien unter VMFS wiederherstellen kann, immer her damit. Windows kann (soweit ich weiss) auf VMFS nicht mal noch vorhandene Dateien lesen.
ich kann mich denen, die begriffen haben was Du im Einsatz hast nur anschließen. Das VMFS bietet Dir keine direkte Möglichkeit zur Datei-Wiederherstellung. Es gibt einige Dateien, die man sichern kann, um ein komplett zerstörtes VMFS-Datei-System zu retten, die hätte man aber vorher sichern müssen.
Kurz gesagt: Nein, selbst unter der Service Console des ESX hättest Du verschwindend geringe Chancen.
Zur Vollständigkeit noch, damit Du Dich nicht verrückt machst:
- Mach Dir keine Gedanken um Hintergrund-Defragmentierung. Du hast da nen Hypervisor der macht das nicht. Der Hypervisor benutzt VMFS, das braucht das nicht.
- Recuva ist toll. Für Windows. Falls jemand erklären kann, wie man damit Dateien unter VMFS wiederherstellen kann, immer her damit. Windows kann (soweit ich weiss) auf VMFS nicht mal noch vorhandene Dateien lesen.
Also alles Futsch?
Ich werde mir einmal den Hyper-V 2008 R2 als Core Server von Microsoft unter die kleine Lupe nehmen. Der scheint mir eine gute Alternative zu sein.
Denn ich habe des Weiteren festgestellt das der ESXi die vmdk Platten einmal als IDE und dann als SCSI "angebunden" hat. Warum? -> Weiß ich nicht.
Dann habe ich noch SCSI 1:0, 1:1 usw. zur Auswahl, was ich als anfaenger nicht kapiere.
Wie kann die Platte denn als IDE oder SCSI angebunden werden, wenn diese doch nur als Datei auf einem Datenspeicher liegt?
naja ich werde mich wohl noch ein wenig belesen müssen...
Danke für Eure Hilfe!
Gruß anfaengerglueck
Ich werde mir einmal den Hyper-V 2008 R2 als Core Server von Microsoft unter die kleine Lupe nehmen. Der scheint mir eine gute Alternative zu sein.
Denn ich habe des Weiteren festgestellt das der ESXi die vmdk Platten einmal als IDE und dann als SCSI "angebunden" hat. Warum? -> Weiß ich nicht.
Dann habe ich noch SCSI 1:0, 1:1 usw. zur Auswahl, was ich als anfaenger nicht kapiere.
Wie kann die Platte denn als IDE oder SCSI angebunden werden, wenn diese doch nur als Datei auf einem Datenspeicher liegt?
naja ich werde mich wohl noch ein wenig belesen müssen...
Danke für Eure Hilfe!
Gruß anfaengerglueck
Hi
ESX ist ein sog Level1 Hypervisor, sprich enorm Resourcenschonend. Bei Hyper-V trägst du (wie beim VMwareServer auch) ein OS unterdrunter mit; das macht sich enorm auf die Performance und Latenzzeit bemerkbar; NTFS hat auch nur bedingte Systemwiederherstellung; wenn die HD sehr voll ist, werden gelöschte große Dateien sehr schnell zerstört (es reicht ja ein überschriebener Block).
Was du bei dem VMDK hast ist ein File-Filesystem, sprich eine Datei enthält ein binäres ABbild eines typ Filesystems (ähnlich einem 1:1 Abbild/Image); dieses kannst du in die VM auf verschiedene Weise einblenden. IDE ist halt auf max 4 Ports festgenagelt (inkl CD) oder du nutzt SCSI mit seinen 16 Kanälen inkl min 8 LUNs je Kanal (jedes LUN kann eine HD darstellen). Vom Doing her absolut das selbe, aber wesentlich umfangreicher/professioneller.
Gruß
Sam
ESX ist ein sog Level1 Hypervisor, sprich enorm Resourcenschonend. Bei Hyper-V trägst du (wie beim VMwareServer auch) ein OS unterdrunter mit; das macht sich enorm auf die Performance und Latenzzeit bemerkbar; NTFS hat auch nur bedingte Systemwiederherstellung; wenn die HD sehr voll ist, werden gelöschte große Dateien sehr schnell zerstört (es reicht ja ein überschriebener Block).
Was du bei dem VMDK hast ist ein File-Filesystem, sprich eine Datei enthält ein binäres ABbild eines typ Filesystems (ähnlich einem 1:1 Abbild/Image); dieses kannst du in die VM auf verschiedene Weise einblenden. IDE ist halt auf max 4 Ports festgenagelt (inkl CD) oder du nutzt SCSI mit seinen 16 Kanälen inkl min 8 LUNs je Kanal (jedes LUN kann eine HD darstellen). Vom Doing her absolut das selbe, aber wesentlich umfangreicher/professioneller.
Gruß
Sam
Meinte ich ja...
Ich weiss nicht, ob es bei virtuellen platten geht, könnte aber
Gruss
Swticher
Ich weiss nicht, ob es bei virtuellen platten geht, könnte aber
Gruss
Swticher
Danke für die wirklich tolle Beschreibung. Daher ist es also immer ratsam SCSI (zumindest bei den Platten) zu wählen?
Danke.
Gruß anfaengerglueck
PS: Besteht eigentlich die Möglichkeit von einem Gast aus auf den Datenspeicher des ESXi Servers zuzugreifen? Das geht ja beim Hyper-V per \\server\c$ zum Beipiel ganz leicht...
Danke.
Gruß anfaengerglueck
PS: Besteht eigentlich die Möglichkeit von einem Gast aus auf den Datenspeicher des ESXi Servers zuzugreifen? Das geht ja beim Hyper-V per \\server\c$ zum Beipiel ganz leicht...
Hi
nein, dem ESXi fehlt im Vergleich zum ESX eine Shell, daher NEIN. Beim ESX läßt sich sogar Samba einrichten (absolut unsinnig..), aber NFS wäre möglich
Gruß
Sam
nein, dem ESXi fehlt im Vergleich zum ESX eine Shell, daher NEIN. Beim ESX läßt sich sogar Samba einrichten (absolut unsinnig..), aber NFS wäre möglich
Gruß
Sam
Also nochmals vielen Dank für Eure Hilfe!
Ich werde den Thread dann heute Abend schließen, insofern keiner mehr etwas hinzuzufügen hat.
Gruß anfaengerglueck
Ich werde den Thread dann heute Abend schließen, insofern keiner mehr etwas hinzuzufügen hat.
Gruß anfaengerglueck
Hallo,
ich hatte einen Crash im RAID-0 eines VMFS Datenstores. Es kammen Fehler (die ich leider auf einen anderen Rechner kopiert habe), die etwas von Unerreichbarkeit der Platten oder des Controllers meldeten. Eine Festplatte scheint sich verabscheidet zu haben - liegt wohl an den 35-42C° im Serverraum. Im Controller-Menü findet man nur "FAILED" zu der Platte.
Wiederherstellung (RAID+VMFS) brauche ich also gar nicht erst versuchen, richtig?
Gibt es eigentlich etwas neues an VMFS-Treibern für Win oder Linux außer dem einen Java-App (http://code.google.com/p/vmfs/) ?
Grüße und Dank!
ich hatte einen Crash im RAID-0 eines VMFS Datenstores. Es kammen Fehler (die ich leider auf einen anderen Rechner kopiert habe), die etwas von Unerreichbarkeit der Platten oder des Controllers meldeten. Eine Festplatte scheint sich verabscheidet zu haben - liegt wohl an den 35-42C° im Serverraum. Im Controller-Menü findet man nur "FAILED" zu der Platte.
Wiederherstellung (RAID+VMFS) brauche ich also gar nicht erst versuchen, richtig?
Gibt es eigentlich etwas neues an VMFS-Treibern für Win oder Linux außer dem einen Java-App (http://code.google.com/p/vmfs/) ?
Grüße und Dank!
Hi
VMFS ist zwar gut dokumentiert aber wie die typischen Unix FS: sobald der inode beschädigt oder weg ist sieht's düster aus. Da ist viel Handarbeit gefordert. Bei moderneren FS wie JFS/XFS/Raiser sieht es selbst für Datenrecoverer recht einsam aus.
Die Ursache von eurem Crash ist aber einfach dumm ein R0 zu nutzen; mit R1+0 wäret ihr genauso performant gewesen und wärt akzeptabel sicher. Da ich oft genug mit solchen Fällen zu tun habe (ihr seid ja nicht die einzigen auf dem trip) ist erste Variante:
a) HDs auf funktionierende mit ddrescue rüber bringen
b) RAID Controller (hoffentlich ein dummer dann geht's; intelligente merken den Tausch und haben dann evtl eine recovery Funktion für zerstörte Arrays dabei; Areca und ICP=Adaptec sind da hervorstechend).
Obwohl HDs es recht gerne kalt mögen, sind die 42° nicht schlimm; Server HDs sind meist bis 60° zertifiziert. Sofern aber euer Server bei weit höheren Temps intern arbeiten muß hoffe ich das ihr keine Tapes + Laufwerke dort verwendet, da diese bei 45° ihre Garantie verfallen lassen (das ist schön nachvollziehbar im NVRAM gespeichert) und sehr schnell altern...
Gruß
Sam
VMFS ist zwar gut dokumentiert aber wie die typischen Unix FS: sobald der inode beschädigt oder weg ist sieht's düster aus. Da ist viel Handarbeit gefordert. Bei moderneren FS wie JFS/XFS/Raiser sieht es selbst für Datenrecoverer recht einsam aus.
Die Ursache von eurem Crash ist aber einfach dumm ein R0 zu nutzen; mit R1+0 wäret ihr genauso performant gewesen und wärt akzeptabel sicher. Da ich oft genug mit solchen Fällen zu tun habe (ihr seid ja nicht die einzigen auf dem trip) ist erste Variante:
a) HDs auf funktionierende mit ddrescue rüber bringen
b) RAID Controller (hoffentlich ein dummer dann geht's; intelligente merken den Tausch und haben dann evtl eine recovery Funktion für zerstörte Arrays dabei; Areca und ICP=Adaptec sind da hervorstechend).
Obwohl HDs es recht gerne kalt mögen, sind die 42° nicht schlimm; Server HDs sind meist bis 60° zertifiziert. Sofern aber euer Server bei weit höheren Temps intern arbeiten muß hoffe ich das ihr keine Tapes + Laufwerke dort verwendet, da diese bei 45° ihre Garantie verfallen lassen (das ist schön nachvollziehbar im NVRAM gespeichert) und sehr schnell altern...
Gruß
Sam
