{"id":4652,"date":"2019-03-13T12:11:02","date_gmt":"2019-03-13T15:11:02","guid":{"rendered":"https:\/\/blog.clusterweb.com.br\/?p=4652"},"modified":"2019-03-13T12:11:02","modified_gmt":"2019-03-13T15:11:02","slug":"free-alternative-for-backing-up-vms-for-esxi","status":"publish","type":"post","link":"https:\/\/blog.clusterweb.com.br\/?p=4652","title":{"rendered":"Free alternative for backing up VM&#8217;s for ESXi"},"content":{"rendered":"<h1>Table of Contents:<\/h1>\n<ul>\n<li style=\"list-style-type: none;\">\n<ul>\n<li>Description<\/li>\n<li>Features<\/li>\n<li>Requirements<\/li>\n<li>Setup<\/li>\n<li>Configurations<\/li>\n<li>Usage<\/li>\n<li>Sample Execution\n<ul>\n<li>Dry run Mode<\/li>\n<li>Debug backup Mode<\/li>\n<li>Backup VMs stored in a list<\/li>\n<li>Backup All VMs residing on specific ESX(i) host<\/li>\n<li>Backup All VMs residing on specific ESX(i) host and exclude the VMs in the exclusion list<\/li>\n<li>Backup VMs using individual backup policies<\/li>\n<\/ul>\n<\/li>\n<li>Enable compression for backups<\/li>\n<li>Email Backup Logs<\/li>\n<li>Restore backups (ghettoVCB-restore.sh)<\/li>\n<li>Cronjob FAQ<\/li>\n<li>Stopping ghettoVCB Process<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li style=\"list-style-type: none;\">\n<ul>\n<li>FAQ<\/li>\n<li>Our NFS Server Configuration<\/li>\n<li>Useful Links<\/li>\n<li>Change Log<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><!--more--><\/p>\n<h1>Description:<\/h1>\n<p>This script performs backups of virtual machines residing on\u00a0<strong>ESX(i) 3.5\/4.x\/5.x<\/strong>\u00a0servers using methodology similar to\u00a0<a class=\"jive-link-external\" href=\"http:\/\/www.vmware.com\/products\/vi\/consolidated_backup.html\">VMware&#8217;s VCB<\/a>\u00a0tool. The script takes snapshots of live running virtual machines, backs up the\u00a0 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 Service Console of the ESX server or Busybox Console (Tech Support Mode) of the ESXi server\u00a0 running the backups as opposed to following the traditional method of offloading virtual machine backups through a VCB proxy.<\/p>\n<p>This script has been tested on\u00a0<strong>ESX 3.5\/4.x\/5.x and ESXi 3.5\/4.x\/5.x<\/strong>\u00a0and supports the following backup mediums:\u00a0<strong>LOCAL STORAGE<\/strong>,\u00a0<strong>SAN<\/strong>\u00a0and\u00a0<strong>NFS<\/strong>. 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\u00a0 granular control over backup policies.<\/p>\n<p>Additionally, for ESX(i) environments that don&#8217;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\u00a0 *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:\u00a0<strong>VM_BACKUP_VOLUME<\/strong>\u00a0variable is ignored if\u00a0<strong>ENABLE_NON_PERSISTENT_NFS=1<\/strong>\u00a0).<\/p>\n<p>In 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\u00a0 it may not fit well into other environments.<\/p>\n<p>&nbsp;<\/p>\n<p>If you have any questions, you may post in the dedicated\u00a0<a class=\"jive-link-socialgroup-small\" href=\"https:\/\/communities.vmware.com\/groups\/ghettovcb\">ghettoVCB VMTN community group<\/a>.<\/p>\n<p>&nbsp;<\/p>\n<p>If you have found this script to be useful and would like to contribute back, please click\u00a0<a class=\"jive-link-external\" href=\"http:\/\/www.virtuallyghetto.com\/p\/how-you-can-help.html\">here<\/a>\u00a0to donate.<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Please read\u00a0ALL\u00a0documentation + FAQ&#8217;s before posting a question about an issue or problem. Thank You<br \/>\n<\/strong><\/p>\n<h1>Features<\/h1>\n<ul>\n<li>Online back up of VM(s)<\/li>\n<li>Support for multiple VMDK disk(s) backup per VM<\/li>\n<li>Only valid VMDK(s) presented to the VM will be backed up<\/li>\n<li>Ability to shutdown guestOS and initiate backup process and power on VM afterwards with the option of hard power timeout<\/li>\n<li>Allow spaces in VM(s) backup list (not recommended and not a best practice)<\/li>\n<li>Ensure that snapshot removal process completes prior to to continuing onto the next VM backup<\/li>\n<li>VM(s) that intially contain\u00a0<strong>snapshots<\/strong>\u00a0will not be backed up and will be ignored<\/li>\n<li>Ability to specify the number of backup rotations for VM<\/li>\n<li>Output back up VMDK(s) in either\u00a0<strong>ZEROEDTHICK<\/strong>\u00a0(default behavior) or\u00a0<strong>2GB SPARSE<\/strong>\u00a0or\u00a0<strong>THIN<\/strong>\u00a0or\u00a0<strong>EAGERZEROEDTHICK<\/strong>\u00a0format<\/li>\n<li>Support for both SCSI and IDE disks<\/li>\n<li>Non-persistent NFS backup<\/li>\n<li>Fully support VMDK(s) stored across multiple datastores<\/li>\n<li>Ability to compress backups (<strong>Experimental Support &#8211; Please refer to FAQ #25<\/strong>)<\/li>\n<li>Ability to configure individual VM backup policies<\/li>\n<li>Ability to include\/exclude specific VMDK(s) per VM (requires individual VM backup policy setup)<\/li>\n<li>Ability to configure logging output to file<\/li>\n<li>Independent disk awareness (will ignore VMDK)<\/li>\n<li>New timeout variables for shutdown and snapshot creations<\/li>\n<li>Ability to configure snapshots with both memory and\/or quiesce options<\/li>\n<li>Ability to configure disk adapter format<\/li>\n<li>Additional debugging information including dry run execution<\/li>\n<li>Support for VMs with both virtual\/physical RDM (pRDM will be ignored and not backed up)<\/li>\n<li>Support for global ghettoVCB configuration file<\/li>\n<li>Support for VM exclusion list<\/li>\n<li>Ability to backup all VMs residing on a specific host w\/o specifying VM list<\/li>\n<li>Implemented simple locking mechenism to ensure only 1 instance of ghettoVCB is running per host<\/li>\n<li>Updated backup directory structure &#8211; rsync friendly<\/li>\n<li>Additional logging and final status output<\/li>\n<li>Logging of ghettoVCB PID (proces id)<\/li>\n<li>Email backup logs (<strong>Experimental Suppport<\/strong>)<\/li>\n<li>Rsync &#8220;Link&#8221; Support (<strong>Experimental Suppport<\/strong>)<\/li>\n<li>Enhanced &#8220;dryrun&#8221; details including configuration and\/or VMDK(s) issues<\/li>\n<li>New storage debugging details pre\/post backup<\/li>\n<li>Quick email status summary<\/li>\n<li>Updated ghettoVCB documentation<\/li>\n<li>ghettoVCB available via github<strong><br \/>\n<\/strong><\/li>\n<li><strong>Support for ESXi 5.1\u00a0<\/strong><strong>NEW!<\/strong><\/li>\n<li><strong>Support for individual VM backup via command-line\u00a0NEW!<br \/>\n<\/strong><\/li>\n<li><strong>Support VM(s) with existing snapshots\u00a0NEW!<\/strong><\/li>\n<li><strong>Support mulitple running instances of ghettoVCB\u00a0<\/strong><strong>NEW!<\/strong><br \/>\n(<strong>Experimental Suppport<\/strong>)<\/li>\n<li><strong>Configure VM shutdown\/startup order\u00a0NEW!<\/strong><\/li>\n<li><strong>Support changing custom VM name during restore\u00a0NEW!<br \/>\n<\/strong><\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<hr \/>\n<p>&nbsp;<\/p>\n<h1>Requirements:<\/h1>\n<ul>\n<li>VMs running on ESX(i) 3.5\/4.x+\/5.x<\/li>\n<li>SSH console access to ESX(i) host<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<hr \/>\n<p>&nbsp;<\/p>\n<h1>Setup:<\/h1>\n<p>1) Download\u00a0<strong>ghettoVCB<\/strong>\u00a0from\u00a0<a class=\"jive-link-external-small\" href=\"https:\/\/github.com\/lamw\/ghettoVCB\/downloads\" rel=\"nofollow\">github<\/a>\u00a0by 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)<\/p>\n<p>2) Extract the contents of the zip file (filename will vary):<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\"><\/code># unzip ghettoVCB-master.zip\r\n\r\nArchive:\u00a0 ghettoVCB-master.zip\r\n\u00a0\u00a0 creating: ghettoVCB-master\/\r\n\u00a0 inflating: ghettoVCB-master\/README\r\n\u00a0 inflating: ghettoVCB-master\/ghettoVCB-restore.sh\r\n\u00a0 inflating: ghettoVCB-master\/ghettoVCB-restore_vm_restore_configuration_template\r\n\u00a0 inflating: ghettoVCB-master\/ghettoVCB-vm_backup_configuration_template\r\n\u00a0 inflating: ghettoVCB-master\/ghettoVCB.conf\r\n\u00a0 inflating: ghettoVCB-master\/ghettoVCB.sh<\/pre>\n<p>3) The script is now ready to be used and is located in a directory named\u00a0<strong>ghettoVCB-master<\/strong><\/p>\n<pre class=\"jive-pre\"># ls -l\r\n\r\n-rw-r--r--\u00a0\u00a0\u00a0 1 root\u00a0\u00a0\u00a0\u00a0 root\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 281 Jan\u00a0 6 03:58 README\r\n-rw-r--r--\u00a0\u00a0\u00a0 1 root\u00a0\u00a0\u00a0\u00a0 root\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 16024 Jan\u00a0 6 03:58 ghettoVCB-restore.sh\r\n-rw-r--r--\u00a0\u00a0\u00a0 1 root\u00a0\u00a0\u00a0\u00a0 root\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 309 Jan\u00a0 6 03:58 ghettoVCB-restore_vm_restore_configuration_template\r\n-rw-r--r--\u00a0\u00a0\u00a0 1 root\u00a0\u00a0\u00a0\u00a0 root\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 356 Jan\u00a0 6 03:58 ghettoVCB-vm_backup_configuration_template\r\n-rw-r--r--\u00a0\u00a0\u00a0 1 root\u00a0\u00a0\u00a0\u00a0 root\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 631 Jan\u00a0 6 03:58 ghettoVCB.conf\r\n-rw-r--r--\u00a0\u00a0\u00a0 1 root\u00a0\u00a0\u00a0\u00a0 root\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 49375 Jan\u00a0 6 03:58 ghettoVCB.sh<\/pre>\n<p>4) Before using the scripts, you will need to enable the execute permission\u00a0 on both\u00a0<strong>ghettoVCB.sh<\/strong>\u00a0and\u00a0<strong>ghettoVCB-restore.sh<\/strong>\u00a0by running the following:<\/p>\n<pre>chmod +x ghettoVCB.shchmod +x ghettoVCB-restore.sh<\/pre>\n<p>&nbsp;<\/p>\n<hr \/>\n<p>&nbsp;<\/p>\n<h1>Configurations:<\/h1>\n<p>The following variables need to be defined within the script or in VM backup policy prior to execution.<\/p>\n<p><strong>Defining the backup datastore and folder in which the backups are stored (if folder does not exist, it will automatically be created):<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">VM_BACKUP_VOLUME=\/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/WILLIAM_BACKUPS\r\n<\/code><\/pre>\n<p><strong>Defining the backup disk format (zeroedthick, eagerzeroedthick, thin, and 2gbsparse are available):<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">DISK_BACKUP_FORMAT=thin\r\n<\/code><\/pre>\n<p><strong>Note:<\/strong>\u00a0If 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\u00a0<a class=\"jive-link-external-small\" href=\"http:\/\/www.virtuallyghetto.com\/2012\/09\/2gbsparse-disk-format-no-longer-working.html\" rel=\"nofollow\">article<\/a>\u00a0for the details.<\/p>\n<p><strong>Defining the backup rotation per VM:<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">VM_BACKUP_ROTATION_COUNT=3\r\n<\/code><\/pre>\n<p><strong>Defining whether the VM is powered down or not prior to backup (1 = enable, 0 = disable):<\/strong><\/p>\n<p><strong>Note:\u00a0VM(s) that are powered off will not require snapshoting<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">POWER_VM_DOWN_BEFORE_BACKUP=0\r\n<\/code><\/pre>\n<p><strong>Defining whether the VM can be hard powered off when\u00a0 &#8220;POWER_VM_DOWN_BEFORE_BACKUP&#8221; is enabled and VM does not have VMware\u00a0 Tools installed<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">ENABLE_HARD_POWER_OFF=0\r\n<\/code><\/pre>\n<p><strong>If &#8220;ENABLE_HARD_POWER_OFF&#8221; is enabled, then this defines the number\u00a0 of (60sec) iterations the script will before executing a hard power off\u00a0 when:<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">ITER_TO_WAIT_SHUTDOWN=3\r\n<\/code><\/pre>\n<p><strong>The number (60sec) iterations the script will wait when powering off\u00a0 the VM and will give up and ignore the particular VM for backup:<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">POWER_DOWN_TIMEOUT=5\r\n<\/code><\/pre>\n<p><strong>The number (60sec) iterations the script will wait when taking a\u00a0 snapshot of a VM and will give up and ignore the particular VM for\u00a0 backup:<\/strong><\/p>\n<p><strong>Note:\u00a0Default value should suffice<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">SNAPSHOT_TIMEOUT=15\r\n<\/code><\/pre>\n<p><strong>Defining whether or not to enable compression (1 = enable, 0 = disable):<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">ENABLE_COMPRESSION=0\r\n<\/code><\/pre>\n<p><strong>NOTE:<\/strong>\u00a0With 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\u00a0should\u00a0not 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\u00a0 supported VM is 8GB. If you try to compress a larger VM, you\u00a0may\u00a0run into issues when trying to extract upon a restore.\u00a0<strong>PLEASE TEST THE RESTORE PROCESS BEFORE MOVING TO PRODUCTION SYSTEMS!<\/strong><\/p>\n<p><strong>Defining the adapter type for backed up VMDK (DEPERCATED\u00a0&#8211;\u00a0NO LONGER NEEDED):<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">ADAPTER_FORMAT=buslogic\r\n<\/code><\/pre>\n<p><strong>Defining whether virtual machine memory is snapped and if quiescing is enabled (1 = enable, 0 = disable):<\/strong><\/p>\n<p><strong>Note:\u00a0By default both are disabled<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">VM_SNAPSHOT_MEMORY=0\r\nVM_SNAPSHOT_QUIESCE=0\r\n<\/code><\/pre>\n<p><strong>NOTE:<\/strong>\u00a0<strong>VM_SNAPSHOT_MEMORY<\/strong>\u00a0is only used to ensure when the snapshot is taken, it&#8217;s memory contents\u00a0 are also captured. This is only relevant to the actual snapshot and it&#8217;s\u00a0 not used in any shape\/way\/form in regards to the backup. All backups\u00a0 taken whether your VM is running or offline will result in an offline VM\u00a0 backup when you restore. This was originally added for debugging\u00a0 purposes and in generally should be left disabled<\/p>\n<p><strong>Defining VMDK(s) to backup from a particular VM either a list of vmdks or &#8220;all&#8221;<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">VMDK_FILES_TO_BACKUP=\"myvmdk.vmdk\"\r\n<\/code><\/pre>\n<p>&nbsp;<\/p>\n<p><strong>Defining whether or not VM(s) with existing snapshots can be backed up. This flag means it will\u00a0CONSOLIDATE ALL EXISTING SNAPSHOTS\u00a0for a VM prior to starting the backup\u00a0<\/strong><strong>(1 = yes, 0 = no):<\/strong><strong><br \/>\n<\/strong><\/p>\n<pre class=\"jive-pre\">ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=0<\/pre>\n<p>&nbsp;<\/p>\n<p><strong>Defining 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 seperate list of VM(s)<\/strong><\/p>\n<pre class=\"jive-pre\">VM_SHUTDOWN_ORDER=vm1,vm2,vm3<\/pre>\n<p>&nbsp;<\/p>\n<p><strong>Defining 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 seperate list of VM(s)<\/strong><\/p>\n<pre class=\"jive-pre\">VM_STARTUP_ORDER=vm3,vm2,vm1<\/pre>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Defining NON-PERSISTENT NFS Backup Volume (1 = yes, 0 = no):<br \/>\n<\/strong><\/p>\n<pre class=\"jive-pre\">ENABLE_NON_PERSISTENT_NFS=0<\/pre>\n<p><strong>NOTE:<\/strong>\u00a0This 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<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Defining whether or not to unmount the NFS backup volume (1 = yes, 0 = no):<\/strong><\/p>\n<pre class=\"jive-pre\">UNMOUNT_NFS=0<\/pre>\n<p><strong>Defining the NFS server address (IP\/hostname):<\/strong><\/p>\n<pre class=\"jive-pre\">NFS_SERVER=172.51.0.192<\/pre>\n<p><strong>Defining the NFS export path:<\/strong><\/p>\n<pre class=\"jive-pre\">NFS_MOUNT=\/upload<\/pre>\n<p><strong>Defining the NFS datastore name:<\/strong><\/p>\n<pre class=\"jive-pre\">NFS_LOCAL_NAME=backup<\/pre>\n<p><strong>Defining the NFS backup directory for VMs:<\/strong><\/p>\n<pre class=\"jive-pre\">NFS_VM_BACKUP_DIR=mybackups<\/pre>\n<p>&nbsp;<\/p>\n<p><strong>NOTE:<\/strong>\u00a0Only supported if you are running vSphere 4.1 and this feature is experimental. If you are having issues with sending mail, please take a look at\u00a0<strong>Email Backup Log<\/strong>\u00a0section<\/p>\n<p><strong>Defining whether or not to email backup logs (1 = yes, 0 = no):<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">EMAIL_LOG=1\r\n<\/code><\/pre>\n<p><strong>Defining whether or not to email message will be deleted off the host\u00a0 whether it is successful in sending, this is used for debugging\u00a0 purposes. (1 = yes, 0 = no):<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">EMAIL_DEBUG=1\r\n<\/code><\/pre>\n<p><strong>Defining email server:<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">EMAIL_SERVER=auroa.primp-industries.com\r\n<\/code><\/pre>\n<p><strong>Defining email server port:<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">EMAIL_SERVER_PORT=25\r\n<\/code><\/pre>\n<p>&nbsp;<\/p>\n<p><strong>Defining email delay interval<\/strong>\u00a0(useful if you have slow SMTP server and would like to include a delay in netcat using -i param, default is 1second):<\/p>\n<pre class=\"jive-pre\">EMAIL_DELAY_INTERVAL=1<\/pre>\n<p><strong>Defining recipient of the email:<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">EMAIL_TO=auroa@primp-industries.com\r\n<\/code><\/pre>\n<p><strong>Defining from user which may require specific domain entry depending on email server configurations:<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">EMAIL_FROM=root@ghettoVCB\r\n<\/code><\/pre>\n<p>&nbsp;<\/p>\n<p><strong>Defining to support RSYNC symbolic link creation (1 = yes, 0 = no):<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">RSYNC_LINK=0\r\n<\/code><\/pre>\n<p>&nbsp;<\/p>\n<p><strong>Note:\u00a0<\/strong>This\u00a0 enables an automatic creation of a generic symbolic link (both a\u00a0 relative &amp; absolution path) in which users can refer to run\u00a0 replication backups using rsync from a remote host. This does not\u00a0 actually support rsync backups with ghettoVCB. Please take a look at the\u00a0 Rsync Section of the documentation for more details.<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>A sample global ghettoVCB configuration file is included with the download called\u00a0<strong>ghettoVCB.conf<\/strong>.\u00a0 It contains the same variables as defined from above and allows a user\u00a0 to customize and define multiple global configurations based on a user&#8217;s\u00a0 environment.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<pre class=\"jive-pre\">\r\n# cat ghettoVCB.conf \r\nVM_BACKUP_VOLUME=\/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/WILLIAM_BACKUPS\r\nDISK_BACKUP_FORMAT=thin\r\nVM_BACKUP_ROTATION_COUNT=3\r\nPOWER_VM_DOWN_BEFORE_BACKUP=0\r\nENABLE_HARD_POWER_OFF=0\r\nITER_TO_WAIT_SHUTDOWN=3\r\nPOWER_DOWN_TIMEOUT=5\r\nENABLE_COMPRESSION=0\r\nVM_SNAPSHOT_MEMORY=0\r\nVM_SNAPSHOT_QUIESCE=0\r\nALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=0\r\nENABLE_NON_PERSISTENT_NFS=0\r\nUNMOUNT_NFS=0\r\nNFS_SERVER=172.30.0.195\r\nNFS_MOUNT=\/nfsshare\r\nNFS_LOCAL_NAME=nfs_storage_backup\r\nNFS_VM_BACKUP_DIR=mybackups\r\nSNAPSHOT_TIMEOUT=15\r\nEMAIL_LOG=0\r\nEMAIL_SERVER=auroa.primp-industries.com\r\nEMAIL_SERVER_PORT=25\r\nEMAIL_DELAY_INTERVAL=1\r\nEMAIL_TO=auroa@primp-industries.com\r\nEMAIL_FROM=root@ghettoVCB\r\nWORKDIR_DEBUG=0\r\nVM_SHUTDOWN_ORDER=\r\nVM_STARTUP_ORDER=<\/pre>\n<p>To override any existing configurations within the ghettoVCB.sh script\u00a0 and to use a global configuration file, user just needs to specify the\u00a0 new flag -g and path to global configuration file (For an example,\u00a0 please refer to the sample execution section of the documenation)<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Running multiple instances of ghettoVCB is now supported with the latest release by specifying the working directory (-w) flag.<\/strong><\/p>\n<p>By 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.<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Ensure that you do not edit past this section:<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">########################## DO NOT MODIFY PAST THIS LINE ##########################\r\n<\/code><\/pre>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<hr \/>\n<p>&nbsp;<\/p>\n<h1>Usage:<\/h1>\n<pre class=\"jive-pre\">\r\n# .\/ghettoVCB.sh \r\n###############################################################################\r\n#\r\n# ghettoVCB for ESX\/ESXi 3.5, 4.x+ and 5.x\r\n# Author: William Lam\r\n# https:\/\/www.virtuallyghetto.com\/\r\n# Documentation: https:\/\/communities.vmware.com\/docs\/DOC-8760\r\n# Created: 11\/17\/2008\r\n# Last modified: 2012_12_17 Version 0\r\n#\r\n###############################################################################\r\n\r\nUsage: ghettoVCB.sh [options]\r\n\r\nOPTIONS:\r\n\u00a0\u00a0 -a\u00a0\u00a0\u00a0\u00a0 Backup all VMs on host\r\n\u00a0\u00a0 -f\u00a0\u00a0\u00a0\u00a0 List of VMs to backup\r\n\u00a0\u00a0 -m\u00a0\u00a0\u00a0\u00a0 Name of VM to backup (overrides -f)\r\n\u00a0\u00a0 -c\u00a0\u00a0\u00a0\u00a0 VM configuration directory for VM backups\r\n\u00a0\u00a0 -g\u00a0\u00a0\u00a0\u00a0 Path to global ghettoVCB configuration file\r\n\u00a0\u00a0 -l\u00a0\u00a0\u00a0\u00a0 File to output logging\r\n\u00a0\u00a0 -w\u00a0\u00a0\u00a0\u00a0 ghettoVCB work directory (default: )\r\n\u00a0\u00a0 -d\u00a0\u00a0\u00a0\u00a0 Debug level [info|debug|dryrun] (default: info)\r\n\r\n(e.g.)\r\n\r\nBackup VMs stored in a list\r\n\u00a0\u00a0\u00a0 .\/ghettoVCB.sh -f vms_to_backup\r\n\r\nBackup a single VM\r\n\u00a0\u00a0\u00a0 .\/ghettoVCB.sh -m vm_to_backup\r\n\r\nBackup all VMs residing on this host\r\n\u00a0\u00a0\u00a0 .\/ghettoVCB.sh -a\r\n\r\nBackup all VMs residing on this host except for the VMs in the exclusion list\r\n\u00a0\u00a0\u00a0 .\/ghettoVCB.sh -a -e vm_exclusion_list\r\n\r\nBackup VMs based on specific configuration located in directory\r\n\u00a0\u00a0\u00a0 .\/ghettoVCB.sh -f vms_to_backup -c vm_backup_configs\r\n\r\nBackup VMs using global ghettoVCB configuration file\r\n\u00a0\u00a0\u00a0 .\/ghettoVCB.sh -f vms_to_backup -g \/global\/ghettoVCB.conf\r\n\r\nOutput will log to \/tmp\/ghettoVCB.log (consider logging to local or remote datastore to persist logs)\r\n\u00a0\u00a0\u00a0 .\/ghettoVCB.sh -f vms_to_backup -l \/vmfs\/volume\/local-storage\/ghettoVCB.log\r\n\r\nDry run (no backup will take place)\r\n\u00a0\u00a0\u00a0 .\/ghettoVCB.sh -f vms_to_backup -d dryrun<code class=\"jive-code jive-plain\">\r\n<\/code><\/pre>\n<p>The input to this script is a file that contains the display name of the\u00a0 virtual machine(s) separated by a newline. When creating this file on a\u00a0 non-Linux\/UNIX system, you may introduce ^M character which can cause\u00a0 the script to miss-behave. To ensure this does not occur, plesae create\u00a0 the file on the ESX\/ESXi host.<\/p>\n<p>Here is a sample of what the file would look like:<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">[root@himalaya ~]# cat vms_to_backup\r\n<\/code>vCOPS\r\nvMA\r\nvCloudConnector<code class=\"jive-code jive-plain\">\r\n<\/code><\/pre>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<hr \/>\n<p>&nbsp;<\/p>\n<h1>Sample Execution:<\/h1>\n<ul>\n<li>Dry run Mode<\/li>\n<li>Debug Mode<\/li>\n<li>Backup VMs stored in a list<\/li>\n<li>Backup Single VM using command-line<\/li>\n<li>Backup All VMs residing on specific ESX(i) host<\/li>\n<li>Backup VMs based on individual VM backup policies<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2>Dry run Mode (no backup will take place)<\/h2>\n<p><strong>Note:<\/strong>\u00a0This execution mode provides a qucik 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.<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>Log verbosity: dryrun<\/li>\n<li>Log output: stdout &amp; \/tmp (default)\n<ul>\n<li>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.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<pre class=\"jive-pre\">[root@himalaya ghettoVCB]# .\/ghettoVCB.sh -f vms_to_backup -d dryrun\r\nLogging output to \"\/tmp\/ghettoVCB-2011-03-13_15-19-57.log\" ...\r\n2011-03-13 15:19:57 -- info: ============================== ghettoVCB LOG START ==============================\r\n\r\n2011-03-13 15:19:57 -- info: CONFIG - VERSION = 2011_03_13_1\r\n2011-03-13 15:19:57 -- info: CONFIG - GHETTOVCB_PID = 30157\r\n2011-03-13 15:19:57 -- info: CONFIG - VM_BACKUP_VOLUME = \/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/WILLIAM_BACKUPS\r\n2011-03-13 15:19:57 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3\r\n2011-03-13 15:19:57 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2011-03-13_15-19-57\r\n2011-03-13 15:19:57 -- info: CONFIG - DISK_BACKUP_FORMAT = thin\r\n2011-03-13 15:19:57 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0\r\n2011-03-13 15:19:57 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0\r\n2011-03-13 15:19:57 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3\r\n2011-03-13 15:19:57 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5\r\n2011-03-13 15:19:57 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15\r\n2011-03-13 15:19:57 -- info: CONFIG - LOG_LEVEL = dryrun\r\n2011-03-13 15:19:57 -- info: CONFIG - BACKUP_LOG_OUTPUT = \/tmp\/ghettoVCB-2011-03-13_15-19-57.log\r\n2011-03-13 15:19:57 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0\r\n2011-03-13 15:19:57 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0\r\n2011-03-13 15:19:57 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all\r\n2011-03-13 15:19:57 -- info: CONFIG - EMAIL_LOG = 0\r\n2011-03-13 15:19:57 -- info:\r\n2011-03-13 15:19:57 -- dryrun: ###############################################\r\n2011-03-13 15:19:57 -- dryrun: Virtual Machine: scofield\r\n2011-03-13 15:19:57 -- dryrun: VM_ID: 704\r\n2011-03-13 15:19:57 -- dryrun: VMX_PATH: \/vmfs\/volumes\/himalaya-local-SATA.RE4-GP:Storage\/scofield\/scofield.vmx\r\n2011-03-13 15:19:57 -- dryrun: VMX_DIR: \/vmfs\/volumes\/himalaya-local-SATA.RE4-GP:Storage\/scofield\r\n2011-03-13 15:19:57 -- dryrun: VMX_CONF: scofield\/scofield.vmx\r\n2011-03-13 15:19:57 -- dryrun: VMFS_VOLUME: himalaya-local-SATA.RE4-GP:Storage\r\n2011-03-13 15:19:57 -- dryrun: VMDK(s):\r\n2011-03-13 15:19:58 -- dryrun:\u00a0 scofield_3.vmdk 3 GB\r\n2011-03-13 15:19:58 -- dryrun:\u00a0 scofield_2.vmdk 2 GB\r\n2011-03-13 15:19:58 -- dryrun:\u00a0 scofield_1.vmdk 1 GB\r\n2011-03-13 15:19:58 -- dryrun:\u00a0 scofield.vmdk\u00a0\u00a0 5 GB\r\n2011-03-13 15:19:58 -- dryrun: INDEPENDENT VMDK(s):\r\n2011-03-13 15:19:58 -- dryrun: TOTAL_VM_SIZE_TO_BACKUP: 11 GB\r\n2011-03-13 15:19:58 -- dryrun: ###############################################\r\n\r\n2011-03-13 15:19:58 -- dryrun: ###############################################\r\n2011-03-13 15:19:58 -- dryrun: Virtual Machine: vMA\r\n2011-03-13 15:19:58 -- dryrun: VM_ID: 1440\r\n2011-03-13 15:19:58 -- dryrun: VMX_PATH: \/vmfs\/volumes\/himalaya-local-SATA.RE4-GP:Storage\/vMA\/vMA.vmx\r\n2011-03-13 15:19:58 -- dryrun: VMX_DIR: \/vmfs\/volumes\/himalaya-local-SATA.RE4-GP:Storage\/vMA\r\n2011-03-13 15:19:58 -- dryrun: VMX_CONF: vMA\/vMA.vmx\r\n2011-03-13 15:19:58 -- dryrun: VMFS_VOLUME: himalaya-local-SATA.RE4-GP:Storage\r\n2011-03-13 15:19:58 -- dryrun: VMDK(s):\r\n2011-03-13 15:19:58 -- dryrun:\u00a0 vMA-000002.vmdk 5 GB\r\n2011-03-13 15:19:58 -- dryrun: INDEPENDENT VMDK(s):\r\n2011-03-13 15:19:58 -- dryrun: TOTAL_VM_SIZE_TO_BACKUP: 5 GB\r\n2011-03-13 15:19:58 -- dryrun: Snapshots found for this VM, please commit all snapshots before continuing!\r\n2011-03-13 15:19:58 -- dryrun: THIS VIRTUAL MACHINE WILL NOT BE BACKED UP DUE TO EXISTING SNAPSHOTS!\r\n2011-03-13 15:19:58 -- dryrun: ###############################################\r\n\r\n2011-03-13 15:19:58 -- dryrun: ###############################################\r\n2011-03-13 15:19:58 -- dryrun: Virtual Machine: vCloudConnector\r\n2011-03-13 15:19:58 -- dryrun: VM_ID: 2064\r\n2011-03-13 15:19:58 -- dryrun: VMX_PATH: \/vmfs\/volumes\/himalaya-local-SATA.RE4-GP:Storage\/vCloudConnector\/vCloudConnector.vmx\r\n2011-03-13 15:19:58 -- dryrun: VMX_DIR: \/vmfs\/volumes\/himalaya-local-SATA.RE4-GP:Storage\/vCloudConnector\r\n2011-03-13 15:19:58 -- dryrun: VMX_CONF: vCloudConnector\/vCloudConnector.vmx\r\n2011-03-13 15:19:58 -- dryrun: VMFS_VOLUME: himalaya-local-SATA.RE4-GP:Storage\r\n2011-03-13 15:19:58 -- dryrun: VMDK(s):\r\n2011-03-13 15:19:59 -- dryrun:\u00a0 vCloudConnector.vmdk\u00a0\u00a0\u00a0 3 GB\r\n2011-03-13 15:19:59 -- dryrun: INDEPENDENT VMDK(s):\r\n2011-03-13 15:19:59 -- dryrun:\u00a0 vCloudConnector_1.vmdk\u00a0 40 GB\r\n2011-03-13 15:19:59 -- dryrun: TOTAL_VM_SIZE_TO_BACKUP: 3 GB\r\n2011-03-13 15:19:59 -- dryrun: Snapshots can not be taken for indepdenent disks!\r\n2011-03-13 15:19:59 -- dryrun: THIS VIRTUAL MACHINE WILL NOT HAVE ALL ITS VMDKS BACKED UP!\r\n2011-03-13 15:19:59 -- dryrun: ###############################################\r\n\r\n2011-03-13 15:19:59 -- info: ###### Final status: OK, only a dryrun. ######\r\n\r\n2011-03-13 15:19:59 -- info: ============================== ghettoVCB LOG END ================================<\/pre>\n<p>In the example above, we have 3 VMs to be backed up:<\/p>\n<ul>\n<li>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<\/li>\n<li>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<\/li>\n<li>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 &#8220;<strong>TOTAL_VM_SIZE_TO_BACKUP<\/strong>&#8220;<\/li>\n<\/ul>\n<h2>Debug backup mode<\/h2>\n<p><strong>Note:<\/strong>\u00a0This 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<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>Log verbosity: debug<\/li>\n<li>Log output: stdout &amp; \/tmp (default)\n<ul>\n<li>Logs by default will be stored in \/tmp, these log files may not persist\u00a0 through reboots, especially when dealing with ESXi. You should log to\u00a0 either a local or remote datastore to ensure that logs are kept upon a\u00a0 reboot.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<pre class=\"jive-pre\">[root@himalaya ghettoVCB]# .\/ghettoVCB.sh -f vms_to_backup -d debug\r\nLogging output to \"\/tmp\/ghettoVCB-2011-03-13_15-27-59.log\" ...\r\n2011-03-13 15:27:59 -- info: ============================== ghettoVCB LOG START ==============================\r\n\r\n2011-03-13 15:27:59 -- debug: Succesfully acquired lock directory - \/tmp\/ghettoVCB.lock\r\n\r\n2011-03-13 15:27:59 -- debug: HOST VERSION: VMware ESX 4.1.0 build-260247\r\n2011-03-13 15:27:59 -- debug: HOST LEVEL: VMware ESX 4.1.0 GA\r\n2011-03-13 15:27:59 -- debug: HOSTNAME: himalaya.primp-industries.com\r\n\r\n2011-03-13 15:27:59 -- info: CONFIG - VERSION = 2011_03_13_1\r\n2011-03-13 15:27:59 -- info: CONFIG - GHETTOVCB_PID = 31074\r\n2011-03-13 15:27:59 -- info: CONFIG - VM_BACKUP_VOLUME = \/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/WILLIAM_BACKUPS\r\n2011-03-13 15:27:59 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3\r\n2011-03-13 15:27:59 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2011-03-13_15-27-59\r\n2011-03-13 15:27:59 -- info: CONFIG - DISK_BACKUP_FORMAT = thin\r\n2011-03-13 15:27:59 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0\r\n2011-03-13 15:27:59 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0\r\n2011-03-13 15:27:59 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3\r\n2011-03-13 15:27:59 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5\r\n2011-03-13 15:27:59 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15\r\n2011-03-13 15:27:59 -- info: CONFIG - LOG_LEVEL = debug\r\n2011-03-13 15:27:59 -- info: CONFIG - BACKUP_LOG_OUTPUT = \/tmp\/ghettoVCB-2011-03-13_15-27-59.log\r\n2011-03-13 15:27:59 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0\r\n2011-03-13 15:27:59 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0\r\n2011-03-13 15:27:59 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all\r\n2011-03-13 15:27:59 -- info: CONFIG - EMAIL_LOG = 0\r\n2011-03-13 15:27:59 -- info:\r\n2011-03-13 15:28:01 -- debug: Storage Information before backup:\r\n2011-03-13 15:28:01 -- debug: SRC_DATASTORE: himalaya-local-SATA.RE4-GP:Storage\r\n2011-03-13 15:28:01 -- debug: SRC_DATASTORE_CAPACITY: 1830.5 GB\r\n2011-03-13 15:28:01 -- debug: SRC_DATASTORE_FREE: 539.4 GB\r\n2011-03-13 15:28:01 -- debug: SRC_DATASTORE_BLOCKSIZE: 4\r\n2011-03-13 15:28:01 -- debug: SRC_DATASTORE_MAX_FILE_SIZE: 1024 GB\r\n2011-03-13 15:28:01 -- debug:\r\n2011-03-13 15:28:01 -- debug: DST_DATASTORE: dlgCore-NFS-bigboi.VM-Backups\r\n2011-03-13 15:28:01 -- debug: DST_DATASTORE_CAPACITY: 1348.4 GB\r\n2011-03-13 15:28:01 -- debug: DST_DATASTORE_FREE: 296.8 GB\r\n2011-03-13 15:28:01 -- debug: DST_DATASTORE_BLOCKSIZE: NA\r\n2011-03-13 15:28:01 -- debug: DST_DATASTORE_MAX_FILE_SIZE: NA\r\n2011-03-13 15:28:01 -- debug:\r\n2011-03-13 15:28:02 -- info: Initiate backup for scofield\r\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\"\r\nDestination disk format: VMFS thin-provisioned\r\nCloning disk '\/vmfs\/volumes\/himalaya-local-SATA.RE4-GP:Storage\/scofield\/scofield_3.vmdk'...\r\nClone: 37% done.\r\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\"\r\nDestination disk format: VMFS thin-provisioned\r\nCloning disk '\/vmfs\/volumes\/himalaya-local-SATA.RE4-GP:Storage\/scofield\/scofield_2.vmdk'...\r\nClone: 85% done.\r\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\"\r\n\r\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\"\r\nDestination disk format: VMFS thin-provisioned\r\nCloning disk '\/vmfs\/volumes\/himalaya-local-SATA.RE4-GP:Storage\/scofield\/scofield.vmdk'...\r\nClone: 78% done.\r\n2011-03-13 15:29:52 -- info: Backup Duration: 1.83 Minutes\r\n2011-03-13 15:29:52 -- info: Successfully completed backup for scofield!\r\n\r\n2011-03-13 15:29:54 -- debug: Storage Information after backup:\r\n2011-03-13 15:29:54 -- debug: SRC_DATASTORE: himalaya-local-SATA.RE4-GP:Storage\r\n2011-03-13 15:29:54 -- debug: SRC_DATASTORE_CAPACITY: 1830.5 GB\r\n2011-03-13 15:29:54 -- debug: SRC_DATASTORE_FREE: 539.4 GB\r\n2011-03-13 15:29:54 -- debug: SRC_DATASTORE_BLOCKSIZE: 4\r\n2011-03-13 15:29:54 -- debug: SRC_DATASTORE_MAX_FILE_SIZE: 1024 GB\r\n2011-03-13 15:29:54 -- debug:\r\n2011-03-13 15:29:54 -- debug: DST_DATASTORE: dlgCore-NFS-bigboi.VM-Backups\r\n2011-03-13 15:29:54 -- debug: DST_DATASTORE_CAPACITY: 1348.4 GB\r\n2011-03-13 15:29:54 -- debug: DST_DATASTORE_FREE: 296.8 GB\r\n2011-03-13 15:29:54 -- debug: DST_DATASTORE_BLOCKSIZE: NA\r\n2011-03-13 15:29:54 -- debug: DST_DATASTORE_MAX_FILE_SIZE: NA\r\n2011-03-13 15:29:54 -- debug:\r\n2011-03-13 15:29:55 -- debug: Storage Information before backup:\r\n2011-03-13 15:29:55 -- debug: SRC_DATASTORE: himalaya-local-SATA.RE4-GP:Storage\r\n2011-03-13 15:29:55 -- debug: SRC_DATASTORE_CAPACITY: 1830.5 GB\r\n2011-03-13 15:29:55 -- debug: SRC_DATASTORE_FREE: 539.4 GB\r\n2011-03-13 15:29:55 -- debug: SRC_DATASTORE_BLOCKSIZE: 4\r\n2011-03-13 15:29:55 -- debug: SRC_DATASTORE_MAX_FILE_SIZE: 1024 GB\r\n2011-03-13 15:29:55 -- debug:\r\n2011-03-13 15:29:55 -- debug: DST_DATASTORE: dlgCore-NFS-bigboi.VM-Backups\r\n2011-03-13 15:29:55 -- debug: DST_DATASTORE_CAPACITY: 1348.4 GB\r\n2011-03-13 15:29:55 -- debug: DST_DATASTORE_FREE: 296.8 GB\r\n2011-03-13 15:29:55 -- debug: DST_DATASTORE_BLOCKSIZE: NA\r\n2011-03-13 15:29:55 -- debug: DST_DATASTORE_MAX_FILE_SIZE: NA\r\n2011-03-13 15:29:55 -- debug:\r\n2011-03-13 15:29:55 -- info: Snapshot found for vMA, backup will not take place\r\n\r\n2011-03-13 15:29:57 -- debug: Storage Information before backup:\r\n2011-03-13 15:29:57 -- debug: SRC_DATASTORE: himalaya-local-SATA.RE4-GP:Storage\r\n2011-03-13 15:29:57 -- debug: SRC_DATASTORE_CAPACITY: 1830.5 GB\r\n2011-03-13 15:29:57 -- debug: SRC_DATASTORE_FREE: 539.4 GB\r\n2011-03-13 15:29:57 -- debug: SRC_DATASTORE_BLOCKSIZE: 4\r\n2011-03-13 15:29:57 -- debug: SRC_DATASTORE_MAX_FILE_SIZE: 1024 GB\r\n2011-03-13 15:29:57 -- debug:\r\n2011-03-13 15:29:57 -- debug: DST_DATASTORE: dlgCore-NFS-bigboi.VM-Backups\r\n2011-03-13 15:29:57 -- debug: DST_DATASTORE_CAPACITY: 1348.4 GB\r\n2011-03-13 15:29:57 -- debug: DST_DATASTORE_FREE: 296.8 GB\r\n2011-03-13 15:29:57 -- debug: DST_DATASTORE_BLOCKSIZE: NA\r\n2011-03-13 15:29:57 -- debug: DST_DATASTORE_MAX_FILE_SIZE: NA\r\n2011-03-13 15:29:57 -- debug:\r\n2011-03-13 15:29:58 -- info: Initiate backup for vCloudConnector\r\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\"\r\nDestination disk format: VMFS thin-provisioned\r\nCloning disk '\/vmfs\/volumes\/himalaya-local-SATA.RE4-GP:Storage\/vCloudConnector\/vCloudConnector.vmdk'...\r\nClone: 97% done.\r\n2011-03-13 15:30:45 -- info: Backup Duration: 47 Seconds\r\n2011-03-13 15:30:45 -- info: WARN: vCloudConnector has some Independent VMDKs that can not be backed up!\r\n\r\n2011-03-13 15:30:45 -- info: ###### Final status: ERROR: Only some of the VMs backed up, and some disk(s) failed! ######\r\n\r\n2011-03-13 15:30:45 -- debug: Succesfully removed lock directory - \/tmp\/ghettoVCB.lock\r\n\r\n2011-03-13 15:30:45 -- info: ============================== ghettoVCB LOG END ================================<\/pre>\n<h2>Backup VMs stored in a list<\/h2>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">[root@himalaya ~]# .\/ghettoVCB.sh -f vms_to_backup<\/code><\/pre>\n<h2>Backup Single VM using command-line<\/h2>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\"># .\/ghettoVCB.sh -m MyVM<\/code><\/pre>\n<h2>Backup All VMs residing on specific ESX(i) host<\/h2>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">\/ghettoVCB # .\/ghettoVCB.sh -a<\/code><\/pre>\n<h2>Backup All VMs residing on specific ESX(i) host and exclude the VMs in the exclusion list<\/h2>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">\/ghettoVCB # .\/ghettoVCB.sh -a -e vm_exclusion_list<\/code><\/pre>\n<p>&nbsp;<\/p>\n<h2>Backup VMs based on individual VM backup policies and log output to \/tmp\/ghettoVCB.log<\/h2>\n<ul>\n<li>Log verbosity: info (default)<\/li>\n<li>Log output: \/tmp\/ghettoVCB.log\n<ul>\n<li>Logs by default will be stored in \/tmp, these log files may not persist\u00a0 through reboots, especially when dealing with ESXi. You should log to\u00a0 either a local or remote datastore to ensure that logs are kept upon a\u00a0 reboot.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>1. Create folder to hold individual VM backup policies (can be named anything):<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">[root@himalaya ~]# mkdir backup_config\r\n<\/code><\/pre>\n<p>2. Create individual VM backup policies for each VM that ensure each\u00a0 file is named exactly as the display name of the VM being backed up (use\u00a0 provided template to create duplicates):<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">[root@himalaya backup_config]# cp ghettoVCB-vm_backup_configuration_template scofield\r\n[root@himalaya backup_config]# cp ghettoVCB-vm_backup_configuration_template vCloudConnector\r\n<\/code><\/pre>\n<p>Listing of VM backup policy within backup configuration directory<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">[root@himalaya backup_config]# ls\r\nghettoVCB-vm_backup_configuration_template\u00a0 <\/code>scofield\u00a0 vCloudConnector<code class=\"jive-code jive-plain\">\u00a0 <\/code><\/pre>\n<p>Backup policy for &#8220;scofield&#8221; (backup only 2 specific VMDKs)<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">[root@himalaya backup_config]# cat scofield\r\nVM_BACKUP_VOLUME=\/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/WILLIAM_BACKUPS\r\nDISK_BACKUP_FORMAT=thin\r\nVM_BACKUP_ROTATION_COUNT=3\r\nPOWER_VM_DOWN_BEFORE_BACKUP=0\r\nENABLE_HARD_POWER_OFF=0\r\nITER_TO_WAIT_SHUTDOWN=4\r\nPOWER_DOWN_TIMEOUT=5\r\nSNAPSHOT_TIMEOUT=15\r\nENABLE_COMPRESSION=0\r\nVM_SNAPSHOT_MEMORY=0\r\nVM_SNAPSHOT_QUIESCE=0\r\nVMDK_FILES_TO_BACKUP=\"<\/code>scofield_2.vmdk,scofield_1.vmdk<code class=\"jive-code jive-plain\">\"\r\n<\/code><\/pre>\n<p>Backup policy for VM &#8220;vCloudConnector&#8221; (backup all VMDKs found)<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">[root@himalaya backup_config]# cat <\/code>vCloudConnector\r\n<code class=\"jive-code jive-plain\">VM_BACKUP_VOLUME=\/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/WILLIAM_BACKUPS\r\nDISK_BACKUP_FORMAT=thin\r\nVM_BACKUP_ROTATION_COUNT=3\r\nPOWER_VM_DOWN_BEFORE_BACKUP=0\r\nENABLE_HARD_POWER_OFF=0\r\nITER_TO_WAIT_SHUTDOWN=4\r\nPOWER_DOWN_TIMEOUT=5\r\nSNAPSHOT_TIMEOUT=15\r\nENABLE_COMPRESSION=0\r\nVM_SNAPSHOT_MEMORY=0\r\nVM_SNAPSHOT_QUIESCE=0\r\nVMDK_FILES_TO_BACKUP=\"<\/code>vCloudConnector.vmdk<code class=\"jive-code jive-plain\">\"\r\n\r\n<\/code><\/pre>\n<p><strong>Note:<\/strong>\u00a0When specifying -c option (individual VM backup policy mode) if a VM is listed in the backup list but\u00a0<strong>DOES NOT<\/strong>\u00a0have a corresponding backup policy, the VM will be backed up using the\u00a0 default configuration found within the ghettoVCB.sh script.<\/p>\n<p>Execution of backup<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">[root@himalaya ~]# .\/ghettoVCB.sh -f vms_to_backup -c backup_config -l \/tmp\/ghettoVCB.log\r\n\r\n<\/code>2011-03-13 15:40:50 -- info: ============================== ghettoVCB LOG START ==============================\r\n\r\n2011-03-13 15:40:51 -- info: CONFIG - USING CONFIGURATION FILE = backup_config\/\/scofield\r\n2011-03-13 15:40:51 -- info: CONFIG - VERSION = 2011_03_13_1\r\n2011-03-13 15:40:51 -- info: CONFIG - GHETTOVCB_PID = 2967\r\n2011-03-13 15:40:51 -- info: CONFIG - VM_BACKUP_VOLUME = \/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/WILLIAM_BACKUPS\r\n2011-03-13 15:40:51 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3\r\n2011-03-13 15:40:51 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2011-03-13_15-40-50\r\n2011-03-13 15:40:51 -- info: CONFIG - DISK_BACKUP_FORMAT = thin\r\n2011-03-13 15:40:51 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0\r\n2011-03-13 15:40:51 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0\r\n2011-03-13 15:40:51 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 4\r\n2011-03-13 15:40:51 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5\r\n2011-03-13 15:40:51 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15\r\n2011-03-13 15:40:51 -- info: CONFIG - LOG_LEVEL = info\r\n2011-03-13 15:40:51 -- info: CONFIG - BACKUP_LOG_OUTPUT = \/tmp\/ghettoVCB.log\r\n2011-03-13 15:40:51 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0\r\n2011-03-13 15:40:51 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0\r\n2011-03-13 15:40:51 -- info: CONFIG - VMDK_FILES_TO_BACKUP = scofield_2.vmdk,scofield_1.vmdk\r\n2011-03-13 15:40:51 -- info: CONFIG - EMAIL_LOG = 0\r\n2011-03-13 15:40:51 -- info:\r\n2011-03-13 15:40:53 -- info: Initiate backup for scofield\r\nDestination disk format: VMFS thin-provisioned\r\nCloning disk '\/vmfs\/volumes\/himalaya-local-SATA.RE4-GP:Storage\/scofield\/scofield_2.vmdk'...\r\nClone: 100% done.\r\n\r\nDestination disk format: VMFS thin-provisioned\r\nCloning disk '\/vmfs\/volumes\/himalaya-local-SATA.RE4-GP:Storage\/scofield\/scofield_1.vmdk'...\r\nClone: 100% done.\r\n\r\n2011-03-13 15:40:55 -- info: Backup Duration: 2 Seconds\r\n2011-03-13 15:40:55 -- info: Successfully completed backup for scofield!\r\n\r\n2011-03-13 15:40:57 -- info: CONFIG - VERSION = 2011_03_13_1\r\n2011-03-13 15:40:57 -- info: CONFIG - GHETTOVCB_PID = 2967\r\n2011-03-13 15:40:57 -- info: CONFIG - VM_BACKUP_VOLUME = \/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/WILLIAM_BACKUPS\r\n2011-03-13 15:40:57 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3\r\n2011-03-13 15:40:57 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2011-03-13_15-40-50\r\n2011-03-13 15:40:57 -- info: CONFIG - DISK_BACKUP_FORMAT = thin\r\n2011-03-13 15:40:57 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0\r\n2011-03-13 15:40:57 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0\r\n2011-03-13 15:40:57 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3\r\n2011-03-13 15:40:57 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5\r\n2011-03-13 15:40:57 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15\r\n2011-03-13 15:40:57 -- info: CONFIG - LOG_LEVEL = info\r\n2011-03-13 15:40:57 -- info: CONFIG - BACKUP_LOG_OUTPUT = \/tmp\/ghettoVCB.log\r\n2011-03-13 15:40:57 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0\r\n2011-03-13 15:40:57 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0\r\n2011-03-13 15:40:57 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all\r\n2011-03-13 15:40:57 -- info: CONFIG - EMAIL_LOG = 0\r\n2011-03-13 15:40:57 -- info:\r\n2011-03-13 15:40:59 -- info: Snapshot found for vMA, backup will not take place\r\n\r\n2011-03-13 15:40:59 -- info: CONFIG - USING CONFIGURATION FILE = backup_config\/\/vCloudConnector\r\n2011-03-13 15:40:59 -- info: CONFIG - VERSION = 2011_03_13_1\r\n2011-03-13 15:40:59 -- info: CONFIG - GHETTOVCB_PID = 2967\r\n2011-03-13 15:40:59 -- info: CONFIG - VM_BACKUP_VOLUME = \/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/WILLIAM_BACKUPS\r\n2011-03-13 15:40:59 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3\r\n2011-03-13 15:40:59 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2011-03-13_15-40-50\r\n2011-03-13 15:40:59 -- info: CONFIG - DISK_BACKUP_FORMAT = thin\r\n2011-03-13 15:40:59 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0\r\n2011-03-13 15:40:59 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0\r\n2011-03-13 15:40:59 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 4\r\n2011-03-13 15:40:59 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5\r\n2011-03-13 15:40:59 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15\r\n2011-03-13 15:40:59 -- info: CONFIG - LOG_LEVEL = info\r\n2011-03-13 15:40:59 -- info: CONFIG - BACKUP_LOG_OUTPUT = \/tmp\/ghettoVCB.log\r\n2011-03-13 15:40:59 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0\r\n2011-03-13 15:40:59 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0\r\n2011-03-13 15:40:59 -- info: CONFIG - VMDK_FILES_TO_BACKUP = vCloudConnector.vmdk\r\n2011-03-13 15:40:59 -- info: CONFIG - EMAIL_LOG = 0\r\n2011-03-13 15:40:59 -- info:\r\n2011-03-13 15:41:01 -- info: Initiate backup for vCloudConnector\r\nDestination disk format: VMFS thin-provisioned\r\nCloning disk '\/vmfs\/volumes\/himalaya-local-SATA.RE4-GP:Storage\/vCloudConnector\/vCloudConnector.vmdk'...\r\nClone: 100% done.\r\n\r\n2011-03-13 15:41:51 -- info: Backup Duration: 50 Seconds\r\n2011-03-13 15:41:51 -- info: WARN: vCloudConnector has some Independent VMDKs that can not be backed up!\r\n\r\n2011-03-13 15:41:51 -- info: ###### Final status: ERROR: Only some of the VMs backed up, and some disk(s) failed! ######\r\n\r\n2011-03-13 15:41:51 -- info: ============================== ghettoVCB LOG END ================================<code class=\"jive-code jive-plain\">\r\n\r\n<\/code><\/pre>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<hr \/>\n<p>&nbsp;<\/p>\n<h1>Enable compression for backups (EXPERIMENTAL SUPPORT)<\/h1>\n<p>Please take a look at\u00a0<strong>FAQ #25<\/strong>\u00a0for more details before continuing<\/p>\n<p>To make use of this feature, modify the variable\u00a0<strong>ENABLE_COMPRESSION<\/strong>\u00a0from 0 to 1. Please note, do not mix uncompressed backups with\u00a0 compressed backups. Ensure that directories selected for backups do not contain any backups with previous versions of ghettoVCB before enabling\u00a0 and implementing the compressed backups feature.<\/p>\n<p>&nbsp;<\/p>\n<hr \/>\n<p>&nbsp;<\/p>\n<h1>Email Backup Logs (EXPERIMENTAL SUPPORT)<\/h1>\n<p>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\u00a0<strong>nc<\/strong>(netcat) utility to communicate to an email server. This feature is\u00a0 provided as-is with no guarantees. If you enable this feature, a\u00a0 separate log will be generated along side\u00a0 any normal logging which will\u00a0 be used to email recipient. If for whatever reason, the email fails to\u00a0 send, an entry will appear per the normal logging mechanism.<\/p>\n<p>&nbsp;<\/p>\n<p>Users should also make note due to limited functionality of netcat, it uses SMTP pipelining which is not the most ideal method of communicating with an SMTP server. Email from ghettoVCB may not work if your email server does not support this feature.<\/p>\n<p>&nbsp;<\/p>\n<p>You can define an email recipient in the following two ways:<\/p>\n<p>&nbsp;<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">EMAIL_TO=william@virtuallyghetto.com\r\n<\/code><\/pre>\n<p>OR<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">EMAIL_TO=william@virtuallyghetto.com,tuan@virtuallyghetto.com<\/code><\/pre>\n<p>&nbsp;<\/p>\n<p>If you are running ESXi 5.1, 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.<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Step 1<\/strong>\u00a0&#8211; Create a file called\u00a0<strong>\/etc\/vmware\/firewall\/email.xml<\/strong>\u00a0with contains the following:<\/p>\n<pre class=\"jive-pre\">&lt;ConfigRoot&gt;\r\n\u00a0 &lt;service&gt;\r\n\u00a0\u00a0\u00a0 &lt;id&gt;email&lt;\/id&gt;\r\n\u00a0\u00a0\u00a0 &lt;rule id=\"0000\"&gt;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 &lt;direction&gt;outbound&lt;\/direction&gt;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 &lt;protocol&gt;tcp&lt;\/protocol&gt;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 &lt;porttype&gt;dst&lt;\/porttype&gt;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 &lt;port&gt;25&lt;\/port&gt;\r\n\u00a0\u00a0\u00a0 &lt;\/rule&gt;\r\n\u00a0\u00a0\u00a0 &lt;enabled&gt;true&lt;\/enabled&gt;\r\n\u00a0\u00a0\u00a0 &lt;required&gt;false&lt;\/required&gt;\r\n\u00a0 &lt;\/service&gt;\r\n&lt;\/ConfigRoot&gt;<\/pre>\n<p>&nbsp;<\/p>\n<p><strong>Step 2<\/strong>\u00a0&#8211; Reload the ESXi firewall by running the following ESXCLI command:<\/p>\n<pre class=\"jive-pre\">~ #<\/pre>\n<pre class=\"jive-pre\">esxcli network firewall refresh<\/pre>\n<p><strong>Step 3<\/strong>\u00a0&#8211; Confirm that your email rule has been loaded by running the following ESXCLI command:<\/p>\n<pre class=\"jive-pre\">~ # esxcli network firewall ruleset list | grep email\r\nemail\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 true<\/pre>\n<p><strong>Step 4<\/strong>\u00a0&#8211; Connect to your email server by usingn nc (netcat) by running the following command and specifying the IP Address\/Port of your email server:<\/p>\n<pre class=\"jive-pre\">~ # nc 172.30.0.107 25\r\n220 mail.primp-industries.com ESMTP Postfix<\/pre>\n<p>You should recieve 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\u00a0<a class=\"jive-link-external-small\" href=\"http:\/\/www.virtuallyghetto.com\/2012\/09\/creating-custom-vibs-for-esxi-50-51.html\" rel=\"nofollow\">article<\/a>\u00a0for the details.<\/p>\n<p>&nbsp;<\/p>\n<hr \/>\n<p>&nbsp;<\/p>\n<h1>Rsync Support\u00a0 (EXPERIMENTAL SUPPORT)<\/h1>\n<p>To make use of this feature, modify the variable\u00a0<strong>RSYNC_LINK<\/strong>\u00a0from 0\u00a0 to 1. Please note, this is an experimental feature request from users that rely on rsync to replicate changes from one datastore volume to\u00a0 another datastore volume. The premise of this feature is to have a standardized folder that rsync can monitor for changes to replicate to\u00a0 another backup datastore. When this feature is enabled, a symbolic link\u00a0 will be generated with the format of &#8220;&lt;VMNAME&gt;-symlink&#8221; and will\u00a0 reference the latest successful VM backup. You can then rely on this\u00a0 symbolic link to watch for changes and replicate to your backup\u00a0 datastore.<\/p>\n<p>Here is an example of what this would look like:<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">[root@himalaya ghettoVCB]# ls -la \/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/WILLIAM_BACKUPS\/vcma\/\r\ntotal 0\r\ndrwxr-xr-x 1 nobody nobody 110 Sep 27 08:08 .\r\ndrwxr-xr-x 1 nobody nobody\u00a0 17 Sep 16 14:01 ..\r\nlrwxrwxrwx 1 nobody nobody\u00a0 89 Sep 27 08:08 vcma-symlink -&gt; \/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/WILLIAM_BACKUPS\/vcma\/vcma-2010-09-27_08-07-37\r\ndrwxr-xr-x 1 nobody nobody\u00a0 58 Sep 27 08:04 vcma-2010-09-27_08-04-26\r\ndrwxr-xr-x 1 nobody nobody\u00a0 58 Sep 27 08:06 vcma-2010-09-27_08-05-55\r\ndrwxr-xr-x 1 nobody nobody\u00a0 58 Sep 27 08:08 vcma-2010-09-27_08-07-37\r\n<\/code><\/pre>\n<p><strong>FYI &#8211;\u00a0<\/strong>This feature has not been tested, please provide feedback if this does not work as expected.<\/p>\n<hr \/>\n<p>&nbsp;<\/p>\n<h1>Restore backups (ghettoVCB-restore.sh):<\/h1>\n<p>To recover a VM that has been processed by ghettoVCB, please take a look at this document:\u00a0<a class=\"jive-link-wiki-small\" href=\"https:\/\/communities.vmware.com\/docs\/DOC-10595\" data-containerid=\"2411\" data-containertype=\"14\" data-objectid=\"10595\" data-objecttype=\"102\">Ghetto Tech Preview &#8211; ghettoVCB-restore.sh &#8211; Restoring VM&#8217;s backed up from ghettoVCB to ESX(i) 3.5, 4.x, and 5.x<\/a><\/p>\n<p>&nbsp;<\/p>\n<hr \/>\n<h1>Stopping ghettoVCB Process:<\/h1>\n<p>There 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.<\/p>\n<p>&nbsp;<\/p>\n<h3><strong>Interactively running ghettoVCB:<\/strong><\/h3>\n<p>&nbsp;<\/p>\n<p><strong>Step 1<\/strong>\u00a0&#8211; Press Ctrl+C which will kill off the main ghettoVCB instance<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Step 2<\/strong>\u00a0&#8211; Search for any existing ghettoVCB process by running the following:<\/p>\n<p>&nbsp;<\/p>\n<pre class=\"jive-pre\"># ps -c | grep ghettoVCB | grep -v grep\r\n3360136 3360136 tail\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 tail -f \/tmp\/ghettoVCB.work\/ghettovcb.Cs1M1x<\/pre>\n<p>&nbsp;<\/p>\n<p><strong>Step 3<\/strong>\u00a0&#8211; 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.<\/p>\n<pre class=\"jive-pre\"># kill -9 3360136<\/pre>\n<p>&nbsp;<\/p>\n<p><strong>Note:<\/strong>\u00a0Make sure you identify the correct PID, else you could accidently impact a running VM or worse your ESXi host.<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Step 4<\/strong>\u00a0&#8211; 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.<\/p>\n<p>&nbsp;<\/p>\n<h3><strong>Non-Interactively running ghettoVCB:<\/strong><\/h3>\n<p>&nbsp;<\/p>\n<p><strong>Step 1<\/strong>\u00a0&#8211; Search for the ghettoVCB process (you can also validate the PID from the logs)<\/p>\n<p>&nbsp;<\/p>\n<pre class=\"jive-pre\">~ # ps -c | grep ghettoVCB | grep -v grep\r\n3360393 3360393 busybox\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ash .\/ghettoVCB.sh -f list -d debug\r\n3360790 3360790 tail\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 tail -f \/tmp\/ghettoVCB.work\/ghettovcb.deGeB7<\/pre>\n<p>&nbsp;<\/p>\n<p><strong>Step 2<\/strong>\u00a0&#8211; Stop both the main ghettoVCB instance &amp; tail command by using the kill command and specifying their respective PID IDs:<\/p>\n<p>&nbsp;<\/p>\n<pre class=\"jive-pre\">kill -9 3360393\r\nkill -9 3360790<\/pre>\n<p>&nbsp;<\/p>\n<p><strong>Step 3<\/strong>\u00a0&#8211; 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:<\/p>\n<pre class=\"jive-pre\"># ps -c | grep vmkfstools | grep -v grep\r\n3360796 3360796 vmkfstools\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/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<\/pre>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Step 4<\/strong>\u00a0&#8211; 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:<\/p>\n<pre class=\"jive-pre\"># kill -9 3360796<\/pre>\n<p>&nbsp;<\/p>\n<p><strong>Step 5<\/strong>\u00a0&#8211; Depending on where you stopped the\u00a0 ghettoVCB process, you may need to consolidate or remove any existing\u00a0 snapshots that may exist on the VM that was being backed up. You can\u00a0 easily do so by using the vSphere Client.<\/p>\n<p>&nbsp;<\/p>\n<hr \/>\n<p>&nbsp;<\/p>\n<h1>Cronjob FAQ:<\/h1>\n<p><a class=\"jive-link-external\" href=\"http:\/\/www.cyberciti.biz\/faq\/how-do-i-add-jobs-to-cron-under-linux-or-unix-oses\/\">Please take a moment to read over what is a cronjob and how to set one up, before continuing<\/a><\/p>\n<p>The task of configuring cronjobs on classic ESX servers (with Service Console) is no different than traditional cronjobs on *nix operating\u00a0 systems (this procedure is outlined in the link above). With ESXi on the\u00a0 other hand, additional factors need to be taken into account when\u00a0 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.<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Important Note:<\/strong>\u00a0Always 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.<\/p>\n<p>&nbsp;<\/p>\n<p>e.g.<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">0 0 * * 1-5 \/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/ghettoVCB.sh -f \/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/backuplist &gt; \/dev\/null<\/code><\/pre>\n<p>or<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">0 0 * * 1-5 \/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/ghettoVCB.sh -f \/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/backuplist &gt; \/tmp\/ghettoVCB.log<\/code><\/pre>\n<p>&nbsp;<\/p>\n<p><strong>Task<\/strong>: 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<\/p>\n<p><strong>Configure on ESX:<\/strong><\/p>\n<p>1. As root, you&#8217;ll install your cronjob by issuing:<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">[root@himalaya ~]# crontab -e\r\n<\/code><\/pre>\n<p>2. Append the following entry:<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">0 0 * * 1-5 \/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/ghettoVCB.sh -f \/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/backuplist &gt; \/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/ghettoVCB-backup-$(date +\\%s).log\r\n<\/code><\/pre>\n<p>3. Save and exit<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">[root@himalaya dlgCore-NFS-bigboi.VM-Backups]# crontab -e\r\nno crontab for root - using an empty one\r\ncrontab: installing new crontab\r\n<\/code><\/pre>\n<p>4. List out and verify the cronjob that was just created:<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">[root@himalaya dlgCore-NFS-bigboi.VM-Backups]# crontab -l\r\n0 0 * * 1-5 \/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/ghettoVCB.sh -f \/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/backuplist &gt; \/vmfs\/volumes\/dlgCore-NFS-bigboi.VM-Backups\/ghettoVCB-backup-$(date +\\%s).log\r\n<\/code><\/pre>\n<p>You&#8217;re ready to go!<\/p>\n<p><strong>Configure on ESXi:<\/strong><\/p>\n<p>1. Setup the cronjob by appending the following line to\u00a0\/var\/spool\/cron\/crontabs\/root:<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">0 0 * * 1-5 \/vmfs\/volumes\/simplejack-local-storage\/ghettoVCB.sh -f \/vmfs\/volumes\/simplejack-local-storage\/backuplist &gt; \/vmfs\/volumes\/simplejack-local-storage\/ghettoVCB-backup-$(date +\\%s).log\r\n<\/code><\/pre>\n<p>&nbsp;<\/p>\n<p>If you are unable to edit\/modify \/var\/spool\/cron\/crontabs\/root, please make a copy and then edit the copy with the changes<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">cp \/var\/spool\/cron\/crontabs\/root \/var\/spool\/cron\/crontabs\/root.backup<\/code><\/pre>\n<p>Once your changes have been made, then &#8220;mv&#8221; the backup to the original file. This may occur on ESXi 4.x or 5.x hosts<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">mv \/var\/spool\/cron\/crontabs\/root.backup \/var\/spool\/cron\/crontabs\/root<\/code><\/pre>\n<p>You can now verify the crontab entry has been updated by using &#8220;cat&#8221; utility.<\/p>\n<p>2. Kill the current crond (cron daemon) and then restart the crond for the changes to take affect:<\/p>\n<p>On ESXi &lt; 3.5u3<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">kill $(ps | grep crond | cut -f 1 -d ' ')\r\n<\/code><\/pre>\n<p>On ESXi 3.5u3+<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">~ # kill $(pidof crond)\r\n~ # crond\r\n<\/code><\/pre>\n<p>On ESXi 4.x\/5.0<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">~ # kill $(cat \/var\/run\/crond.pid)\r\n~ # busybox crond\r\n<\/code><\/pre>\n<p>&nbsp;<\/p>\n<p>On ESXi 5.1<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">~ # kill $(cat \/var\/run\/crond.pid)\r\n~ # crond\r\n<\/code><\/pre>\n<p>&nbsp;<\/p>\n<p>3. Now that the cronjob is ready to go, you need to ensure that this\u00a0 cronjob will persist through a reboot. You&#8217;ll need to add the following two lines to\u00a0<strong>\/etc\/rc.local<\/strong>(ensure that the cron entry matches what was defined above). In ESXi 5.1, you will need to edit\u00a0<strong>\/etc\/rc.local.d\/local.sh<\/strong>\u00a0instead of \/etc\/rc.local as that is no longer valid.<\/p>\n<p>On ESXi 3.5<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">\/bin\/kill $(pidof crond)\r\n\/bin\/echo \"0 0 * * 1-5 \/vmfs\/volumes\/simplejack-local-storage\/ghettoVCB.sh -f \/vmfs\/volumes\/simplejack-local-storage\/backuplist &gt; \/vmfs\/volumes\/simplejack-local-storage\/ghettoVCB-backup-\\$(date +\\\\%s).log\" &gt;&gt; \/var\/spool\/cron\/crontabs\/root\r\ncrond\r\n<\/code><\/pre>\n<p>On ESXi 4.x\/5.0<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">\/bin\/kill $(cat \/var\/run\/crond.pid)\r\n\/bin\/echo \"0 0 * * 1-5 \/vmfs\/volumes\/simplejack-local-storage\/ghettoVCB.sh -f \/vmfs\/volumes\/simplejack-local-storage\/backuplist &gt; \/vmfs\/volumes\/simplejack-local-storage\/ghettoVCB-backup-\\$(date +\\\\%s).log\" &gt;&gt; \/var\/spool\/cron\/crontabs\/root\r\n\/bin\/busybox crond\r\n<\/code><\/pre>\n<p>&nbsp;<\/p>\n<p>On ESXi 5.1<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">\/bin\/kill $(cat \/var\/run\/crond.pid)\r\n\/bin\/echo \"0 0 * * 1-5 \/vmfs\/volumes\/simplejack-local-storage\/ghettoVCB.sh -f \/vmfs\/volumes\/simplejack-local-storage\/backuplist &gt; \/vmfs\/volumes\/simplejack-local-storage\/ghettoVCB-backup-\\$(date +\\\\%s).log\" &gt;&gt; \/var\/spool\/cron\/crontabs\/root\r\ncrond<\/code><\/pre>\n<p>Afterwards the file should look like the following:<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">~ # cat \/etc\/rc.local\r\n#! \/bin\/ash\r\nexport PATH=\/sbin:\/bin\r\n\r\nlog() {\r\n\u00a0\u00a0 echo \"$1\"\r\n\u00a0\u00a0 logger init \"$1\"\r\n}\r\n\r\n#execute all service retgistered in \/etc\/rc.local.d\r\nif [http:\/\/ -d \/etc\/rc.local.d |http:\/\/ -d \/etc\/rc.local.d ]; then\r\n\u00a0\u00a0 for filename in `find \/etc\/rc.local.d\/ | sort`\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 do\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 if [ -f $filename ] &amp;&amp; [ -x $filename ]; then\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 log \"running $filename\"\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 $filename\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 fi\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 done\r\nfi\r\n\r\n\/bin\/kill $(cat \/var\/run\/crond.pid)\r\n\/bin\/echo \"0 0 * * 1-5 \/vmfs\/volumes\/simplejack-local-storage\/ghettoVCB.sh -f \/vmfs\/volumes\/simplejack-local-storage\/backuplist &gt; \/vmfs\/volumes\/simplejack-local-storage\/ghettoVCB-backup-\\$(date +\\\\%s).log\" &gt;&gt; \/var\/spool\/cron\/crontabs\/root\r\n\/bin\/busybox crond\r\n\r\n<\/code><\/pre>\n<p>This will ensure that the cronjob is re-created upon a reboot of the system through a startup script<\/p>\n<p>2. To ensure that this is saved in the ESXi configuration, we need to manually initiate an ESXi backup by running:<\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">~ # \/sbin\/auto-backup.sh\r\nconfig implicitly loaded\r\nlocal.tgz\r\netc\/vmware\/vmkiscsid\/vmkiscsid.db\r\netc\/dropbear\/dropbear_dss_host_key\r\netc\/dropbear\/dropbear_rsa_host_key\r\netc\/opt\/vmware\/vpxa\/vpxa.cfg\r\netc\/opt\/vmware\/vpxa\/dasConfig.xml\r\netc\/sysconfig\/network\r\netc\/vmware\/hostd\/authorization.xml\r\netc\/vmware\/hostd\/hostsvc.xml\r\netc\/vmware\/hostd\/pools.xml\r\netc\/vmware\/hostd\/vmAutoStart.xml\r\netc\/vmware\/hostd\/vmInventory.xml\r\netc\/vmware\/hostd\/proxy.xml\r\netc\/vmware\/ssl\/rui.crt\r\netc\/vmware\/ssl\/rui.key\r\netc\/vmware\/vmkiscsid\/initiatorname.iscsi\r\netc\/vmware\/vmkiscsid\/iscsid.conf\r\netc\/vmware\/vmware.lic\r\netc\/vmware\/config\r\netc\/vmware\/dvsdata.db\r\netc\/vmware\/esx.conf\r\netc\/vmware\/license.cfg\r\netc\/vmware\/locker.conf\r\netc\/vmware\/snmp.xml\r\netc\/group\r\netc\/hosts\r\netc\/inetd.conf\r\netc\/rc.local\r\netc\/chkconfig.db\r\netc\/ntp.conf\r\netc\/passwd\r\netc\/random-seed\r\netc\/resolv.conf\r\netc\/shadow\r\netc\/sfcb\/repository\/root\/interop\/cim_indicationfilter.idx\r\netc\/sfcb\/repository\/root\/interop\/cim_indicationhandlercimxml.idx\r\netc\/sfcb\/repository\/root\/interop\/cim_listenerdestinationcimxml.idx\r\netc\/sfcb\/repository\/root\/interop\/cim_indicationsubscription.idx\r\nBinary files \/etc\/vmware\/dvsdata.db and \/tmp\/auto-backup.31345.dir\/etc\/vmware\/dvsdata.db differ\r\nconfig implicitly loaded\r\nSaving current state in \/bootbank\r\nClock updated.\r\nTime: 20:40:36\u00a0\u00a0 Date: 08\/14\/2009\u00a0\u00a0 UTC\r\n\r\n<\/code><\/pre>\n<p>Now you&#8217;re really done!<\/p>\n<p>If you&#8217;re still having trouble getting the cronjob to work, ensure that\u00a0 you&#8217;ve specified the correct parameters and there aren\u2019t any typos in\u00a0 any part of the syntax.<\/p>\n<p>Ensure crond (cron daemon) is running:<\/p>\n<p><strong>ESX 3.x\/4.0:<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">[root@himalaya dlgCore-NFS-bigboi.VM-Backups]# ps -ef | grep crond | grep -v grep\r\nroot\u00a0\u00a0\u00a0\u00a0\u00a0 2625\u00a0\u00a0\u00a0\u00a0 1\u00a0 0 Aug13 ?\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 00:00:00 crond\r\n<\/code><\/pre>\n<p><strong>ESXi 3.x\/4.x\/5.x:<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">~ # ps | grep crond | grep -v grep\r\n5196 5196 busybox\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 crond\r\n<\/code><\/pre>\n<p>&nbsp;<\/p>\n<p>Ensure that the date\/time on your ESX(i) host is setup correctly:<\/p>\n<p><strong>ESX(i):<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">[root@himalaya dlgCore-NFS-bigboi.VM-Backups]# date\r\nFri Aug 14 23:44:47 PDT 2009\r\n<\/code><\/pre>\n<p>&nbsp;<\/p>\n<p><strong>Note:<\/strong>\u00a0Careful attention must be noted if more than one backup is performed per day. Backup windows\u00a0 should be staggered to avoid contention or saturation of resources\u00a0 during these periods.<\/p>\n<p>&nbsp;<\/p>\n<hr \/>\n<p>&nbsp;<\/p>\n<h1>FAQ:<\/h1>\n<p><strong>0Q:<\/strong>\u00a0I&#8217;m getting error X when using the script or I&#8217;m not getting any errors, the backup didn\u2019t even take place. What can I do?<br \/>\n<strong>0A:<\/strong>\u00a0First off, before posting a comment\/question, please thoroughly read through the\u00a0<strong>ENTIRE<\/strong>\u00a0documentation\u00a0including\u00a0the FAQs to see if your question has already been ansered.<\/p>\n<p><strong>1Q:<\/strong>\u00a0I&#8217;ve read through the entire documentation + FAQs and still have not found my answer to the problem I&#8217;m seeing. What can I do?<br \/>\n<strong>1A:<\/strong>\u00a0Please join the\u00a0<a class=\"jive-link-socialgroup-small\" href=\"https:\/\/communities.vmware.com\/groups\/ghettovcb\">ghettoVCB Group<\/a>\u00a0to post your question\/comment.<\/p>\n<p>&nbsp;<\/p>\n<p><strong>2Q:<\/strong>\u00a0I&#8217;ve sent you private message or email but I haven&#8217;t received a response? What gives?<br \/>\n<strong>2A:<\/strong>\u00a0I do not accept issues\/bugs reported via PM or email, I will\u00a0 reply back, directing you to post on the appropriate VMTN forum (that&#8217;s\u00a0 what it&#8217;s for). If the data\/results you&#8217;re providing is truely senstive\u00a0 to your environment I will hear you out, but 99.99% it is not, so please\u00a0 do not messsage\/email me directly. I do monitor all forums that contain\u00a0 my script including the normal VMTN forums and will try to get back to\u00a0 your question as soon as I can and as time permits. Please do be patient as you&#8217;re not the only person using the script (600,000+ views), thank you.<\/p>\n<p><strong>3Q:<\/strong>\u00a0Can I schedule backups to take place hourly, daily, monthly, yearly?<br \/>\n<strong>3A:<\/strong>\u00a0Yes, do a search online for\u00a0<strong>crontab<\/strong>.<\/p>\n<p><strong>4Q:<\/strong>\u00a0I would like to setup cronjob for ESX(i) 3.5 or 4.0?<br \/>\n<strong>4A:<\/strong>\u00a0Take a look at the Cronjob FAQ section in this document.<\/p>\n<p><strong>5Q:<\/strong>\u00a0I want to schedule my backup on Windows, how do I do this?<br \/>\n<strong>5A:<\/strong>\u00a0Do a search for\u00a0<strong>plink<\/strong>. Make sure you have paired SSH keys setup between your Windows system and ESX\/ESXi host.<\/p>\n<p><strong>6Q:<\/strong>\u00a0I only have a single ESXi host. I want to take backups and\u00a0 store them somewhere else. The problem is: I don&#8217;t have NFS, iSCSI nor\u00a0 FC SAN. What can I do?<br \/>\n<strong>6A:<\/strong>\u00a0You can use local storage to store your backups assuming that\u00a0 you have enough space on the destination datastore.\u00a0 Afterwards, you\u00a0 can use scp (WinSCP\/FastSCP) to transfer the backups from the ESXi host\u00a0 to your local desktop.<\/p>\n<p><strong>7Q:<\/strong>\u00a0I\u2019m pissed; the backup is taking too long. My datastore is of type X?<br \/>\n<strong>7A:<\/strong>\u00a0YMMV, take a look at your storage configuration and make sure it is optimized.<\/p>\n<p><strong>8Q:<\/strong>\u00a0I noticed that the backup rotation is occurring after a\u00a0 backup. I don&#8217;t have enough local storage space, can the process be\u00a0 changed?<br \/>\n<strong>8A:<\/strong>\u00a0This is primarily done to ensure that you have at least one\u00a0 good backup in case the new backup fails. If you would like to modify\u00a0 the script, you&#8217;re more than welcome to do so.<\/p>\n<p><strong>9Q:<\/strong>\u00a0What is the best storage configuration for datastore type X?<br \/>\n<strong>9A:<\/strong>\u00a0Search the VMTN forums; there are various configurations for the different type of storage\/etc.<\/p>\n<p><strong>10Q:<\/strong>\u00a0I want to setup an NFS server to run my backups. Which is the best and should it be virtual or physical?<br \/>\n<strong>10A:<\/strong>\u00a0Please refer to answer 7A. From experience, we\u2019ve seen\u00a0 physical instances of NFS servers to be faster than their virtual\u00a0 counterparts. As always, YMMV.<\/p>\n<p><strong>11Q:<\/strong>\u00a0I have VMs that have snapshots. I want to back these things up but the script doesn\u2019t let me do it. How do I fix that?<br \/>\n<strong>11A:<\/strong>\u00a0VM snapshots are not meant to be kept for long durations.\u00a0 When backing up a VM that contains a snapshot, you should ensure all snapshots have been committed prior to running a backup. No exceptions\u00a0 will be made\u2026ever.<\/p>\n<p><strong>12Q:<\/strong>\u00a0I would like to restore from backup, what is the best method?<br \/>\n<strong>12A:<\/strong>\u00a0The restore process will be unique for each environment and\u00a0 should be determined by your backup\/recovery plans. At a high level you have the option of mounting the backup datastore and registering the VM\u00a0 in question or copy the VM from the backup datastore to the ESX\/ESXi\u00a0 host. The latter is recommended so that you&#8217;re not running a VM living\u00a0 on the backup datastore or inadvertently modifying your backup VM(s). You can also take a look at\u00a0<a class=\"jive-link-wiki-small\" href=\"https:\/\/communities.vmware.com\/docs\/DOC-10595\" data-containerid=\"2411\" data-containertype=\"14\" data-objectid=\"10595\" data-objecttype=\"102\">ghettoVCB-restore<\/a>\u00a0which is experimentally supported.<\/p>\n<p><strong>13Q:<\/strong>\u00a0When I try to run the script I get:\u00a0<strong>&#8220;-bash: .\/ghettoVCB.sh: Permission denied&#8221;<\/strong>, what is wrong?<br \/>\n<strong>13A:<\/strong>\u00a0You need to change the permission on the script to be executable, chmod +x ghettoVCB.sh<\/p>\n<p><strong>14Q:<\/strong>\u00a0Where can I download the latest version of the script?<br \/>\n<strong>14A:<\/strong>\u00a0The latest version is available on on github &#8211;\u00a0<a class=\"jive-link-external-small\" href=\"https:\/\/github.com\/lamw\/ghettoVCB\/downloads\" rel=\"nofollow\">httpss:\/\/github.com\/lamw\/ghettoVCB\/downloads<\/a><\/p>\n<p><strong>15Q:<\/strong>\u00a0I would like to suggest\/recommend feature X, can I get it?\u00a0 When can I get it? Why isn&#8217;t it here, what gives?<br \/>\n<strong>15A:<\/strong>\u00a0The general purpose of this script is to provide a backup\u00a0 solution around VMware VMs. Any additional features outside of that\u00a0 process will be taken into consideration depending on the amount of\u00a0 time, number of requests and actual usefulness as a whole to the\u00a0 community rather than to an individual.<\/p>\n<p><strong>16Q:<\/strong>\u00a0I have found this script to be very useful and would like to contribute back, what can I do?<br \/>\n<strong>16A:<\/strong>\u00a0To continue to develop and share new scripts and resources with the community, we need your support. You can donate\u00a0<a class=\"jive-link-external\" href=\"http:\/\/www.virtuallyghetto.com\/p\/how-you-can-help.html\">here<\/a>\u00a0Thank You!<\/p>\n<p><strong>17Q:<\/strong>\u00a0What are the different type of backup uses cases that are supported with ghettoVCB?<br \/>\n<strong>17A:<\/strong>\u00a01) Live backup of VM with the use of a snapshot and 2)\u00a0 Offline backup of a VM without a snapshot. These are the only two use\u00a0 cases supported by the script.<\/p>\n<p><strong>18Q:<\/strong>\u00a0When I execute the script on ESX(i) I get some funky errors such as &#8220;: not found.sh&#8221; or &#8220;command not found&#8221;. What is this?<br \/>\n<strong>18A:<\/strong>\u00a0Most likely you have some ^M characters within the script\u00a0 which may have come from either editing the script using Windows editor,\u00a0 uploading the script using the datastore browser OR using wget. The\u00a0 best option is to either using WinSCP on Windows to upload the script\u00a0 and edit using vi editor on ESX(i) host OR Linux\/UNIX scp to copy the\u00a0 script into the host. If you still continue to have the issue, do a\u00a0 search online on various methods of removing this Windows return\u00a0 carriage from the script<\/p>\n<p><strong>19Q:<\/strong>\u00a0My backup works fine OR it works for a single backup but I get an error message\u00a0 &#8220;Input\/output error&#8221; or &#8220;-ash: YYYY-MM-DD: not found&#8221; during the snapshot removal process. What is this?<br \/>\n<strong>19A:<\/strong>\u00a0The issue has been recently identified by few users as a problem with user&#8217;s NFS server in which it reports an error when deleting large files that take longer than 10seconds. VMware has recently released a KB article\u00a0<a class=\"jive-link-external-small\" href=\"http:\/\/kb.vmware.com\/kb\/1035332\" rel=\"nofollow\">https:\/\/kb.vmware.com\/kb\/1035332<\/a>\u00a0explaining the details and starting with\u00a0<strong>vSphere 4.1 Update 2<\/strong>\u00a0or\u00a0<strong>vSphere 5.0<\/strong>, a new advanced ESX(i) parameter has been introduced to increase the timeout. This has resolved the problem for several users and maybe something to consider if you are running into this issue, specifically with NFS based backups.<\/p>\n<p><strong>20Q:<\/strong>\u00a0Will this script function with vCenter and DRS enabled?<br \/>\n<strong>20Q:<\/strong>\u00a0No, if the ESX(i) hosts are in a DRS enabled cluster, VMs\u00a0 that are to be backed up could potentially be backed up twice or never\u00a0 get backed up. The script is executed on a per host basis and one would\u00a0 need to come up a way of tracking backups on all hosts and perhaps write\u00a0 out to external file to ensure that all VMs are backed up. The main use\u00a0 case for this script are for standalone ESX(i) host<\/p>\n<p><strong>21Q:<\/strong>\u00a0I&#8217;m trying to use WinSCP to manually copy VM files but it&#8217;s very slow or never completes on huge files, why is that?<br \/>\n<strong>21A:<\/strong>\u00a0WinSCP was not designed for copying VM files out of your\u00a0 ESX(i) host, take a look at Veeam&#8217;s FastSCP which is designed for moving\u00a0 VM files and is a free utility.<\/p>\n<p><strong>22Q:<\/strong>\u00a0Can I use setup NFS Server using Windows Services for UNIX (WSFU) and will it work?<br \/>\n<strong>22A:<\/strong>\u00a0I&#8217;ve only heard a handful of users that have successfully\u00a0 implemented WSFU and got it working, YMMV. VMware also has a KB article\u00a0 decribing the setup process here:\u00a0<a class=\"jive-link-external\" href=\"http:\/\/kb.vmware.com\/kb\/1004490\">https:\/\/kb.vmware.com\/kb\/1004490<\/a>\u00a0for those that are interested. Here is a\u00a0<a class=\"jive-link-thread-small\" href=\"https:\/\/communities.vmware.com\/thread\/304951\" data-containerid=\"1052\" data-containertype=\"700\" data-objectid=\"304951\" data-objecttype=\"1\">thread<\/a>\u00a0on a user&#8217;s experience between Windows Vs. Linux NFS that maybe helpful.<\/p>\n<p><strong>23Q:<\/strong>\u00a0How do VMware Snapshots work?<br \/>\n<strong>23A:<\/strong>\u00a0<a class=\"jive-link-external\" href=\"http:\/\/kb.vmware.com\/kb\/1015180\">https:\/\/kb.vmware.com\/kb\/1015180<\/a><\/p>\n<p><strong>24Q:<\/strong>\u00a0What files make up a Virtual Machine?<br \/>\n<strong>24A:<\/strong>\u00a0<a class=\"jive-link-external\" href=\"http:\/\/virtualisedreality.wordpress.com\/2009\/09\/16\/quick-reminder-of-what-files-make-up-a-virtual-machine\/\">https:\/\/virtualisedreality.wordpress.com\/2009\/09\/16\/quick-reminder-of-what-files-make-up-a-virtual-machine\/<\/a><\/p>\n<p><strong>25Q:<\/strong>\u00a0I&#8217;m having some issues restoring a compressed VM backup?<br \/>\n<strong>25A:<\/strong>\u00a0There is a limitation in the size of the VM for compression\u00a0 under ESXi 3.x &amp; 4.x, this limitation is in the unsupported Busybox\u00a0 console and\u00a0should\u00a0not affect classic ESX 3.x\/4.x. On ESXi 3.x,\u00a0 the maximum largest supported VM is 4GB for compression and on ESXi 4.x\u00a0 the largest supported VM is 8GB. If you try to compress a larger VM, you\u00a0\u00a0may\u00a0run into issues when trying to extract upon a restore.\u00a0<strong>PLEASE TEST THE RESTORE PROCESS BEFORE MOVING TO PRODUCTION SYSTEMS!<\/strong><\/p>\n<p><strong>26Q:<\/strong>\u00a0I&#8217;m backing up my VM as &#8220;thin&#8221; format but I&#8217;m still not noticing any size reduction in the backup? What gives?<br \/>\n<strong>2bA:<\/strong>\u00a0Please refer to this blog post which explains what&#8217;s going on:\u00a0<a class=\"jive-link-external\" href=\"http:\/\/www.yellow-bricks.com\/2009\/07\/31\/storage-vmotion-and-moving-to-a-thin-provisioned-disk\/\">https:\/\/www.yellow-bricks.com\/2009\/07\/31\/storage-vmotion-and-moving-to-a-thin-provisioned-disk\/<\/a><\/p>\n<p><strong>27Q:<\/strong>\u00a0I&#8217;ve enabled\u00a0<strong>VM_SNAPSHOT_MEMORY<\/strong>\u00a0and when I restore my VM it&#8217;s still offline, I thought this would keep it&#8217;s memory state?<br \/>\n<strong>27A:<\/strong>\u00a0<strong>VM_SNAPSHOT_MEMORY<\/strong>\u00a0is only used to ensure when the\u00a0 snapshot is taken, it&#8217;s memory contents are also captured. This is only\u00a0 relavent to the actual snapshot itself and it&#8217;s not used in any\u00a0 shape\/way\/form in regards to the backup. All backups taken whether your\u00a0 VM is running or offline will result in an offline VM backup when you\u00a0 restore. This was originally added for debugging purposes and in\u00a0 generally should be left disabled<\/p>\n<p><strong>28Q:<\/strong>\u00a0Can I rename the directories and the VMs after a VM has been backed up?<br \/>\n<strong>28A:<\/strong>\u00a0The answer yes, you can &#8230; but you may run into all sorts\u00a0 of issues which may break the backup process. The script expects a\u00a0 certain layout and specific naming scheme for it to maintain the proper\u00a0 rotation count. If you need to move or rename a VM, please take it out\u00a0 of the directory and place it in another location<\/p>\n<p><strong>29Q:<\/strong>\u00a0Can ghettoVCB support CBT (Change Block Tracking)?<br \/>\n<strong>29A:\u00a0<\/strong>No, that is a functionality of the vSphere API + VDDK API (vSphere Disk Development Kit). You will need to look at paid solutions such as VMware vDR, Veeam Backup &amp; Recovery, PHD Virtual Backups, etc. to leverage that functionailty.<\/p>\n<p>&nbsp;<\/p>\n<p><strong>30Q:<\/strong>\u00a0Does ghettoVCB support rsync backups?<br \/>\n<strong>30A:\u00a0<\/strong>Currently ghettoVCB does not support rsync backups, you either obtain or compile your own static rsync binary and run on ESXi, but this is an unsupported configuration. You may take a look at this\u00a0<a class=\"jive-link-external-small\" href=\"http:\/\/www.virtuallyghetto.com\/2011\/02\/how-to-compile-statically-linked-rsync.html\" rel=\"nofollow\">blog post<\/a>\u00a0for some details.<\/p>\n<p>&nbsp;<\/p>\n<p><strong>31Q:<\/strong>\u00a0How can I contribute back?<\/p>\n<p><strong>31A:<\/strong>\u00a0You can provide feedback\/comments on the\u00a0<a class=\"jive-link-socialgroup-small\" href=\"https:\/\/communities.vmware.com\/groups\/ghettovcb\">ghettoVCB Group<\/a>. If you have found this script to be useful and would like to contribute back, please click\u00a0<a class=\"jive-link-external\" href=\"http:\/\/www.virtuallyghetto.com\/p\/how-you-can-help.html\">here<\/a>\u00a0to donate.<\/p>\n<p>&nbsp;<\/p>\n<p><strong>32Q<\/strong>: How can select individual VMDKs to backup from a VM?<\/p>\n<p><strong>32A<\/strong>: Ideally you would use the &#8220;<strong>-c<\/strong>&#8221; option which requires you to create individual VM configuration file, this is where you would select specific VMDKs to backup. Note, that if you do not need to define all properties, anything not defined will adhere from the default global properties whether you&#8217;re editing the ghettoVCB.sh script or using ghettoVCB global configuration file. It is not recommended that you edit the ghettoVCB.sh script and modify the\u00a0<strong>VMDK_FILES_TO_BACKUP<\/strong>\u00a0variable, but if you would like to keep everything in one script, you may add the extensive list of VMDKs to backup but do know this can get error prone as script may be edited frequently and lose some flexibility to support multiple environments.<\/p>\n<p>&nbsp;<\/p>\n<p><strong>33Q:<\/strong>\u00a0Why is email not working when I&#8217;m using ESXi 5.x but it worked in ESXi 4.x?<\/p>\n<p><strong>33A:<\/strong>\u00a0ESXi 5.x has implemented a new firewall which requires the email port that is being used to be opened. Please refer to the following articles on creating a custom firewall rule for email:<\/p>\n<p><a class=\"jive-link-external-small\" href=\"http:\/\/www.virtuallyghetto.com\/2012\/09\/creating-custom-vibs-for-esxi-50-51.html\" rel=\"nofollow\">https:\/\/www.virtuallyghetto.com\/2012\/09\/creating-custom-vibs-for-esxi-50-51.html<\/a><\/p>\n<p><a class=\"jive-link-external-small\" href=\"http:\/\/www.virtuallyghetto.com\/2011\/07\/how-to-create-custom-firewall-rules-in.html\" rel=\"nofollow\">How to Create Custom Firewall Rules in ESXi 50<\/a><\/p>\n<p><a class=\"jive-link-external-small\" href=\"http:\/\/www.virtuallyghetto.com\/2011\/08\/how-to-persist-configuration-changes-in.html\" rel=\"nofollow\">How to Persist Configuration Changes in ESXi 4.x\/5.x Part 1<\/a><\/p>\n<p><a class=\"jive-link-external-small\" href=\"http:\/\/www.virtuallyghetto.com\/2011\/08\/how-to-persist-configuration-changes-in_09.html\" rel=\"nofollow\">How to Persist Configuration Changes in ESXi 4.x\/5.x Part 2<\/a><\/p>\n<p>&nbsp;<\/p>\n<p><strong>34Q:<\/strong>\u00a0How do I stop the ghettoVCB process?<\/p>\n<p><strong>34A:<\/strong>\u00a0Take a look at the\u00a0<strong>Stopping ghettoVCB Process<\/strong>\u00a0section of the documentation for more details.<\/p>\n<p>&nbsp;<\/p>\n<hr \/>\n<p>&nbsp;<\/p>\n<h1>Our NFS Server Configuration<\/h1>\n<p>Many have asked what is the best configuration and recommendation for\u00a0 setting up a cheap NFS Server to run backups for VMs. This has been a\u00a0 question we&#8217;ve tried to stay away from just because the possiblities and\u00a0 solutions are endless. One can go with physical vs. virtual, use VSA\u00a0 (Virtual Storage Appliances) such as OpenFiler or Lefthand Networks,\u00a0 Windows vs. Linux\/UNIX. We&#8217;ve not personally tested and verify all these\u00a0 solutions and it all comes down to &#8220;it depends&#8221; type of answer. Though\u00a0 from our experience, we&#8217;ve had much better success with a physical\u00a0 server than a virtual.<\/p>\n<p>It is also well known that some users are experiencing backup issues\u00a0 when running specifically against NFS, primarily around the rotation and\u00a0 purging of previous backups. The theory from what we can tell by\u00a0 talking to various users is that when the rotation is occuring, the\u00a0 request to delete the file(s) may take awhile and does not return within\u00a0 a certain time frame and causes the script to error out with unexpected\u00a0 messages. Though the backups were successful, it will cause unexpected\u00a0 results with directory structures on the NFS target. We&#8217;ve not been able\u00a0 to isolate why this is occuring and maybe due to NFS\u00a0 configuration\/exports or hardware or connection not being able to\u00a0 support this process.<\/p>\n<p>We&#8217;ll continue to help where we can in diagonising this issus but we\u00a0 wanted to share our current NFS configuration, perhaps it may help some\u00a0 users who are new or trying to setup their system. (\u00a0<strong>Disclaimer:<\/strong>\u00a0These configurations are not recommendations nor endorsement for any of the components being used)<\/p>\n<p><strong>UPDATE:<\/strong>\u00a0Please also read FAQ #19 for details + resolution<\/p>\n<p><strong>Server Type:<\/strong>\u00a0Physical<br \/>\n<strong>Model:<\/strong>\u00a0HP DL320 G2<br \/>\n<strong>OS:<\/strong>\u00a0Arch linux 2.6.28<br \/>\n<strong>Disks:<\/strong>\u00a02 x 1.5TB<br \/>\n<strong>RAID:<\/strong>\u00a0Software RAID1<br \/>\n<strong>Source Host Backups:<\/strong>\u00a0ESX 3.5u4 and ESX 4.0u1 (We don&#8217;t run any ESXi hosts)<\/p>\n<p><strong>uname -a output<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">Linux XXXXX.XXXXX.ucsb.edu 2.6.28-ARCH #1 SMP PREEMPT Sun Jan 18 20:17:17 UTC 2009 i686 Intel(R) Pentium(R) 4 CPU 3.06GHz GenuineIntel GNU\/Linux\r\n<\/code><\/pre>\n<p><strong>NICs:<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">00:05.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5702X Gigabit Ethernet (rev 02)\r\n00:06.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5702X Gigabit Ethernet (rev 02)\r\n<\/code><\/pre>\n<p><strong>NFS Export Options:<\/strong><\/p>\n<pre class=\"jive-pre\"><code class=\"jive-code jive-plain\">\/exports\/vm-backups XXX.XXX.XXX.XXX\/24(rw,async,all_squash,anonuid=99,anongid=99)\r\n<\/code><\/pre>\n<p>&nbsp;<\/p>\n<p>*One important thing to check is to verify that your NFS exportion options are setup correctly,\u00a0<strong>&#8220;async&#8221;<\/strong>\u00a0should be configured to ensure that all IO requests are processed and\u00a0 reply back to the client before waiting for the data to be written to\u00a0 the storage.<\/p>\n<p>*Recently VMware released a KB article describing the various &#8220;Advanced NFS Options&#8221; and their meanings and recommendations:\u00a0<a class=\"jive-link-external\" href=\"http:\/\/kb.vmware.com\/kb\/1007909\" name=\"&amp;lpos=apps_scodevmw : 97\">https:\/\/kb.vmware.com\/kb\/1007909<\/a>\u00a0We&#8217;ve not personally had to touch any of these, but for other vendors\u00a0 such as EMC and NetApp, there are some best practices around configuring\u00a0 some of these values depending on the number of NFS volumes or number\u00a0 of ESX(i) host connecting to a volume. You may want to take a look to\u00a0 see if any of these options may help with NFS issue that some are seeing<\/p>\n<p>*Users should also try to look at their ESX(i) host logs during the time\u00a0 interval when they&#8217;re noticing these issues and see if they can find\u00a0 any correlation along with monitoring the performance on their NFS\u00a0 Server.<\/p>\n<p>*Lastly, there are probably other things that can be done to improve NFS\u00a0 performance or further optimization, a simple search online will also\u00a0 yield many resources.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Table of Contents: Description Features Requirements Setup Configurations Usage Sample Execution Dry run Mode Debug backup Mode Backup VMs stored in a list Backup All VMs residing on specific ESX(i) host Backup All VMs residing on specific ESX(i) host and exclude the VMs in the exclusion list Backup VMs using individual backup policies Enable compression [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[730,1,42,51,495,1304],"tags":[1305,1307,1310,1306,739,1308,1309],"class_list":["post-4652","post","type-post","status-publish","format-standard","hentry","category-clusterweb","category-viazap","category-leitura-recomendada","category-linux-linuxrs","category-profissional-de-ti","category-vmware-esxi","tag-alternative","tag-backing","tag-esxi","tag-for","tag-free","tag-up","tag-vms"],"_links":{"self":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/4652","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=4652"}],"version-history":[{"count":1,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/4652\/revisions"}],"predecessor-version":[{"id":4653,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/4652\/revisions\/4653"}],"wp:attachment":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=4652"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=4652"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=4652"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}