Home / server / Questions / 441740
In Process
Ulf Klose
Asked: 2012-10-25 03:52:47 +0800 CST

ghettoVCB: ERROR: Unable to backup MACHINE-NAME due to error in VMDK backup

  • 772

I'm on VMware ESXI 5.0.0 Update 1 and wanted to use the ghettoVCB script for backuping my VMs.

The dryrun went perfectly fine:

2012-10-24 11:47:46 -- info: ###### Final status: OK, only a dryrun. ######

But when I try to do an actual backup, I get the following message for every VM on my host:

2012-10-24 11:48:43 -- info: Initiate backup for Willert-Tools
2012-10-24 11:48:43 -- info: Creating Snapshot "ghettoVCB-snapshot-2012-10-24" for Willert-Tools

2012-10-24 11:48:47 -- info: ERROR: error in backing up of "/vmfs/volumes/datastore1/Willert-Tools/Willert-Tools_1.vmdk" for Willert-Tools

2012-10-24 11:48:47 -- info: ERROR: error in backing up of "/vmfs/volumes/datastore1/Willert-Tools/Willert-Tools.vmdk" for Willert-Tools
2012-10-24 11:48:50 -- info: Removing snapshot from Willert-Tools ...
2012-10-24 11:48:50 -- info: Compressing VM backup "/vmfs/volumes/Cluster-Backup/Willert-Tools/Willert-Tools-2012-10-24_11-48-31.gz"...
2012-10-24 11:48:50 -- info: Successfully compressed backup for Willert-Tools!

2012-10-24 11:48:50 -- info: Backup Duration: 7 Seconds
2012-10-24 11:48:50 -- info: ERROR: Unable to backup Willert-Tools due to error in VMDK backup!

What am I doing wrong? As I didn’t want to paste every configuration snippet from my configuration, please ask if you need more specific information.

The backup is supposed to be saved to a NFS share which is correctly mounted on my ESXi host.

Thanks for your help :-).

backup

2 Answers

  1. the most I can suggest by seeing the output is:

    1) Are you sure the path to your NFS mount or datastore is correct in the ghettoVCB configs? Double check all NFS configs for ghettoVCB.

    And...

    2) Is your NFS share accepting anonymous access and granting read/write permissions?

    Judging by the output, the script was able to create the snapshot but then 5 seconds later it said it could not back up the VMDK. My guess is this is a permissions issue on NFS mount. That, or lack of free space.

    • 1

  2. I recently began seeing this error on a system that had long been running flawlessly, and which had not been changed. One difference is that ghettoVCB was successfully backing up the other VMs on the system.

    Direct execution of vmkfstools clone command resulted in the same error, with 3 different target file systems. The VM was powered down for this attempt.

    This is a windows 7 pro VM. What ultimately worked for me was the following:

    • defrag the drive (used defraggler)
    • zero the free space (\sdelete\sdelete -z c:)
    • chkdsk c: /f
    • reboot
    • shutdown
    • ssh to esxi 5.5 box
    • vmkfstools -i /path/to/disk.vmdk -d thin /path/to/disk_backup.vmdk
      • note the "-d thin" is useless when writing to the same physical medium as the source disk.

    SUCCESS!

    • vmkfstools -E /path/to/disk.vmdk /path/to/renamed_disk.vmdk
    • vmkfstools -E /path/to/disk_backup.vmdk /path/to/disk.vmdk
    • Start up the vm to test
    • run ghettoVCB against the VM while the VM was "powered up" (with the added benefit that the "thin" parameter applies when writing from the source to the NFS target).

    SUCCESS!

    I suspect the sdelete command was the key operation.

    Remember to remove the renamed_disk.vmdk and renamed_disk-flat.vmdk

    addenda (2020-11-03)

    This issue recently came up in the ghettoVCB mailing list (Error in VMDK backup (#202)). This is the thread for ghettoVCB on GitHub.

    the user described this issue, then later posted this fix:

    So I made one change, and that was to mount my backup datastore as nfs3 instead of nfs4. This seems t have solved the issue. Not sure why it is, but posting this in case anyone else runs into a similar issue.

    There was also a handy tip for troubleshooting in the thread, contributed by another user:

    Some times is difficult to find an error on vmkfstools phase, like a bad block on a storage, the returned error is a generic error.

    Using -v 10 on vmkfstools line, like above, you can watch and find the error, but when ghettoVCB.sh runs on CRON schedule, the captured log does not includes the debug lines from vmkfstools:

    Lines changed:

    if [[ -z "${FORMAT_OPTION}" ]] ; then logger "debug" > "${VMKFSTOOLS_CMD} -i "${SOURCE_VMDK}" -a "${ADAPTER_FORMAT}" "${DESTINATIO ... ${VMKFSTOOLS_CMD} -v 10 -i "${SOURCE_VMDK}" -a "${ADAPTER_FORMAT}" "${DESTINATION_VMDK}" > "${V... else logger "debug" "${VMKFSTOOLS_CMD} -i "${SOURCE_VMDK}" -a "${ADAPTER_FORMAT}" -d "${FORMAT_... ${VMKFSTOOLS_CMD} -v 10 -i "${SOURCE_VMDK}" -a "${ADAPTER_FORMAT}" -d "${FORMAT_OPTION}" "${DES fi

    where "lines changed" are in the ghettoVCB.sh script.

    • 0