{"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\/es\/docs\/vmm-backup-google-drive-cloud-sync\/","title":{"rendered":"Copia de seguridad de VMM a Google Drive: exportaci\u00f3n programada, sincronizaci\u00f3n en la nube y un \u00fanico script para renombrar archivos."},"content":{"rendered":"

Una copia de seguridad de VMM que solo reside en el mismo NAS que la m\u00e1quina virtual no es realmente una copia de seguridad. Si ese servidor falla, ambas copias se pierden con \u00e9l. Este almac\u00e9n se ejecuta como un invitado Virtual DSM en Synology Virtual Machine Manager, y nuestra copia de seguridad de VMM externa se basa en dos herramientas gratuitas incluidas en DSM: exportaci\u00f3n programada en Virtual Machine Manager y sincronizaci\u00f3n en la nube con Google Drive. Configurarlo nos llev\u00f3 una tarde. Descubrir por qu\u00e9 hab\u00eda dejado de funcionar silenciosamente nos llev\u00f3 m\u00e1s tiempo, y esa es la raz\u00f3n de ser de este art\u00edculo de Introducci\u00f3n al alojamiento NAS. A continuaci\u00f3n, se muestra la configuraci\u00f3n que funciona, la peculiaridad del nombre de archivo que la provoca, el peque\u00f1o script que la soluciona y los resultados de una auditor\u00eda de nuestras propias exportaciones.<\/p>\n\n\n\n

\n

Punto SynoPower Club:<\/strong> Cada ingeniero de soporte tiene una an\u00e9cdota sobre un cliente cuyas copias de seguridad funcionaron correctamente durante un a\u00f1o sin restaurar nada. No esperaba tener que escribir una sobre nuestra propia empresa. Nuestra copia de seguridad de VMM parec\u00eda estar en perfecto estado en la interfaz, pero un host hab\u00eda acumulado un terabyte de exportaciones que nunca pudo limpiar, y el otro no hab\u00eda generado ni un solo archivo en trece d\u00edas. No hab\u00eda nada oculto. Todo estaba en un registro que nadie lee. La soluci\u00f3n tard\u00f3 una hora; la lecci\u00f3n es comprobar que los archivos realmente existen donde se supone que est\u00e1n, seg\u00fan un cronograma, como cualquier otra tarea.<\/p>\n<\/blockquote>\n\n\n\n

Lo que necesita una copia de seguridad completa de VMM<\/h2>\n\n\n\n

Virtual Machine Manager ofrece tres capas de protecci\u00f3n, y cada una cubre un tipo de fallo diferente. Un buen plan de copia de seguridad de VMM utiliza m\u00e1s de una.<\/p>\n\n\n\n

Capa<\/th>Donde se encuentra la copia<\/th>De qu\u00e9 protege<\/th><\/tr><\/thead>
Instant\u00e1neas<\/td>Mismo volumen que el invitado<\/td>Una actualizaci\u00f3n defectuosa o un error dentro del invitado<\/td><\/tr>
Replicaci\u00f3n (VMM Pro)<\/td>Otro NAS en el cl\u00faster<\/td>Un NAS falla, con una r\u00e1pida recuperaci\u00f3n en el otro host.<\/td><\/tr>
Exportaci\u00f3n programada + Sincronizaci\u00f3n en la nube<\/td>Una cuenta en la nube fuera del sitio<\/td>P\u00e9rdida total del sitio: incendio, robo, ransomware en la LAN.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Ya replicamos seis invitados a un anfitri\u00f3n de reserva, como se describe en nuestro informe sobre el cl\u00faster de m\u00e1quinas virtuales Synology de tres nodos<\/a>. La replicaci\u00f3n mantiene una copia dentro del edificio. La capa de exportaci\u00f3n es la que mantiene una copia fuera del mismo.<\/p>\n\n\n\n

C\u00f3mo funciona la exportaci\u00f3n programada de VMM<\/h2>\n\n\n\n

Para una copia de seguridad de VMM, la exportaci\u00f3n programada crea una copia completa de la m\u00e1quina virtual, sus discos y su configuraci\u00f3n, como un \u00fanico archivo OVA en una carpeta compartida. Puede elegir la carpeta de destino, el modo de exportaci\u00f3n (diario, semanal o mensual) y la cantidad de archivos m\u00e1s recientes que desea conservar. Las exportaciones se ejecutan mientras la m\u00e1quina virtual est\u00e1 en funcionamiento.<\/p>\n\n\n\n

Hay dos reglas que son f\u00e1ciles de pasar por alto. Primero, la exportaci\u00f3n se configura y se escribe en el host donde se encuentra el invitado. almacenamiento<\/strong> El sistema se centra en el funcionamiento interno, no en el lugar donde se ejecuta. En un cl\u00faster, un sistema invitado puede ejecutarse en un NAS mientras sus discos se encuentran en otro, y Virtual Machine Manager desactiva la opci\u00f3n de exportaci\u00f3n programada en el host incorrecto. En segundo lugar, la programaci\u00f3n utiliza el reloj de ese host de almacenamiento.<\/p>\n\n\n\n

\"Configuraci\u00f3n
Nuestra configuraci\u00f3n de exportaci\u00f3n programada: una carpeta compartida como destino, diariamente a las 08:00, conservando los tres archivos m\u00e1s recientes.<\/figcaption><\/figure>\n\n\n\n

El cuadro de di\u00e1logo tambi\u00e9n muestra el estado consistente. Sin la herramienta Synology Guest Tool instalada en la m\u00e1quina virtual, las exportaciones presentan una consistencia de fallo, el mismo estado que al desconectar el cable de alimentaci\u00f3n. Esto es aceptable para la mayor\u00eda de las cargas de trabajo, y la instalaci\u00f3n de Guest Tool lo actualiza a una consistencia de sistema de archivos.<\/p>\n\n\n\n

\u00bfPor qu\u00e9 Cloud Sync omite los archivos de copia de seguridad de VMM?<\/h2>\n\n\n\n

El siguiente paso l\u00f3gico es configurar Cloud Sync para que apunte a la carpeta de exportaci\u00f3n y suba todo a Google Drive. Hicimos exactamente eso, y los archivos de copia de seguridad de VMM nunca llegaron.<\/p>\n\n\n\n

La raz\u00f3n es el nombre del archivo. Virtual Machine Manager nombra cada exportaci\u00f3n con una marca de tiempo que contiene dos puntos:<\/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 no sub\u00eda esos nombres a nuestro Google Drive, por lo que todas las exportaciones se guardaban localmente. El archivo es v\u00e1lido; el problema reside en el car\u00e1cter. Dado que el formato de la marca de tiempo de exportaci\u00f3n no se puede modificar en Virtual Machine Manager, la correcci\u00f3n debe realizarse entre la exportaci\u00f3n y la subida.<\/p>\n\n\n\n
Curiosamente, solo las exportaciones programadas llevan la marca de tiempo. Una exportaci\u00f3n manual desde el mismo men\u00fa se guarda simplemente como el nombre del invitado, como por ejemplo: spc_4C8G.ova<\/code>, y Cloud Sync lo sube sin problemas. Por eso, una prueba manual r\u00e1pida puede hacer que todo parezca correcto, aunque la programaci\u00f3n nocturna nunca llegue a la nube.<\/p>\n\n\n\n
Configurar una copia de seguridad de VMM en Google Drive en 4 pasos<\/h2>\n\n\n\n
Esta es la configuraci\u00f3n de copia de seguridad de VMM que funciona en cada host que almacena m\u00e1quinas virtuales. Requiere Virtual Machine Manager, Cloud Sync y una cuenta de Google; no necesita VMM Pro.<\/p>\n\n\n
\n
\n\n<\/div>\n\n
\n
\n
Programar la exportaci\u00f3n<\/h3>\n
En el servidor que almacena la m\u00e1quina virtual, abra Virtual Machine Manager, seleccione la m\u00e1quina virtual, elija Acci\u00f3n, Exportar, Programado, seleccione una carpeta compartida como destino y configure la hora. Deje la configuraci\u00f3n de retenci\u00f3n con el n\u00famero de copias que desea conservar localmente.<\/p>\n<\/div>\n<\/div>\n
\n
Crear la tarea de sincronizaci\u00f3n en la nube<\/h3>\n
En Cloud Sync, conecta Google Drive y sincroniza la carpeta compartida de exportaci\u00f3n con una carpeta de Drive. Configura la direcci\u00f3n para cargar los cambios locales y marca la opci\u00f3n para que no se eliminen los archivos en el destino cuando se eliminen en el origen, si quieres que la nube conserve copias antiguas.<\/p>\n<\/div>\n<\/div>\n
\n
Agregue el script de cambio de nombre<\/h3>\n
Guarda el script de este art\u00edculo en el NAS y crea una tarea programada que lo ejecute como root cada hora. Renombra las exportaciones finalizadas sin dos puntos y conserva las copias m\u00e1s recientes para cada m\u00e1quina virtual.<\/p>\n<\/div>\n<\/div>\n
\n
Verificar la primera carga<\/h3>\n
Tras la siguiente exportaci\u00f3n, confirme que el archivo renombrado aparece en la carpeta de exportaci\u00f3n, que Cloud Sync lo reporta como subido y que el tama\u00f1o del archivo en Google Drive coincide con el original.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
\"Configuraci\u00f3n
Nuestra tarea de sincronizaci\u00f3n en la nube: cargar solo los cambios locales, con la opci\u00f3n marcada para que Google Drive conserve las exportaciones despu\u00e9s de que el NAS las elimine.<\/figcaption><\/figure>\n\n\n\n
El script de cambio de nombre detr\u00e1s de nuestra copia de seguridad de VMM<\/h2>\n\n\n\n
El script es el \u00fanico componente personalizado de la cadena de copias de seguridad de VMM y realiza dos funciones: renombra cada exportaci\u00f3n finalizada, reemplazando los dos puntos por guiones, y conserva \u00fanicamente las copias m\u00e1s recientes de cada m\u00e1quina virtual en la carpeta de exportaci\u00f3n. Solo modifica los archivos que no han sufrido cambios en los \u00faltimos quince minutos, por lo que nunca renombra una exportaci\u00f3n que a\u00fan se est\u00e9 escribiendo.<\/p>\n\n\n\n
#!\/bin\/bash # vm-export-cloud.sh - permite que las exportaciones de VMM se puedan cargar mediante Cloud Sync. # # Exportaciones de nombres de VMM " -AAAA-MM-DD HH:MM:SS- .ova". Cloud Sync no cargar\u00e1 nombres que contengan ":", lo que tambi\u00e9n significa que nunca toca una exportaci\u00f3n que a\u00fan se est\u00e9 escribiendo. Una vez que una exportaci\u00f3n termina, la renombra en su lugar con ":" reemplazado por "-" para que Cloud Sync la detecte y luego conserve solo las exportaciones renombradas m\u00e1s recientes por invitado. (La retenci\u00f3n propia de VMM ya no puede ver los archivos renombrados, por lo que la retenci\u00f3n se realiza aqu\u00ed). Uso: vm-export-cloud.sh EXPORT_DIR KEEP [--apply] Sin --apply solo imprime lo que har\u00eda. set -u DIR=${1:?EXPORT_DIR}; KEEP=${2:?KEEP}; APPLY=${3:-} MIN_AGE_MIN=15 # una exportaci\u00f3n terminada no se ha tocado durante este largo LOG="$(dirname "$(readlink -f "$0")")\/vm-export-cloud.log" say() { echo "$(date '+%F %T') $*"; [ "$APPLY" = "--apply" ] && echo "$(date '+%F %T') $*" >> "$LOG"; } run() { if [ "$APPLY" = "--apply" ]; then "$@"; else echo " (dry-run) $*"; fi; } [ -d "$DIR" ] || { say "ERROR carpeta de exportaci\u00f3n faltante: $DIR"; salir 1; } # 1. renombrar exportaciones terminadas encontrar "$DIR" -maxdepth 1 -type f -name '*:*.ova' -mmin +$MIN_AGE_MIN -print0 | mientras IFS= leer -r -d '' f; hacer si comando -v fuser >\/dev\/null 2>&1 && fuser -s "$f" 2>\/dev\/null; entonces decir "omitir (en uso): $(nombre base "$f")"; continuar fi nuevo="$DIR\/$(nombre base "$f" | tr ':' '-')" decir "renombrar: $(nombre base "$f") -> $(nombre base "$new")" ejecutar mv -n "$f" "$new" hecho # 2. mantener las exportaciones renombradas m\u00e1s recientes por invitado (la marca de tiempo est\u00e1 en el nombre) { buscar "$DIR" -maxdepth 1 -type f -name '*.ova' ! -name '*:*' -printf '%f\\n' [ "$APPLY" = "--apply" ] || buscar "$DIR" -maxdepth 1 -type f -name '*:*.ova' -mmin +$MIN_AGE_MIN -printf '%f\\n' | tr ':' '-' } | sort -u | sed -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&\/' | awk -F'\\t' 'NF==3' | sort -t$'\\t' -k1,1 -k2,2r | awk -F'\\t' -v keep="$KEEP" '{ n[$1]++; if (n[$1] > keep) print $3 }' | while IFS= read -r old; do say "delete (beyond newest $KEEP): $old" run rm -f -- "$DIR\/$old" done say "done: $(find "$DIR" -maxdepth 1 -name '*.ova' | wc -l) exporta en $DIR, $(df -h "$DIR" | awk 'NR==2{print $4" free"}')"\"<\/code><\/pre>\n\n\n\n
Ejec\u00fatalo primero sin el \u00faltimo argumento. En ese modo, solo imprime lo que renombrar\u00eda y eliminar\u00eda. Una vez que la salida parezca correcta, progr\u00e1mala con el argumento adicional que la activa. Nuestro trabajo del Programador de tareas se ejecuta cada hora como root con un comando como este, un trabajo por carpeta de exportaci\u00f3n:<\/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
Un efecto secundario \u00fatil de la regla de los dos puntos: Cloud Sync no puede subir una exportaci\u00f3n hasta que el script la haya renombrado, y el script solo renombra los archivos terminados. Las exportaciones incompletas nunca llegan a la nube.<\/p>\n\n\n\n
Por qu\u00e9 el script gestiona la retenci\u00f3n de copias de seguridad de VMM<\/h2>\n\n\n\n
Virtual Machine Manager tiene su propia configuraci\u00f3n de retenci\u00f3n, que funciona registrando cada exportaci\u00f3n que crea. Una vez que el script cambia el nombre de un archivo, Virtual Machine Manager deja de reconocerlo y nunca lo eliminar\u00e1. Por lo tanto, la retenci\u00f3n se gestiona mediante el script, que cuenta las copias por usuario a partir de la marca de tiempo del nombre.<\/p>\n\n\n\n
En lo que respecta a la sincronizaci\u00f3n en la nube, una casilla de verificaci\u00f3n decide qu\u00e9 sucede en Google Drive. Su redacci\u00f3n es f\u00e1cil de malinterpretar: No elimine los archivos de la carpeta de destino cuando se eliminen de la carpeta de origen.<\/strong>. Si no la marcas, Google Drive replicar\u00e1 el NAS, manteniendo las mismas tres copias. Si la marcas, la nube conservar\u00e1 todas las exportaciones subidas, lo cual es la opci\u00f3n m\u00e1s segura contra el ransomware, pero seguir\u00e1 creciendo hasta que la elimines manualmente.<\/p>\n\n\n\n
Lo que revel\u00f3 una auditor\u00eda de nuestras propias exportaciones<\/h2>\n\n\n\n
Antes de esta configuraci\u00f3n, nuestra copia de seguridad de VMM llevaba funcionando aproximadamente un mes en ambos hosts de producci\u00f3n. Al revisar los archivos en lugar del panel de control, se detectaron tres fallos distintos.<\/p>\n\n\n\n