Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
esx 3.5 vcb 2.5 u2 sicherung dauert ewig
esx 3.5 vcb 2.5 u2 sicherung dauert ewig
hallo,
wir machen unsere sicherung der virtuellen maschinen mit vcb 1.5 u2 unter esx 3.5. seit einigen tagen funktioniert das ganze nicht mehr richtig. vcb ist auf einer separaten maschine server 2008 32 bit (richtiges blech) installiert.
mein script:
"C:\Program Files\VMware\VMware Consolidated Backup Framework\vcbmounter" -h 123.456.789.000 -u administrator -p 1234567890 -a name:"server" -t "fullvm" -r e:\vmbackups\server -m "nbd" -M "1"> E:\test\server.log
xcopy.exe e:\vmbackups\server\*.* E:\test\ /S /E /H /R /K /Y >> E:\test\server.log 2>&1
"C:\Program Files\VMware\VMware Consolidated Backup Framework\vcbmounter" -h 123.456.789.000 -u administrator -p 1234567890 -U e:\vmbackups\server\ >> E:\test\server.log
logausgabe:
-> Copying funktioniert ohne probleme
Copying "[san] server/server.vmx":
Copying "[san] server/RMS_DB_NEW.nvram":
Copying "[san] server//vmware-1.log":
Copying "[san] server//vmware-2.log":
Copying "[san] server//vmware-4.log":
Copying "[san] server//vmware-5.log":
Copying "[san] server//vmware-3.log":
Copying "[san] server//vmware.log":
Copying "[san] server//vmware-0.log":
-> Converting dauert mehrere stunden (10 stunden und länger), was vorher nicht der fall war, das max lag bei 2 stunden.
Converting "e:\vmbackups\server\scsi0-0-0-server.vmdk" (compact file):
Converting "e:\vmbackups\server\scsi0-1-0-server_1.vmdk" (compact file):
Converting "e:\vmbackups\server\scsi0-2-0-server_2.vmdk" (compact file):
Converting "e:\vmbackups\server\scsi0-3-0-server_3.vmdk" (compact file):
dateien der maschine im san:
server.vmdk 52428800,00 kb
server.vmsd 5,20
server.vmx 2,72
server.vmxf 0,25
server_1.vmdk 10485760,00
server_1-000001.vmdk 90112,00
server_2.vmdk 5242880,00
server_2-000001.vmdk 24576,00
server_3.vmdk 31753520,00
server_3-000001.vmdk 24576,00
server-000001.vmdk 338654,00
server-3685efe3.hlog 0,04
server-a130c6bb.vswp 4194304,00
server-Snapshot1403.vmsn 19,30
server.nvram 8,48
jemand eine idee? der momentane zustand bringt alles durcheinander. da der alte task noch läuft und der neue task schon wieder starten will.
mfg
wir machen unsere sicherung der virtuellen maschinen mit vcb 1.5 u2 unter esx 3.5. seit einigen tagen funktioniert das ganze nicht mehr richtig. vcb ist auf einer separaten maschine server 2008 32 bit (richtiges blech) installiert.
mein script:
"C:\Program Files\VMware\VMware Consolidated Backup Framework\vcbmounter" -h 123.456.789.000 -u administrator -p 1234567890 -a name:"server" -t "fullvm" -r e:\vmbackups\server -m "nbd" -M "1"> E:\test\server.log
xcopy.exe e:\vmbackups\server\*.* E:\test\ /S /E /H /R /K /Y >> E:\test\server.log 2>&1
"C:\Program Files\VMware\VMware Consolidated Backup Framework\vcbmounter" -h 123.456.789.000 -u administrator -p 1234567890 -U e:\vmbackups\server\ >> E:\test\server.log
logausgabe:
-> Copying funktioniert ohne probleme
Copying "[san] server/server.vmx":
Copying "[san] server/RMS_DB_NEW.nvram":
Copying "[san] server//vmware-1.log":
Copying "[san] server//vmware-2.log":
Copying "[san] server//vmware-4.log":
Copying "[san] server//vmware-5.log":
Copying "[san] server//vmware-3.log":
Copying "[san] server//vmware.log":
Copying "[san] server//vmware-0.log":
-> Converting dauert mehrere stunden (10 stunden und länger), was vorher nicht der fall war, das max lag bei 2 stunden.
Converting "e:\vmbackups\server\scsi0-0-0-server.vmdk" (compact file):
Converting "e:\vmbackups\server\scsi0-1-0-server_1.vmdk" (compact file):
Converting "e:\vmbackups\server\scsi0-2-0-server_2.vmdk" (compact file):
Converting "e:\vmbackups\server\scsi0-3-0-server_3.vmdk" (compact file):
dateien der maschine im san:
server.vmdk 52428800,00 kb
server.vmsd 5,20
server.vmx 2,72
server.vmxf 0,25
server_1.vmdk 10485760,00
server_1-000001.vmdk 90112,00
server_2.vmdk 5242880,00
server_2-000001.vmdk 24576,00
server_3.vmdk 31753520,00
server_3-000001.vmdk 24576,00
server-000001.vmdk 338654,00
server-3685efe3.hlog 0,04
server-a130c6bb.vswp 4194304,00
server-Snapshot1403.vmsn 19,30
server.nvram 8,48
jemand eine idee? der momentane zustand bringt alles durcheinander. da der alte task noch läuft und der neue task schon wieder starten will.
mfg
hwei hat geschrieben:der snapshot stammt nicht vom vcb, der ist händisch angelegt worden un den muss ich noch eine weile vorhalten. es ging ja vorher auch mit diesem snapshot drin.
kann es an der größe der maschine liegen?
Auaa... wie lange wird der Snapshot denn schon vorgehalten? Und wenn ja, wozu? Auf den Snap zurück heißt, alle Änderungen seit dem Snapshot futsch.
Denn der ist kein Backup vom Zeitpunkt des Snapshot.
Und wenn ich da was von "RMS_DB_NEW.nvram" lese ist es wohl auch noch eine DB?
ESX350-201002411-BG 3.5.0 (U5) Patch 19 2010-02-16 226117
http://www.virten.net/vmware/esx-releas ... r-history/
-
- King of the Hill
- Beiträge: 12950
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Dayworker hat geschrieben:Nur zur Info, in der VMware-Welt enthält eine Datei mit der Endung nvram immer die vBIOS-Einstellungen.RMS_DB_NEW.nvram
Er hat sich auf RMS_DB_NEW bezogen weil man vermuten kann das DBs durch erhoehte Schreibleistung auffallen was bei einem offenem Snapshot nicht so toll ist.
Ich haette erstmal alle 3 beteiligten Komponenten neugestartet.
Achja... wenn Mountpoint sowie Ablage Verzeichnis auf dem selben Laufwerk liegen dann ist ein Move viel schneller als ein Copy und braucht auch weniger Platz. Man muss nur einige wenige Dateien zurueck kopieren damit der Umount dann klappt. Ich hatte mal nen Backupscript welches in PHP geschrieben war.... damals , als es im Winter noch schneite und wie auch wir noch VCB benutzt haben.
Gruss
Joerg
-
- King of the Hill
- Beiträge: 13568
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Der Bezug auf RMS_DB_NEW ist mir klar, aber diese Bezeichnung ist veränderbar (muß ggf in der VMX-Datei gegändert werden) und durch die Endung sind das ganz eindeutig die vBIOS-Einstellungen. Wenn man sich die Grösse der nvram-Datei ansieht, können 8.48KB keine DB sein.
Was mich jedoch etwas irritiert sind die Logausgabe Copying "[san] server/RMS_DB_NEW.nvram" und dazu die Dateien der Maschine im SAN server.nvram 8,48. Wenn er eine Datei RMS_DB_NEW.nvram kopiert, dürfte im SAN nachher nicht server.nvram sichtbar sein.
Worauf ist eigentlich der Datastore auf dem ESX3.5 eingerichtet? Eine massive Verschlechterung der IO-Performance könnte auch von einer ausgefallenen Platte bzw BBU herrühren.
Was mich jedoch etwas irritiert sind die Logausgabe Copying "[san] server/RMS_DB_NEW.nvram" und dazu die Dateien der Maschine im SAN server.nvram 8,48. Wenn er eine Datei RMS_DB_NEW.nvram kopiert, dürfte im SAN nachher nicht server.nvram sichtbar sein.
Worauf ist eigentlich der Datastore auf dem ESX3.5 eingerichtet? Eine massive Verschlechterung der IO-Performance könnte auch von einer ausgefallenen Platte bzw BBU herrühren.
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste