esx 3.5 vcb 2.5 u2 sicherung dauert ewig
Verfasst: 24.06.2014, 16:28
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