Copia de seguridad de VMM a Google Drive: exportación programada, sincronización en la nube y un único script para renombrar archivos.

Una copia de seguridad de VMM que solo reside en el mismo NAS que la máquina virtual no es realmente una copia de seguridad. Si ese servidor falla, ambas copias se pierden con él. Este almacén 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ón programada en Virtual Machine Manager y sincronización en la nube con Google Drive. Configurarlo nos llevó una tarde. Descubrir por qué había dejado de funcionar silenciosamente nos llevó más tiempo, y esa es la razón de ser de este artículo de Introducción al alojamiento NAS. A continuación, se muestra la configuración que funciona, la peculiaridad del nombre de archivo que la provoca, el pequeño script que la soluciona y los resultados de una auditoría de nuestras propias exportaciones.

Punto SynoPower Club: Cada ingeniero de soporte tiene una anécdota sobre un cliente cuyas copias de seguridad funcionaron correctamente durante un año sin restaurar nada. No esperaba tener que escribir una sobre nuestra propia empresa. Nuestra copia de seguridad de VMM parecía estar en perfecto estado en la interfaz, pero un host había acumulado un terabyte de exportaciones que nunca pudo limpiar, y el otro no había generado ni un solo archivo en trece días. No había nada oculto. Todo estaba en un registro que nadie lee. La solución tardó una hora; la lección es comprobar que los archivos realmente existen donde se supone que están, según un cronograma, como cualquier otra tarea.

Lo que necesita una copia de seguridad completa de VMM #

Virtual Machine Manager ofrece tres capas de protección, y cada una cubre un tipo de fallo diferente. Un buen plan de copia de seguridad de VMM utiliza más de una.

Capa	Donde se encuentra la copia	De qué protege
Instantáneas	Mismo volumen que el invitado	Una actualización defectuosa o un error dentro del invitado
Replicación (VMM Pro)	Otro NAS en el clúster	Un NAS falla, con una rápida recuperación en el otro host.
Exportación programada + Sincronización en la nube	Una cuenta en la nube fuera del sitio	Pérdida total del sitio: incendio, robo, ransomware en la LAN.

Ya replicamos seis invitados a un anfitrión de reserva, como se describe en nuestro informe sobre el clúster de máquinas virtuales Synology de tres nodos. La replicación mantiene una copia dentro del edificio. La capa de exportación es la que mantiene una copia fuera del mismo.

Cómo funciona la exportación programada de VMM #

Para una copia de seguridad de VMM, la exportación programada crea una copia completa de la máquina virtual, sus discos y su configuración, como un único archivo OVA en una carpeta compartida. Puede elegir la carpeta de destino, el modo de exportación (diario, semanal o mensual) y la cantidad de archivos más recientes que desea conservar. Las exportaciones se ejecutan mientras la máquina virtual está en funcionamiento.

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

El cuadro de diálogo también muestra el estado consistente. Sin la herramienta Synology Guest Tool instalada en la máquina virtual, las exportaciones presentan una consistencia de fallo, el mismo estado que al desconectar el cable de alimentación. Esto es aceptable para la mayoría de las cargas de trabajo, y la instalación de Guest Tool lo actualiza a una consistencia de sistema de archivos.

¿Por qué Cloud Sync omite los archivos de copia de seguridad de VMM? #

El siguiente paso lógico es configurar Cloud Sync para que apunte a la carpeta de exportación y suba todo a Google Drive. Hicimos exactamente eso, y los archivos de copia de seguridad de VMM nunca llegaron.

La razón es el nombre del archivo. Virtual Machine Manager nombra cada exportación con una marca de tiempo que contiene dos puntos:

exp_web-2026-09-25 10:29:51-6f713905-cee2-4647-94d5-a5ce6fbdc585.ova

Cloud Sync no subía esos nombres a nuestro Google Drive, por lo que todas las exportaciones se guardaban localmente. El archivo es válido; el problema reside en el carácter. Dado que el formato de la marca de tiempo de exportación no se puede modificar en Virtual Machine Manager, la corrección debe realizarse entre la exportación y la subida.

Curiosamente, solo las exportaciones programadas llevan la marca de tiempo. Una exportación manual desde el mismo menú se guarda simplemente como el nombre del invitado, como por ejemplo: spc_4C8G.ova, y Cloud Sync lo sube sin problemas. Por eso, una prueba manual rápida puede hacer que todo parezca correcto, aunque la programación nocturna nunca llegue a la nube.

Configurar una copia de seguridad de VMM en Google Drive en 4 pasos #

Esta es la configuración de copia de seguridad de VMM que funciona en cada host que almacena máquinas virtuales. Requiere Virtual Machine Manager, Cloud Sync y una cuenta de Google; no necesita VMM Pro.

El script de cambio de nombre detrás de nuestra copia de seguridad de VMM #

El script es el único componente personalizado de la cadena de copias de seguridad de VMM y realiza dos funciones: renombra cada exportación finalizada, reemplazando los dos puntos por guiones, y conserva únicamente las copias más recientes de cada máquina virtual en la carpeta de exportación. Solo modifica los archivos que no han sufrido cambios en los últimos quince minutos, por lo que nunca renombra una exportación que aún se esté escribiendo.

#!/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á nombres que contengan ":", lo que también significa que nunca toca una exportación que aún se esté escribiendo. Una vez que una exportación termina, la renombra en su lugar con ":" reemplazado por "-" para que Cloud Sync la detecte y luego conserve solo las exportaciones renombradas más recientes por invitado. (La retención propia de VMM ya no puede ver los archivos renombrados, por lo que la retención se realiza aquí). Uso: vm-export-cloud.sh EXPORT_DIR KEEP [--apply] Sin --apply solo imprime lo que haría. set -u DIR=${1:?EXPORT_DIR}; KEEP=${2:?KEEP}; APPLY=${3:-} MIN_AGE_MIN=15 # una exportación 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ón 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ás recientes por invitado (la marca de tiempo está 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"}')""

Ejecútalo primero sin el último argumento. En ese modo, solo imprime lo que renombraría y eliminaría. Una vez que la salida parezca correcta, prográmala 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ón:

bash /volume1/@vm-export-cloud/vm-export-cloud.sh "/volume3/VM_BK_Export" 3 --apply

Un efecto secundario útil de la regla de los dos puntos: Cloud Sync no puede subir una exportación hasta que el script la haya renombrado, y el script solo renombra los archivos terminados. Las exportaciones incompletas nunca llegan a la nube.

Por qué el script gestiona la retención de copias de seguridad de VMM #

Virtual Machine Manager tiene su propia configuración de retención, que funciona registrando cada exportación que crea. Una vez que el script cambia el nombre de un archivo, Virtual Machine Manager deja de reconocerlo y nunca lo eliminará. Por lo tanto, la retención se gestiona mediante el script, que cuenta las copias por usuario a partir de la marca de tiempo del nombre.

En lo que respecta a la sincronización en la nube, una casilla de verificación decide qué sucede en Google Drive. Su redacción es fácil de malinterpretar: No elimine los archivos de la carpeta de destino cuando se eliminen de la carpeta de origen.. Si no la marcas, Google Drive replicará el NAS, manteniendo las mismas tres copias. Si la marcas, la nube conservará todas las exportaciones subidas, lo cual es la opción más segura contra el ransomware, pero seguirá creciendo hasta que la elimines manualmente.

Lo que reveló una auditoría de nuestras propias exportaciones #

Antes de esta configuración, nuestra copia de seguridad de VMM llevaba funcionando aproximadamente un mes en ambos hosts de producción. Al revisar los archivos en lugar del panel de control, se detectaron tres fallos distintos.

• La retención de datos se ha interrumpido silenciosamente en uno de los servidores. La pequeña base de datos que Virtual Machine Manager utiliza para rastrear las exportaciones no se pudo crear en la carpeta de exportación, por lo que cada ejecución registraba un error y nunca se eliminaba ninguna exportación antigua. Un servidor acumuló un terabyte de archivos OVA y alcanzó la capacidad máxima de 97%.
• El cliente más importante dejó de exportar. Su exportación de 84 GB ya no cabía en el espacio restante, por lo que falló durante tres días seguidos sin que notáramos ninguna alerta.
• Tres horarios que no llevan a ninguna parte. Un cambio en la configuración dejó tres programaciones de exportación con un destino vacío. A partir de ese día, registraron un nombre de recurso compartido no válido cada minuto, más de 20.000 veces, y no exportaron nada, incluida la programación para esta tienda.

En condiciones normales de uso, nada de esto se manifestó como un fallo en la copia de seguridad de VMM. Los invitados funcionaban, la tienda procesaba los pedidos y la replicación mantenía una copia en el host de reserva. La capa de exportación, la única copia externa, simplemente se había detenido. Ahora revisamos las carpetas de exportación y la lista de cargas de Cloud Sync después de cada cambio en la programación.

Planificación de ancho de banda y almacenamiento para una copia de seguridad de VMM #

Cada exportación de copia de seguridad de VMM es una copia completa, no un incremento, así que dimensione el archivo antes de elegir una programación. Nuestros clientes varían desde un sitio web pequeño de 5 GB hasta un sitio web asociado de 84 GB, y la exportación de esta tienda ocupa aproximadamente 7 GB. En total, una programación diaria carga más de 100 GB al día.

Google Drive permite a cada usuario subir 750 GB en 24 horas, con archivos de hasta 5 TB, por lo que el límite rara vez es el problema. El tiempo de subida y el almacenamiento en la nube sí lo son. Mantener tres copias de cada invitado en la nube requiere tres veces el espacio diario total de Drive, e incluso más si la nube conserva todas las copias. Para invitados grandes que cambian poco, una exportación semanal suele ser suficiente, sobre todo cuando la replicación ya cubre la recuperación diaria.

Por qué creamos copias de seguridad en las herramientas Synology #

Todos los componentes de esta cadena de copias de seguridad de VMM vienen incluidos con DSM. Virtual Machine Manager exporta las máquinas virtuales, Cloud Sync las carga, el Programador de tareas ejecuta el script y las mismas unidades NAS almacenan nuestros archivos y gestionan el almacenamiento. No es necesario licenciar ningún agente de copia de seguridad por máquina virtual ni mantener un servidor de copias de seguridad independiente.

Las piezas por las que sí pagamos son las que añaden protección entre anfitriones: Licencia VMM Pro para replicación en el sistema en espera, y Licencias Virtual DSM para los invitados adicionales de DSM. Si está decidiendo qué edición necesita, nuestra Comparación entre Virtual Machine Manager y VMM Pro lo cubre.

Limitaciones y advertencias de las copias de seguridad de VMM #

Una exportación es una copia completa en un momento dado. Sin la herramienta Guest Tool, la consistencia ante fallos es tal que las bases de datos dentro de la máquina virtual se recuperan como lo harían después de un corte de energía. Pruebe a restaurar su máquina virtual más importante al menos una vez.

Restaurar una copia de seguridad de VMM desde la nube implica descargar primero el archivo completo. Exportar 84 GB lleva horas con una conexión de oficina típica, por lo que la copia en la nube es para casos de emergencia, no para errores cotidianos. Las instantáneas y la replicación gestionan estos errores mucho más rápido.

Cloud Sync puede cifrar archivos antes de subirlos, y recomendamos activarlo para los invitados que almacenan datos de clientes. Guarde la contraseña de cifrado en un lugar seguro, independiente del NAS que está protegiendo.

Por último, el script de cambio de nombre depende del formato del nombre de exportación. Si una futura actualización de Virtual Machine Manager lo modifica, el script dejará de reconocer los archivos. El modo de prueba es la forma más rápida de confirmar que sigue reconociendo tus exportaciones después de una actualización.

Preguntas frecuentes #

Referencias y tutoriales en vídeo #

• Máquina virtual en Virtual Machine Manager, el artículo del centro de conocimiento que trata sobre la exportación.
• Ayuda de sincronización en la nube, incluyendo la dirección de sincronización y la configuración de tareas.
• Límites de almacenamiento y carga de Google Drive, con el límite de subida diaria de 750 GB.
• Documento técnico de Synology VMM, sobre capas de protección de datos para máquinas virtuales.
• Programador de tareas en DSM, para ejecutar el script de cambio de nombre como una tarea programada.

Vídeos sobre las herramientas de esta cadena: Sincronización en la nube y exportación y migración de máquinas virtuales en un NAS Synology.

¿Quieres agregar replicación entre hosts además de tu copia externa? Obtén una Licencia VMM Pro, o lea cómo funciona el resto de este sitio en Nuestra serie de introducción al alojamiento NAS.