{"id":21498,"date":"2026-09-27T22:09:37","date_gmt":"2026-09-27T14:09:37","guid":{"rendered":"https:\/\/synopower.club\/?post_type=docs&p=21498"},"modified":"2026-09-27T22:09:43","modified_gmt":"2026-09-27T14:09:43","password":"","slug":"vmm-backup-google-drive-cloud-sync","status":"publish","type":"docs","link":"https:\/\/synopower.club\/ko\/docs\/vmm-backup-google-drive-cloud-sync\/","title":{"rendered":"VMM \ubc31\uc5c5\uc744 Google Drive\ub85c: \uc608\uc57d \ub0b4\ubcf4\ub0b4\uae30, \ud074\ub77c\uc6b0\ub4dc \ub3d9\uae30\ud654 \ubc0f \ub2e8\uc77c \ud30c\uc77c \uc774\ub984 \ubcc0\uacbd \uc2a4\ud06c\ub9bd\ud2b8"},"content":{"rendered":"

A VMM backup that only lives on the same NAS as the virtual machine is not really a backup. If that box fails, both copies go with it. This store runs as a Virtual DSM guest in Synology Virtual Machine Manager, and our off-site VMM backup is built from two free tools that ship with DSM: scheduled export in Virtual Machine Manager, and Cloud Sync to Google Drive. Setting it up took an afternoon. Finding out why it had quietly stopped working took longer, and that part is the reason this NAS Hosting 101 article exists. Below is the setup that works, the one filename quirk that breaks it, the small script that fixes it, and what an audit of our own exports turned up.<\/p>\n\n\n\n

\n

SynoPower Club \ud3ec\uc778\ud2b8:<\/strong> Every support engineer has a story about the customer whose backups ran green for a year and restored nothing. I did not expect to write one about our own shop. Our VMM backup job looked perfectly healthy in the interface, yet one host had piled up a terabyte of exports it could never clean, and the other had not produced a single file in thirteen days. Nothing was hidden. It was all in a log nobody reads. The fix took an hour; the lesson is to check that the files actually exist where you think they are, on a schedule, like any other job.<\/p>\n<\/blockquote>\n\n\n\n

What a Complete VMM Backup Needs<\/h2>\n\n\n\n

Virtual Machine Manager gives you three layers of protection, and each one covers a different failure. A sound VMM backup plan uses more than one.<\/p>\n\n\n\n

Layer<\/th>Where the copy lives<\/th>What it protects against<\/th><\/tr><\/thead>
\uc2a4\ub0c5\uc0f7<\/td>Same volume as the guest<\/td>A bad update or a mistake inside the guest<\/td><\/tr>
Replication (VMM Pro)<\/td>Another NAS in the cluster<\/td>A NAS failing, with quick recovery on the other host<\/td><\/tr>
Scheduled export + Cloud Sync<\/td>A cloud account off site<\/td>Losing the whole site: fire, theft, ransomware on the LAN<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

We already replicate six guests to a standby host, as described in our write-up of the three-node Synology virtual machine cluster<\/a>. Replication keeps a copy in the building. The export layer is what keeps a copy outside it.<\/p>\n\n\n\n

How VMM Scheduled Export Works<\/h2>\n\n\n\n

For a VMM backup, scheduled export writes a complete copy of a guest, disks and configuration, as a single OVA file on a shared folder. You choose the destination folder, the export mode, daily, weekly or monthly timing, and how many of the latest files to keep. Exports run while the guest is running.<\/p>\n\n\n\n

Two rules are easy to miss. First, the export is configured and written on the host where the guest’s storage<\/strong> lives, not where it is running. In a cluster, a guest can run on one NAS while its disks sit on another, and Virtual Machine Manager greys out the scheduled export option on the wrong host. Second, the schedule uses that storage host’s clock.<\/p>\n\n\n\n

\"VMM
Our scheduled export settings: a shared folder as the destination, daily at 08:00, keeping the newest three files.<\/figcaption><\/figure>\n\n\n\n

The dialog also shows the consistent state. Without the Synology Guest Tool installed in the guest, exports are crash consistent, the same state as pulling the power cord. That is fine for most workloads, and installing the Guest Tool upgrades it to file system consistent.<\/p>\n\n\n\n

Why Cloud Sync Skips VMM Backup Files<\/h2>\n\n\n\n

The obvious next step is to point Cloud Sync at the export folder and let it upload everything to Google Drive. We did exactly that, and the VMM backup files never arrived.<\/p>\n\n\n\n

The reason is the filename. Virtual Machine Manager names each export with a timestamp that contains colons:<\/p>\n\n\n\n

exp_web-2026-09-25 10:29:51-6f713905-cee2-4647-94d5-a5ce6fbdc585.ova<\/code><\/pre>\n\n\n\n
Cloud Sync would not upload those names to our Google Drive, so every export stayed local. The file is valid; the character is the problem. Since the export timestamp format cannot be changed in Virtual Machine Manager, the fix has to happen between the export and the upload.<\/p>\n\n\n\n
Interestingly, only scheduled exports carry the timestamp. A manual export from the same menu is saved simply as the guest name, such as spc_4C8G.ova<\/code>, and Cloud Sync uploads it without complaint. That is why a quick manual test can make the whole chain look fine while the nightly schedule never reaches the cloud.<\/p>\n\n\n\n
Setting Up a VMM Backup to Google Drive in 4 Steps<\/h2>\n\n\n\n
This is the working VMM backup setup on each host that stores guests. It needs Virtual Machine Manager, Cloud Sync and a Google account; none of it needs VMM Pro.<\/p>\n\n\n
\n
\n\n<\/div>\n\n
\n
\n
Schedule the export<\/h3>\n
On the host that stores the guest, open Virtual Machine Manager, select the guest, choose Action, Export, Scheduled, pick a shared folder as the destination and set the time. Leave the retention setting at the number of copies you want to keep locally.<\/p>\n<\/div>\n<\/div>\n
\n
Create the Cloud Sync task<\/h3>\n
In Cloud Sync, connect Google Drive and sync the export shared folder to a Drive folder. Set the direction to upload local changes, and tick the option not to remove files in the destination when they are removed in the source if you want the cloud to keep older copies.<\/p>\n<\/div>\n<\/div>\n
\n
Add the rename script<\/h3>\n
Save the script from this article on the NAS and create a Task Scheduler job that runs it as root every hour. It renames finished exports without colons and keeps the newest copies per guest.<\/p>\n<\/div>\n<\/div>\n
\n
Verify the first upload<\/h3>\n
After the next export, confirm the renamed file appears in the export folder, that Cloud Sync reports it as uploaded, and that the file size in Google Drive matches the original.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
\"Cloud
Our Cloud Sync task: upload local changes only, with the option ticked so Google Drive keeps exports after the NAS prunes them.<\/figcaption><\/figure>\n\n\n\n
The Rename Script Behind Our VMM Backup<\/h2>\n\n\n\n
The script is the only custom piece of the VMM backup chain, and it does two things. It renames each finished export, replacing colons with dashes, and it keeps only the newest copies of each guest in the export folder. It only touches files that have not changed for fifteen minutes, so it never renames an export that is still being written.<\/p>\n\n\n\n
#!\/bin\/bash\n# vm-export-cloud.sh - make VMM exports uploadable by Cloud Sync.\n#\n# VMM names exports \"<guest>-YYYY-MM-DD HH:MM:SS-<uuid>.ova\". Cloud Sync will\n# not upload names containing \":\", which also means it never touches an export\n# that is still being written. Once an export is finished, this renames it in\n# place with \":\" replaced by \"-\" so Cloud Sync picks it up, then keeps only the\n# newest KEEP renamed exports per guest. (VMM's own retention can no longer see\n# renamed files, so retention is done here.)\n#\n# Usage: vm-export-cloud.sh EXPORT_DIR KEEP [--apply]\n# Without --apply it only prints what it would do.\n\nset -u\nDIR=${1:?EXPORT_DIR}; KEEP=${2:?KEEP}; APPLY=${3:-}\nMIN_AGE_MIN=15                      # a finished export is untouched this long\nLOG=\"$(dirname \"$(readlink -f \"$0\")\")\/vm-export-cloud.log\"\n\nsay() { echo \"$(date '+%F %T') $*\"; [ \"$APPLY\" = \"--apply\" ] && echo \"$(date '+%F %T') $*\" >> \"$LOG\"; }\nrun() { if [ \"$APPLY\" = \"--apply\" ]; then \"$@\"; else echo \"   (dry-run) $*\"; fi; }\n\n[ -d \"$DIR\" ] || { say \"ERROR export folder missing: $DIR\"; exit 1; }\n\n# 1. rename finished exports\nfind \"$DIR\" -maxdepth 1 -type f -name '*:*.ova' -mmin +$MIN_AGE_MIN -print0 |\nwhile IFS= read -r -d '' f; do\n    if command -v fuser >\/dev\/null 2>&1 && fuser -s \"$f\" 2>\/dev\/null; then\n        say \"skip (in use): $(basename \"$f\")\"; continue\n    fi\n    new=\"$DIR\/$(basename \"$f\" | tr ':' '-')\"\n    say \"rename: $(basename \"$f\") -> $(basename \"$new\")\"\n    run mv -n \"$f\" \"$new\"\ndone\n\n# 2. keep the newest KEEP renamed exports per guest (timestamp is in the name)\n{ find \"$DIR\" -maxdepth 1 -type f -name '*.ova' ! -name '*:*' -printf '%f\\n'\n  [ \"$APPLY\" = \"--apply\" ] || find \"$DIR\" -maxdepth 1 -type f -name '*:*.ova' -mmin +$MIN_AGE_MIN -printf '%f\\n' | tr ':' '-'\n} | sort -u |\nsed -E 's\/^(.*)-([0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}-[0-9]{2}-[0-9]{2})-.*\\.ova$\/\\1\\t\\2\\t&\/' |\nawk -F'\\t' 'NF==3' | sort -t$'\\t' -k1,1 -k2,2r |\nawk -F'\\t' -v keep=\"$KEEP\" '{ n[$1]++; if (n[$1] > keep) print $3 }' |\nwhile IFS= read -r old; do\n    say \"delete (beyond newest $KEEP): $old\"\n    run rm -f -- \"$DIR\/$old\"\ndone\n\nsay \"done: $(find \"$DIR\" -maxdepth 1 -name '*.ova' | wc -l) exports in $DIR, $(df -h \"$DIR\" | awk 'NR==2{print $4\" free\"}')\"<\/code><\/pre>\n\n\n\n
Run it without the last argument first. In that mode it only prints what it would rename and delete. Once the output looks right, schedule it with the extra argument that makes it act. Our Task Scheduler job runs every hour as root with a command like this, one job per export folder:<\/p>\n\n\n\n
bash \/volume1\/@vm-export-cloud\/vm-export-cloud.sh \"\/volume3\/VM_BK_Export\" 3 --apply<\/code><\/pre>\n\n\n\n
A useful side effect of the colon rule: Cloud Sync cannot upload an export until the script has renamed it, and the script only renames finished files. Half-written exports never reach the cloud.<\/p>\n\n\n\n
Why the Script Handles VMM Backup Retention<\/h2>\n\n\n\n
Virtual Machine Manager has its own retention setting, and it works by recording each export it creates. Once the script renames a file, Virtual Machine Manager no longer recognises it and will never delete it. So retention moves into the script, which counts copies per guest from the timestamp in the name.<\/p>\n\n\n\n
On the Cloud Sync side, one checkbox decides what happens in Google Drive. Its wording is easy to misread: Do not remove files in the destination folder when they are removed in the source folder<\/strong>. Leave it unticked and Google Drive mirrors the NAS, keeping the same three copies. Tick it and the cloud keeps every export ever uploaded, which is the safer choice against ransomware but grows until you prune it by hand.<\/p>\n\n\n\n
What an Audit of Our Own Exports Found<\/h2>\n\n\n\n
Before this setup, our VMM backup had been running on both production hosts for about a month. Checking the files instead of the dashboard turned up three separate failures.<\/p>\n\n\n\n