ghettoVCB and ghettoVCBg2 are two completely different scripts, they are similar in their function but in terms of features, they're not complete parity of each other.
ghettoVCB is able to support compression as the actual backups are done through either the classic ESX Service Console or ESXi Busybox Console and using the available compression utilities, we're able to provide this functionality. The other main key is that the backup runs directly on the console, it does not make use of any of the vSphere API and is able to support both licensed and free version of ESX and ESXi.
ghettoVCBg2 on the other hand utilizes the vSphere API to perform the backups and the script does not run on ESX(i) console(s) but remotely from vMA. This requies that your ESX and ESXi host are licensed and there are no compression features built into the vSphere API and hence compression of the backups can only be done through an external system after the backup has completed.
If you heavliy use the compression mechenism, I would recommend sticking to ghettoVCB OR looking at paid solutions such as Veeam, Phd, VMware vDR in which you can leverage CBT (Change Block Tracking) to not only shrink your backup window but also backing up only blocks of data that changes.
I am using ghettoVCB (Not g2) and I would like to transfer the ghetto Backups to a filesystem outside of esxi (on another physical host on the LAN). The files have a 100G+ provisioned size, but are actually around 67G.
In what way can I transfer these files at their 67G size, and not their 100G size?
I am currently out of the office and will return on Monday, May 23rd. Please feel free to call the Kemba Helpdesk at 513-763-1822 for assistance.
Kemba Credit Union, Inc.
NOTICE: The information contained in this electronic mail transmission is intended by Kemba Credit Union, Inc. for the use of the named individual or entity to which it is directed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this email is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email, so that the sender's address records can be corrected.
If you enable the "thin" vmdk option and put them on an NFS datastore that supports sparse files, it will only copy non-zero blocks in the vmdk. This may require zero'ing free space in the guest first to be effective.
Another option is to have your nfs export on a fuse mount using some compression filesystem. I don't currently have a recomentdation for this. I've had some good luck with lessfs, but not with nfs exports.