ghettoVCB Rotation, Compression, and Disk Formats

Every ghettoVCB backup is a full copy of a virtual machine’s disks. That fact shapes everything about storage planning. There is no incremental mode quietly saving you space, and no changed-block tracking that copies only what changed. Each run copies the whole VMDK set again, and the only things standing between you and a full datastore are the rotation count, the disk format, and compression. This guide explains all three, how they interact, and how to choose settings that keep enough history without filling the destination.

Start with the arithmetic, because it is unforgiving and it is also simple. Multiply the size of one full backup set by the number of rotations you keep, and compare the result with the free space on the backup destination. If the numbers do not fit, no setting will save you, and you need a bigger destination, fewer rotations, or fewer VMs in the backup set. Do that calculation per VM, because a 20 GB test VM and a 2 TB file server live in different worlds. A rotation policy that is generous for one is impossible for the other.

Rotation: How Many Backups to Keep

VM_BACKUP_ROTATION_COUNT sets how many backups of each VM the script keeps. When a new backup finishes, the oldest backup beyond that count is deleted. A count of 3 keeps three dated folders per VM. A count of 7 keeps a week of daily backups. The right count depends on how far back you need to reach and how much space you have, and those two needs pull in opposite directions. More history is safer against slow discoveries, such as corruption found a week after it happened. More history also costs more space, linearly, because each rotation is a full copy.

Think about what failures you are actually protecting against. An accidental deletion is usually noticed the same day, so a few rotations cover it. Corruption or a bad update might be noticed days later, so a longer rotation helps. A ransomware event or a datastore failure is covered by the first good backup on separate storage, whatever the rotation count. Match the count to the discovery time of the problems you fear, then check the space arithmetic. If the arithmetic fails, shorten the rotation or thin the backup set before you shorten anything else, because a rotation count that fills the datastore will break every VM’s backup at once.

Disk Formats: Thin, Thick, and Sparse

DISK_BACKUP_FORMAT decides the format of the backed-up VMDK files, and the format decides how much space each backup really uses. The choices are thin, zeroedthick, eagerzeroedthick, 2gbsparse, and sesparse. A thin backup uses only the space the data actually occupies inside the disk, so a 100 GB disk holding 30 GB of data backs up as roughly 30 GB. A thick backup reserves the full provisioned space, so the same disk backs up as 100 GB. Eagerzeroedthick goes further and zeroes the space up front. The sparse formats split the disk into 2 GB pieces, which suits filesystems and copy methods that prefer smaller files.

Thin is the usual choice for space efficiency on VMFS destinations, and it is the choice most small setups should start with. But thin is not free. A thin backup of a disk that has grown and shrunk over time can still be larger than you expect, because deleted data inside the guest does not always return its blocks. Test with your real VMs and measure the actual backup sizes, rather than trusting the provisioned sizes in the client. The measured sizes are the numbers your rotation arithmetic must use.

The NFS Format Restriction

One restriction overrides every other format discussion. On non-VMFS volumes, such as NFS, only 2gbsparse and thick formats can be used. A thin format against an NFS destination will not behave as you expect, and the problem may only surface when you try to restore. This matters because NFS is a common ghettoVCB destination, especially for backups to a NAS. If your destination is NFS, choose 2gbsparse or a thick format, test a backup and a restore with that format, and write the choice down in your run notes. Changing formats between runs leaves you with a mixed backup set that is harder to restore, so settle the format before the first scheduled run and keep it stable.

The sesparse format deserves a mention as the newer space-efficient sparse option in the list. It belongs in the same conversation as thin for space efficiency, but the same rule applies as everywhere else in this guide: test it with your storage and your restore procedure before you depend on it. A format is only as good as the restore you have proven from it, and an untested format is a guess, whatever the documentation promises.

Compression: What It Saves and What It Costs

ENABLE_COMPRESSION compresses backup files to save space. A value of 0 turns compression off. A value of 1 compresses with tar and gzip. A value of 2 compresses only the.vmsn and.vmdk files. Compression is attractive when space is tight, and it is real savings when your VM disks hold compressible data such as text, logs, and uncompressed databases. It is nearly useless when disks hold already-compressed data such as videos, encrypted files, or compressed archives, because there is nothing left to squeeze. Measure the result on your own VMs before you assume a savings ratio.

Compression costs time and CPU on the host, and it changes the restore. A compressed backup must be decompressed before the VM can be registered, which adds a step and a delay to the restore, exactly when you are in a hurry. It also makes spot-checking a backup harder, because you cannot just browse and register the files. For those reasons, many small setups leave compression off and spend the space instead, treating restore speed as more valuable than disk savings. If you do enable compression, test the full restore path, including decompression, before the first scheduled run, and keep the decompression steps written down with the backup notes.

Putting It Together: A Space Plan

Measure one real backup per VM, with the format and compression you plan to use
Multiply the measured size by the rotation count, plus a margin for one extra run
Compare the total with the free space on the backup destination, not the total size of the volume
Keep the disk format stable across runs, and respect the NFS format restriction
Re-measure after any big change, such as a new VM, a disk resize, or a format change
Alert on destination free space, because a full destination fails every backup at once

That plan fits on a small note, and it prevents the most common ghettoVCB storage failure: a rotation policy written for small VMs meeting a large VM for the first time. Space planning is not exciting work, and it is the work that keeps backups running. Review the numbers quarterly, or whenever a VM grows, and adjust the rotation count before the datastore tells you to.

Conclusion

Rotation, disk format, and compression are your three levers for controlling what full-copy backups cost. Rotation sets how much history you keep. Disk format sets how much space each copy uses, with thin leading on VMFS and 2gbsparse or thick required on NFS. Compression trades time and restore complexity for space. Measure real backups, do the arithmetic, keep the settings stable, and test a restore. A backup set that fits its destination and has a proven restore is a backup set you can keep.

ghettoVCB Backup Rotation, Compression, and Disk Formats Explained