Ghetto Tech Preview - ghettoVCB-restore.sh - Restoring VM's backed up from ghettoVCB to ESX(i) 3.5, 4.x & 5.x

Ghetto Tech Preview - ghettoVCB-restore.sh - Restoring VM's backed up from ghettoVCB to ESX(i) 3.5, 4.x & 5.x

Table of Contents:

    • Description
    • Requirements
    • Setup
    • Usage
    • Sample Execution
    • Change Log
    • Known Issues

Description:

This script performs a restore of virtual machines backed up using ghettoVCB .  Tasks are performed directly within the service console of the ESX(i)  server involved in the restore process. This is currently a Ghetto Tech  Preview that includes basic restore functionality. Two main use cases  are supported in this release:

1) Restore a VM that contains ALL VMDKs on one datastore

2) Restore a VM that has VMDKs located on multiple datastores

In all cases, restored VMs will have VMDKs that reside on the SAME  datastore chosen for the restore process. Please ensure that there is  sufficient space on the target datastore before attempting a restore  operation. In the near future, restoration of VMs backed up using the  compression feature of ghettoVCB will be implemented.

Features

  • Support for logging output
  • Support for various debugging output
  • Allow spaces in VM(s) backup list (not recommended and not a best practice)
  • Support for restore in the following formats: ZEROEDTHICK (default behavior), 2GB SPARSE, THIN or EAGERZEROEDTHICK
  • Support for ESXi 5.1 NEW!
  • Support changing custom VM name during restore NEW! 

If you have found this script to be useful and would like to contribute back, please click here to donate.

If you have any questions, you may post in the dedicated ghettoVCB VMTN community group.


Requirements:

VMs backed up using ghettoVCB.sh on ESX(i) 3.5, 4.x or 5.x

SSH console access to ESX(i) host


Setup:

1) Download ghettoVCB from github (which includes ghettoVCB-restore) by clicking on the ZIP button at the top and upload to either your ESX or ESXi system (use scp or WinSCP to transfer the file)

2) Extract the contents of the zip file (filename will vary):

# unzip ghettoVCB-master.zip

Archive:  ghettoVCB-master.zip
   creating: ghettoVCB-master/
  inflating: ghettoVCB-master/README
  inflating: ghettoVCB-master/ghettoVCB-restore.sh
  inflating: ghettoVCB-master/ghettoVCB-restore_vm_restore_configuration_template
  inflating: ghettoVCB-master/ghettoVCB-vm_backup_configuration_template
  inflating: ghettoVCB-master/ghettoVCB.conf
  inflating: ghettoVCB-master/ghettoVCB.sh

3) The script is now ready to be used and is located in a directory named ghettoVCB-master

# ls -l

-rw-r--r--    1 root     root           281 Jan  6 03:58 README
-rw-r--r--    1 root     root         16024 Jan  6 03:58 ghettoVCB-restore.sh
-rw-r--r--    1 root     root           309 Jan  6 03:58 ghettoVCB-restore_vm_restore_configuration_template
-rw-r--r--    1 root     root           356 Jan  6 03:58 ghettoVCB-vm_backup_configuration_template
-rw-r--r--    1 root     root           631 Jan  6 03:58 ghettoVCB.conf
-rw-r--r--    1 root     root         49375 Jan  6 03:58 ghettoVCB.sh


Usage:

[root@himalaya ~]# ./ghettoVCB-restore.sh
###############################################################################
#
# ghettoVCB-restore for ESX/ESXi 3.5, 4.x and 5.x
# Author: William Lam
# http://www.virtuallyghetto.com/
# Created: 08/18/2009
# Last modified: 2011_11_19_1
#
###############################################################################

Usage: ./ghettoVCB-restore.sh -c [VM_BACKUP_UP_LIST] -l [LOG_FILE] -d [DRYRUN_DEBUG_INFO]

OPTIONS:
   -c     VM backup list
   -l     File ot output logging
   -d     Dryrun/Debug Info [1|2]

(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

Dryrun/Debug Info (dryrun only)
        ./ghettoVCB-restore.sh -c vms_to_restore -d 1
        ./ghettoVCB-restore.sh -c vms_to_restore -d 2

Standard input for script is a file that contains:

1) Full path to the backed up VM

2) Full restore path

3) Restoration disk format

4) Restored VM Display Name (NEW!)

Reminder: When creating this file on a non-Linux/UNIX system, one may  introduce ^M characters that will cause the script to misbehave. To  ensure that this does not occur, please create the file on the ESX/ESXi  host.

Here is a sample of what the file should look like:

[root@himalaya ~]# cat vms_to_restore
#"<DIRECTORY or .TGZ>;<DATASTORE_TO_RESTORE_TO>;<DISK_FORMAT_TO_RESTORE>;<OPTIONAL_RESTORED_VM_DISPLAY_NAME>"
# 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/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36;/vmfs/volumes/mini-local-datastore-1;3"
"/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36;/vmfs/volumes/mini-local-datastore-1;1;VCSA-RESTORE"

Comments in the input file is acceptable so long as the intended line is preceded by a #. The above sample VM restore file,

vms_to_restore, describes the following backup:

VM to restoreDatastore to restore toVMDK formatRestore VM Name
/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36/vmfs/volumes/mini-local-datastore-1thinVCSA-5.1
/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36/vmfs/volumes/mini-local-datastore-zeroedthickVCSA-RESTORE



Sample Execution:

Perform a dryrun by displaying debug information ( restore will not take place)

Display debug information level 1:

# ./ghettoVCB-restore.sh -c vms_to_restore -d 1

################ DEBUG MODE ##############
Virtual Machine: "VCSA-5.1"
VM_ORIG_VMX: "VCSA-5.1.vmx"
VM_ORG_FOLDER: "VCSA-5.1-2012-12-25_01-30-36"
VM_RESTORE_VMX: "VCSA-5.1.vmx"
VM_RESTORE_FOLDER: "VCSA-5.1"
VMDK_LIST_TO_MODIFY:
scsi0:0.fileName = "VCSA-5.1.vmdk"
scsi0:0.fileName  = "VCSA-5.1-0.vmdk"
scsi0:1.fileName = "VCSA-5.1_1.vmdk"
scsi0:1.fileName  = "VCSA-5.1-1.vmdk"
##########################################


################ DEBUG MODE ##############
Virtual Machine: "VCSA-RESTORE"
VM_ORIG_VMX: "VCSA-5.1.vmx"
VM_ORG_FOLDER: "VCSA-5.1-2012-12-25_01-30-36"
VM_RESTORE_VMX: "VCSA-RESTORE.vmx"
VM_RESTORE_FOLDER: "VCSA-RESTORE"
VMDK_LIST_TO_MODIFY:
scsi0:0.fileName = "VCSA-5.1.vmdk"
scsi0:0.fileName  = "VCSA-RESTORE-0.vmdk"
scsi0:1.fileName = "VCSA-5.1_1.vmdk"
scsi0:1.fileName  = "VCSA-RESTORE-1.vmdk"
##########################################


Start time: Sun Jan 13 16:45:12 UTC 2013
End   time: Sun Jan 13 16:45:14 UTC 2013
Duration  : 2 Seconds

---------------------------------------------------------------------------------------------------------------

Display debug information level 2:

[root@himalaya ~]# ./ghettoVCB-restore.sh -c vms_to_restore -d 2


################## Restoring VM: VCSA-5.1  #####################
==========> DEBUG MODE LEVEL 2 ENABLED <==========
Start time: Sun Jan 13 16:45:35 UTC 2013
Restoring VM from: "/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36"
Restoring VM to Datastore: "/vmfs/volumes/mini-local-datastore-1" using Disk Format: "thin"
Creating VM directory: "/vmfs/volumes/mini-local-datastore-1/VCSA-5.1" ...
Copying "VCSA-5.1.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "VCSA-5.1.vmx" file ...

SOURCE: "/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36/VCSA-5.1.vmdk"
    ORIGINAL_VMX_LINE: -->scsi0:0.fileName = "VCSA-5.1.vmdk"<--
DESTINATION: "/vmfs/volumes/mini-local-datastore-1/VCSA-5.1/VCSA-5.1-0.vmdk"
    MODIFIED_VMX_LINE: -->scsi0:0.fileName  = "VCSA-5.1-0.vmdk"<--
Updating VMDK entry in "VCSA-5.1.vmx" file ...

SOURCE: "/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36/VCSA-5.1_1.vmdk"
    ORIGINAL_VMX_LINE: -->scsi0:1.fileName = "VCSA-5.1_1.vmdk"<--
DESTINATION: "/vmfs/volumes/mini-local-datastore-1/VCSA-5.1/VCSA-5.1-1.vmdk"
    MODIFIED_VMX_LINE: -->scsi0:1.fileName  = "VCSA-5.1-1.vmdk"<--
Registering VCSA-5.1 ...
End time: Sun Jan 13 16:45:35 UTC 2013
################## Completed restore for VCSA-5.1! #####################

################## Restoring VM: VCSA-RESTORE  #####################
==========> DEBUG MODE LEVEL 2 ENABLED <==========
Start time: Sun Jan 13 16:45:35 UTC 2013
Restoring VM from: "/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36"
Restoring VM to Datastore: "/vmfs/volumes/mini-local-datastore-1" using Disk Format: "zeroedthick"
Creating VM directory: "/vmfs/volumes/mini-local-datastore-1/VCSA-RESTORE" ...
Copying "VCSA-5.1.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "VCSA-RESTORE.vmx" file ...

SOURCE: "/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36/VCSA-5.1.vmdk"
    ORIGINAL_VMX_LINE: -->scsi0:0.fileName = "VCSA-5.1.vmdk"<--
DESTINATION: "/vmfs/volumes/mini-local-datastore-1/VCSA-RESTORE/VCSA-RESTORE-0.vmdk"
    MODIFIED_VMX_LINE: -->scsi0:0.fileName  = "VCSA-RESTORE-0.vmdk"<--
Updating VMDK entry in "VCSA-RESTORE.vmx" file ...

SOURCE: "/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36/VCSA-5.1_1.vmdk"
    ORIGINAL_VMX_LINE: -->scsi0:1.fileName = "VCSA-5.1_1.vmdk"<--
DESTINATION: "/vmfs/volumes/mini-local-datastore-1/VCSA-RESTORE/VCSA-RESTORE-1.vmdk"
    MODIFIED_VMX_LINE: -->scsi0:1.fileName  = "VCSA-RESTORE-1.vmdk"<--
Registering VCSA-RESTORE ...
End time: Sun Jan 13 16:45:35 UTC 2013
################## Completed restore for VCSA-RESTORE! #####################


Start time: Sun Jan 13 16:45:34 UTC 2013
End   time: Sun Jan 13 16:45:35 UTC 2013
Duration  : 1 Seconds

---------------------------------------------------------------------------------------------------------------

Execute restore with output going to stdout (restore the first two VMs listed from above):

Input file:

# cat vms_to_restore

"/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36;/vmfs/volumes/mini-local-datastore-1;3"
"/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36;/vmfs/volumes/mini-local-datastore-1;1;VCSA-RESTORE"

./ghettoVCB-restore.sh -c vms_to_restore


################## Restoring VM: VCSA-5.1  #####################
Start time: Sun Jan 13 16:46:41 UTC 2013
Restoring VM from: "/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36"
Restoring VM to Datastore: "/vmfs/volumes/mini-local-datastore-1" using Disk Format: "thin"
Creating VM directory: "/vmfs/volumes/mini-local-datastore-1/VCSA-5.1" ...
Copying "VCSA-5.1.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "VCSA-5.1.vmx" file ...
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36/VCSA-5.1.vmdk'...
Clone: 100% done.
Updating VMDK entry in "VCSA-5.1.vmx" file ...
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36/VCSA-5.1_1.vmdk'...
Clone: 100% done.
Registering VCSA-5.1 ...
34
End time: Sun Jan 13 16:48:51 UTC 2013
################## Completed restore for VCSA-5.1! #####################

################## Restoring VM: VCSA-RESTORE  #####################
Start time: Sun Jan 13 16:48:52 UTC 2013
Restoring VM from: "/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36"
Restoring VM to Datastore: "/vmfs/volumes/mini-local-datastore-1" using Disk Format: "zeroedthick"
Creating VM directory: "/vmfs/volumes/mini-local-datastore-1/VCSA-RESTORE" ...
Copying "VCSA-5.1.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "VCSA-RESTORE.vmx" file ...
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36/VCSA-5.1.vmdk'...
Clone: 100% done.
Updating VMDK entry in "VCSA-RESTORE.vmx" file ...
Failed to clone disk: There is not enough space on the file system for the selected operation (13).
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36/VCSA-5.1_1.vmdk'...
Registering VCSA-RESTORE ...
35
End time: Sun Jan 13 16:50:19 UTC 2013
################## Completed restore for VCSA-RESTORE! #####################


Start time: Sun Jan 13 16:46:40 UTC 2013
End   time: Sun Jan 13 16:50:19 UTC 2013
Duration  : 3.65 Minutes


---------------------------------------------------------------------------------------------------------------

Execute restore with output going to log file

/tmp/ghettoVCB-restore.log (restore the last two VMs listed from above):

[root@himalaya ~]# ./ghettoVCB-restore.sh -c vms_to_restore -l /tmp/ghettoVCB-restore.log
Logging output to "/tmp/ghettoVCB-restore.log" ...
Attachments
Comments

This is a great script. One question I have is with regards to restoring. When I do a backup it pulls the info from the following directory (for example)

/vmfs/volumes/SAN1/SERVERNAME

When I do the restore after deleting the system from disk it restores to

/vmfs/volumes/SAN1/SERVERNAME-2010-06-30_16-22-36

I noticed it does update the vmdk file for the new location, but is there some way to restore to the original location minus the time stamp?

Thanks!

I think I've mentioned in this in the document but there is a limitation with compression on ESXi, with ESXi 4.0 I believe it went from 4 to 8GB, any files larger will have issues. This is what you're seeing, the problem does not exist with classic ESX

=========================================================================

William Lam

VMware vExpert 2009,2010

VMware scripts and resources at:

Twitter: @lamw

vGhetto Script Repository

Getting Started with the vMA (tips/tricks)

Getting Started with the vSphere SDK for Perl

VMware Code Central - Scripts/Sample code for Developers and Administrators

VMware Developer Community

If you find this information useful, please award points for "correct" or "helpful".

I initially put this script together pretty quick to see how it might be used, one of the things I had left out was renaming the directory ... I was not sure if users would prefer to see that it was infact a restore or if they wanted the original name. I can add this to my back log of things to do, but tell you truth I'm pretty swamped with projects both on and off work Smiley Wink I manage probably 100+ other scripts. Not sure when I'll get to this update but it shouldn't be too bad, you can probably even figure it out if you have some shell scripting experience.

Thanks for the feedback

=========================================================================

William Lam

VMware vExpert 2009,2010

VMware scripts and resources at:

Twitter: @lamw

vGhetto Script Repository

Getting Started with the vMA (tips/tricks)

Getting Started with the vSphere SDK for Perl

VMware Code Central - Scripts/Sample code for Developers and Administrators

VMware Developer Community

If you find this information useful, please award points for "correct" or "helpful".

I am running on ESX 3.5 not ESXi or ESX4.0, any clues how restore it?

TIA

William,

thanks a lot for this great work. The backup as well as the restore are really helpfull, and run like a charm in my small environment.

There is one thing comming to my mind: It might help other people as well, if the backup script would already create a kind of vms_to_restore file for each backup, containing a proposal how to subsequently restore the machine from it.

Please carry on with your great work

Thanks again

Jochen

Hi, I tried running the script from a ESX 4.0 upgraded to 4.1 and the script gives me was "ERROR: You're not running ESX(i) 3.5+ or 4.0+!" why is that ? i can run the backup script but not the restore script

I tried playing with the script a bit to see the checking done, I changed the Script to check for version 4.1.0 and it will run fine,

Why is it that esxi seems to not cap the vmkfstool when uploading (backup) to an nfs share but downloading from nfs (restore) is capped? I can get 80MB/s backing up but only 7/MB restoring? With a straight NFS link to a linux server I'm getting 80MB/s read/write but not through esxi from nfs to a local or san datastore? ESXi 4.0

I'm having an issue trying to perform a restore, here are the messages I'm receiving when I enter the command:

# ./ghettoVCB-restore.sh -c vm_list.txt -d 2


grep: /vmfs/volumes/FreeNAS/Win2008Serv/VM-DOAHLNPER001/VM-DOAHLNPER001-2011-02-02_16-50-31/VM-DOAHLNPER001.vmx
VM-DOAHLNPER001.vmxf: No such file or directory
grep: /vmfs/volumes/FreeNAS/Win2008Serv/VM-DOAHLNPER001/VM-DOAHLNPER001-2011-02-02_16-50-31/VM-DOAHLNPER001.vmx
VM-DOAHLNPER001.vmxf: No such file or directory
################## Restoring VM:   #####################
==========> DEBUG MODE LEVEL 2 ENABLED <==========
Start time: Thu Feb  3 18:08:46 UTC 2011
Restoring VM from: "/vmfs/volumes/FreeNAS/Win2008Serv/VM-DOAHLNPER001/VM-DOAHLNPER001-2011-02-02_16-50-31"
Restoring VM to Datastore: "/vmfs/volumes/datastore2TB" using Disk Format: "thin"
Creating VM directory: "/vmfs/volumes/datastore2TB/VM-DOAHLNPER001-2011-02-02_16-50-31" ...
Copying "VM-DOAHLNPER001.vmx
VM-DOAHLNPER001.vmxf" file ...
Restoring VM's VMDK(s) ...
Registering  ...
End time: Thu Feb  3 18:08:46 UTC 2011
################## Completed restore for ! #####################


Start time: Thu Feb  3 18:08:46 UTC 2011
End   time: Thu Feb  3 18:08:46 UTC 2011
Duration  : 0 Seconds


Yet I can list the files it says don't exist:

# ls /vmfs/volumes/FreeNAS/Win2008Serv/VM-DOAHLNPER001/VM-DOAHLNPER001-2011-02-02_16-50-31/VM-DOAHLNPER001.vmx -l
-rwxr-xr-x    1 root     root               3632 Feb  3 09:21 /vmfs/volumes/FreeNAS/Win2008Serv/VM-DOAHLNPER001/VM-DOAHLNPER001-2011-02-02_16-50-31/VM-DOAHLNPER001.vmx

# ls /vmfs/volumes/FreeNAS/Win2008Serv/VM-DOAHLNPER001/VM-DOAHLNPER001-2011-02-02_16-50-31/VM-DOAHLNPER001.vmxf -l
-rw-------    1 root     root                270 Feb  3 09:21 /vmfs/volumes/FreeNAS/Win2008Serv/VM-DOAHLNPER001/VM-DOAHLNPER001-2011-02-02_16-50-31/VM-DOAHLNPER001.vmxf

I can also manually copy these files to a different location, so I don't think its a security issue

TIA for any light you can shed on this.

I'm having the same Issue with a restore I tried 2 days ago... I gave up and did a reinstall (cause it was a clean "template" I created some time ago...) of the virtual machine.... Smiley Sad

GJI

Hey fellas!

First thanks for the outline above and making this script. I had a issue that's coming up when i do a restore.

I did a backup using ghettoVCB and the backup is in the following folder 

vmfs/volumes/datastore1/backups

There are 3 files in the "backups" folder and they are:

Centos.vmdk (500kb)

Centos.vmx (300kb)

Centos-flat.vmdk (about 8.5GB)

I edited the config file and saved the following in it:

"/vmfs/volumes/datastore1/backups--1;/vmfs/volumes/datastore1/Centos:Storage;1"

I have an empty folder in \datastore1 called Centos so the restore can be done there.

When I run the command i get the following error:

root@esx01 ghettoVCB-restore]# ./ghettoVCB-restore.sh -c vms_to_restore_sample.txt
Support for .tgz not supported - "/vmfs/volumes/datastorage1/backups--1" will not be backed up!

Start time: Fri Feb 25 12:51:39 CST 2011
End   time: Fri Feb 25 12:51:39 CST 2011
Duration  : 0 Seconds

------------------------------------------------------

Any suggestions? I saw some discussion about compression not supported and I tried to follow it but got totally lost. Sorry i'm totally new the linux terminology so could someone please help me with this?

im getting same error "Support for .tgz not supported" when restoring.

Can somebody assist us please.

Bickyz,

make sure the path is correct espeically the path where you are restoring from. In order to validate that you have the correct path, browse your backup files and do a "pwd" command. This should tell your correct path of your vmdk files. Hope this helps.

Hello,

this tool is great!

But it would be even better if it would restore form the symlink created by RSYNC_LINK of ghettoVCB.sh.

If use

"/vmfs/volumes/backupstore/myvm/mywm-symlink;/vmfs/volumes/mydatastore;3"

instead of

"/vmfs/volumes/backupstore/myvm/mywm-2011-05-16_10-11-12;/vmfs/volumes/mydatastore;3"

the restore won't work. 😞

If it could be made possible I can use the script to restore the lastest successfull backup without checking the real directory name first and changeing the configuration-file.

- Steffen

hi guys

i backed up my 35gb/400gb thin vm in about 70 minutes to my NAS drive. verified it was there, no problems. now i have started doing a restore. so far we are at 49% and it has been about 6 hours. it looks as though it has now hit the whitespace section of the thin vm and although it has sped up it looks as though it's going to take about another 4 hours at this rate before it finishes.

70 minutes to backup, but 10 hours to restore?

any thoughts as to why my source and destination HDD activity is almost zero but my switch is still happily flickering away with a gigabit link?

the restore is taking place on a different esxi box, although physically the two servers are identical.

any thoughts as to why it might be taking so long would be much appreciated!

thanks,

brett

When i try to run a script ./ ghettoVCB-restore.sh -c vms_to_restore_sample, my permission is denied ash: ./: Permission denied. Do anyone have any idea of what's happening? I have changed the chmod 777 of the script file but the problem persists. Appreciate any help for the matter. Thanks.

I actually restart the management network and it's still not working until i restart the host machine. Just don' t understand why the script files are being deleted after host restarted. After the host being restarted, i can execute the script again. I'm confused... Appreciate any reply in the matter. Thanks.

Can someone help me to understand the FAQ 25a below:

"the maximum largest supported VM is 4GB for compression and on ESXi 4.x  the largest supported VM is 8GB. If you try to compress a larger VM, you  may run into issues when trying to extract upon a restore."

Does the VM size referr to "hard disk1" or "virtual disk" size?

If my disk size is 70 GB, can I use Ghetto to backup or not?

TIA!

Extremely, Helpful script. Just one small request for a future rev. if you ever get the time. It would be great if there was an optional parameter in the config file to re-name the target VM to something different. Or maybe I should tackle it myself and submit it you for code review, that is if I ever find the time myself.

-Greg

Hello William,

I'm using ghettoVCB to backup my VMs on ESXi 4.1 and I'm facing a problem:

  • I tried to run one backup in vmware workstation, and the first time, it actually worked fine. Now, for some reason I don't understand, the newly backed-up VM doesn't have the hard drive showing up at bootime (in the BIOS) and the system tries to netboot. The vmdks files are there, the vmx points to the right files, but I can't get the VM to detect the disk. Any idea on what could be the problem?
  • Second, I tried to restore the same VM using the ghettoVCB restore script, and the process ran smoothly ; the VM is restored and shows up in vSphere client, but I have the exact same behavior: the VM tries to netboot, and I can't get it to boot on the disk, which doesn't show up in the BIOS.

Any clue on what could be the cause of that problem?

Thanks for your help!

Regards,

Hi,

can i use this version "as is" to restore VM's backed up from ghettoVCB (with upgrade for 5.0)?

Thanks for your help!

Regards.

Dear William Lam,

Could you please   ,

update ghettoVCB-restore script,

to support the free esxi v5

thanks , best regards

I join to last post to William Lam.

Could you ... to update to ver. 5?

Hi

You can make it work by editing the script yourself. Open up ghettoVCB-restore.sh and where it says

        ESX_VERSION=$(vmware -v | awk '{print $3}')
        if [[ "${ESX_VERSION}" == "4.0.0" ]] || [[ "${ESX_VERSION}" == "4.1.0" ]
                VER=4

Edit 4.0.0 to read 5.0.0 and save the script then run it.

Dumb way to make it work but I've tested it myself and it does work Smiley Happy

Hi,

i want to restore, but I got a strange error message, google can't help me:(

/vmfs/volumes/4b70479c-93e0a9a6-6fcc-002655527ac8 # ./ghettoVCB-restore.sh -c restore ################## Restoring VM: OC-Sharepoint  #####################

Start time: Tue Nov 29 08:41:56 UTC 2011

Restoring VM from: "/vmfs/volumes/esxi_storage/OC-Sharepoint/OC-Sharepoint-2011-08-03"

Restoring VM to Datastore: "/vmfs/volumes/datastore1" using Disk Format: ""

Creating VM directory: "/vmfs/volumes/datastore1/OC-Sharepoint-2011-08-03" ...

Copying "OC-Sharepoint.vmx" file ...

Restoring VM's VMDK(s) ...

Updating VMDK entry in "OC-Sharepoint.vmx" file ...

sh: 1: unknown operand

sh: 2: unknown operand

sh: 3: unknown operand

sh: 4: unknown operand

Registering OC-Sharepoint ...

End time: Tue Nov 29 08:41:59 UTC 2011

################## Completed restore for OC-Sharepoint! #####################

Start time: Tue Nov 29 08:41:56 UTC 2011

End  time: Tue Nov 29 08:41:59 UTC 2011

Duration  : 3 Seconds

what can I do??

I tinkered around until I got the settings working, and I executed the script on a non-compressed backup I made with ghettoVCB.  I am restoring from a NAS mounted via NFS, so I know it's going to take awhile.  I stopped the restore (using Ctrl + C) to test a change in my config file.  I made the change, ran the restore script again, and now get an error.  I have since reverted my change, and I'm still getting the same error.  What do I need to do to work around this (poorly worded?) issue?

ERROR: Directory "/vmfs/volumes/[datastore-location][backup-datastore-location]/[backup-date_time]" looks like it already exists, please check contents and remove directory before trying to restore!

Of course my backup exists...  Why would I want to delete the backup before restoring from it?  Have I broken something in the backup and am now hosed, or is there an easy fix to get the restore running again?

Well since you ctrl+c out of the restore, the directory structure of the restore was created. The script does not know if that is a live running VM or a failed restore and hence the error. Please clean up the partial restore and try it again.

Yes, it took me awhile to realize it was actually telling me about the folder in my local datastore and not in the backup datastore.  I had assumed the script was going to write the restored VM over top of the VM that was originally backed up, (it decided to write to a folder named after the backup, which included a date and time stamp that I later edit out manually), and didn't think to refresh WinSCP view of the folder on the server.

Thanks for the quick response.  Other than this bit of confusion, it's been great, as it has for so many other people.  Thanks for writing it.

Dear William,

First of all let me thank you. At least in one occasion your backup script "saved my ass" ......

Today I tried out ESXI 5.1 and I've noticed that the (restore) script does not run.

a) version (fixed it myself)

b) whoami (does not exist in 5.1, so I've commented it out from sanity check - I'am root ......)

c) tgz? - on line 162 -d "${VM_TO_RESTORE .... it is jumping into the else line on 216. But it's a normal backup without compression !

I gave up at this point, cause your backup solution it essential for me and reinstalled 5.0. Seems that vmware changed a lot of things ...

Will you bring us a new version of ghetto ?

Thanks a lot

Klaus

Damned !

problem c) was NOT 5.1. After downgrade to 5.0 error remains !

It was an "stupid ass vm with spaces.vmx" problem - seems that I have an old version - oh god no - don't understand why, version was bundled with ghettoVCB ..........

sorry!

Klaus

William,

Great script.  One thing we found with your latest build (on github as of 1/8/2013) was that when restoring, your script would create the restore directory with the same name of the directory containing the backup (i.e., VMNAME-YYYY-MM-DD_hh-mm-ss).  The script did this on both ESXi 4.1.0 and 5.1.0 (free versions).

When we changed the following line of your script:

VM_FOLDER_NAME=$(echo "${VM_ORIG_FOLDER_NAME}" | sed 's/-[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]--[0-1]*//g')

To the following:

VM_FOLDER_NAME=$(echo "${VM_ORIG_FOLDER_NAME}" | sed 's/-[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]_[0-9][0-9]-[0-9][0-9]-[0-9][0-9]*//g')

The destination directory was created correctly.  No idea if this was specific to our environment or not, but wanted to make you aware.

Keep up the good work.

Hi Zorg5,

It looks like at some point the backup naming convention changed which broke the sed :X

You should be able to use the following:

sed 's/-[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]_[0-1].*//g'

Let me know if that works and I'll go ahead and push the change.

Thanks for reporting this

Works great with that change - Thanks!

Hi,

I am trying backup and restore ghettoVCB all the day and I accomplish to backup one virtual machine but I can't restore this machine in a source datastore again. I ginving this error all times:

Support for .tgz not supported

Then I think about a problem and I make a decision to test ghettoVCB with another version of ESXi and the result is that in my ESXi 5.1 ghettoVCB-restore doesn't work, nevertheless with ESXi 4.1 works fine.

It's possible that this version is not qualified to restore virtual machines in ESXi 5.1 with Hardware Version 8.

I hope this data helps someone

Version history
Revision #:
1 of 1
Last update:
‎08-23-2009 11:28 PM
Updated by: