chmod +x ghettoVCB-restore.sh
[root@himalaya ~]# ./ghettoVCB-restore.sh
###############################################################################
#
# ghettoVCB-restore for ESX/ESXi 3.5u2+ & 4.x+
# Author: William Lam
# http://www.engineering.ucsb.edu/~duonglt/vmware/
# Created: 08/18/2009
# Last modified: 08/25/2009
#
###############################################################################
Usage: ./ghettoVCB-restore.sh -c [VM_BACKUP_UP_LIST] -l [LOG_FILE]
OPTIONS:
-c VM backup list
-l File ot output logging
(e.g.)
Output will go to stdout
./ghettoVCB-restore.sh -c vms_to_restore
Output will log to /tmp/ghettoVCB-restore.log
./ghettoVCB-restore.sh -c vms_to_restore -l /tmp/ghettoVCB-restore.log
[root@himalaya ~]# cat vms_to_restore
#"<DIRECTORY or .TGZ>;<DATASTORE_TO_RESTORE_TO>;<DISK_FORMAT_TO_RESTORE>"
# DISK_FORMATS
# 1 = zeroedthick
# 2 = 2gbsparse
# 3 = thin
# 4 = eagerzeroedthick
# e.g.
# "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/VCAP/VCAP-2009-08-18--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;1"
"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/VCAP/VCAP-2009-08-20--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;1"
"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/sideswipe/sideswipe-2009-08-20--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;1"
"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/stupid ass vm with spaces/stupid ass vm with spaces-2009-08-20--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;2"
"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/vMA-resize/vMA-resize-2009-08-23--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;3"
| VM to restore | Datastore to restore to | VMDK format |
| /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/VCAP/VCAP-2009-08-20--1 | /vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage | zeroedthick |
| /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/sideswipe/sideswipe-2009-08-20--1 | /vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage | zeroedthick |
| /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/stupid ass vm with spaces/stupid ass vm with spaces-2009-08-20--1 | /vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage | 2gbsparse |
| /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/vMA-resize/vMA-resize-2009-08-23--1 | /vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage | thin |
[root@himalaya ~]# cat vms_to_restore
"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/VCAP/VCAP-2009-08-20--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;1"
"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/sideswipe/sideswipe-2009-08-20--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;1"
[root@himalaya ~]# ./ghettoVCB-restore.sh -c vms_to_restore
################## Restoring VM: VCAP #####################
Start time: Sun Aug 23 22:31:26 PDT 2009
Restoring VM from: "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/VCAP/VCAP-2009-08-20--1"
Restoring VM to Datastore: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage" using Disk Format: "zeroedthick"
Creating VM directory: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/VCAP" ...
Copying "VCAP.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "VCAP.vmx" file ...
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/VCAP/VCAP-2009-08-20--1/VCAP.vmdk'...
Clone: 100% done.
Registering VCAP ...
End time: Sun Aug 23 22:32:32 PDT 2009
################## Completed restore for VCAP! #####################
################## Restoring VM: sideswipe #####################
Start time: Sun Aug 23 22:32:32 PDT 2009
Restoring VM from: "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/sideswipe/sideswipe-2009-08-20--1"
Restoring VM to Datastore: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage" using Disk Format: "zeroedthick"
Creating VM directory: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/sideswipe" ...
Copying "sideswipe.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "sideswipe.vmx" file ...
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/sideswipe/sideswipe-2009-08-20--1/sideswipe.vmdk'...
Clone: 100% done.
Updating VMDK entry in "sideswipe.vmx" file ...
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/sideswipe/sideswipe-2009-08-20--1/4a31aece-e34d675a-72cf-003048d9586a/sideswipe.vmdk'...
Clone: 100% done.
Updating VMDK entry in "sideswipe.vmx" file ...
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/sideswipe/sideswipe-2009-08-20--1/4a31aece-e34d675a-72cf-003048d9586a/sideswipe_1.vmdk'...
Clone: 100% done.
Updating VMDK entry in "sideswipe.vmx" file ...
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/sideswipe/sideswipe-2009-08-20--1/sideswipe_1.vmdk'...
Clone: 100% done.
Registering sideswipe ...
End time: Sun Aug 23 22:34:46 PDT 2009
################## Completed restore for sideswipe! #####################
Start time: Sun Aug 23 22:31:26 PDT 2009
End time: Sun Aug 23 22:34:46 PDT 2009
Duration : 3.33 Minutes
---------------------------------------------------------------------------------------------------------------
[root@himalaya ~]# cat vms_to_restore
"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/stupid ass vm with spaces/stupid ass vm with spaces-2009-08-20--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;2"
"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/vMA-resize/vMA-resize-2009-08-23--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;3"
[root@himalaya ~]# ./ghettoVCB-restore.sh -c vms_to_restore -l /tmp/ghettoVCB-restore.log
Logging output to "/tmp/ghettoVCB-restore.log" ...
cat /tmp/ghettoVCB-restore.log
[root@himalaya ~]# ./ghettoVCB-restore.sh -c vms_to_restore -d 1
################ DEBUG MODE ##############
Virtual Machine: "VCAP"
VM_VMX: "VCAP.vmx"
VM_ORG_FOLDER: "VCAP-2009-08-20--1"
VM_FOLDER_NAME: "VCAP"
VMDK_LIST_TO_MODIFY:
scsi0:0.fileName = "VCAP.vmdk"
scsi0:0.fileName = "VCAP-0.vmdk"
##########################################
################ DEBUG MODE ##############
Virtual Machine: "sideswipe"
VM_VMX: "sideswipe.vmx"
VM_ORG_FOLDER: "sideswipe-2009-08-20--1"
VM_FOLDER_NAME: "sideswipe"
VMDK_LIST_TO_MODIFY:
scsi0:0.fileName = "sideswipe.vmdk"
scsi0:0.fileName = "sideswipe-0.vmdk"
scsi0:1.fileName = "/vmfs/volumes/4a31aece-e34d675a-72cf-003048d9586a/sideswipe/sideswipe.vmdk"
scsi0:1.fileName = "sideswipe-1.vmdk"
scsi1:8.fileName = "/vmfs/volumes/4a31aece-e34d675a-72cf-003048d9586a/sideswipe/sideswipe_1.vmdk"
scsi1:8.fileName = "sideswipe-2.vmdk"
scsi3:12.fileName = "sideswipe_1.vmdk"
scsi3:12.fileName = "sideswipe-3.vmdk"
##########################################
Start time: Sun Aug 23 23:04:49 PDT 2009
End time: Sun Aug 23 23:04:49 PDT 2009
Duration : 0 Seconds
---------------------------------------------------------------------------------------------------------------
[root@himalaya ~]# ./ghettoVCB-restore.sh -c vms_to_restore -d 2
################## Restoring VM: stupid ass vm with spaces #####################
==========> DEBUG MODE LEVEL 2 ENABLED <==========
Start time: Sun Aug 23 23:05:11 PDT 2009
Restoring VM from: "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/stupid ass vm with spaces/stupid ass vm with spaces-2009-08-20--1"
Restoring VM to Datastore: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage" using Disk Format: "2gbsparse"
Creating VM directory: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/stupid ass vm with spaces" ...
Copying "stupid ass vm with spaces.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "stupid ass vm with spaces.vmx" file ...
SOURCE: "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/stupid ass vm with spaces/stupid ass vm with spaces-2009-08-20--1/stupid ass vm with spaces.vmdk"
ORIGINAL_VMX_LINE: -->scsi0:0.fileName = "stupid ass vm with spaces.vmdk"<--
DESTIONATION: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/stupid ass vm with spaces/stupid ass vm with spaces-0.vmdk"
MODIFIED_VMX_LINE: -->scsi0:0.fileName = "stupid ass vm with spaces-0.vmdk"<--
Updating VMDK entry in "stupid ass vm with spaces.vmx" file ...
SOURCE: "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/stupid ass vm with spaces/stupid ass vm with spaces-2009-08-20--1/4a31aece-e34d675a-72cf-003048d9586a/stupid ass vm with spaces.vmdk"
ORIGINAL_VMX_LINE: -->scsi0:1.fileName = "/vmfs/volumes/4a31aece-e34d675a-72cf-003048d9586a/stupid ass vm with spaces/stupid ass vm with spaces.vmdk"<--
DESTIONATION: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/stupid ass vm with spaces/stupid ass vm with spaces-1.vmdk"
MODIFIED_VMX_LINE: -->scsi0:1.fileName = "stupid ass vm with spaces-1.vmdk"<--
Updating VMDK entry in "stupid ass vm with spaces.vmx" file ...
SOURCE: "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/stupid ass vm with spaces/stupid ass vm with spaces-2009-08-20--1/4a31aece-e34d675a-72cf-003048d9586a/stupid ass vm with spaces_1.vmdk"
ORIGINAL_VMX_LINE: -->scsi0:2.fileName = "/vmfs/volumes/4a31aece-e34d675a-72cf-003048d9586a/stupid ass vm with spaces/stupid ass vm with spaces_1.vmdk"<--
DESTIONATION: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/stupid ass vm with spaces/stupid ass vm with spaces-2.vmdk"
MODIFIED_VMX_LINE: -->scsi0:2.fileName = "stupid ass vm with spaces-2.vmdk"<--
Registering stupid ass vm with spaces ...
End time: Sun Aug 23 23:05:11 PDT 2009
################## Completed restore for stupid ass vm with spaces! #####################
################## Restoring VM: vMA-resize #####################
==========> DEBUG MODE LEVEL 2 ENABLED <==========
Start time: Sun Aug 23 23:05:11 PDT 2009
Restoring VM from: "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/vMA-resize/vMA-resize-2009-08-23--1"
Restoring VM to Datastore: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage" using Disk Format: "thin"
Creating VM directory: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/vMA-resize" ...
Copying "vMA-resize.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "vMA-resize.vmx" file ...
SOURCE: "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/vMA-resize/vMA-resize-2009-08-23--1/vMA-resize.vmdk"
ORIGINAL_VMX_LINE: -->scsi0:0.fileName = "vMA-resize.vmdk"<--
DESTIONATION: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/vMA-resize/vMA-resize-0.vmdk"
MODIFIED_VMX_LINE: -->scsi0:0.fileName = "vMA-resize-0.vmdk"<--
Registering vMA-resize ...
End time: Sun Aug 23 23:05:11 PDT 2009
################## Completed restore for vMA-resize! #####################
Start time: Sun Aug 23 23:05:11 PDT 2009
End time: Sun Aug 23 23:05:11 PDT 2009
Duration : 0 Seconds
---------------------------------------------------------------------------------------------------------------
It works. I wiped my VM using VI Client (a bit scary), then I used this script to restore a previous backup. After a while it automatically popped up in the VI client.
Very nice. Thanks a lot.
Awesome to hear!
when I run the restore script I get the following....complains about support for .tgz ???
~ # ./ghettoVCB-restore.sh -c vms_to_restore
Support for .tgz not supported - "/vmfs/volumes/backup/OCSSE_DR/OCSSE_DR-2009-10-01" will not be backed up!
Start time: Thu Oct 1 11:37:31 UTC 2009
End time: Thu Oct 1 11:37:31 UTC 2009
Duration : 0 Seconds
As noted in this document, compression restore is not supported yet.
I've tried walking away so I could look at this from a fresh mind, but I'm still getting a path problem on restore.
Could I get some input on maybe some syntax problems with this?? I'm really sure about the path. I've tried the aliased (as shown) and actual (with all the letters/numbers) for the final directory where the datastore resides.
I've run it from the root directory and in the datastore directory just for giggles. No luck.
restore.txt
#"<DIRECTORY or .TGZ>;<DATASTORE_TO_RESTORE_TO>;<DISK_FORMAT_TO_RESTORE>"
"/vmfs/volumes/macpro/vm/IBMvfusion;/vmfs/volumes/datastore1:datastore1;1"
Output
~ # ./ghettoVCB-restore.sh -c restore.txt
ERROR: Unable to verify datastore locateion: "/vmfs/volumes/datastore1:datastore1"! Ensure this exists
Thanks for looking
Brian
Remember to note that this script will ONLY work with backups taken with ghettoVCB.sh ... I only bring this up to ensure you're able to use the script and secondly, the format of your restore configuration doesn't match up from the sample template provided.
The first param /vmfs/volumes/macpro/vm/IBMvfusion should look something like /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/VCAP/VCAP-2009-08-18--1 where it points to the directory of a specific VM backup, not the root directory of the VM backups but a specific backup.
The second param /vmfs/volumes/datastore1:datastore1 is the datastore to restore to, I don't know if this is correct or a typo? Did you mean to say _/vmfs/volumes/datastore1_?
The third param 1 should just be the disk format and that looks fine to me.
Pleae double check your input and make sure /vmfs/volumes/datastore1:datastore1 does exists
Found the clue in this:
"Did you mean to say _/vmfs/volumes/datastore1_?"
I took verbatim what was in the original restore text like this:
"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/VCAP/VCAP-2009-08-18--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;1"
"/vmfs/volumes/macpro/vm/IBMvfusion;/vmfs/volumes/datastore1:datastore1;1"
but this worked:
"/vmfs/volumes/macpro/vm/IBMvfusion;/vmfs/volumes/datastore1;1"
I'm assuming somewhere along the line the ":Storage" part worked at one time?? Or I was using it incorrectly.
Thanks for your help and VERY SOLID blogging/reply posts in all the ESX forums.
Brian
The example I gave was for our development environment and the datastore I was testing this with had the following display name: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage", ":Storage" is not some string that needs to be appended
You just need to provide the name of your datastore that you're restoring to.
Glad everything works
banthorpe,
I also got that message about "Support for .tgz not supported..." even though I had not chosen any file that was tgz'd.
What I found was that I had the wrong case (Macpro instead of macpro) on one of my nfs datastores. I was using essentially a wrong path. The script couldn't find the directory and halted. Just took some squinting on my part to see my error.
I added my own comment to the script in case I forget in the future too ![]()
Brian
I cannot even run this script.
The script fails to create a log file even.
It is spouting off errors in the actual script involving lines 30 / 31
http://pastebin.com/m15e0794c has more information. I tried to throw in some diagnostic info as well.
First of all great script.
I have successfully backed up my VM's using the script however I was wanting to test the restore function as well to make sure my backups were useful.
When running : "./ghettoVCB-restore.sh -c vmrestore.list" I get the following error message. Same error regardless of whether I'm restoring from a compressed .gz file or not.
/backup # ./ghettoVCB-restore.sh -c vmrestore.list
Restoring VM:
Start time: Wed Nov 25 20:01:19 UTC 2009
Restoring VM from: "/vmfs/volumes/vmbackups/Test Machine"
Restoring VM to Datastore: "/vmfs/volumes/datastore1" using Disk Format: "zeroedthick"
Creating VM directory: "/vmfs/volumes/datastore1/Test Machine" ...
Copying "" file ...
cp: /vmfs/volumes/vmbackups/Test Machine: omitting directory
Restoring VM's VMDK(s) ...
Registering ...
(vmodl.fault.InvalidArgument) {
dynamicType = <unset>,
invalidProperty = <unset>,
msg = "A specified parameter was not correct.
"
}
End time: Wed Nov 25 20:01:20 UTC 2009
Completed restore for !
Start time: Wed Nov 25 20:01:19 UTC 2009
End time: Wed Nov 25 20:01:20 UTC 2009
Duration : 1 Seconds
Any Clues...? Thanks.
Can you please re-run the restore using -d 2 which is second level of debugging, remember to always provide debugging information when running into issues/problems and all this is documented within this document ![]()
I'm looking at your initial output provided and it looks like it was not able to locate the .vmx configuration file and thats probably why its throwing the error because it uses the .vmx to register. Secondly, there is no support for restoring a zipped backup.
Remember that this script is ONLY supported if your back up were taken from ghettoVCB.
Here is the debug level 2 output: Thank you.
/backup # ./ghettoVCB-restore.sh -c vmrestore.list -d 2
Restoring VM:
==========> DEBUG MODE LEVEL 2 ENABLED <==========
Start time: Thu Nov 26 16:28:15 UTC 2009
Restoring VM from: "/vmfs/volumes/vmbackups/Test Machine"
Restoring VM to Datastore: "/vmfs/volumes/datastore1" using Disk Format: "zeroedthick"
Creating VM directory: "/vmfs/volumes/datastore1/Test Machine" ...
Copying "" file ...
Restoring VM's VMDK(s) ...
Registering ...
End time: Thu Nov 26 16:28:15 UTC 2009
Completed restore for !
Start time: Thu Nov 26 16:28:15 UTC 2009
End time: Thu Nov 26 16:28:15 UTC 2009
Duration : 0 Seconds
Take a look at my previous reply .... I don't see the amount of debugging info as I should be. Is there a .vmx file in the directory in which you're trying to restore the VM from?
Never mind I just figured it out. I feel like a goober. When I was declaring my "restore from" path I was stopping one directory short. I was using /vmfs/volumes/vmbackups/Test Machine when I needed to be using /vmfs/volumes/vmbackups/Test Machine/Test Machine-2009-11-25--1. Thank you for all of your help. Also kudos on the script again.
I have ESXi 4.0. I had to adjust your script to remove every blank line in it. Same thing with the backup script. Strange.
After that it runs fine. I just tested restore and it worked very well. When you start the restored VM you have to choose "i moved it" to the UUID question, else you loose networking (at least on my linux VM).
Great scripts ! Excellent.
Just a quick note:
./ghettoVCB-restore.sh -c vms_to_restore
Support for .tgz not supported - "/vmfs/volumes/backup/OCSSE_DR/OCSSE_DR-2009-10-01" will not be backed up!
I had the same problem some days ago - but i didn't have taken .tgz backups... I had a typo in my restore-path. Seems like "Support for .tgz not supported" is the default msg when the path is not found. Maybe another message would help find the solution?
Greets
Peter
Thanks for the info, I'll take a look into updating the error message.
Thank you for providing backup and restore scripts. I have, however, encountered a problem while trying to perform a restore on the test (not production) VM called WDW1
First, I used ghettoVCB.sh to backup the VM to an external NFS volume (created with Allegro on a Windows machine). The backup created 3 files: WDW1.vmdk (1 KB) , WDW1.vmx (2KB) , WDW1-flat.vmdk (11G)
Next, I used the "Delete from Disk" GUI option in the VMware Infrastructure Console to remove the VM from the ESX host.
When I executed the ghettoVCB-restore.sh script it reported being complete (see below), but I didn't see a re-emergence of the WDW1VM.
One unusual thing I noticed is that the debug says: Creating VM directory: "/vmfs/volumes/datastore2/WDW1", but that directory does not exist after the script completes.
Here is the debug output:
/vmfs/volumes/4acfe3c9-5ec075de-c4c5-000bcd82437d # ./ghettoVCB-restore.sh -c vms_to_restore -d 2
Restoring VM: WDW1
DEBUG MODE LEVEL 2 ENABLED
Start time: Tue Dec 1 13:30:25 UTC 2009
Restoring VM from: "/vmfs/volumes/backup2/WDW1/WDW1-2009-11-30--1"
Restoring VM to Datastore: "/vmfs/volumes/datastore2" using Disk Format: "zeroedthick"
Creating VM directory: "/vmfs/volumes/datastore2/WDW1" ...
Copying "WDW1.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "WDW1.vmx" file ...
SOURCE: "/vmfs/volumes/backup2/WDW1/WDW1-2009-11-30--1/WDW1.vmdk"
ORIGINAL_VMX_LINE: >scsi0:0.fileName = "WDW1.vmdk"<
DESTINATION: "/vmfs/volumes/datastore2/WDW1/WDW1-0.vmdk"
MODIFIED_VMX_LINE: >scsi0:0.fileName = "WDW1-0.vmdk"<
Registering WDW1 ...
End time: Tue Dec 1 13:30:25 UTC 2009
Completed restore for WDW1!
Start time: Tue Dec 1 13:30:25 UTC 2009
End time: Tue Dec 1 13:30:25 UTC 2009
Duration : 0 Seconds
Can you paste me your vms_to_restore file and wrap the content in {code} tags
The following is what happens whenever i trying any execution of the script on the server.
This included the -d 2 diagnostics. no files are generated in the /var/logs dir.
I have included extra outputs to tell you what is where and what is in the vms_to_restore file.
I'd sure like to be able to use this script.
/scripts # ./ghettoVCB-restore.sh -c vms_to_restore
: not found-restore.sh: line 5:
: not found-restore.sh: line 7:
###############################################################################
#
vms_to_restore:
[code]"/vmfs/volumes/backup2/WDW1/WDW1-2009-11-30--1;/vmfs/volumes/datastore2;1"[/code]
Looking at your vms_to_restore, compressed backups are NOT supported in the script. You should have seen an error when trying to execute the script, from the errors I'm seeing it looks like you might have saved/edited the script on a windows system, make sure you download the script and upload directly to ESX(i) host.
The restore file looks to be okay, and based on the logs it looks like it tried to the restore but you mentioned that /vmfs/volumes/datastore2/WDW1 was not created .... ? Is there something wrong with that volume? Can you manually create a directory on that volume? Sounds like there might have been something wrong with that volume.
I am able to create a directory on /vmfs/volumes/datastore2
~ # cd /vmfs/volumes/datastore2
/vmfs/volumes/4acfe3c9-5ec075de-c4c5-000bcd82437d # ls -l
drwxr-xr-x 1 root root 1400 Dec 2 16:44 DEV1
drwxr-xr-x 1 root root 1960 Dec 3 07:12 MAP1
drwxr-xr-x 1 root root 1960 Nov 9 14:30 UBP1
drwxr-xr-x 1 root root 1820 Nov 9 17:19 UDP1
-rw-r--r-- 1 root root 5 Nov 30 19:15 WDW1backup
-rw-r--r-- 1 root root 5 Nov 14 09:41 backup_MAP1
-rw-r--r-- 1 root root 5 Nov 9 18:01 backup_UDP1
-rwxr-xr-x 1 root root 17965 Nov 30 20:50 backup_ghettoVCB.sh
-rwxr-xr-x 1 root root 15279 Dec 1 19:05 ghettoVCB-restore.sh
-rwxr-xr-x 1 root root 17966 Nov 30 20:55 ghettoVCB.sh
-rwxr-xr-x 1 root root 15279 Dec 1 12:17 unmodified_ghettoVCB-restore.sh
-rwxr-xr-x 1 root root 18004 Nov 9 13:25 unmodified_ghettoVCB.sh
-rw-r--r-- 1 root root 10 Nov 9 12:24 vmbackups
-rw-r--r-- 1 root root 76 Dec 2 12:11 vms_to_restore
-rw-r--r-- 1 root root 175 Dec 1 14:32 vms_to_restore_to_backup
/vmfs/volumes/4acfe3c9-5ec075de-c4c5-000bcd82437d # mkdir test
/vmfs/volumes/4acfe3c9-5ec075de-c4c5-000bcd82437d # ls -l
drwxr-xr-x 1 root root 1400 Dec 2 16:44 DEV1
drwxr-xr-x 1 root root 1960 Dec 3 07:12 MAP1
drwxr-xr-x 1 root root 1960 Nov 9 14:30 UBP1
drwxr-xr-x 1 root root 1820 Nov 9 17:19 UDP1
-rw-r--r-- 1 root root 5 Nov 30 19:15 WDW1backup
-rw-r--r-- 1 root root 5 Nov 14 09:41 backup_MAP1
-rw-r--r-- 1 root root 5 Nov 9 18:01 backup_UDP1
-rwxr-xr-x 1 root root 17965 Nov 30 20:50 backup_ghettoVCB.sh
-rwxr-xr-x 1 root root 15279 Dec 1 19:05 ghettoVCB-restore.sh
-rwxr-xr-x 1 root root 17966 Nov 30 20:55 ghettoVCB.sh
drwxr-xr-x 1 root root 280 Dec 3 07:57 test
-rwxr-xr-x 1 root root 15279 Dec 1 12:17 unmodified_ghettoVCB-restore.sh
-rwxr-xr-x 1 root root 18004 Nov 9 13:25 unmodified_ghettoVCB.sh
-rw-r--r-- 1 root root 10 Nov 9 12:24 vmbackups
-rw-r--r-- 1 root root 76 Dec 2 12:11 vms_to_restore
-rw-r--r-- 1 root root 175 Dec 1 14:32 vms_to_restore_to_backup
/vmfs/volumes/4acfe3c9-5ec075de-c4c5-000bcd82437d #
I'm going to try again with a new test VM.
Thank you for your great scripts.
First I ran into the same issue as xerolame but remembered from a previous version of ghettoVCB that this is the common CRLF problem. So I removed all occurences of \r using
sed -i.bak 's/\r//g' ghettoVCB-restore.sh
if [ "${RESTORE_DISK_FORMAT}" -eq 1 ]; then
if [ "${RESTORE_DISK_FORMAT}" == "1" ]; then
afaik, removing the ^M character is not required unless you did something funky during the download such as editing within Widnows editor. I've downloaded both ghettoVCB/ghettoVCB-restore on my system and transferred it to ESX(i) host and executed perfectly fine. As you know, the work around if you get into this problem is to remove via sed or some other method. You should not need to change any of the conditionals so I'm wondering if you're having an issue with specific version of ESX(i) or if something else is going on, definitely see if you can provide debugging logs and that may help me figure out what might be going on.
Can I ask what your environment looks like in terms of the ESX(i) version, VMs, size of VMs, etc.
Also note, the tags used on the VMTN forums is not with 'brackets' but with 'squiggly braces' like {code}
I don't know what happened to the script. I downloaded it with Firefox on OS X 10.6.2, copied it to the network share and from there to the root's home.
Sorry, forgot to mention my environment:
Found my mistake with the code tags. I thought, I have to "close" the code using a slash.
I don't have a 4.0u1 system to test with atm, but I imagine it should be exactly the same as 4.0. One thing I noticed you mentioned was you use ghettoVCBg2 to do the backup and the restore script is only supported using ghettoVCB .... I don't believe there is a difference in the way the backups are being stored but that is something to keep in mind.
As you've noted, the logs may hold the key on what's going on. I'll try to spin up an ESX 4.0u1 VM tonight and see if there are any issues with both backup/restore using the scripts.
I have to remove the ^M everytime i download your scripts to my Windows machine - Even if i don't open it. sing Notepad++ to convert to unix and they're gone.
Maybe it's from the squid proxy i have to use here... But even without editing, there are ^M ![]()
Greets
Peter
Hi lamw. Thanks for the quick reply. I don't thing it would make a difference if I used ghettoVCB or ghettoVCBg2 since the actual backup process is equivalent. Only the "driver" is different (correct me, if I'm wrong)
I grabbed a fresh copy of the script. And here is the config file:
[root@LTH-ESX02 trentis]# cat restore-test
#"<DIRECTORY or .TGZ>;<DATASTORE_TO_RESTORE_TO>;<DISK_FORMAT_TO_RESTORE>"
# DISK_FORMATS
# 1 = zeroedthick
# 2 = 2gbsparse
# 3 = thin
# 4 = eagerzeroedthick
# e.g.
# "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/STA202I/STA202I-2009-08-18--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;1"
"/vmfs/volumes/backup/ghettoVCBg2/lth-s06.alpma.de/lth-s06.alpma.de-2009-12-07--1;/vmfs/volumes/storage1;1"
[root@LTH-ESX02 trentis]# la /vmfs/volumes/backup/ghettoVCBg2/lth-s06.alpma.de/lth-s06.alpma.de-2009-12-07--1
total 47G
drwxr-xr-x 1 65534 65534 4.0K Dec 7 20:15 .
drwxr-xr-x 1 65534 65534 4.0K Dec 7 15:42 ..
-rw------- 1 65534 65534 2.2M Dec 7 15:42 lth-s06.alpma.de_1-ctk.vmdk
-rw------- 1 65534 65534 34G Dec 7 15:42 lth-s06.alpma.de_1-flat.vmdk
-rw------- 1 65534 65534 675 Dec 7 15:42 lth-s06.alpma.de_1.vmdk
-rw------- 1 65534 65534 2.2M Dec 7 15:34 lth-s06.alpma.de-ctk.vmdk
-rw------- 1 65534 65534 34G Dec 7 15:34 lth-s06.alpma.de-flat.vmdk
-rw------- 1 65534 65534 671 Dec 7 15:34 lth-s06.alpma.de.vmdk
-rw------- 1 65534 65534 3.8K Dec 7 15:24 lth-s06.alpma.de.vmx
[root@LTH-ESX02 trentis]# la
total 60K
drwx------ 2 trentis trentis 4.0K Dec 8 08:54 .
drwxr-xr-x 3 root root 4.0K Nov 30 11:00 ..
-rw------- 1 trentis trentis 70 Dec 8 08:47 .bash_history
-rw-r--r-- 1 trentis trentis 33 Nov 30 11:00 .bash_logout
-rw-r--r-- 1 trentis trentis 176 Nov 30 11:00 .bash_profile
-rw-r--r-- 1 trentis trentis 124 Nov 30 11:00 .bashrc
-rwxr-xr-x 1 root root 15K Dec 8 08:54 ghettoVCB-restore.sh
-rwxr-xr-x 1 root root 16K Dec 8 08:51 ghettoVCB-restore.sh.bak
-rw-r--r-- 1 root root 426 Dec 8 08:53 restore-test
[root@LTH-ESX02 trentis]# ./ghettoVCB-restore.sh -c restore-test -d 2
: command not found.sh: line 5:
: command not found.sh: line 7:
'/ghettoVCB-restore.sh: line 8: syntax error near unexpected token `{
'/ghettoVCB-restore.sh: line 8: `printUsage() {
[root@LTH-ESX02 trentis]# sed -i.bak 's/\r//g' ghettoVCB-restore.sh
[root@LTH-ESX02 trentis]# ./ghettoVCB-restore.sh -c restore-test -d 2
: integer expression expected141: [: 1
: integer expression expected143: [: 1
: integer expression expected145: [: 1
: integer expression expected147: [: 1
################## Restoring VM: lth-s06.alpma.de #####################
==========> DEBUG MODE LEVEL 2 ENABLED <==========
Start time: Tue Dec 8 08:55:13 CET 2009
Restoring VM from: "/vmfs/volumes/backup/ghettoVCBg2/lth-s06.alpma.de/lth-s06.alpma.de-2009-12-07--1"
Restoring VM to Datastore: "/vmfs/volumes/storage1" using Disk Format: ""
Creating VM directory: "/vmfs/volumes/storage1/lth-s06.alpma.de" ...
Copying "lth-s06.alpma.de.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "lth-s06.alpma.de.vmx" file ...
SOURCE: "/vmfs/volumes/backup/ghettoVCBg2/lth-s06.alpma.de/lth-s06.alpma.de-2009-12-07--1/lth-s06.alpma.de.vmdk"
ORIGINAL_VMX_LINE: -->scsi0:0.fileName = "lth-s06.alpma.de.vmdk"<--
DESTINATION: "/vmfs/volumes/storage1/lth-s06.alpma.de/lth-s06.alpma.de-0.vmdk"
MODIFIED_VMX_LINE: -->scsi0:0.fileName = "lth-s06.alpma.de-0.vmdk"<--
Updating VMDK entry in "lth-s06.alpma.de.vmx" file ...
SOURCE: "/vmfs/volumes/backup/ghettoVCBg2/lth-s06.alpma.de/lth-s06.alpma.de-2009-12-07--1/lth-s06.alpma.de_1.vmdk"
ORIGINAL_VMX_LINE: -->scsi0:2.fileName = "lth-s06.alpma.de_1.vmdk"<--
DESTINATION: "/vmfs/volumes/storage1/lth-s06.alpma.de/lth-s06.alpma.de-1.vmdk"
MODIFIED_VMX_LINE: -->scsi0:2.fileName = "lth-s06.alpma.de-1.vmdk"<--
Registering lth-s06.alpma.de ...
End time: Tue Dec 8 08:55:13 CET 2009
################## Completed restore for lth-s06.alpma.de! #####################
Start time: Tue Dec 8 08:55:13 CET 2009
End time: Tue Dec 8 08:55:13 CET 2009
Duration : 0 Seconds
---------------------------------------------------------------------------------------------------------------
[root@LTH-ESX02 trentis]# ./ghettoVCB-restore.sh -c restore-test -d 2
################## Restoring VM: lth-s06.alpma.de #####################
==========> DEBUG MODE LEVEL 2 ENABLED <==========
Start time: Tue Dec 8 09:11:42 CET 2009
Restoring VM from: "/vmfs/volumes/backup/ghettoVCBg2/lth-s06.alpma.de/lth-s06.alpma.de-2009-12-07--1"
Restoring VM to Datastore: "/vmfs/volumes/storage1" using Disk Format: ""
Creating VM directory: "/vmfs/volumes/storage1/lth-s06.alpma.de" ...
Copying "lth-s06.alpma.de.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "lth-s06.alpma.de.vmx" file ...
SOURCE: "/vmfs/volumes/backup/ghettoVCBg2/lth-s06.alpma.de/lth-s06.alpma.de-2009-12-07--1/lth-s06.alpma.de.vmdk"
ORIGINAL_VMX_LINE: -->scsi0:0.fileName = "lth-s06.alpma.de.vmdk"<--
DESTINATION: "/vmfs/volumes/storage1/lth-s06.alpma.de/lth-s06.alpma.de-0.vmdk"
MODIFIED_VMX_LINE: -->scsi0:0.fileName = "lth-s06.alpma.de-0.vmdk"<--
Updating VMDK entry in "lth-s06.alpma.de.vmx" file ...
SOURCE: "/vmfs/volumes/backup/ghettoVCBg2/lth-s06.alpma.de/lth-s06.alpma.de-2009-12-07--1/lth-s06.alpma.de_1.vmdk"
ORIGINAL_VMX_LINE: -->scsi0:2.fileName = "lth-s06.alpma.de_1.vmdk"<--
DESTINATION: "/vmfs/volumes/storage1/lth-s06.alpma.de/lth-s06.alpma.de-1.vmdk"
MODIFIED_VMX_LINE: -->scsi0:2.fileName = "lth-s06.alpma.de-1.vmdk"<--
Registering lth-s06.alpma.de ...
End time: Tue Dec 8 09:11:42 CET 2009
################## Completed restore for lth-s06.alpma.de! #####################
Start time: Tue Dec 8 09:11:42 CET 2009
End time: Tue Dec 8 09:11:42 CET 2009
Duration : 0 Seconds
---------------------------------------------------------------------------------------------------------------
[root@LTH-ESX02 trentis]# ./ghettoVCB-restore.sh -c restore-test
################## Restoring VM: lth-s06.alpma.de #####################
Start time: Tue Dec 8 09:12:16 CET 2009
Restoring VM from: "/vmfs/volumes/backup/ghettoVCBg2/lth-s06.alpma.de/lth-s06.alpma.de-2009-12-07--1"
Restoring VM to Datastore: "/vmfs/volumes/storage1" using Disk Format: ""
Creating VM directory: "/vmfs/volumes/storage1/lth-s06.alpma.de" ...
Copying "lth-s06.alpma.de.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "lth-s06.alpma.de.vmx" file ...
: integer expression expected295: [: 1
: integer expression expected301: [: 1
: integer expression expected303: [: 1
: integer expression expected305: [: 1
Updating VMDK entry in "lth-s06.alpma.de.vmx" file ...
: integer expression expected295: [: 1
: integer expression expected301: [: 1
: integer expression expected303: [: 1
: integer expression expected305: [: 1
Registering lth-s06.alpma.de ...
End time: Tue Dec 8 09:12:17 CET 2009
################## Completed restore for lth-s06.alpma.de! #####################
Start time: Tue Dec 8 09:12:16 CET 2009
End time: Tue Dec 8 09:12:17 CET 2009
Duration : 1 Seconds
---------------------------------------------------------------------------------------------------------------
I forgot to mention that it's Hardware Version 7. Maybe that makes a difference.
Following up. I had the same result the second time I tried the restore script. The script executed and reported completing with out any error in the debug output, but the directory was never created in the destination datastore and the VM was not restored. Since many other people have had success with this script I am going to have to chalk it up to some unique factor in my method (see RES1.1 in my 3BX blog) or my infrastructure environment. I can still manually restore the vm using the files created with the ghettoVCB back up script - so I'll just be doing things manually. Given the current size of my infrastructure that is fine.
Hello!
Thank youf or your scripts! Great work!
But tell me why do I need a script like this to restore VMs?
Isn't it possible to copy the backuped files to a datastore, register the VM and start it?
Or is the purpose of this restore script only to make the restore process more comfortable?
@ralfortner:
I guess the mainpurpose is making the restore process more comfortable. As you may have seen from my earlier posts, I have some trouble with this script, and so I had to restore them manually.
It is possible to copy the backed up files to a datastore and register the VM, but that is (due to many restrictions for the service console) kind of painfull ![]()
I didn't get more than 5 MB/s and so it takes a long time to recover a 100GB VMDK. Even though my backup was on an iSCSI-Storage connected with GB-LAN and the server's RAID could write at approximately 200MB/s (unbuffered).
As mentioned already, it's to make the backup/restore as much hands off as possible. I'm not sure about you, but I'm not a fan of click this and click that or type this out manually X amount of times.
Yes you can restore using various means but this has been a request from the community to provide a script to aide in the restore process. You don't have to use the script for the restore as the backup process is not done in such a way that you have to us a restore script from me.
Hopefully that answers your question
Yes I'm aware of vifs potentially being a transport method though it's slow as dirt ...not sure if I would transfer 50-100+GB using vifs unless you don't mind waiting more than double the amount of time using either ghettoVCB or ghettoVCBg2.
Having said that, it probably isn't too much work to implement a vifs restore OR backup... but I'll leave that as an exercise for the users.
nice example, but what is up with the script name? "stupid ass vm with space"