{"id":15037810,"url":"https://github.com/lamw/ghettovcb","last_synced_at":"2025-05-14T10:13:03.921Z","repository":{"id":1378542,"uuid":"1332066","full_name":"lamw/ghettoVCB","owner":"lamw","description":"ghettoVCB","archived":false,"fork":false,"pushed_at":"2025-02-04T14:07:47.000Z","size":873,"stargazers_count":1323,"open_issues_count":100,"forks_count":370,"subscribers_count":111,"default_branch":"master","last_synced_at":"2025-04-03T20:44:49.725Z","etag":null,"topics":["hacktoberfest"],"latest_commit_sha":null,"homepage":"","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/lamw.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.md","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2011-02-05T17:47:15.000Z","updated_at":"2025-04-03T05:57:04.000Z","dependencies_parsed_at":"2023-07-07T09:32:48.323Z","dependency_job_id":"ee1ec55f-e14f-4085-9226-b370299c7f89","html_url":"https://github.com/lamw/ghettoVCB","commit_stats":{"total_commits":183,"total_committers":37,"mean_commits":4.945945945945946,"dds":0.7814207650273224,"last_synced_commit":"871d2b66a57a72dad86c1ea637bd8951b9bbbef3"},"previous_names":[],"tags_count":4,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lamw%2FghettoVCB","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lamw%2FghettoVCB/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lamw%2FghettoVCB/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lamw%2FghettoVCB/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/lamw","download_url":"https://codeload.github.com/lamw/ghettoVCB/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248338249,"owners_count":21087189,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["hacktoberfest"],"created_at":"2024-09-24T20:35:48.527Z","updated_at":"2025-04-11T03:37:45.752Z","avatar_url":"https://github.com/lamw.png","language":"Shell","funding_links":["https://www.buymeacoffee.com/lamw"],"categories":[],"sub_categories":[],"readme":"# ghettoVCB\n\n## Table of Contents\n\n* [Description](#description)\n* [Features](#features)\n* [Requirements](#requirements)\n* [Download](#download)\n* [Install](#install)\n* [Uninstall](#uninstall)\n* [Build VIB and Offline Bundle](#build-vib-and-offline-bundle)\n* [Configuration Options](#configuration-options)\n* [Usage](#usage)\n* [Sample Execution](#sample-execution)\n    * [Dry Run](#dry-run)\n    * [Debug](#debug)\n    * [Backup VMs stored in a list](#backup-vms-stored-in-a-list)\n    * [Backup Single VM using CLI](#backup-single-vm-using-cli)\n    * [Backup All VMs residing on specific host](#backup-all-vms-residing-on-specific-host)\n    * [Backup VMs based on individual VM backup policies](#backup-vms-based-on-individual-vm-backup-policies)\n* [Stopping ghettoVCB Process](#stopping-ghettovcb-process)\n* [Scheduling Backups using Cron](#scheduling-backups-using-cron)\n* [Restore Backups](#restore-backups)\n\n\n## Description\n\nThe ghettoVCB script performs backups of virtual machines residing on ESX(i) 3.x, 4.x, 5.x, 6.x, 7.x \u0026 8.x servers using methodology similar to VMware's VCB tool. The script takes snapshots of live running virtual machines, backs up the  master VMDK(s) and then upon completion, deletes the snapshot until the next backup. The only caveat is that it utilizes resources available to the ESXi Shell running the backups as opposed to following the traditional method of offloading virtual machine backups through a VCB proxy.\n\nThis script has been tested on ESX 3.5/4.x/5.x and ESXi 3.5/4.x/5.x/6.x/7.x/8.x and supports the following backup mediums: LOCAL STORAGE, SAN and NFS. The script is non-interactive and can be setup to run via cron. Currently, this script accepts a text file that lists the display names of virtual machine(s) that are to be backed up. Additionally, one can specify a folder containing configuration files on a per VM basis for  granular control over backup policies.\n\nAdditionally, for ESX(i) environments that don't have persistent NFS datastores designated for backups, the script offers the ability to automatically connect the ESX(i) server to a NFS exported folder and then upon backup completion, disconnect it from the ESX(i) server. The connection is established by creating an NFS datastore link which enables monolithic (or thick) VMDK backups as opposed to using the usual  *nix mount command which necessitates breaking VMDK files into the 2gbsparse format for backup. Enabling this mode is self-explanatory and will evidently be so when editing the script (Note: `VM_BACKUP_VOLUME` variable is ignored if `ENABLE_NON_PERSISTENT_NFS=1`).\n\nIn its current configuration, the script will allow up to 3 unique backups of the Virtual Machine before it will overwrite the previous backups; this however, can be modified to fit procedures if need be. Please be diligent in running the script in a test or staging environment before using it on production live Virtual Machines; this script functions well within our environment but there is a chance that  it may not fit well into other environments.\n\n**Note:** If you have found this script to be useful and would like to contribute back, feel free to [donate a cup of coffee](https://www.buymeacoffee.com/lamw) ☕😁\n\n## Features\n* Online back up of VM(s)\n* Support for multiple VMDK disk(s) backup per VM\n    * Only valid VMDK(s) presented to the VM will be backed up\n* Ability to shutdown guestOS and initiate backup process and power on VM afterwards with the option of hard power timeout\n* Allow spaces in VM(s) backup list (not recommended and not a best practice)\n* Ensure that snapshot removal process completes prior to to continuing onto the next VM backup\n    * VM(s) that initially contain snapshots will not be backed up and will be ignored\n* Ability to specify the number of backup rotations for VM\n* Output back up VMDK(s) in either ZEROEDTHICK (default behavior) or 2GB SPARSE or THIN or EAGERZEROEDTHICK format\n* Support for both SCSI and IDE disks\n* Non-persistent NFS backup\n* Fully support VMDK(s) stored across multiple datastores\n* Ability to compress backups\n* Ability to configure individual VM backup policies\n* Ability to include/exclude specific VMDK(s) per VM (requires individual VM backup policy setup)\n* Ability to configure logging output to file\n* Independent disk awareness (will ignore VMDK)\n* New timeout variables for shutdown and snapshot creations\n* Ability to configure snapshots with both memory and/or quiesce options\n* Ability to configure disk adapter format\n* Additional debugging information including dry run execution\n* Support for VMs with both virtual/physical RDM (pRDM will be ignored and not backed up)\n* Support for global ghettoVCB configuration file\n* Support for VM exclusion list\n* Ability to backup all VMs residing on a specific host w/o specifying VM list\n* Implemented simple locking mechanism to ensure only 1 instance of ghettoVCB is running per host\n* Updated backup directory structure - rsync friendly\n* Additional logging and final status output\n* Logging of ghettoVCB PID (process ID)\n* Email backup logs\n* Rsync \"Link\" Support (Experimental Support)\n* Enhanced \"dryrun\" details including configuration and/or VMDK(s) issues\n* New storage debugging details pre/post backup\n* Quick email status summary\n* Support for individual VM backup via command-line\n* Support VM(s) with existing snapshots\n* Support multiple running instances of ghettoVCB\n* Configure VM shutdown/startup order\n* Support changing custom VM name during restore\n\n## Requirements:\n* VMs running on ESX(i) 3.5/4.x+/5.x/6.x/7.x/8.x\n* SSH console access to ESX(i) host\n\n## Download\n\nLatest ghettoVCB VIB and Offline Bundle can be downloaded from [here](https://github.com/lamw/ghettoVCB/releases)\n\n## Install\n\nYou can quickly install/update ghettoVCB by downloading and installing either the [VIB or offline bundle](https://github.com/lamw/ghettoVCB/releases) using the following commands. If you wish to update to latest ghettoVCB release and are using the ghettovcb.conf file and wish to have your settings persist, make sure to use the *update* command instead of *install*\n\nOnce installed, you will find all ghettoVCB configuration files located in:\n```console\n/opt/ghettovcb/ghettoVCB.conf\n/opt/ghettovcb/ghettoVCB-restore_vm_restore_configuration_template\n/opt/ghettovcb/ghettoVCB-vm_backup_configuration_template\n```\n\nBoth ghettoVCB and ghettoVCB-restore scripts are located in:\n```console\n/opt/ghettovcb/bin/ghettoVCB.sh\n/opt/ghettovcb/bin/ghettoVCB-restore.sh\n```\n\n### For ESXi 5.x to 6.x\n\nInstall VIB\n```\nesxcli software vib install -v /vghetto-ghettoVCB-7x.vib -f\n```\n\nUpdate VIB\n```\nesxcli software vib update -v /vghetto-ghettoVCB-7x.vib -f\n```\n\nRetrieve installation\n```console\nesxcli software vib get -n ghettoVCB\n```\n\n### For ESXi 7.x\n\nInstall VIB\n```\nesxcli software vib install -v /vghetto-ghettoVCB-7x.vib -f\n```\n\nInstall offline bundle\n```\nesxcli software vib install -d /vghetto-ghettoVCB-offline-bundle-7x.zip -f\n```\n\nUpdate VIB\n```\nesxcli software vib update -v /vghetto-ghettoVCB-7x.vib -f\n```\n\nUpdate offline bundle\n```\nesxcli software vib update -d /vghetto-ghettoVCB-offline-bundle-7x.zip -f\n```\n\nRetrieve installation\n```console\nesxcli software vib get -n ghettoVCB\n```\n\n### For ESXi 8.x and later\n\nInstall VIB\n```\nesxcli software vib install -v /vghetto-ghettoVCB-8x.vib -f\n```\n\nInstall offline bundle\n```\nesxcli software vib install -d /vghetto-ghettoVCB-offline-bundle-8x.zip -f\n```\n\nUpdate VIB\n```\nesxcli software vib update -v /vghetto-ghettoVCB-8x.vib -f\n```\n\nUpdate offline bundle\n```\nesxcli software vib update -d /vghetto-ghettoVCB-offline-bundle-8x.zip -f\n```\n\nRetrieve installation\n```console\nesxcli software vib get -n ghettoVCB\n```\n\n## Uninstall\n\nRemove ghettoVCB\n\n```console\nesxcli software vib remove -n ghettoVCB\n```\n\n\u003e **Note:** If the installation takes some time. Just wait. This is normal.\n\n## Build VIB and Offline Bundle\n\nSee the build documentation [here](build/README.md)\n\n## Configuration Options\n\nThe following variables need to be defined within the script or in VM backup policy prior to execution.\n\nDefining the backup datastore and folder in which the backups are stored (if folder does not exist, it will automatically be created):\n\n```console\nVM_BACKUP_VOLUME=/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS\n```\n\nDefining the backup disk format (zeroedthick, eagerzeroedthick, thin, and 2gbsparse are available):\n```console\nDISK_BACKUP_FORMAT=thin\n```\n\n\u003e **Note:** If you are using the 2gbsparse on an ESXi 5.1 host, backups may fail. Please download the latest version of the ghettoVCB script which automatically resolves this or take a look at [this article](https://williamlam.com/2012/09/2gbsparse-disk-format-no-longer-working.html) for the details.\n\nDefining the backup rotation per VM:\n```console\nVM_BACKUP_ROTATION_COUNT=3\n```\n\nDefining whether the VM is powered down or not prior to backup (1 = enable, 0 = disable):\n```console\nPOWER_VM_DOWN_BEFORE_BACKUP=0\n```\n\n\u003e **Note:** VM(s) that are powered off will not require snapshotting\n\nDefining whether the VM can be hard powered off when `POWER_VM_DOWN_BEFORE_BACKUP` is enabled and VM does not have VMware Tools installed\n```console\nENABLE_HARD_POWER_OFF=0\n```\n\nIf `ENABLE_HARD_POWER_OFF` is enabled, then this defines the number of (60sec) iterations the script will before executing a hard power off when:\n```console\nITER_TO_WAIT_SHUTDOWN=3\n```\n\nThe number (60sec) iterations the script will wait when powering off the VM and will give up and ignore the particular VM for backup:\n```console\nPOWER_DOWN_TIMEOUT=5\n```\n\nThe number (60sec) iterations the script will wait when taking a snapshot of a VM and will give up and ignore the particular VM for  backup:\n```console\nSNAPSHOT_TIMEOUT=15\n```\n\nDefining whether or not to enable compression (1 = enable, 0 = disable):\n```console\nENABLE_COMPRESSION=0\n```\n\n\u003e **Note:** With ESXi 3.x/4.x/5.x, there is a limitation of the maximum size of a VM for compression within the unsupported Busybox Console which _should_ not affect backups running classic ESX 3.x,4.x or 5.x. On ESXi 3.x the 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. **PLEASE TEST THE RESTORE PROCESS BEFORE MOVING TO PRODUCTION SYSTEMS!**. Please note, do not mix uncompressed backups with  compressed backups. Ensure that directories selected for backups do not contain any backups with previous versions of ghettoVCB before enabling  and implementing the compressed backups feature.\n\nDefining whether virtual machine memory is snapped and if quiescing is enabled (1 = enable, 0 = disable):\n```console\nVM_SNAPSHOT_MEMORY=0\nVM_SNAPSHOT_QUIESCE=0\n```\n\n\u003e **Note:** `VM_SNAPSHOT_MEMORY` is only used to ensure when the snapshot is taken, it's memory contents  are also captured. This is only relevant to the actual snapshot and it's  not used in any shape/way/form in regards to the backup. All backups  taken whether your VM is running or offline will result in an offline VM  backup when you restore. This was originally added for debugging  purposes and in generally should be left disabled\n\nDefining VMDK(s) to backup from a particular VM either a list of vmdks or \"all\"\n```console\nVMDK_FILES_TO_BACKUP=\"myvmdk.vmdk\"\n```\n\nDefining whether or not VM(s) with existing snapshots can be backed up. This flag means it will **CONSOLIDATE ALL EXISTING SNAPSHOTS** for a VM prior to starting the backup (1 = yes, 0 = no):\n```console\nALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=0\n```\n\nDefining the order of which VM(s) should be shutdown first, especially if there is a dependency between multiple VM(s). This should be a comma separated list of VM(s)\n```console\nVM_SHUTDOWN_ORDER=vm1,vm2,vm3\n```\n\nDefining the order of VM(s) that should be started up first after backups have completed, especially if there is a dependency between multiple VM(s). This should be a comma separated list of VM(s)\n```console\nVM_STARTUP_ORDER=vm3,vm2,vm1\n```\n\nDefining NON-PERSISTENT NFS Backup Volume (1 = yes, 0 = no):\n```console\nENABLE_NON_PERSISTENT_NFS=0\n```\n\n\u003e **Note:** This is meant for environments that do not want a persisted connection to their NFS backup volume and allows the NFS volume to only be mounted during backups. The script expects the following 5 variables to be defined if this is to be used: `UNMOUNT_NFS`, `NFS_SERVER`, `NFS_MOUNT`, `NFS_LOCAL_NAME` and `NFS_VM_BACKUP_DIR`\n\nDefining whether or not to unmount the NFS backup volume (1 = yes, 0 = no):\n```console\nUNMOUNT_NFS=0\n```\n\nDefining the NFS server address (IP/hostname):\n```console\nNFS_SERVER=172.51.0.192\n```\n\nDefining the NFS export path:\n```console\nNFS_MOUNT=/upload\n```\n\nDefining the NFS datastore name:\n```console\nNFS_LOCAL_NAME=backup\n```\n\nDefining the NFS backup directory for VMs:\n```console\nNFS_VM_BACKUP_DIR=mybackups\n```\n\n\u003e **Note:** Only supported if you are running vSphere 4. and later. If you are having issues with sending mail, please take a look at Email Backup Log section\n\nDefining whether or not to email backup logs (1 = yes, 0 = no):\n```console\nEMAIL_LOG=1\n```\n\nDefining whether or not to email message will be deleted off the host  whether it is successful in sending, this is used for debugging  purposes. (1 = yes, 0 = no):\n```console\nEMAIL_DEBUG=1\n```\n\nDefining email server:\n```console\nEMAIL_SERVER=auroa.primp-industries.com\n```\n\nDefining email server port:\n```console\nEMAIL_SERVER_PORT=25\n```\n\nDefining email delay interval (useful if you have slow SMTP server and would like to include a delay in netcat using -i param, default is 1second):\n```console\nEMAIL_DELAY_INTERVAL=1\n```\n\nDefining recipient of the email (comma separated):\n```console\nEMAIL_TO=auroa@primp-industries.com\n```\n\nDefining from user which may require specific domain entry depending on email server configurations:\n```console\nEMAIL_FROM=root@ghettoVCB\n```\n\n\u003e **Note:** nc (netcat) utility must be present for email support to function, this utility is a now a default with the release of vSphere 4.1 or greater, previous releases of VI 3.5 and/or vSphere 4.0 does not contain this utility. The reason this is listed as experimental is it may not be compatible with all email servers as the script utlizes nc (netcat) utility to communicate to an email server. This feature is  provided as-is with no guarantees. If you enable this feature, a  separate log will be generated along side  any normal logging which will be used to email recipient. If for whatever reason, the email fails to  send, an entry will appear per the normal logging mechanism.\n\nIf you are running ESXi 5.1 and later, you will need to create a custom firewall rule to allow your email traffic to go out which I will assume is default port 25. Here are the steps for creating a custom email rule.\n\nStep 1 - Create a file called /etc/vmware/firewall/email.xml with contains the following:\n```console\n\u003cConfigRoot\u003e\n  \u003cservice\u003e\n    \u003cid\u003eemail\u003c/id\u003e\n    \u003crule id=\"0000\"\u003e\n      \u003cdirection\u003eoutbound\u003c/direction\u003e\n      \u003cprotocol\u003etcp\u003c/protocol\u003e\n      \u003cporttype\u003edst\u003c/porttype\u003e\n      \u003cport\u003e25\u003c/port\u003e\n    \u003c/rule\u003e\n    \u003cenabled\u003etrue\u003c/enabled\u003e\n    \u003crequired\u003efalse\u003c/required\u003e\n  \u003c/service\u003e\n\u003c/ConfigRoot\u003e\n```\n\nStep 2 - Reload the ESXi firewall by running the following ESXCLI command:\n```console\n# esxcli network firewall refresh\n```\n\nStep 3 - Confirm that your email rule has been loaded by running the following ESXCLI command:\n```console\n# esxcli network firewall ruleset list | grep email\nemail                  true\n```\n\nStep 4 - Connect to your email server by using nc (netcat) by running the following command and specifying the IP Address/Port of your email server:\n```console\n\n# nc 172.30.0.107 25\n220 mail.primp-industries.com ESMTP Postfix\n```\n\nYou should receive a response from your email server and you can enter Ctrl+C to exit. This custom ESXi firewall rule will not persist after a reboot, so you should create a custom VIB to ensure it persists after a system reboot. Please take a look at [this article](https://williamlam.com/2023/07/creating-a-custom-vib-for-esxi-8-x.html) for the details.\n\n\nDefining to support RSYNC symbolic link creation (1 = yes, 0 = no):\n```console\nRSYNC_LINK=0\n```\n\nTo make use of this feature, modify the variable RSYNC_LINK from 0  to 1. Please note, this is an experimental feature request from users that rely on rsync to replicate changes from one datastore volume to  another datastore volume. The premise of this feature is to have a standardized folder that rsync can monitor for changes to replicate to  another backup datastore. When this feature is enabled, a symbolic link  will be generated with the format of \"\u003cVMNAME\u003e-symlink\" and will  reference the latest successful VM backup. You can then rely on this  symbolic link to watch for changes and replicate to your backup  datastore.\n\nHere is an example of what this would look like:\n```console\n[root@himalaya ghettoVCB]# ls -la /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/vcma/\ntotal 0\ndrwxr-xr-x 1 nobody nobody 110 Sep 27 08:08 .\ndrwxr-xr-x 1 nobody nobody  17 Sep 16 14:01 ..\nlrwxrwxrwx 1 nobody nobody  89 Sep 27 08:08 vcma-symlink -\u003e /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/vcma/vcma-2010-09-27_08-07-37\ndrwxr-xr-x 1 nobody nobody  58 Sep 27 08:04 vcma-2010-09-27_08-04-26\ndrwxr-xr-x 1 nobody nobody  58 Sep 27 08:06 vcma-2010-09-27_08-05-55\ndrwxr-xr-x 1 nobody nobody  58 Sep 27 08:08 vcma-2010-09-27_08-07-37\n```\n\n\u003e **Note:** This enables an automatic creation of a generic symbolic link (both a  relative \u0026 absolution path) in which users can refer to run  replication backups using rsync from a remote host. This does not  actually support rsync backups with ghettoVCB. Please take a look at the  Rsync Section of the documentation for more details.\n\nA sample global ghettoVCB configuration file is included with the download called ghettoVCB.conf. It contains the same variables as defined from above and allows a user  to customize and define multiple global configurations based on a user's environment.\n\n```console\n# cat ghettoVCB.conf\nVM_BACKUP_VOLUME=/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS\nDISK_BACKUP_FORMAT=thin\nVM_BACKUP_ROTATION_COUNT=3\nPOWER_VM_DOWN_BEFORE_BACKUP=0\nENABLE_HARD_POWER_OFF=0\nITER_TO_WAIT_SHUTDOWN=3\nPOWER_DOWN_TIMEOUT=5\nENABLE_COMPRESSION=0\nVM_SNAPSHOT_MEMORY=0\nVM_SNAPSHOT_QUIESCE=0\nALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=0\nENABLE_NON_PERSISTENT_NFS=0\nUNMOUNT_NFS=0\nNFS_SERVER=172.30.0.195\nNFS_MOUNT=/nfsshare\nNFS_LOCAL_NAME=nfs_storage_backup\nNFS_VM_BACKUP_DIR=mybackups\nSNAPSHOT_TIMEOUT=15\nEMAIL_LOG=0\nEMAIL_SERVER=auroa.primp-industries.com\nEMAIL_SERVER_PORT=25\nEMAIL_DELAY_INTERVAL=1\nEMAIL_TO=auroa@primp-industries.com\nEMAIL_FROM=root@ghettoVCB\nWORKDIR_DEBUG=0\nVM_SHUTDOWN_ORDER=\nVM_STARTUP_ORDER=\n```\n\nTo override any existing configurations within the ghettoVCB.sh script and to use a global configuration file, user just needs to specify the -g flag and path to global configuration file.\n\nRunning multiple instances of ghettoVCB is now supported with the latest release by specifying the working directory (-w) flag.\n\nBy default, the working directory of the ghettoVCB instance is /tmp/ghettoVCB.work and you can run another instance by providing an alternate working directory. You should try to minimize the number of ghettoVCB instances running on your ESXi host as it does consume some amount of resources when running in the ESXi Shell. This is considered an experimental feature, so please test in a development environment to ensure everything is working prior to moving to production system.\n\n## Usage\n\n```\n# /opt/ghettovcb/bin/ghettoVCB.sh\n###############################################################################\n#\n# ghettoVCB for ESX/ESXi 3.5, 4.x, 5.x, 6.x, 7.x \u0026 8.x\n# Author: William Lam\n# http://www.virtuallyghetto.com/\n# Documentation: http://communities.vmware.com/docs/DOC-8760\n# Created: 11/17/2008\n# Last modified: 2023_09_29 Version 1\n#\n###############################################################################\n\nUsage: ghettoVCB.sh [options]\n\nOPTIONS:\n   -a     Backup all VMs on host\n   -f     List of VMs to backup\n   -m     Name of VM to backup (overrides -f)\n   -j     Job name to show in email report subject (makes sense only in conjunction with -f)\n   -c     VM configuration directory for VM backups\n   -g     Path to global ghettoVCB configuration file\n   -l     File to output logging\n   -w     ghettoVCB work directory (default: /tmp/ghettoVCB.work)\n   -d     Debug level [info|debug|dryrun] (default: info)\n\n(e.g.)\n\nBackup list of VMs from a file (optionally include a job name for the email report)\n\t/opt/ghettovcb/bin/ghettoVCB.sh -f vms_to_backup [ -j myJob ]\n\nBackup a single VM\n\t/opt/ghettovcb/bin/ghettoVCB.sh -m vm_to_backup\n\nBackup all VMs residing on this host\n\t/opt/ghettovcb/bin/ghettoVCB.sh -a\n\nBackup all VMs residing on this host except for the VMs in the exclusion list\n\t/opt/ghettovcb/bin/ghettoVCB.sh -a -e vm_exclusion_list\n\nBackup VMs based on specific configuration located in directory\n\t/opt/ghettovcb/bin/ghettoVCB.sh -f vms_to_backup -c vm_backup_configs\n\nBackup VMs using global ghettoVCB configuration file\n\t/opt/ghettovcb/bin/ghettoVCB.sh -f vms_to_backup -g /global/ghettoVCB.conf\n\nOutput will log to /tmp/ghettoVCB.log (consider logging to local or remote datastore to persist logs)\n\t/opt/ghettovcb/bin/ghettoVCB.sh -f vms_to_backup -l /vmfs/volume/local-storage/ghettoVCB.log\n\nDry run (no backup will take place)\n\t/opt/ghettovcb/bin/ghettoVCB.sh -f vms_to_backup -d dryrun\n```\n\nThe input to this script is a file that contains the display name of the  virtual machine(s) separated by a newline. When creating this file on a non-Linux/UNIX system, you may introduce ^M character which can cause  the script to miss-behave. To ensure this does not occur, please create the file on the ESX/ESXi host.\n\nHere is a sample of what the file would look like:\n```console\n[root@himalaya ~]# cat vms_to_backup\nvCOPS\nvMA\nvCloudConnector\n```\n\n## Sample Execution:\n\n### Dry Run\n\nThis execution mode provides a quick summary of details on whether a given set of VM(s)/VMDK(s) will be backed up. It provides additional information such as VMs that may have snapshots, VMDK(s) that are configured as independent disks, or other issues that may cause a VM or VMDK to not backed up.\n\n* Log verbosity: dryrun\n* Log output: stdout \u0026 /tmp (default)\n    * Logs by default will be stored in /tmp, these log files may not persist through reboots, especially when dealing with ESXi. You should log to either a local or remote datastore to ensure that logs are kept upon a reboot.\n\n```console\n[root@himalaya]# /opt/ghettovcb/bin/ghettoVCB.sh -f vms_to_backup -d dryrun\nLogging output to \"/tmp/ghettoVCB-2011-03-13_15-19-57.log\" ...\n2011-03-13 15:19:57 -- info: ============================== ghettoVCB LOG START ==============================\n\n2011-03-13 15:19:57 -- info: CONFIG - VERSION = 2011_03_13_1\n2011-03-13 15:19:57 -- info: CONFIG - GHETTOVCB_PID = 30157\n2011-03-13 15:19:57 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS\n2011-03-13 15:19:57 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3\n2011-03-13 15:19:57 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2011-03-13_15-19-57\n2011-03-13 15:19:57 -- info: CONFIG - DISK_BACKUP_FORMAT = thin\n2011-03-13 15:19:57 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0\n2011-03-13 15:19:57 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0\n2011-03-13 15:19:57 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3\n2011-03-13 15:19:57 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5\n2011-03-13 15:19:57 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15\n2011-03-13 15:19:57 -- info: CONFIG - LOG_LEVEL = dryrun\n2011-03-13 15:19:57 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB-2011-03-13_15-19-57.log\n2011-03-13 15:19:57 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0\n2011-03-13 15:19:57 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0\n2011-03-13 15:19:57 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all\n2011-03-13 15:19:57 -- info: CONFIG - EMAIL_LOG = 0\n2011-03-13 15:19:57 -- info:\n2011-03-13 15:19:57 -- dryrun: ###############################################\n2011-03-13 15:19:57 -- dryrun: Virtual Machine: scofield\n2011-03-13 15:19:57 -- dryrun: VM_ID: 704\n2011-03-13 15:19:57 -- dryrun: VMX_PATH: /vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield.vmx\n2011-03-13 15:19:57 -- dryrun: VMX_DIR: /vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield\n2011-03-13 15:19:57 -- dryrun: VMX_CONF: scofield/scofield.vmx\n2011-03-13 15:19:57 -- dryrun: VMFS_VOLUME: himalaya-local-SATA.RE4-GP:Storage\n2011-03-13 15:19:57 -- dryrun: VMDK(s):\n2011-03-13 15:19:58 -- dryrun:  scofield_3.vmdk 3 GB\n2011-03-13 15:19:58 -- dryrun:  scofield_2.vmdk 2 GB\n2011-03-13 15:19:58 -- dryrun:  scofield_1.vmdk 1 GB\n2011-03-13 15:19:58 -- dryrun:  scofield.vmdk   5 GB\n2011-03-13 15:19:58 -- dryrun: INDEPENDENT VMDK(s):\n2011-03-13 15:19:58 -- dryrun: TOTAL_VM_SIZE_TO_BACKUP: 11 GB\n2011-03-13 15:19:58 -- dryrun: ###############################################\n\n2011-03-13 15:19:58 -- dryrun: ###############################################\n2011-03-13 15:19:58 -- dryrun: Virtual Machine: vMA\n2011-03-13 15:19:58 -- dryrun: VM_ID: 1440\n2011-03-13 15:19:58 -- dryrun: VMX_PATH: /vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/vMA/vMA.vmx\n2011-03-13 15:19:58 -- dryrun: VMX_DIR: /vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/vMA\n2011-03-13 15:19:58 -- dryrun: VMX_CONF: vMA/vMA.vmx\n2011-03-13 15:19:58 -- dryrun: VMFS_VOLUME: himalaya-local-SATA.RE4-GP:Storage\n2011-03-13 15:19:58 -- dryrun: VMDK(s):\n2011-03-13 15:19:58 -- dryrun:  vMA-000002.vmdk 5 GB\n2011-03-13 15:19:58 -- dryrun: INDEPENDENT VMDK(s):\n2011-03-13 15:19:58 -- dryrun: TOTAL_VM_SIZE_TO_BACKUP: 5 GB\n2011-03-13 15:19:58 -- dryrun: Snapshots found for this VM, please commit all snapshots before continuing!\n2011-03-13 15:19:58 -- dryrun: THIS VIRTUAL MACHINE WILL NOT BE BACKED UP DUE TO EXISTING SNAPSHOTS!\n2011-03-13 15:19:58 -- dryrun: ###############################################\n\n2011-03-13 15:19:58 -- dryrun: ###############################################\n2011-03-13 15:19:58 -- dryrun: Virtual Machine: vCloudConnector\n2011-03-13 15:19:58 -- dryrun: VM_ID: 2064\n2011-03-13 15:19:58 -- dryrun: VMX_PATH: /vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/vCloudConnector/vCloudConnector.vmx\n2011-03-13 15:19:58 -- dryrun: VMX_DIR: /vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/vCloudConnector\n2011-03-13 15:19:58 -- dryrun: VMX_CONF: vCloudConnector/vCloudConnector.vmx\n2011-03-13 15:19:58 -- dryrun: VMFS_VOLUME: himalaya-local-SATA.RE4-GP:Storage\n2011-03-13 15:19:58 -- dryrun: VMDK(s):\n2011-03-13 15:19:59 -- dryrun:  vCloudConnector.vmdk    3 GB\n2011-03-13 15:19:59 -- dryrun: INDEPENDENT VMDK(s):\n2011-03-13 15:19:59 -- dryrun:  vCloudConnector_1.vmdk  40 GB\n2011-03-13 15:19:59 -- dryrun: TOTAL_VM_SIZE_TO_BACKUP: 3 GB\n2011-03-13 15:19:59 -- dryrun: Snapshots can not be taken for independent disks!\n2011-03-13 15:19:59 -- dryrun: THIS VIRTUAL MACHINE WILL NOT HAVE ALL ITS VMDKS BACKED UP!\n2011-03-13 15:19:59 -- dryrun: ###############################################\n\n2011-03-13 15:19:59 -- info: ###### Final status: OK, only a dryrun. ######\n\n2011-03-13 15:19:59 -- info: ============================== ghettoVCB LOG END ================================\n```\n\nIn the example above, we have 3 VMs to be backed up:\n\n* scofield has 4 VMDK(s) that total up to 11GB and does not contain any snapshots/independent disks and this VM should backup without any issues\n* vMA has 1 VMDK but it also contains a snapshot and clearly this VM will not be backed up until the snapshot has been committed\n* vCloudConnector has 2 VMDK(s), one which is 3GB and another which is 40GB and configured as an independent disk. Since snapshots do not affect independent disk, only the 3GB VMDK will be backed up for this VM as denoted by the \"TOTAL_VM_SIZE_TO_BACKUP\"\n\n### Debug\n\nThis execution modes provides more in-depth information about environment/backup process including additional storage debugging information which provides information about both the source/destination datastore pre and post backups. This can be very useful in troubleshooting backups\n\n* Log verbosity: debug\n* Log output: stdout \u0026 /tmp (default)\n    * Logs by default will be stored in /tmp, these log files may not persist  through reboots, especially when dealing with ESXi. You should log to  either a local or remote datastore to ensure that logs are kept upon a reboot.\n\n```console\n[root@himalaya]# /opt/ghettovcb/bin/ghettoVCB.sh -f vms_to_backup -d debug\nLogging output to \"/tmp/ghettoVCB-2011-03-13_15-27-59.log\" ...\n2011-03-13 15:27:59 -- info: ============================== ghettoVCB LOG START ==============================\n\n2011-03-13 15:27:59 -- debug: Succesfully acquired lock directory - /tmp/ghettoVCB.lock\n\n2011-03-13 15:27:59 -- debug: HOST VERSION: VMware ESX 4.1.0 build-260247\n2011-03-13 15:27:59 -- debug: HOST LEVEL: VMware ESX 4.1.0 GA\n2011-03-13 15:27:59 -- debug: HOSTNAME: himalaya.primp-industries.com\n\n2011-03-13 15:27:59 -- info: CONFIG - VERSION = 2011_03_13_1\n2011-03-13 15:27:59 -- info: CONFIG - GHETTOVCB_PID = 31074\n2011-03-13 15:27:59 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS\n2011-03-13 15:27:59 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3\n2011-03-13 15:27:59 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2011-03-13_15-27-59\n2011-03-13 15:27:59 -- info: CONFIG - DISK_BACKUP_FORMAT = thin\n2011-03-13 15:27:59 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0\n2011-03-13 15:27:59 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0\n2011-03-13 15:27:59 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3\n2011-03-13 15:27:59 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5\n2011-03-13 15:27:59 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15\n2011-03-13 15:27:59 -- info: CONFIG - LOG_LEVEL = debug\n2011-03-13 15:27:59 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB-2011-03-13_15-27-59.log\n2011-03-13 15:27:59 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0\n2011-03-13 15:27:59 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0\n2011-03-13 15:27:59 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all\n2011-03-13 15:27:59 -- info: CONFIG - EMAIL_LOG = 0\n2011-03-13 15:27:59 -- info:\n2011-03-13 15:28:01 -- debug: Storage Information before backup:\n2011-03-13 15:28:01 -- debug: SRC_DATASTORE: himalaya-local-SATA.RE4-GP:Storage\n2011-03-13 15:28:01 -- debug: SRC_DATASTORE_CAPACITY: 1830.5 GB\n2011-03-13 15:28:01 -- debug: SRC_DATASTORE_FREE: 539.4 GB\n2011-03-13 15:28:01 -- debug: SRC_DATASTORE_BLOCKSIZE: 4\n2011-03-13 15:28:01 -- debug: SRC_DATASTORE_MAX_FILE_SIZE: 1024 GB\n2011-03-13 15:28:01 -- debug:\n2011-03-13 15:28:01 -- debug: DST_DATASTORE: dlgCore-NFS-bigboi.VM-Backups\n2011-03-13 15:28:01 -- debug: DST_DATASTORE_CAPACITY: 1348.4 GB\n2011-03-13 15:28:01 -- debug: DST_DATASTORE_FREE: 296.8 GB\n2011-03-13 15:28:01 -- debug: DST_DATASTORE_BLOCKSIZE: NA\n2011-03-13 15:28:01 -- debug: DST_DATASTORE_MAX_FILE_SIZE: NA\n2011-03-13 15:28:01 -- debug:\n2011-03-13 15:28:02 -- info: Initiate backup for scofield\n2011-03-13 15:28:02 -- debug: /usr/sbin/vmkfstools -i \"/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield_3.vmdk\" -a \"buslogic\" -d \"thin\" \"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/scofield/scofield-2011-03-13_15-27-59/scofield_3.vmdk\"\nDestination disk format: VMFS thin-provisioned\nCloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield_3.vmdk'...\nClone: 37% done.\n2011-03-13 15:28:04 -- debug: /usr/sbin/vmkfstools -i \"/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield_2.vmdk\" -a \"buslogic\" -d \"thin\" \"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/scofield/scofield-2011-03-13_15-27-59/scofield_2.vmdk\"\nDestination disk format: VMFS thin-provisioned\nCloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield_2.vmdk'...\nClone: 85% done.\n2011-03-13 15:28:05 -- debug: /usr/sbin/vmkfstools -i \"/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield_1.vmdk\" -a \"buslogic\" -d \"thin\" \"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/scofield/scofield-2011-03-13_15-27-59/scofield_1.vmdk\"\n\n2011-03-13 15:28:06 -- debug: /usr/sbin/vmkfstools -i \"/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield.vmdk\" -a \"buslogic\" -d \"thin\" \"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/scofield/scofield-2011-03-13_15-27-59/scofield.vmdk\"\nDestination disk format: VMFS thin-provisioned\nCloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield.vmdk'...\nClone: 78% done.\n2011-03-13 15:29:52 -- info: Backup Duration: 1.83 Minutes\n2011-03-13 15:29:52 -- info: Successfully completed backup for scofield!\n\n2011-03-13 15:29:54 -- debug: Storage Information after backup:\n2011-03-13 15:29:54 -- debug: SRC_DATASTORE: himalaya-local-SATA.RE4-GP:Storage\n2011-03-13 15:29:54 -- debug: SRC_DATASTORE_CAPACITY: 1830.5 GB\n2011-03-13 15:29:54 -- debug: SRC_DATASTORE_FREE: 539.4 GB\n2011-03-13 15:29:54 -- debug: SRC_DATASTORE_BLOCKSIZE: 4\n2011-03-13 15:29:54 -- debug: SRC_DATASTORE_MAX_FILE_SIZE: 1024 GB\n2011-03-13 15:29:54 -- debug:\n2011-03-13 15:29:54 -- debug: DST_DATASTORE: dlgCore-NFS-bigboi.VM-Backups\n2011-03-13 15:29:54 -- debug: DST_DATASTORE_CAPACITY: 1348.4 GB\n2011-03-13 15:29:54 -- debug: DST_DATASTORE_FREE: 296.8 GB\n2011-03-13 15:29:54 -- debug: DST_DATASTORE_BLOCKSIZE: NA\n2011-03-13 15:29:54 -- debug: DST_DATASTORE_MAX_FILE_SIZE: NA\n2011-03-13 15:29:54 -- debug:\n2011-03-13 15:29:55 -- debug: Storage Information before backup:\n2011-03-13 15:29:55 -- debug: SRC_DATASTORE: himalaya-local-SATA.RE4-GP:Storage\n2011-03-13 15:29:55 -- debug: SRC_DATASTORE_CAPACITY: 1830.5 GB\n2011-03-13 15:29:55 -- debug: SRC_DATASTORE_FREE: 539.4 GB\n2011-03-13 15:29:55 -- debug: SRC_DATASTORE_BLOCKSIZE: 4\n2011-03-13 15:29:55 -- debug: SRC_DATASTORE_MAX_FILE_SIZE: 1024 GB\n2011-03-13 15:29:55 -- debug:\n2011-03-13 15:29:55 -- debug: DST_DATASTORE: dlgCore-NFS-bigboi.VM-Backups\n2011-03-13 15:29:55 -- debug: DST_DATASTORE_CAPACITY: 1348.4 GB\n2011-03-13 15:29:55 -- debug: DST_DATASTORE_FREE: 296.8 GB\n2011-03-13 15:29:55 -- debug: DST_DATASTORE_BLOCKSIZE: NA\n2011-03-13 15:29:55 -- debug: DST_DATASTORE_MAX_FILE_SIZE: NA\n2011-03-13 15:29:55 -- debug:\n2011-03-13 15:29:55 -- info: Snapshot found for vMA, backup will not take place\n\n2011-03-13 15:29:57 -- debug: Storage Information before backup:\n2011-03-13 15:29:57 -- debug: SRC_DATASTORE: himalaya-local-SATA.RE4-GP:Storage\n2011-03-13 15:29:57 -- debug: SRC_DATASTORE_CAPACITY: 1830.5 GB\n2011-03-13 15:29:57 -- debug: SRC_DATASTORE_FREE: 539.4 GB\n2011-03-13 15:29:57 -- debug: SRC_DATASTORE_BLOCKSIZE: 4\n2011-03-13 15:29:57 -- debug: SRC_DATASTORE_MAX_FILE_SIZE: 1024 GB\n2011-03-13 15:29:57 -- debug:\n2011-03-13 15:29:57 -- debug: DST_DATASTORE: dlgCore-NFS-bigboi.VM-Backups\n2011-03-13 15:29:57 -- debug: DST_DATASTORE_CAPACITY: 1348.4 GB\n2011-03-13 15:29:57 -- debug: DST_DATASTORE_FREE: 296.8 GB\n2011-03-13 15:29:57 -- debug: DST_DATASTORE_BLOCKSIZE: NA\n2011-03-13 15:29:57 -- debug: DST_DATASTORE_MAX_FILE_SIZE: NA\n2011-03-13 15:29:57 -- debug:\n2011-03-13 15:29:58 -- info: Initiate backup for vCloudConnector\n2011-03-13 15:29:58 -- debug: /usr/sbin/vmkfstools -i \"/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/vCloudConnector/vCloudConnector.vmdk\" -a \"buslogic\" -d \"thin\" \"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/vCloudConnector/vCloudConnector-2011-03-13_15-27-59/vCloudConnector.vmdk\"\nDestination disk format: VMFS thin-provisioned\nCloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/vCloudConnector/vCloudConnector.vmdk'...\nClone: 97% done.\n2011-03-13 15:30:45 -- info: Backup Duration: 47 Seconds\n2011-03-13 15:30:45 -- info: WARN: vCloudConnector has some Independent VMDKs that can not be backed up!\n\n2011-03-13 15:30:45 -- info: ###### Final status: ERROR: Only some of the VMs backed up, and some disk(s) failed! ######\n\n2011-03-13 15:30:45 -- debug: Succesfully removed lock directory - /tmp/ghettoVCB.lock\n\n2011-03-13 15:30:45 -- info: ============================== ghettoVCB LOG END ================================\n```\n\n### Backup VMs stored in a list\n\n```console\n[root@himalaya ~]# /opt/ghettovcb/bin/ghettoVCB.sh -f vms_to_backup\n```\n\n### Backup Single VM using CLI\n```console\n[root@himalaya ~]# /opt/ghettovcb/bin/ghettoVCB.sh -m MyVM\n```\n\n### Backup All VMs residing on specific host\n```console\n[root@himalaya ~]# /opt/ghettovcb/bin/ghettoVCB.sh -a\n```\n\n### Backup All VMs residing on specific host and exclude the VMs in the exclusion list\n```console\n[root@himalaya ~]# /opt/ghettovcb/bin/ghettoVCB.sh -a -e vm_exclusion_list\n```\n\n### Backup VMs based on individual VM backup policies\n\n* Log verbosity: info (default)\n* Log output: /tmp/ghettoVCB.log\n * Logs by default will be stored in /tmp, these log files may not persist through reboots, especially when dealing with ESXi. You should log to  either a local or remote datastore to ensure that logs are kept upon a  reboot.\n\n1. Create folder to hold individual VM backup policies (can be named anything):\n```console\n[root@himalaya ~]# mkdir backup_config\n```\n\n2. Create individual VM backup policies for each VM that ensure each  file is named exactly as the display name of the VM being backed up (use  provided template to create duplicates):\n```console\n[root@himalaya]# cp /opt/ghettovcb/ghettoVCB-vm_backup_configuration_template scofield\n[root@himalaya]# cp /opt/ghettovcb/ghettoVCB-vm_backup_configuration_template vCloudConnector\n```\n\nListing of VM backup policy within backup configuration directory\n```console\n[root@himalaya backup_config]# ls\nghettoVCB-vm_backup_configuration_template  scofield  vCloudConnector\n```\n\nBackup policy for \"scofield\" (backup only 2 specific VMDKs)\n```console\n[root@himalaya backup_config]# cat scofield\nVM_BACKUP_VOLUME=/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS\nDISK_BACKUP_FORMAT=thin\nVM_BACKUP_ROTATION_COUNT=3\nPOWER_VM_DOWN_BEFORE_BACKUP=0\nENABLE_HARD_POWER_OFF=0\nITER_TO_WAIT_SHUTDOWN=4\nPOWER_DOWN_TIMEOUT=5\nSNAPSHOT_TIMEOUT=15\nENABLE_COMPRESSION=0\nVM_SNAPSHOT_MEMORY=0\nVM_SNAPSHOT_QUIESCE=0\nVMDK_FILES_TO_BACKUP=\"scofield_2.vmdk,scofield_1.vmdk\"\n```\n\nBackup policy for VM \"vCloudConnector\" (backup all VMDKs found)\n```console\n[root@himalaya backup_config]# cat vCloudConnector\nVM_BACKUP_VOLUME=/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS\nDISK_BACKUP_FORMAT=thin\nVM_BACKUP_ROTATION_COUNT=3\nPOWER_VM_DOWN_BEFORE_BACKUP=0\nENABLE_HARD_POWER_OFF=0\nITER_TO_WAIT_SHUTDOWN=4\nPOWER_DOWN_TIMEOUT=5\nSNAPSHOT_TIMEOUT=15\nENABLE_COMPRESSION=0\nVM_SNAPSHOT_MEMORY=0\nVM_SNAPSHOT_QUIESCE=0\nVMDK_FILES_TO_BACKUP=\"vCloudConnector.vmdk\"\n```\n\n\u003e **Note:** When specifying -c option (individual VM backup policy mode) if a VM is listed in the backup list but DOES NOT have a corresponding backup policy, the VM will be backed up using the default configuration found within the ghettoVCB.sh script.\n\nExecution of backup\n```console\n[root@himalaya ~]# /opt/ghettovcb/bin/ghettoVCB.sh -f vms_to_backup -c backup_config -l /tmp/ghettoVCB.log\n\n2011-03-13 15:40:50 -- info: ============================== ghettoVCB LOG START ==============================\n\n2011-03-13 15:40:51 -- info: CONFIG - USING CONFIGURATION FILE = backup_config//scofield\n2011-03-13 15:40:51 -- info: CONFIG - VERSION = 2011_03_13_1\n2011-03-13 15:40:51 -- info: CONFIG - GHETTOVCB_PID = 2967\n2011-03-13 15:40:51 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS\n2011-03-13 15:40:51 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3\n2011-03-13 15:40:51 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2011-03-13_15-40-50\n2011-03-13 15:40:51 -- info: CONFIG - DISK_BACKUP_FORMAT = thin\n2011-03-13 15:40:51 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0\n2011-03-13 15:40:51 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0\n2011-03-13 15:40:51 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 4\n2011-03-13 15:40:51 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5\n2011-03-13 15:40:51 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15\n2011-03-13 15:40:51 -- info: CONFIG - LOG_LEVEL = info\n2011-03-13 15:40:51 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB.log\n2011-03-13 15:40:51 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0\n2011-03-13 15:40:51 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0\n2011-03-13 15:40:51 -- info: CONFIG - VMDK_FILES_TO_BACKUP = scofield_2.vmdk,scofield_1.vmdk\n2011-03-13 15:40:51 -- info: CONFIG - EMAIL_LOG = 0\n2011-03-13 15:40:51 -- info:\n2011-03-13 15:40:53 -- info: Initiate backup for scofield\nDestination disk format: VMFS thin-provisioned\nCloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield_2.vmdk'...\nClone: 100% done.\n\nDestination disk format: VMFS thin-provisioned\nCloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield_1.vmdk'...\nClone: 100% done.\n\n2011-03-13 15:40:55 -- info: Backup Duration: 2 Seconds\n2011-03-13 15:40:55 -- info: Successfully completed backup for scofield!\n\n2011-03-13 15:40:57 -- info: CONFIG - VERSION = 2011_03_13_1\n2011-03-13 15:40:57 -- info: CONFIG - GHETTOVCB_PID = 2967\n2011-03-13 15:40:57 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS\n2011-03-13 15:40:57 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3\n2011-03-13 15:40:57 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2011-03-13_15-40-50\n2011-03-13 15:40:57 -- info: CONFIG - DISK_BACKUP_FORMAT = thin\n2011-03-13 15:40:57 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0\n2011-03-13 15:40:57 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0\n2011-03-13 15:40:57 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3\n2011-03-13 15:40:57 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5\n2011-03-13 15:40:57 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15\n2011-03-13 15:40:57 -- info: CONFIG - LOG_LEVEL = info\n2011-03-13 15:40:57 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB.log\n2011-03-13 15:40:57 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0\n2011-03-13 15:40:57 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0\n2011-03-13 15:40:57 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all\n2011-03-13 15:40:57 -- info: CONFIG - EMAIL_LOG = 0\n2011-03-13 15:40:57 -- info:\n2011-03-13 15:40:59 -- info: Snapshot found for vMA, backup will not take place\n\n2011-03-13 15:40:59 -- info: CONFIG - USING CONFIGURATION FILE = backup_config//vCloudConnector\n2011-03-13 15:40:59 -- info: CONFIG - VERSION = 2011_03_13_1\n2011-03-13 15:40:59 -- info: CONFIG - GHETTOVCB_PID = 2967\n2011-03-13 15:40:59 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS\n2011-03-13 15:40:59 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3\n2011-03-13 15:40:59 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2011-03-13_15-40-50\n2011-03-13 15:40:59 -- info: CONFIG - DISK_BACKUP_FORMAT = thin\n2011-03-13 15:40:59 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0\n2011-03-13 15:40:59 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0\n2011-03-13 15:40:59 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 4\n2011-03-13 15:40:59 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5\n2011-03-13 15:40:59 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15\n2011-03-13 15:40:59 -- info: CONFIG - LOG_LEVEL = info\n2011-03-13 15:40:59 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB.log\n2011-03-13 15:40:59 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0\n2011-03-13 15:40:59 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0\n2011-03-13 15:40:59 -- info: CONFIG - VMDK_FILES_TO_BACKUP = vCloudConnector.vmdk\n2011-03-13 15:40:59 -- info: CONFIG - EMAIL_LOG = 0\n2011-03-13 15:40:59 -- info:\n2011-03-13 15:41:01 -- info: Initiate backup for vCloudConnector\nDestination disk format: VMFS thin-provisioned\nCloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/vCloudConnector/vCloudConnector.vmdk'...\nClone: 100% done.\n\n2011-03-13 15:41:51 -- info: Backup Duration: 50 Seconds\n2011-03-13 15:41:51 -- info: WARN: vCloudConnector has some Independent VMDKs that can not be backed up!\n\n2011-03-13 15:41:51 -- info: ###### Final status: ERROR: Only some of the VMs backed up, and some disk(s) failed! ######\n\n2011-03-13 15:41:51 -- info: ============================== ghettoVCB LOG END ================================\n```\n## Enable compression for backups\n\nTo make use of this feature, modify the variable ENABLE_COMPRESSION from 0 to 1. Please note, do not mix uncompressed backups with  compressed backups. Ensure that directories selected for backups do not contain any backups with previous versions of ghettoVCB before enabling  and implementing the compressed backups feature.\n\n## Stopping ghettoVCB Process\n\nThere may be a situation where you need to stop the ghettoVCB process and entering Ctrl+C will only kill off the main ghettoVCB process, however there may still be other spawn processes that you may need to identify and stop. Below are two scenarios you may encounter and the process to completely stop all processes related to ghettoVCB.\n\n**Interactively running ghettoVCB:**\n\nStep 1 - Press Ctrl+C which will kill off the main ghettoVCB instance\n\nStep 2 - Search for any existing ghettoVCB process by running the following:\n```console\n# ps -c | grep ghettoVCB | grep -v grep\n3360136 3360136 tail                 tail -f /tmp/ghettoVCB.work/ghettovcb.Cs1M1x\n```\n\nStep 3 - Here we can see there is a tail command that was used in the script. We need to stop this process by using the kill command which accepts the PID (Process ID) which is identified by the first value on the far left hand side of the command. In this example, it is 3360136.\n```console\n# kill -9 3360136\n```\n\n\u003e **Note:** Make sure you identify the correct PID, else you could accidentally impact a running VM or worse your ESXi host.\n\nStep 4 - Depending on where you stopped the ghettoVCB process, you may need to consolidate or remove any existing snapshots that may exist on the VM that was being backed up. You can easily do so by using the vSphere Client.\n\n**Non-Interactively running ghettoVCB:**\n\nStep 1 - Search for the ghettoVCB process (you can also validate the PID from the logs)\n```console\n~ # ps -c | grep ghettoVCB | grep -v grep\n3360393 3360393 busybox              ash ./ghettoVCB.sh -f list -d debug\n3360790 3360790 tail                 tail -f /tmp/ghettoVCB.work/ghettovcb.deGeB7\n```\n\nStep 2 - Stop both the main ghettoVCB instance \u0026 tail command by using the kill command and specifying their respective PID IDs:\n```console\nkill -9 3360393\nkill -9 3360790\n```\n\nStep 3 - If a VM was in the process of being backed up, there is an additional process for the actual vmkfstools copy. You will need to identify the process for that and kill that as well. We will again use ps -c command and search for any vmkfstools that are running:\n```console\n# ps -c | grep vmkfstools | grep -v grep\n3360796 3360796 vmkfstools           /sbin/vmkfstools -i /vmfs/volumes/himalaya-temporary/VC-Windows/VC-Windows.vmdk -a lsilogic -d thin /vmfs/volumes/test-dont-use-this-volume/backups/VC-Windows/VC-Windows-2013-01-26_16-45-35/VC-Windows.vmdk\n```\n\nStep 4 - In case there is someone manually running a vmkfstools, make sure you take a look at the command itself and that it maps back to the current VM that was being backed up before kill the process. Once you have identified the proper PID, go ahead and use the kill command:\n```console\n# kill -9 3360796\n```\n\nStep 5 - Depending on where you stopped the  ghettoVCB process, you may need to consolidate or remove any existing  snapshots that may exist on the VM that was being backed up. You can  easily do so by using the vSphere Client.\n\n## Scheduling Backups using Cron\n\nFirst, please review this [primer on what is cronjob](https://web.archive.org/web/20231110163544/http://www.cyberciti.biz/faq/how-do-i-add-jobs-to-cron-under-linux-or-unix-oses/)\n\nThe task of configuring cronjobs on classic ESX servers (with Service Console) is no different than traditional cronjobs on *nix operating  systems (this procedure is outlined in the link above). With ESXi on the  other hand, additional factors need to be taken into account when  setting up cronjobs in the limited shell console called Busybox because changes made do not persist through a system reboot. The following document will outline steps to ensure that cronjob configurations are saved and present upon a reboot.\n\n\u003e **Note:** Always redirect the ghettoVCB output to /dev/null and/or to a log when automating via cron, this becomes very important as one user has identified a limited amount of buffer capacity in which once filled, may cause ghettoVCB to stop in the middle of a backup. This primarily only affects users on ESXi, but it is good practice to always redirect the output. Also ensure you are specifying the FULL PATH when referencing the ghettoVCB script, input or log files.\n\ne.g.\n```console\n0 0 * * 1-5 /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/ghettoVCB.sh -f /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/backuplist \u003e /dev/null\n```\nor\n\n```copnsole\n0 0 * * 1-5 /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/ghettoVCB.sh -f /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/backuplist \u003e /tmp/ghettoVCB.log\n```\n\nExample - Configure ghettoVCB.sh to execute a backup five days a week (M-F) at 12AM (midnight) everyday and send output to a unique log file\n\n\n### Configure on ESX:\n\n1. As root, you'll install your cronjob by issuing:\n```console\n[root@himalaya ~]# crontab -e\n```\n\n2. Append the following entry:\n```console\n0 0 * * 1-5 /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/ghettoVCB.sh -f /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/backuplist \u003e /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/ghettoVCB-backup-$(date +\\%s).log\n```\n\n3. Save and exit\n```console\n[root@himalaya dlgCore-NFS-bigboi.VM-Backups]# crontab -e\nno crontab for root - using an empty one\ncrontab: installing new crontab\n```\n\n4. List out and verify the cronjob that was just created:\n```console\n[root@himalaya dlgCore-NFS-bigboi.VM-Backups]# crontab -l\n0 0 * * 1-5 /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/ghettoVCB.sh -f /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/backuplist \u003e /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/ghettoVCB-backup-$(date +\\%s).log\n```\n\n### Configure on ESXi:\n\n1. Setup the cronjob by appending the following line to `/var/spool/cron/crontabs/root`:\n```console\n0 0 * * 1-5 /vmfs/volumes/simplejack-local-storage/ghettoVCB.sh -f /vmfs/volumes/simplejack-local-storage/backuplist \u003e /vmfs/volumes/simplejack-local-storage/ghettoVCB-backup-$(date +\\%s).log\n```\n\nIf you are unable to edit/modify `/var/spool/cron/crontabs/root`, please make a copy and then edit the copy with the changes\n```console\ncp /var/spool/cron/crontabs/root /var/spool/cron/crontabs/root.backup\n```\nOnce your changes have been made, then \"mv\" the backup to the original file. This may occur on ESXi 4.x or 5.x hosts\n```console\nmv /var/spool/cron/crontabs/root.backup /var/spool/cron/crontabs/root\n```\nYou can now verify the crontab entry has been updated by using \"cat\" utility.\n\n\n2. Kill the current crond (cron daemon) and then restart the crond for the changes to take affect:\n\nOn ESXi \u003c 3.5u3\n```console\nkill $(ps | grep crond | cut -f 1 -d ' ')\n```\n\nOn ESXi 3.5u3+\n```console\n~ # kill $(pidof crond)\n~ # crond\n```\n\nOn ESXi 4.x/5.0\n```console\n~ # kill $(cat /var/run/crond.pid)\n~ # busybox crond\n```\n\nOn ESXi 5.1 to 6.x\n```console\n~ # kill $(cat /var/run/crond.pid)\n~ # crond\n```\n\nOn ESXi 7.x\n```console\n~ # kill $(cat /var/run/crond.pid)\n~ # /usr/lib/vmware/busybox/bin/busybox crond\n```\n\n3. Now that the cronjob is ready to go, you need to ensure that this  cronjob will persist through a reboot. You'll need to add the following two lines to /etc/rc.local (ensure that the cron entry matches what was defined above). In ESXi 5.1, you will need to edit /etc/rc.local.d/local.sh instead of /etc/rc.local as that is no longer valid.\n\nOn ESXi 3.5\n```console\n/bin/kill $(pidof crond)\n/bin/echo \"0 0 * * 1-5 /vmfs/volumes/simplejack-local-storage/ghettoVCB.sh -f /vmfs/volumes/simplejack-local-storage/backuplist \u003e /vmfs/volumes/simplejack-local-storage/ghettoVCB-backup-\\$(date +\\\\%s).log\" \u003e\u003e /var/spool/cron/crontabs/root\ncrond\n```\n\nOn ESXi 4.x/5.0\n```console\n/bin/kill $(cat /var/run/crond.pid)\n/bin/echo \"0 0 * * 1-5 /vmfs/volumes/simplejack-local-storage/ghettoVCB.sh -f /vmfs/volumes/simplejack-local-storage/backuplist \u003e /vmfs/volumes/simplejack-local-storage/ghettoVCB-backup-\\$(date +\\\\%s).log\" \u003e\u003e /var/spool/cron/crontabs/root\n/bin/busybox crond\n```\n\nOn ESXi 5.1 to 6.x\n```console\n/bin/kill $(cat /var/run/crond.pid)\n/bin/echo \"0 0 * * 1-5 /vmfs/volumes/simplejack-local-storage/ghettoVCB.sh -f /vmfs/volumes/simplejack-local-storage/backuplist \u003e /vmfs/volumes/simplejack-local-storage/ghettoVCB-backup-\\$(date +\\\\%s).log\" \u003e\u003e /var/spool/cron/crontabs/root\ncrond\n```\n\nOn ESXi 7.x and later\n```console\n/bin/kill $(cat /var/run/crond.pid) \u003e /dev/null 2\u003e\u00261\n/bin/echo \"0 0 * * 1-5 /vmfs/volumes/simplejack-local-storage/ghettoVCB.sh -f /vmfs/volumes/simplejack-local-storage/backuplist \u003e /vmfs/volumes/simplejack-local-storage/ghettoVCB-backup-\\$(date +\\\\%s).log\" \u003e\u003e /var/spool/cron/crontabs/root\n/usr/lib/vmware/busybox/bin/busybox crond\n```\n\nAfterwards the file should look like the following:\n```console\n~ # cat /etc/rc.local\n#! /bin/ash\nexport PATH=/sbin:/bin\n\nlog() {\n   echo \"$1\"\n   logger init \"$1\"\n}\n\n#execute all service retgistered in /etc/rc.local.d\nif [http:// -d /etc/rc.local.d |http:// -d /etc/rc.local.d ]; then\n   for filename in `find /etc/rc.local.d/ | sort`\n      do\n         if [ -f $filename ] \u0026\u0026 [ -x $filename ]; then\n            log \"running $filename\"\n            $filename\n         fi\n      done\nfi\n\n/bin/kill $(cat /var/run/crond.pid)\n/bin/echo \"0 0 * * 1-5 /vmfs/volumes/simplejack-local-storage/ghettoVCB.sh -f /vmfs/volumes/simplejack-local-storage/backuplist \u003e /vmfs/volumes/simplejack-local-storage/ghettoVCB-backup-\\$(date +\\\\%s).log\" \u003e\u003e /var/spool/cron/crontabs/root\n/bin/busybox crond\n```\n\nThis will ensure that the cronjob is re-created upon a reboot of the system through a startup script\n\n2. To ensure that this is saved in the ESXi configuration, we need to manually initiate an ESXi backup by running:\n```console\n~ # /sbin/auto-backup.sh\nconfig implicitly loaded\nlocal.tgz\netc/vmware/vmkiscsid/vmkiscsid.db\netc/dropbear/dropbear_dss_host_key\netc/dropbear/dropbear_rsa_host_key\netc/opt/vmware/vpxa/vpxa.cfg\netc/opt/vmware/vpxa/dasConfig.xml\netc/sysconfig/network\netc/vmware/hostd/authorization.xml\netc/vmware/hostd/hostsvc.xml\netc/vmware/hostd/pools.xml\netc/vmware/hostd/vmAutoStart.xml\netc/vmware/hostd/vmInventory.xml\netc/vmware/hostd/proxy.xml\netc/vmware/ssl/rui.crt\netc/vmware/ssl/rui.key\netc/vmware/vmkiscsid/initiatorname.iscsi\netc/vmware/vmkiscsid/iscsid.conf\netc/vmware/vmware.lic\netc/vmware/config\netc/vmware/dvsdata.db\netc/vmware/esx.conf\netc/vmware/license.cfg\netc/vmware/locker.conf\netc/vmware/snmp.xml\netc/group\netc/hosts\netc/inetd.conf\netc/rc.local\netc/chkconfig.db\netc/ntp.conf\netc/passwd\netc/random-seed\netc/resolv.conf\netc/shadow\netc/sfcb/repository/root/interop/cim_indicationfilter.idx\netc/sfcb/repository/root/interop/cim_indicationhandlercimxml.idx\netc/sfcb/repository/root/interop/cim_listenerdestinationcimxml.idx\netc/sfcb/repository/root/interop/cim_indicationsubscription.idx\nBinary files /etc/vmware/dvsdata.db and /tmp/auto-backup.31345.dir/etc/vmware/dvsdata.db differ\nconfig implicitly loaded\nSaving current state in /bootbank\nClock updated.\nTime: 20:40:36   Date: 08/14/2009   UTC\n```\n\nNow you're really done!\n\nIf you're still having trouble getting the cronjob to work, ensure that  you've specified the correct parameters and there aren't any typos in  any part of the syntax.\n\nEnsure crond (cron daemon) is running:\n\nESX 3.x/4.0:\n```console\n[root@himalaya dlgCore-NFS-bigboi.VM-Backups]# ps -ef | grep crond | grep -v grep\nroot      2625     1  0 Aug13 ?        00:00:00 crond\n```\n\nESXi 3.x/4.x/5.x:\n```console\n~ # ps | grep crond | grep -v grep\n5196 5196 busybox              crond\n```\n\nEnsure that the date/time on your ESX(i) host is setup correctly:\n\nESX(i):\n```console\n[root@himalaya dlgCore-NFS-bigboi.VM-Backups]# date\nFri Aug 14 23:44:47 PDT 2009\n```\n\nNote: Careful attention must be noted if more than one backup is performed per day. Backup windows  should be staggered to avoid contention or saturation of resources  during these periods.\n\n## Restore Backups\n\nThe [ghettoVCB-restore.sh]() 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. Two main use cases are supported:\n\n1) Restore a VM that contains ALL VMDKs on one datastore\n2) Restore a VM that has VMDKs located on multiple datastores\n\nIn 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.\n\nFeatures\n* Support for logging output\n* Support for various debugging output\n* Allow spaces in VM(s) backup list (not recommended and not a best practice)\n* Support for restore in the following formats: ZEROEDTHICK (default behavior), 2GB SPARSE, THIN or EAGERZEROEDTHICK\n* Support changing custom VM name during restore\n\n### Usage\n\n```console\n[root@himalaya ~]# /opt/ghettovcb/bin/ghettoVCB-restore.sh\n###############################################################################\n#\n# ghettoVCB-restore for ESX/ESXi 3.5, 4.x and 5.x\n# Author: William Lam\n# http://www.virtuallyghetto.com/\n# Created: 08/18/2009\n# Last modified: 2011_11_19_1\n#\n###############################################################################\n\nUsage: ./ghettoVCB-restore.sh -c [VM_BACKUP_UP_LIST] -l [LOG_FILE] -d [DRYRUN_DEBUG_INFO]\n\nOPTIONS:\n   -c     VM backup list\n   -l     File ot output logging\n   -d     Dryrun/Debug Info [1|2]\n\n(e.g.)\n\nOutput will go to stdout\n        ./ghettoVCB-restore.sh -c vms_to_restore\n\nOutput will log to /tmp/ghettoVCB-restore.log\n        ./ghettoVCB-restore.sh -c vms_to_restore -l /tmp/ghettoVCB-restore.log\n\nDryrun/Debug Info (dryrun only)\n        ./ghettoVCB-restore.sh -c vms_to_restore -d 1\n        ./ghettoVCB-restore.sh -c vms_to_restore -d 2\n```\n\nStandard input for script is a file that contains:\n\n1) Full path to the backed up VM\n2) Full restore path\n3) Restoration disk format\n4) Restored VM Display Name (NEW!)\n\nReminder: 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.\n\nHere is a sample of what the file should look like:\n```console\n[root@himalaya ~]# cat vms_to_restore\n#\"\u003cDIRECTORY or .TGZ\u003e;\u003cDATASTORE_TO_RESTORE_TO\u003e;\u003cDISK_FORMAT_TO_RESTORE\u003e;\u003cOPTIONAL_RESTORED_VM_DISPLAY_NAME\u003e\"\n# DISK_FORMATS\n# 1 = zeroedthick\n# 2 = 2gbsparse\n# 3 = thin\n# 4 = eagerzeroedthick\n# e.g.\n# \"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/VCAP/VCAP-2009-08-18--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;1\"\n\"/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\"\n\"/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\"\n```\n\nComments in the input file is acceptable so long as the intended line is preceded by a #.\n\nThe above sample VM restore file, vms_to_restore, describes the following backup:\n| VM to restore                                                                      | Datastore to restore to              | VMDK format | Restore VM Name |\n|------------------------------------------------------------------------------------|--------------------------------------|-------------|-----------------|\n| /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 | thin        | VCSA-5.1        |\n| /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 | zeroedthick | VCSA-RESTORE    |\n\n### Sample Execution:\nPerform a dryrun by displaying debug information ( restore will not take place)\n\nDisplay debug information level 1:\n```console\n# /opt/ghettovcb/bin/ghettoVCB-restore.sh -c vms_to_restore -d 1\n\n################ DEBUG MODE ##############\nVirtual Machine: \"VCSA-5.1\"\nVM_ORIG_VMX: \"VCSA-5.1.vmx\"\nVM_ORG_FOLDER: \"VCSA-5.1-2012-12-25_01-30-36\"\nVM_RESTORE_VMX: \"VCSA-5.1.vmx\"\nVM_RESTORE_FOLDER: \"VCSA-5.1\"\nVMDK_LIST_TO_MODIFY:\nscsi0:0.fileName = \"VCSA-5.1.vmdk\"\nscsi0:0.fileName  = \"VCSA-5.1-0.vmdk\"\nscsi0:1.fileName = \"VCSA-5.1_1.vmdk\"\nscsi0:1.fileName  = \"VCSA-5.1-1.vmdk\"\n##########################################\n\n\n################ DEBUG MODE ##############\nVirtual Machine: \"VCSA-RESTORE\"\nVM_ORIG_VMX: \"VCSA-5.1.vmx\"\nVM_ORG_FOLDER: \"VCSA-5.1-2012-12-25_01-30-36\"\nVM_RESTORE_VMX: \"VCSA-RESTORE.vmx\"\nVM_RESTORE_FOLDER: \"VCSA-RESTORE\"\nVMDK_LIST_TO_MODIFY:\nscsi0:0.fileName = \"VCSA-5.1.vmdk\"\nscsi0:0.fileName  = \"VCSA-RESTORE-0.vmdk\"\nscsi0:1.fileName = \"VCSA-5.1_1.vmdk\"\nscsi0:1.fileName  = \"VCSA-RESTORE-1.vmdk\"\n##########################################\n\n\nStart time: Sun Jan 13 16:45:12 UTC 2013\nEnd   time: Sun Jan 13 16:45:14 UTC 2013\nDuration  : 2 Seconds\n```\n\nDisplay debug information level 2:\n```console\n[root@himalaya ~]# /opt/ghettovcb/bin/ghettoVCB-restore.sh -c vms_to_restore -d 2\n\n\n################## Restoring VM: VCSA-5.1  #####################\n==========\u003e DEBUG MODE LEVEL 2 ENABLED \u003c==========\nStart time: Sun Jan 13 16:45:35 UTC 2013\nRestoring VM from: \"/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36\"\nRestoring VM to Datastore: \"/vmfs/volumes/mini-local-datastore-1\" using Disk Format: \"thin\"\nCreating VM directory: \"/vmfs/volumes/mini-local-datastore-1/VCSA-5.1\" ...\nCopying \"VCSA-5.1.vmx\" file ...\nRestoring VM's VMDK(s) ...\nUpdating VMDK entry in \"VCSA-5.1.vmx\" file ...\n\nSOURCE: \"/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36/VCSA-5.1.vmdk\"\n    ORIGINAL_VMX_LINE: --\u003escsi0:0.fileName = \"VCSA-5.1.vmdk\"\u003c--\nDESTINATION: \"/vmfs/volumes/mini-local-datastore-1/VCSA-5.1/VCSA-5.1-0.vmdk\"\n    MODIFIED_VMX_LINE: --\u003escsi0:0.fileName  = \"VCSA-5.1-0.vmdk\"\u003c--\nUpdating VMDK entry in \"VCSA-5.1.vmx\" file ...\n\nSOURCE: \"/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36/VCSA-5.1_1.vmdk\"\n    ORIGINAL_VMX_LINE: --\u003escsi0:1.fileName = \"VCSA-5.1_1.vmdk\"\u003c--\nDESTINATION: \"/vmfs/volumes/mini-local-datastore-1/VCSA-5.1/VCSA-5.1-1.vmdk\"\n    MODIFIED_VMX_LINE: --\u003escsi0:1.fileName  = \"VCSA-5.1-1.vmdk\"\u003c--\nRegistering VCSA-5.1 ...\nEnd time: Sun Jan 13 16:45:35 UTC 2013\n################## Completed restore for VCSA-5.1! #####################\n\n################## Restoring VM: VCSA-RESTORE  #####################\n==========\u003e DEBUG MODE LEVEL 2 ENABLED \u003c==========\nStart time: Sun Jan 13 16:45:35 UTC 2013\nRestoring VM from: \"/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36\"\nRestoring VM to Datastore: \"/vmfs/volumes/mini-local-datastore-1\" using Disk Format: \"zeroedthick\"\nCreating VM directory: \"/vmfs/volumes/mini-local-datastore-1/VCSA-RESTORE\" ...\nCopying \"VCSA-5.1.vmx\" file ...\nRestoring VM's VMDK(s) ...\nUpdating VMDK entry in \"VCSA-RESTORE.vmx\" file ...\n\nSOURCE: \"/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36/VCSA-5.1.vmdk\"\n    ORIGINAL_VMX_LINE: --\u003escsi0:0.fileName = \"VCSA-5.1.vmdk\"\u003c--\nDESTINATION: \"/vmfs/volumes/mini-local-datastore-1/VCSA-RESTORE/VCSA-RESTORE-0.vmdk\"\n    MODIFIED_VMX_LINE: --\u003escsi0:0.fileName  = \"VCSA-RESTORE-0.vmdk\"\u003c--\nUpdating VMDK entry in \"VCSA-RESTORE.vmx\" file ...\n\nSOURCE: \"/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36/VCSA-5.1_1.vmdk\"\n    ORIGINAL_VMX_LINE: --\u003escsi0:1.fileName = \"VCSA-5.1_1.vmdk\"\u003c--\nDESTINATION: \"/vmfs/volumes/mini-local-datastore-1/VCSA-RESTORE/VCSA-RESTORE-1.vmdk\"\n    MODIFIED_VMX_LINE: --\u003escsi0:1.fileName  = \"VCSA-RESTORE-1.vmdk\"\u003c--\nRegistering VCSA-RESTORE ...\nEnd time: Sun Jan 13 16:45:35 UTC 2013\n################## Completed restore for VCSA-RESTORE! #####################\n\n\nStart time: Sun Jan 13 16:45:34 UTC 2013\nEnd   time: Sun Jan 13 16:45:35 UTC 2013\nDuration  : 1 Seconds\n\n---------------------------------------------------------------------------------------------------------------\n```\n\nExecute restore with output going to stdout (restore the first two VMs listed from above):\n\nInput file:\n```console\n[root@himalaya ~]# cat vms_to_restore\n\n\"/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\"\n\"/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\"\n```\n\n```console\n[root@himalaya ~]# /opt/ghettovcb/bin/ghettoVCB-restore.sh -c vms_to_restore\n\n################## Restoring VM: VCSA-5.1  #####################\nStart time: Sun Jan 13 16:46:41 UTC 2013\nRestoring VM from: \"/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36\"\nRestoring VM to Datastore: \"/vmfs/volumes/mini-local-datastore-1\" using Disk Format: \"thin\"\nCreating VM directory: \"/vmfs/volumes/mini-local-datastore-1/VCSA-5.1\" ...\nCopying \"VCSA-5.1.vmx\" file ...\nRestoring VM's VMDK(s) ...\nUpdating VMDK entry in \"VCSA-5.1.vmx\" file ...\nDestination disk format: VMFS thin-provisioned\nCloning disk '/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36/VCSA-5.1.vmdk'...\nClone: 100% done.\nUpdating VMDK entry in \"VCSA-5.1.vmx\" file ...\nDestination disk format: VMFS thin-provisioned\nCloning 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'...\nClone: 100% done.\nRegistering VCSA-5.1 ...\n34\nEnd time: Sun Jan 13 16:48:51 UTC 2013\n################## Completed restore for VCSA-5.1! #####################\n\n################## Restoring VM: VCSA-RESTORE  #####################\nStart time: Sun Jan 13 16:48:52 UTC 2013\nRestoring VM from: \"/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36\"\nRestoring VM to Datastore: \"/vmfs/volumes/mini-local-datastore-1\" using Disk Format: \"zeroedthick\"\nCreating VM directory: \"/vmfs/volumes/mini-local-datastore-1/VCSA-RESTORE\" ...\nCopying \"VCSA-5.1.vmx\" file ...\nRestoring VM's VMDK(s) ...\nUpdating VMDK entry in \"VCSA-RESTORE.vmx\" file ...\nDestination disk format: VMFS zeroedthick\nCloning disk '/vmfs/volumes/mini-local-datastore-2/backups/VCSA-5.1/VCSA-5.1-2012-12-25_01-30-36/VCSA-5.1.vmdk'...\nClone: 100% done.\nUpdating VMDK entry in \"VCSA-RESTORE.vmx\" file ...\nFailed to clone disk: There is not enough space on the file system for the selected operation (13).\nDestination disk format: VMFS zeroedthick\nCloning 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'...\nRegistering VCSA-RESTORE ...\n35\nEnd time: Sun Jan 13 16:50:19 UTC 2013\n################## Completed restore for VCSA-RESTORE! #####################\n\n\nStart time: Sun Jan 13 16:46:40 UTC 2013\nEnd   time: Sun Jan 13 16:50:19 UTC 2013\nDuration  : 3.65 Minutes\n\n\n---------------------------------------------------------------------------------------------------------------\n```\n\nExecute restore with output going to log file\n\n/tmp/ghettoVCB-restore.log (restore the last two VMs listed from above):\n```console\n[root@himalaya ~]# ./ghettoVCB-restore.sh -c vms_to_restore -l /tmp/ghettoVCB-restore.log\nLogging output to \"/tmp/ghettoVCB-restore.log\" ...\n```","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flamw%2Fghettovcb","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Flamw%2Fghettovcb","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flamw%2Fghettovcb/lists"}