ghettoVCB Documentation

repository·master·Indexed 23 days ago

https://github.com/lamw/ghettovcb

A non-interactive backup solution for ESX(i) virtual machines (versions 3.x through 9.x) that runs directly in the ESXi Shell. It provides a lightweight alternative to VMware's VCB tool by taking snapshots of live VMs and backing up master VMDKs to local storage, SAN, or NFS. The tool supports automated scheduling via cron, non-persistent NFS mounts, and granular backup policies per VM.

Tokens
5.6K
Snippets
13
Records
30
Agent score
31%

What's inside ghettoVCB

  1. Overview of ghettoVCB

    master

    ghettoVCB is a script designed to perform online backups of virtual machines residing on ESX(i) servers (versions 3.x through 9.x). It follows a methodology similar to VMware's VCB tool by taking snapshots of live running VMs, backing up the master VMDK(s), and then deleting the snapshot upon completion.

    Unlike traditional VCB methods that use a proxy, ghettoVCB utilizes the resources available directly to the ESXi Shell. It supports LOCAL STORAGE, SAN, and NFS backup mediums. The script is non-interactive and can be scheduled via cron. It supports both persistent and non-persistent NFS backups, where the script automatically connects/disconnects the ESXi server to an NFS exported folder to enable monolithic (thick) VMDK backups.

  2. Configure individual VM backup policies

    master

    You can define granular backup policies for specific VMs using the -c option.

    1. Create a directory to hold your policy files (e.g., mkdir backup_config).
    2. Create a policy file for each VM. The filename must match the exact display name of the VM.
    3. Use the template /opt/ghettovcb/ghettoVCB-vm_backup_configuration_template to create these files.

    Behavior Note: If a VM is included in a backup list (via -f or -a) but does not have a corresponding policy file in the directory specified by -c, the script will fall back to the default configuration defined within ghettoVCB.sh for that VM.

  3. Schedule ghettoVCB backups on classic ESX

    master

    On classic ESX servers (with Service Console), cronjobs behave like traditional *nix systems. To schedule a backup:

    1. Open the crontab editor as root: crontab -e
    2. Append your cron entry. For example, to run a backup Monday-Friday at midnight and save a unique log file using a timestamp: 0 0 * * 1-5 /vmfs/volumes/path/to/ghettoVCB.sh -f /vmfs/volumes/path/to/backuplist > /vmfs/volumes/path/to/ghettoVCB-backup-$(date +\%s).log
    3. Save and exit.
    4. Verify the entry with crontab -l.
  4. Configure logging for ghettoVCB.sh

    master

    By default, logs are output to /tmp/ghettoVCB.log. Because /tmp is often volatile, it is recommended to redirect logs to a local or remote datastore to ensure they persist for troubleshooting. Use the -l flag to specify the log file path.

    /opt/ghettovcb/bin/ghettoVCB.sh -f vms_to_backup -l /vmfs/volume/local-storage/ghettoVCB.log
  5. Schedule ghettoVCB backups on ESXi (with persistence)

    master

    On ESXi, changes to the cron configuration do not persist through a reboot. You must configure the cronjob and then add it to the startup scripts to ensure it survives a reboot.

    1. Configure the Cronjob

    Append the cron line to /var/spool/cron/crontabs/root. If you cannot edit it directly, create a backup, edit the copy, and move it back:

    cp /var/spool/cron/crontabs/root /var/spool/cron/crontabs/root.backup
    # [Edit root.backup with your cron line]
    mv /var/spool/cron/crontabs/root.backup /var/spool/cron/crontabs/root

    2. Restart the Cron Daemon

    You must restart crond for changes to take effect. The command depends on your ESXi version:

    • ESXi 5.1 to 6.x: kill $(cat /var/run/crond.pid) && crond
    • ESXi 7.x and later: kill $(cat /var/run/crond.pid) > /dev/null 2>&1 && /usr/lib/vmware/busybox/bin/busybox crond

    3. Ensure Persistence via /etc/rc.local

    Add the commands to recreate the cronjob to /etc/rc.local (or /etc/rc.local.d/local.sh on ESXi 5.1). This ensures the cronjob is re-added upon reboot.

    For ESXi 7.x and later, add these lines to /etc/rc.local:

    /bin/kill $(cat /var/run/crond.pid) > /dev/null 2>&1
    /bin/echo "0 0 * * 1-5 /vmfs/volumes/path/to/ghettoVCB.sh -f /vmfs/volumes/path/to/backuplist > /vmfs/volumes/path/to/ghettoVCB-backup-\$(date +\\%s).log" >> /var/spool/cron/crontabs/root
    /usr/lib/vmware/busybox/bin/busybox crond

    4. Save ESXi Configuration

    After modifying /etc/rc.local, run the following to save the state to the bootbank: /sbin/auto-backup.sh

    # Example for ESXi 7.x persistence in /etc/rc.local
    /bin/kill $(cat /var/run/crond.pid) > /dev/null 2>&1
    /bin/echo "0 0 * * 1-5 /vmfs/volumes/simplejack-local-storage/ghettoVCB.sh -f /vmfs/volumes/simplejack-local-storage/backuplist > /vmfs/volumes/simplejack-local-storage/ghettoVCB-backup-\$(date +\\%s).log" >> /var/spool/cron/crontabs/root
    /usr/lib/vmware/busybox/bin/busybox crond
  6. Run a dry run of ghettoVCB

    master

    Use the dryrun debug mode to preview which VMs and VMDKs will be backed up without actually performing any backup operations. This mode identifies potential issues such as existing snapshots (which prevent backup) or independent disks (which may result in incomplete backups).

    Note on Logging: By default, logs are stored in /tmp. On ESXi, files in /tmp may not persist through reboots. For reliable log retention, configure the script to log to a local or remote datastore.

    [root@himalaya]# /opt/ghettovcb/bin/ghettoVCB.sh -f vms_to_backup -d dryrun
  7. Install ghettoVCB on ESXi 5.x to 6.x

    master
    To install or update ghettoVCB on ESXi versions 5.x through 6.x, use the esxcli command to install the VIB file. Use the update command instead of install if you want to preserve settings from an existing ghettoVCB.conf file.
  8. Use a Global Configuration File and Multiple Instances

    master

    To avoid modifying the main ghettoVCB.sh script, you can use a global configuration file (e.g., ghettoVCB.conf) containing all your environment-specific variables.

    Using a Global Config

    Run the script with the -g flag followed by the path to your configuration file:

    ./ghettoVCB.sh -g /path/to/ghettoVCB.conf

    Running Multiple Instances

    You can run multiple instances of ghettoVCB simultaneously by specifying a unique working directory using the -w flag. This prevents conflicts between concurrent runs.

    Warning: Running multiple instances consumes ESXi Shell resources. This is an experimental feature; test in a development environment before production use.

  9. Stop ghettoVCB processes (Non-Interactively)

    master

    When running ghettoVCB non-interactively (e.g., via a script), you must manually stop the main process, the tail command, and any active vmkfstools copy processes.

    1. Identify processes: Search for the ghettoVCB and tail processes:
      ~ # ps -c | grep ghettoVCB | grep -v grep
    2. Kill main and tail processes: Use the PIDs found in step 1:
      kill -9 <PID_of_ghettoVCB>
      kill -9 <PID_of_tail>
    3. Kill vmkfstools process: If a VM was actively being backed up, a vmkfstools process will be running. Search for it:
      # ps -c | grep vmkfstools | grep -v grep
      Warning: Verify the command path maps to the correct VM before killing the process to avoid impacting other running VMs or the ESXi host.
      # kill -9 <PID_of_vmkfstools>
    4. Post-stop cleanup: Use the vSphere Client to consolidate or remove any snapshots remaining on the VM that was being backed up.
    # ps -c | grep ghettoVCB | grep -v grep
    # ps -c | grep vmkfstools | grep -v grep
    # kill -9 <PID>