VMware-Forum

Hallo zusammen,

ich brauche dringend die Hilfe eines erfahrenen VM-Ware Spezialisten. Habe leider nur ein Halbwissen. Wir setzen VM-Ware vSphere 4 Essentials Plus bei einem Kunden ein. Als Backup-Programm benutzen wir Acronis B&R 10 Virtual Edition. Dies lief eigentlich recht stabil, aber nun war ein Kollege im Urlaub, der das Backup immer überwacht hat und es ist deshalb nicht aufgefallen, dass die Sicherung einer VM (Acronis benutzt die Schnittstelle zu VMWare Consolidated Backup) seit Tagen nicht richtig funktionierte. Dann fiel das Ganze auf, weil zwei VMs nicht mehr ordentlich starteten. Grund: Der Datenspeicher, auf welchem die log-Files etc. liegen, war "übergelaufen". Dies wiederum lag daran, dass es von der betreffenden VM lauter Snapshots gab, die Acronis offenbar erzeugt hat. Deshalb startete auch schon eine zweite VM nicht mehr. In unserer Not haben wir dann auf dem Datenspeicher versucht, die von den Snaphots erzeugten vmdk-files zu löschen. Bei den meisten kam eine Fehlermeldung (Datei kann nicht gelöscht werden), aber bei zweien hat es dann doch geklappt und es war wieder ein bisschen Speicherplatz frei. Anschließend haben wir auch im Snapshot-Manager die Snapshots entfernt.

Das Problem ist nun, dass die betreffende VM nicht mehr startet. Fehlermeldung lautet: "Zugriff auf eine Datei <unspecified filename> nicht möglich, weil sie gesperrt ist." Sicherlich will er auf eine der Snapshot vmdks zugreifen, die wir dämlicherweise gelöscht haben. Gibt es noch irgendeine Möglichkeit, die Maschine wieder zum Laufen zu bringen? Das letzte Backup ist nämlich über eine Woche alt, während die noch vorhandenen "ursprünglichen" VMDK-Files ein Datum vom 17.08. aufweisen.

Wir sind für jeden Tipp dankbar!

ACHTUNG!

auf KEINEN Fall die VM nochmal starten. Poste mal die Dateiliste mit Größen- und Datumsangaben und die *.vmx und verlinke mal die vmware.log auf ifile.it (Filehoster). Und dann warten wir gemeinsam auf Ulli aka continuum.

Hier noch einen Link: http://vmware-forum.de/viewtopic.php?p=104661#104661

Da du von Essential Plus gesprochen hast wurde der VMware Support mit gekauft und mit etwas Glueck ist dieser auch nach Ablauf verlaengert worden oder aber noch Aktiv. Somit ist das die erste Anlaufadresse fuer euch!

Ansonnsten ist der Koenig aller Snapshotrettungen unter http://www.sanbarrow.com/sickbay.html zu erreichen und das ist unser Forenmitglied Ulli aka continuum.

- Die Fehlermeldung fuer fehlende Snaps und vDisks ist eine andere
- Die Anzeige im Snapshotmanager ist mit Vorsicht zugeniessen und man sollte den ESX(i) bzw. das Filesystem befragen. Aber das Thema hatten wir nun schon zuoft
- Damit euch ein Supporter ueberhaupt helfen kann macht schon mal SSH auf bzw. seht zu das die RemoteKonsole der Serverhardware fuer euch erreichbar ist.
- Die Info ob es ein ESX bzw. ESXi ist waere Hilfreich obwohl du hier im ESX Forum gepostet hast

Sofern man die Kisten wieder zum fliegen bringt koennen wir gerne hinterher darueber reden was die richtige Vorgehensweise gewesen waere bzw. wie sich sowas in Zukunft verhinder laesst.

Gruss
Joerg

Danke für eure schnellen ersten Antworten!

Nach dem ersten schnellen Überfliegen der sickbay-Seite, gehe ich davon aus, dass es sich um eine Broken CID-chain handelt, da wir teilweise manuell gelöscht haben.

Hier die Dateiliste:
http://ifile.it/inlgy1w

Und die älteste Log:
http://ifile.it/s01vl8h

Leider haben wir die VM vor dem Posting hier schon einige Male neugestartet. Fürchte deshalb, dass die log schon unbrauchbar ist...

Weiterhin hatten wir schon mal in der VM die Platten ungemountet und wieder gemountet, was bestimmt auch nicht so clever war. Aber man probiert leider erst selbst soviel herum, bevor man sich an ein Forum wendet. Den Fehler macht man nur einmal. Ich war leider auch der felsenfesten Überzeugung, dass den Basedisks nichts passiert ist und die Snapshots nicht gebraucht werden - wusste nichtmal, dass Acronis welche erzeugt, denn darauf wird man ja nicht hingewiesen. ISt schon Mist, wenn ein Programm, welches eigentlich zur DatenSICHERUNG dient, letztendlich mitverschuldet, dass es zu DatenVERLUST kommt.

Achso, noch vergessen: Es handelt sich um einen ESX 4.0 U1 Host. Puuh, SSH freischalten und so weiter, keinen Schimmer, wie und wo...

Die Bilder von Dateilisten mittels Datastorebrowser sind irrelevant da dieser nur einer Interpretation anzeigt und nicht die Wirklichkeit. Hier wurde einmal der schoene Spruch gepraegt "Wenn der Datastorebrowser etwas richtig anzeigt dann ist etwas kaputt".

Entweder wurde der SSH Zugang fuer Root gleich nach der Installation freigeschaltet oder aber es wurde hoffentlich ein Servicebenutzer mit angelegt welcher sich dann per SSH und seinem Benutzernamen einloggen darf. Mittels "su -" wird er dann "root" und kann im Datastatore auf Datei- und Verzeichnisebene nach dem Rechten sehen.

Bei Sickbay gibts eine Textdatei welche du ausfuellen darfst um die dem Ulli zukommen zulassen.

Frage: Was ist mit dem VMware Support? Wenn ihr Partner seit koennt ihr auch auf euren Namen den Call aufmachen und muesst halt sagen das euer VCP im Urlaub ist und das die "Huette brennt"

Gruss
Joerg

Hallo Joerg,

danke erneut für deine Antwort. Danke für den Tipp mit dem Supportformular bei Sickbay. Habe inzwischen auch einen Support-Case bei VMWare eröffnet.

Mit dem SSH-Zugang klappts leider noch nicht. Per putty kann ich zwar den Host erreichen, aber wenn ich mich dann als root anmelden will, klappt es leider nicht mit dem selben Passwort, welches ich auch nutze, um mich mit dem vSphere-Client auf dem Host einzuloggen. Kann ich irgendwie nachträglich den SSH-Zugang für Root freischalten? Muss ich dafür etwa an die Konsole (ist im Moment für mich nicht möglich, da Fernwartung)?

Viele Grüße
Alex

Da die ServiceKonsole ein OpenSSH enthaelt ist es dort ueblich das sich Root in der Voreinstellung nicht anmelden darf!. Entweder wird die bei der Einrichtung gleich gaendert oder aber es wird ein normaler Benutzer angelegt mit einem andern Password.

Frueher zu 3.5 Zeiten war das Anlegen eines Benutzers auch im Nachhinein mittels VIC moeglich. Ob das heute zu 4.x Zeiten noch so ist muesste man mal gucken. Dazu muesste man sich mal direkt mit dem VIC auf den ESX verbinden und gucken was ueber die Benutzerverwaltung dann noch zumachen ist.

Wenn der Server aber eine Hardware Remote Karte hat dann ist das kein Beinbruch und benutzt diese um soch auf der Konsole anzumelden und den SSH Zugang aufzumachen bzw. den Benutzeraccount fuer Servicearbeiten anzulegen. Das ist aber nicht ESX spezifischen Wissen oder Vorgehen sondern normalen UNIX/Linux doing.

Gruss
Joerg

Hallo Joerg,

bei ESX 4.0 habe ich im vSphere-Client (ex VIC) keine Möglichkeit gefunden, User anzulegen. Man kann lediglich Rollen definieren etc.

Der Server ist ein IBM BladeCenterS, somit wäre Remote-Zugriff auf die Konsole eigentlich kein Problem, aber die IBM-Software muss einen Bug haben, da es bei Maschinen, auf denen ESX installiert ist, nicht funktioniert (Citrix XenServer geht komischerweise). Somit muss wohl einer von uns hinfahren, um das Ganze vor Ort freizuschalten.

Normales UNIX/Linux doing klingt für Linux-Spezies leicht, bedeuten für Windows-Admins aber leider bömische Dörfer. Falls du einen Link für eine Anleitung zum Einrichten dieses Support-Users hast, wäre das sehr hilfreich.

Viele Grüße
Alex

Mit dem VIC (die Schreibweise ist kuerzer als vSphere Client) direkt auf den ESX anmelden und dann weiter ->Invectory->User&Groups. Mittels Rechtsklick dann AddUser. Beim anlegen des Users den Haken machen bei "Grant shell access to user" weil sonst klappt das nicht.

Mit diesem Account dann per SSH auf den ESX Hosts und wenn man da ist ein "su -". Wer das RootPW dann hat ist lokaler root dann auf dem ESX. Allerdings wenn du keine Ahnung hast wuerde ich die bitten einfach die Finger von zulassen weil sonst geht nur noch mehr kaputt. Die Datastores liegen unter /vmfs/volumes wobei das ein vdf -h auch anzeigen sollte. Wenn du hier im Forum mal nach "snapinfo" suchst wirst du ein Shellscript finden welches die Funktionen snapVMX und snapTree bereitstellen. Hat mir damals der Support empfohlen wenn man mit Snapshotketten hantiert.

Gruss
Joerg

Abolute_Beginner hat geschrieben:Ich war leider auch der felsenfesten Überzeugung, dass den Basedisks nichts passiert ist und die Snapshots nicht gebraucht werden - wusste nichtmal, dass Acronis welche erzeugt, denn darauf wird man ja nicht hingewiesen. ISt schon Mist, wenn ein Programm, welches eigentlich zur DatenSICHERUNG dient, letztendlich mitverschuldet, dass es zu DatenVERLUST kommt.

Den Basedisks ist sicherlich auch nichts passiert.
Wenn du die in eine neue Maschine einbinden würdest, hättest du halt den Stand von vor dem ersten Snapshot.
Die Snapshots beinhalten allerdings die seitdem gemachten Änderungen.

Generell solltest du darauf achten möglichst die Snapshots nach Gebrauch wieder zu löschen wenn du sie manuell erstellt hast.

Wie ist es jetzt mit eurem Platz auf dem Host?
Sieh dir mal die noch laufenden Maschinen an, und entferne dort die nicht benötigten Snaps.
Am besten löscht du zuerst die direkt neben der Basedisk, dann brauchst du für den Vorgang weniger Speicherplatz.

Acronis erzeugt die Snapshots für die Sicherung und sollte sie danach auch wieder entfernen.
Ob es allerdings Schuld daran ist das ihr einfach irgendwelche Dateien löscht...

Bevor du jetzt weiteres unternimmst solltest du nach Möglichkeit den gesamten Ordner der VM vom Host auf ein externes Medium kopieren!

Die Fehlermeldung klingt aber nicht nach einem fehlendem Snapshot.
Erscheint die Meldung im vSphere Client oder im startenden Windows?

Hallo nochmal,

wieder mal danke für eure Antworten. Habe die Sache nun einem Kollegen übergeben, da ich krankheitsbedingt zu Hause bin und nur heute Morgen für ein paar Stunden eingesprungen bin.

Dass den Basedisks nichts passiert ist, hatte ich auch gehofft, aber leider startet eine neu angelegte VM mit diesen Disks auch nicht (gleiche Fehlermeldung wie oben beschrieben). Vielleicht liegt's ja doch nicht an den Snapshots? Die wurden ja wie gesagt nicht manuell erzeugt, sondern von Acronis. Und Acronis löscht diese normalerweise wieder nach erfolgreichem Backup. Natürlich kann Acronis nix dafür, dass wir etwas gelöscht haben, aber dass ein Backup-System einfach tagelang sichert und dabei nicht darauf achtet, dass die "Snapshot-Partition" vollläuft, finde ich eher nicht so toll.

Inzwischen ist auch ein nette Support-Mitarbeiterin von VMWare an der Sache dran und versucht ihr bestes. Mal abwarten, wie es weitergeht. Ich werde euch auf jeden Fall informieren, wie die Sache ausgegangen ist.

Vielen Dank nochmal!

Gruß
Alex

P.S.: Falls doch noch jemand eine schlaue Idee hat, auf welches Symptom die Fehlermeldung hindeutet, gerne raus damit...

Die Meldung besagt das noch jemand den Fuss auf den Dateien hat da diese im Normalbetrieb ja auch gelocked sind. Wenn die Kiste gegen die Wand faehrt ist nicht gesagt das alles sauber gestorben ist. Oft sieht man noch Prozesse mittels ps aux|grep VMname und man kann versuchen diesen mittels killall -9 PID abzuschiessen. Meistens hilft aber nur ein Neustart des ESXs.

Kauft halt eine vernuenftige Backupsoftware welche mehr Features hat. Ich hab bislang noch keine Software kennengelernt gehabt welche einen 2. Durchgang startet wenn sie auf einen ihrer eigenen Snapshots trifft. Allerdings ist eine Software auch Chancenlos wenn die Snapshotkette kaputt ist und das vCenter immer reportet das kein Snap mehr vorhanden ist.

Das euch der Platz ausgegangen ist alleine dem Admin anzukreiden. Aber eine Aufarbeitung bzw. Verbesserungsvorschlaege damit soetwas nicht nochmal passiert wollten wir eigentlich hinterher machen.

Gruss
Joerg

Hi
hatte heute viel um die Ohren ... wie siehts es aus ?

Falls der Fall noch akut ist - ruf am besten mal durch

(schick ne Telefonnummer per PM)

Gruss

Hallo Zusammen, ich übernehme vom Kollegen, der echt krank ist und muss eingestehen, dass ich vom der Materie noch weniger Ahnung habe.

Am Freitag hat uns der Support noch sehr geholfen. Erst per WebEx-Session, als dass nicht mehr half, bin ich mit einem Kollegen, der Linux/Unix beherrscht zum Kunden gefahren und wir haben dort den SHH-Zugriff (temporär) eingerichtet. Gegen Abend lief es wieder, allerdings 2 Tage Datenverlust und das System basiert noch immer auf vorhandenen snapshots. Die Maschine startete erst wieder, als der Zugriff durch Acronis auf die vdmks durch Herunterfahren der SicherungsVMs unterbunden wurde. Derzeit habe ich das Vertrauen in Acronis verloren, die Festplatten nicht überwacht zu haben, geht natürlich voll auf unsere Kappe.

Den Status-Report und die Empfehlungen vom VMWare Support poste ich gesondert. Unser dringenstes Problem ist derzeit das Comitten der Snapshots, damit die Maschine wieder vernünftig läuft. Die zweite Frage, die wir uns stellen: Der VMWare Support erwähnt, das nur eine 25 GB VMDK (LW C: der Maschine mit Win2003) sowie eine 100 GB vxmdk (wird für Datensicherungen verwendet) Datenverlust erlitten hätten. Die Produktiv-Datenbank leigt aber auf einer 50 GB vmdk. Könnt ihr einschätzen, ob man den letzten Stand doch noch retten kann? Das würde einer Buchhaltungsabteilung heftigst Arbeit ersparen.
Viele Grüße

As discussed the root cause of this issue was that the Navision-Server and Naviserv VM disks were attached to the AcronisESXAppliance Blade3 VM. As this VM was powered on, the disks were locked, and we therefore could not power on the VMs. By powering off the AcronisESXAppliance Blade3 VM, we were able to successfully start the Navision-Server VM.

You will need to investigate how the Acronis does backups, and why on the Acronis Blade3 VM the disks were not removed.

From the Navision-Server snapshot information, the data files for the latest snapshots on the 25G and 100G disks were gone - which means that, in order to start the VM, I had to link to the snapshot prior to them. Note, that there is data loss because of this.

Regarding the Navision-Server VM - which still has snapshots - the snapshot files will need to be deleted. Unfortunately there is not enough space on the filesystem in order to commit all the snapshots:

Navision-Server-000005.vmdk Size: 305M
Navision-Server-000003.vmdk Size: 49M
Navision-Server-000001.vmdk Size: 49M
Base Disk: /vmfs/volumes/4b14e31e-f288852e-5434-00215e9725f6/Navision-Server/Navision-Server.vmdk Size: 25G Space needed on this Datastore to delete all the snapshots of this disk is: 656.15 Megabytes = 0.64 Gigabytes
----------------
Navision-Server_1-000003.vmdk Size: 1.2G
Navision-Server_1-000002.vmdk Size: 17M
Navision-Server_1-000001.vmdk Size: 17M
Base Disk: /vmfs/volumes/4b14e31e-f288852e-5434-00215e9725f6/Navision-Server/Navision-Server_1.vmdk Size: 50G Space needed on this Datastore to delete all the snapshots of this disk is: 2320.30 Megabytes = 2.27 Gigabytes
----------------
Navision-Server-000006.vmdk Size: 20G
Navision-Server-000004.vmdk Size: 17M
Navision-Server-000002.vmdk Size: 17M
Base Disk: /vmfs/volumes/4b14e347-e65b99ae-1b1e-00215e9725f6/Navision-Server/Navision-Server.vmdk Size: 100G Space needed on this Datastore to delete all the snapshots of this disk is: 39536.59 Megabytes = 38.61 Gigabytes
----------------

TOTAL SPACE REQUIRED: 38.61GB+2.27GB+0.64GB = 41.52GB
TOTAL SPACE AVAILABLE ON FILESYSTEM: 29GB

[root@vmw-host-03 Navision-Server]# vdf -h .
Filesystem Size Used Avail Use% Mounted on
/vmfs/volumes/4b14e2a3-103cb70c-33e4-00215e9725f6/Navision-Server
86G 57G 29G 65% /vmfs/volumes/VMFS_Shared_Storage


I would recommend cloning the 100GB snapshotted disk into a new virtual disk. And then attaching this new disk to the VM. You will then have an additional 20GB free on the filessystem.
See http://kb.vmware.com/kb/1007849 for details on how to use the "vmkfstools -i" command. Note: The VM will need to be POWERED OFF in order to do this, so should be done outside normal working hours

Moin,
die 50er Platte ist denn ja noch vollstaendig und ob die darauf laufende Datenbank es irgendwie uebelgenommen hat siehst du erst nachdem Start. Das ist dann aber eher MS Navision Knowhow. Unter Umstaenden haengt man die Disk mal kurzzeitig aus so das dein Navision auf die Nase faellt wenn der Server startet. Dann alle Dienste auf Manuell/DIsabled und wieder einhaengen die Platte.

Entweder treibst du nun den Aufwand die 100GB Sicherungplatte umzubewegen auf einen anderen Datastore, um Platz fuer das loeschen der Snaps zubekommen. Oder du verabschiedest dich gleich davon weil du sagst was da drauf ist zualt. Da keiner hier weis wie und wofuer diese 100GB Disk eigentlich gut ist kannst nur du das beantworten.

Wenn genug Platz da ist sollten erstmal die Snaps geloescht werden und das dann auch kontrolliert sprich auf der Konsole des ESX und hinterher gucken das auch alle weg sind.

Wenn die Kiste dann wieder laueft kannst du im ldf. Betrieb die 100er mal einhaengen und gucken von wann der letzte Sicherungsstand ist.

Gruss
Joerg

So... damit man sich das naechste mal selber helfen kann bzw. es garnicht soweit kommt.

Wie man im nachhinein einen Benutzer mit SSH Zugang anlegt hatte ich oben schon geschrieben. Auch das die Fehlermeldung damit zu tun hat, dass ein anderer den Fuss auf den Dateien hat wurde auch oben schon erwaehnt.

Bis Dato sind mit nur 2 Scennarien bekannt wo das Problem auftreten kann
1. Eine andere VM verwendet die Dateien
Loesung: Den Dateinamen der VMDK nehmen und mittels "grep" alle VMX Dateien durchsuchen. Da auf den VMX aber ein Lock ist muss man das auf jedem ESX Host tun der Teil des Clusters ist. Man erhaelt hier natuerlich viele Fehlermeldungen so das man genau nach seinem Treffer Ausschau halten. Wer es schoener haben will ermittelt mit vmware-cmd -l die registrieren VMs und verwendet diese Pfade fuer sein greppen.

2. Die eigene VM, oder besser ein Kernel, lockt die Datei
Das passiert wenn VMs wegen Platzmangel gegen die Wandfahren oder andere unplanmaessige Dinge passieren wie wenn eine VMs beim vMotion zwischen den Stuehlen sitzen bleibt.
Loesung: Man führt bewusst eine Aktion mit den VMDKs aus um Anhand der Fehlermeldung im hostd.log den ESX Host zubestimmen. Wer ein Cloning von Hand mittels vmkfstool -i aktiv.vmdk test.vmdk auf eine Datei ausfuehrt welche gelockt ist rennt in einen gewollten Fehler. Die Meldung aus dem hostd.log enthaelt hinten die MAC Adresse des Hosts welcher den Lock gesetzt hat. Auf dem guckt man dann mittels ps aux ob noch alte Prozesse laufen bzw. man raeumt den Host frei und rebootet ihn.


So und nun zu euch.....
Ihr habt ein vCenter welches Alarme generiert wenn ein Datastore zuvoll wird. Der Alarm muss natuerlich konfiguriert und im einfachsten Fall wird an eine EMail Adresse verschickt. Im Idealfall ist das eine Verteilerliste so das keiner sagen kann er haette nichts mitbekommen.....

Es gibt den schoenen vCenter Healthcheck welcher alle Infos aus dem vCenter ausliest und als HTML Dokument per E-Mail verschickt. Neben dem schoenen Seiteneffekt das man fasst die gesamte Konfiguration ausgelesen bekommt und man im Notfall seine Umgebung damit wiederaufabauen kann sind dort auch die Snapshots mit der Groesse und dem Alter gelistet. Man kann Schwellwerte hinterlegen so das Snap welche Aelter als X Tage sind markiert werden.

Da man aber dem vCenter nur bedingt trauen kann verwendet der SnapCheck das Dateisystem um einfach nach -delta* Dateien zusuchen. Somit bekommt man auch kaputte Snapshotketten heraus. Auch dieser Report wird als HTML per E-Mail verschickt. Leider muss man dem ESX Hosts dazu noch 2 kleine Perl Module bekannt machen und das ganze tut dann auch nur mit ESX und nicht ESXi. Aber auch fuer letzteren gibt es Loesungen da ich mir per RCLI wohl auch Dateilisten uebermitteln lassen kann.

Wer es ehrer Grafisch mag der kann RVtool verwenden und wenn mich nicht alles tauscht hat er einen Tab wo alle Snaps gelistet werden.

Gruss
Joerg

Und zu Acronis...
das hoert sich so nachdem HotAdd Modus vom VCB an wo die zusichernde Disk immer kurz einer Helper VM angehaengt wurde.

Gruss
Joerg

Hallo Irix und Andere,
vielen Dank für deine weiteren Hinweise! Wir sind absolut positiv überrrascht von eurer Hilfsbereitsschaft und auch sehr dankbar dafür.

Ich hatte ein sehr kurzes Wochenende, will aber gern berichten, wie es weiter abgelaufen ist:
Am Sonntag hat uns continuum sehr geholfen, er hat die drei Laufwerke nacheinander commitet. Speziell beim Datenbank-Laufwerk haben wir jeden vorhanden Snapshot einzeln betrachtet, um eventuell noch eine Version zu finden, die einen aktuellen Datenbestand wiederspiegelt. Hat leider nichts gebracht, unser Kunden muss nun 2 Tage Buchhaltungsdaten nachpflegen. Auch an dieser Stelle nochmals vielen Dank an continuum!

Wir hatten gerade noch genügend Platz auf dem SAN, um die 3 Festplatten zu committen und als neue VM wieder darzustellen. Diese lief einwandfrei hoch, daher haben wir dann die alten VMDKS und ihre Snapshots sowie die ursprüngliche VM gelöscht. Der Kunde konnte heute Morgen weiterarbeiten. Pflicht erfüllt, die Kür wäre gewesen, ihm noch eine aktuellere Datenbank wiederzugeben.

Was lernen wir daraus:

Umbedingt die Festplattenbelegung aller Laufwerke überwachen lassen. Wir haben nicht gewußt, wo Acronis seine Snapshots hinschreibt, daher muss man alle Laufwerke im Auge haben. Aber das hatte IRIX ja schon (ohne Spott, den wir wohl verdient hätten), ausführlich dargestellt. Irix, wir werden das beherzigen und sind aus Schaden klug geworden. Speziell den vCenter Healthcheck werden wir uns mal genau anschauen.

Irix hatte Recht mit der Aussage, das irgendjemand seinen Fuß auf en Daten hatte. Erst als wir die entsprechende VM von Acronis für diesen host heruntergefahren hatten, startete die Maschine am Freitag wieder.

Weiß jemand sicher, wie der Mechanismus von Acronis funktioniert. Ist es der von Irix angesprochene HotAdd Modus vom VCB? Wird die vmdk währenddessen für die eigentliche VM auf read-only gesetzt oder wie kann es sein, dass die vmdk eines Datenbank-Servers auch bei der Acronis ESX-VM im Zugriff ist? Wo können wir mal nachlesen, wie so ein snapshot-Mechanismus funktioniert?

Navision hatte noch einen internen Sicherungsmechanismus, der die Datenbank um 20:00 täglich auf eine separate vmdk kopiert, am nächsten Tag wird diese wieder überschrieben. Der Vorteil ist, dass eine Sicherung im SAN sehr flott ist. Im Fehlerfall kommt man aber an die Sicherung nicht so schnell heran, daher sollte man solche Sicherungen auf ein anderes Datenziel kopieren oder zu verschieben.

Nochmals Dank an Alle, hoffentlich bleibt das Anderen erspart.
Viele Grüße
Dirk

Wie du ja nun schon bemerkt hast sind im Normalbetrieb die Dateien mit einem Lock gesperrt. Das heist, das kein anderer Prozess zugreifen kann. Das schliesst eine Datensicherung mit ein!. Somit ist das Mittel der Wahl eine VMDK im aktiven Zustand zukopieren(Backuppen) die, dass ein Snapshot erstellt wird. Hier wandern dann alle neuren Aenderungen in eine zusaetzliche Datei -delta.vmdk geschrieben und der Lock auf die Originaldatei wird aufgehoben.

Ab diesem Zeitpunkt kann man also Schweinereien mit der Basisdisk machen. K.A was das Acronis genau treibt. Aber es scheint ja das diese Disks temporaer einer Appliance angehaengt werden. Ab diesem Zeitpunkt ist natuerlich wieder ein Lock aktiv.

Gibt ja bestimmt ein Whitepaper von denen mit Uebersicht was die da genau treiben. Ansonsten mal den Support bemuehen. Wenn du heraus bekommen hast wie es genau funktioniert dann bitte hier wieder Posten oder besser noch einen neuen Thread eroeffnen.

Gruss
Joerg

Hier lag ein erschwerter Fall vor - durch unguenstige Bennenung der vmdks gab es zwei snapshot-ketten gleichen Namens in ein und demselben Ordner.

Moeglicherweise ist Acronis dadurch durcheinander gekommen und hat die backup-snapshots nach dem wegsichern nicht wieder entfernt ... ?

Drei Methoden, um ein Backup und Restore von virtuellen Maschinen durchzuführen:
http://www.searchdatacenter.de/themenbe ... index.html

VMware Consolidated Backup, Backup direkt vom SAN
http://www.searchdatacenter.de/themenbe ... es/135521/

Dirk

Also Artikel welche 2.5 Jahre als sind bitte immer mit Vorsicht zugeniessen und zu VCB ist zusagen das es EOL ist und mit der naechsten vSphere Version nicht mehr funktionieren wird.

Gruss
Joerg