Putting a Running VM Folder in Dropbox, OneDrive, Google Drive, iCloud or pCloud Is Not the Same as Backing Up the VM

Short answer: a cloud sync client can copy virtual-machine files, but that does not make it a VM-aware backup system. A running virtual machine is not one static document. The hypervisor may be updating a virtual disk, differencing disk, configuration file, saved-memory state and snapshot metadata as a coordinated set.

If ordinary cloud sync captures those files at different moments, you can end up with a folder that looks complete but does not represent one recoverable machine state.

The safest model is:

create a consistent VM state first → then copy or upload that stable state to cloud storage

Depending on the hypervisor, that can mean:

• power the VM off and copy/export it;
• use the hypervisor's supported snapshot/checkpoint/backup interface;
• use VSS or a VM-aware backup tool for a running guest;
• create a verified export/clone and then send that artifact to cloud storage.

What you should not assume is:

“The .vmdk, .vhdx or .vdi is inside my sync folder, so every green check is a recoverable VM backup.”

A VM is a coordinated state machine, not just one large disk file

The virtual disk is usually the largest file, so it attracts all the attention.

But recoverability can depend on more than that disk.

A VM may have:

• base virtual disks;
• differencing / delta disks;
• snapshot metadata;
• VM configuration;
• firmware/NVRAM state;
• saved-memory state;
• guest application data that still has unwritten buffers;
• hypervisor-managed locks;
• log/state files that identify the current disk chain.

A cloud client sees host filesystem changes.

It usually does not coordinate with the hypervisor to ask:

“Are the guest filesystem, database buffers, base disk, delta disk and VM configuration all consistent at this exact recovery point?”

That is the missing layer.

VMware Workstation is explicit: power the VM off before making a folder-copy backup

Broadcom's current VMware Workstation backup guidance is unusually direct.

To back up a Workstation virtual machine by copying its VM folder, VMware says to ensure the virtual machine is not running or suspended and to place it in a powered-off state before copying the folder.

That single requirement tells you why ordinary continuous cloud sync is not equivalent to VMware's documented folder-copy backup procedure.

A running Workstation VM can have:

• open VMDK files;
• lock files;
• changing VM state;
• snapshot/delta relationships;
• memory state if suspended or snapshotted.

Cloud sync may be able to upload some of those files while the machine is active. That is different from VMware promising the resulting remote folder is a valid backup.

Why “suspended” is not the same as “powered off” for this copy method

A suspended VM has machine state that must remain coordinated with its disk state. VMware's backup guidance specifically excludes both running and suspended state from the simple copy-the-folder method.

That means the user should not improvise:

1. suspend VM;
2. let Dropbox/OneDrive/pCloud copy whatever is there;
3. call it a backup.

For a simple file-copy backup, follow the hypervisor's documented state requirement.

For live protection, use a VM-aware snapshot/backup mechanism instead.

Hyper-V shows why a real running-VM backup needs coordination

Microsoft documents Hyper-V backup as a hypervisor-aware process.

Current Hyper-V guidance distinguishes complete VM backup from data-only backup and explains that a full VM backup includes associated configuration and state, not merely the VHDX bytes.

Microsoft's documentation lists VM state/configuration files such as:

• .VMCX configuration;
• .VMGS guest state;
• .VMRS runtime state;
• the virtual hard disks and related state.

Hyper-V also has a VSS writer and WMI-based backup mechanisms specifically designed to create consistent backups while the VM is running.

That architecture exists for a reason.

If simply copying a changing VHDX with an ordinary desktop sync client were equivalent, there would be no need for VSS integration, recovery checkpoints, saved-state coordination or VM-aware APIs.

A Hyper-V checkpoint creates a disk chain — do not copy random pieces of it

Hyper-V checkpoints are represented by differencing disks such as .avhdx files associated with the base .vhdx.

Microsoft explicitly warns users not to delete AVHDX files directly. When a checkpoint is removed through Hyper-V, the platform merges the differencing data back correctly.

This is important for cloud sync because a live VM folder can contain a changing chain:

``text Base.vhdx Base-Checkpoint-1.avhdx Base-Checkpoint-2.avhdx VM configuration/state ``

A remote folder that receives those files at different points in a merge or checkpoint operation can look superficially complete while representing the wrong chain state.

The risk is not simply “one file was still uploading.”

The deeper risk is:

the set of files is not one transactionally valid VM state.

VirtualBox snapshots prove the same architectural point

Oracle VirtualBox documents snapshots using differencing images.

When a snapshot is created for a normal virtual disk, VirtualBox freezes the parent image and directs future writes into a new differencing image. The child image only makes sense in relation to its parent.

VirtualBox also documents that a running snapshot can include memory state, which can be as large as the VM's configured RAM.

That means a VirtualBox machine with snapshots is also a multi-file state graph, not just machine.vdi.

Oracle's full-clone process understands that graph: a full clone copies the dependent disk images needed for an independent VM.

A generic cloud client scanning the directory does not automatically have that semantic understanding.

Snapshot is not the same as backup — but it can create a consistent source for one

This distinction matters.

A hypervisor snapshot/checkpoint usually remains tied to the same storage system and may depend on parent disks. It can also grow, fail to merge or create long chains if retained badly.

So the workflow should not be:

“Take snapshot and therefore I have off-site backup.”

A stronger workflow is:

1. create a supported consistent checkpoint/snapshot or shut the VM down;
2. export/clone/copy using the hypervisor's supported method;
3. obtain a self-contained stable artifact or known-valid set;
4. upload that artifact to cloud storage;
5. verify the remote copy;
6. perform a restore/import test.

The cloud is the storage destination. The hypervisor-aware tool creates the consistent recovery point.

OneDrive: “file is being used” is already enough reason not to use live VM files as the backup contract

Microsoft's OneDrive troubleshooting guidance documents a general class of issue where a file being used by another application may not sync until that application releases it.

VM disk/state files are exactly the kind of workload where the hypervisor can keep files open or continually change them.

Even when OneDrive eventually uploads the file, that still does not provide application-consistency for the whole VM.

So the safe conclusion is not:

“OneDrive can't store VHDX.”

It is:

Ordinary OneDrive file synchronization is not the same thing as Hyper-V's VSS/checkpoint-aware backup path.

If the VM is important, create a valid backup/export first.

Dropbox: mature file sync does not mean VM-chain awareness

Dropbox can synchronize large ordinary files and it has mature conflict/version behavior.

But the public consumer sync model does not promise to coordinate VMware/VirtualBox/Hyper-V disk chains as one atomic VM recovery point.

A particularly dangerous architecture is:

1. run a VM from a folder watched by Dropbox;
2. let VM disk and snapshot files change continuously;
3. also open/run the same restored VM on a second computer before the first writer is fully quiescent;
4. allow Dropbox to reconcile competing versions of opaque virtual disks.

A file-sync conflict resolver cannot merge two diverged guest filesystems inside two VMDK images.

The same single-writer principle used for encrypted containers applies here even more strongly.

Google Drive: syncing the bytes does not create a guest-consistent point

Google Drive for desktop can store and synchronize ordinary binary files, but Google does not publish a consumer contract turning Drive for desktop into a VMware, Hyper-V or VirtualBox backup coordinator.

The Drive object layer does not know whether:

• Windows inside the VM still has dirty filesystem buffers;
• a database inside the guest has flushed its transaction log;
• a VDI differencing image and its parent were captured in matching generations;
• a VMware snapshot operation is mid-transition.

Therefore a successful upload should be interpreted as:

“these host files reached Drive”

not automatically:

“the guest can be restored consistently.”

iCloud Drive: Finder synchronization is not virtual-machine backup orchestration

The same boundary applies to iCloud Drive.

Finder/File Provider can represent file transfer status and cloud/local availability, but Apple does not document ordinary iCloud Drive as a VM-consistency engine for VMware Fusion, VirtualBox or arbitrary virtual-disk chains.

A .vmwarevm bundle can look like one item in Finder while internally containing multiple VM files. A package-like presentation does not make the contents an atomic cloud backup transaction.

If you use a Mac hypervisor, create a stable powered-off copy or supported export/snapshot artifact first, then let iCloud or another storage service carry that artifact if appropriate.

pCloud: differential upload is useful, but it does not solve application consistency

pCloud's current file-transfer documentation says that when an already-synced file is updated, only the changed content is uploaded, reducing transfer time and bandwidth.

That is useful for large changing files.

But pCloud also explicitly advises avoiding files that are:

• actively used;
• frequently updated;
• locked by another application;
• database-like state that changes continuously.

The reason given is the risk of conflicts during transfer.

A live VMDK, VHDX or VDI fits the operational shape of a large actively modified application file even if pCloud does not name every VM extension individually.

So do not turn pCloud's differential upload into the false claim:

“pCloud can safely back up a running VM because only changed blocks upload.”

Transfer optimization and application consistency are different layers.

pCloud can be useful after you produce a stable export, clone or powered-off VM archive.

Two safe patterns

Pattern A — powered-off cold copy

This is the simplest model for a personal/dev VM that can tolerate downtime.

1. Shut down the guest cleanly.
2. Confirm the hypervisor shows the VM powered off, not merely paused/suspended where the vendor says that is insufficient for folder-copy backup.
3. Let snapshot merges or pending disk operations complete.
4. Copy or export the entire required VM set to a separate staging directory.
5. Hash the stable files or create a manifest.
6. Upload the staging copy to cloud storage.
7. Verify a fresh download.
8. Import/open the restored copy in an isolated test location.

The staging directory is important because it separates the stable backup artifact from the working VM folder that will start changing again.

Pattern B — running VM with hypervisor-aware backup

For a VM that must remain online:

1. use the hypervisor's supported online backup/checkpoint/VSS interface or a VM-aware backup product;
2. let the mechanism coordinate guest/host state;
3. produce the supported backup/export artifact;
4. send the resulting stable artifact to cloud storage;
5. validate restore/import.

For Hyper-V, this is the category of problem VSS and WMI backup APIs are designed to solve.

For VMware/vSphere environments, VM-aware backup software generally uses snapshot APIs rather than blindly copying a live VMDK.

Why copying only the largest disk can fail

Users often find the biggest file and assume it is the VM:

``text vm.vmdk ``

or:

``text vm.vhdx ``

or:

``text vm.vdi ``

But the current state may depend on:

• child/differencing disks;
• snapshot descriptors;
• configuration;
• saved-memory state;
• VM generation IDs / metadata;
• external disks not stored in the same folder.

Microsoft's Hyper-V backup documentation explicitly distinguishes full VM backup from data-only backup for exactly this reason.

If you only preserve the virtual disk, you may still be able to create a new VM and attach/restore the data. But that is not the same recovery objective as restoring the original machine state.

Define which one you need before the backup.

The VM backup contract

A good VM backup manifest answers these questions:

Identity

• Which VM is this?
• Hypervisor/version?
• Guest OS?

Disk chain

• Which base disks?
• Which differencing disks?
• Which external disks?
• Are snapshots intentionally included?

Machine state

• Powered off?
• Crash-consistent snapshot?
• Application-consistent snapshot?
• Saved memory included?

Configuration

• CPU/RAM settings?
• Firmware/UEFI?
• virtual network configuration?
• TPM/secure-boot dependencies where relevant?

Verification

• file hashes?
• import succeeds?
• VM boots in isolated environment?
• guest filesystem check passes?
• critical service starts?

A folder count alone answers almost none of those questions.

Do not run the same cloud-synced VM from two computers

This is one of the highest-risk shortcuts.

Suppose Laptop A and Desktop B both synchronize MyVM/.

A dangerous sequence is:

1. A runs the VM and changes the virtual disk.
2. A has not finished synchronizing.
3. B still has an older disk generation.
4. B starts its local copy and also writes to it.
5. Both machines now have different valid guest filesystem histories.
6. The cloud client must resolve two opaque binary disk states.

There is no meaningful file-level merge for that situation.

At best, the provider preserves conflicted versions. At worst, the state you expect is not the state that wins.

The safe rule is:

one authoritative VM writer; other machines only consume a verified, completed backup/export generation.

Why VM snapshots can also become dangerous if kept forever

Snapshots are coordination tools, not free archival storage.

Hyper-V and VirtualBox both use differencing-disk chains. VMware uses snapshot delta disks as well.

Long chains can:

• grow large;
• consume unexpected storage;
• complicate merges;
• increase the number of dependent files needed for recovery;
• make a partial cloud copy more dangerous.

Microsoft explicitly warns against manually deleting AVHDX files and documents checkpoint-chain corruption as a backup/storage failure class.

Therefore:

• create snapshots/checkpoints through the hypervisor;
• let the hypervisor merge/delete them;
• do not “clean up” delta files manually because cloud storage shows several similarly named disks.

The verification step most people skip: actually boot the restored VM

A checksum is important, but it only proves the restored files match the artifact you uploaded.

For a VM backup, the real end-to-end test is stronger:

1. download/export the recovery set to a new location;
2. keep the original production VM offline from this test;
3. import/register the restored VM as a separate test machine;
4. isolate networking if duplicate identity/IP/domain membership could cause problems;
5. boot it;
6. verify guest filesystem and key applications;
7. record whether the backup is crash-consistent or application-consistent.

That test catches problems no cloud progress bar can detect.

Provider comparison: what ordinary sync does and does not prove

The important comparison is not which logo sits next to the VMDK.

It is whether some component upstream of cloud storage created a valid recovery point.

Final answer

If the VM is powered off and the hypervisor documents folder-copy backup, a verified cold copy can be an excellent cloud archive source.

If the VM must stay running, use a hypervisor-aware snapshot/backup mechanism first.

Then put the resulting stable artifact in cloud storage.

Do not ask ordinary Dropbox, Google Drive, OneDrive, iCloud or pCloud sync to infer guest filesystem consistency, snapshot-chain dependencies and VM configuration from changing host files.

The clean architecture is:

hypervisor consistency layer → stable backup/export artifact → cloud storage → restore test

That is a backup chain you can actually reason about.

Sources used for this article

• Broadcom / VMware — Best practices when backing up a VMware Workstation virtual machine: https://knowledge.broadcom.com/external/article/304707/best-practices-when-backing-up-a-vmware.html
• Microsoft Learn — Hyper-V Backup Approaches: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/backup-approaches
• Microsoft Learn — Backing up and restoring virtual machines: https://learn.microsoft.com/en-us/windows/win32/hyperv_v2/backing-up-and-restoring-virtual-machines
• Microsoft Learn — Hyper-V checkpoints: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/checkpoints
• Microsoft Learn — Hyper-V backup/checkpoint/storage troubleshooting: https://learn.microsoft.com/en-us/troubleshoot/windows-server/virtualization/hyper-v-virtual-machine-backup-checkpoint-storage
• Oracle VirtualBox 7.2 — Working with Virtual Machines / snapshots and clones: https://docs.oracle.com/en/virtualization/virtualbox/7.2/user/working-with-vms.html
• Oracle VirtualBox — Virtual Storage / differencing images: https://docs.oracle.com/en/virtualization/virtualbox/7.1/user/storage.html
• pCloud Help — Uploading, Downloading and Organizing Files: https://help.pcloud.com/article/uploading-downloading-organizing
• pCloud Help — Files Not Recommended for Sync, Backup, or Uploads: https://help.pcloud.com/article/files-not-recommended-for-sync-backup-or-uploads