-l lista, -d FECHA busca en seco, -d FECHA -r borra.Hay una escena que se repite. Alguien va a aplicar una actualización grande en una máquina, hace un snapshot por si acaso —bien hecho—, la actualización sale bien y nadie vuelve a acordarse de aquel snapshot. Pasan seis meses. La máquina ha escrito varios cientos de gigas desde entonces, y todos esos bloques siguen ahí porque hay una foto antigua que los sujeta.
El problema no es que el snapshot exista. Es que nadie sabe que existe.
Proxmox VE te deja crear snapshots desde la interfaz, desde qm, desde la API y desde cualquier script. Lo que no te da es la pregunta inversa: enséñame todos los snapshots que hay ahora mismo en este clúster, de qué fecha son y quién los dejó ahí. Para eso tienes que entrar invitado por invitado, pestaña por pestaña. En un clúster de cuarenta máquinas eso no lo hace nadie, y por eso los snapshots viejos se acumulan hasta que alguien mira el gráfico de espacio y se lleva un susto.
ProxSnap existe para tapar exactamente ese agujero.
| Dato | Valor |
|---|---|
| Autor | Florian Paul Azim Hoberg (gyptazy) |
| Licencia | GPL-3.0 |
| Lenguaje | Rust |
| Versión | 1.0.0, solo amd64 |
| Primer commit | 16 de enero de 2026 |
| Último commit | 22 de enero de 2026 |
| Popularidad | ~21 estrellas en GitHub |
| Instalación | Repositorio Debian propio o paquete .deb suelto |
| Autenticación | Token de API de Proxmox VE |
| Alcance | VMs QEMU y contenedores LXC de todo el clúster |
El nombre del autor probablemente te suene por ProxLB, su planificador de recursos y balanceador de carga para Proxmox, que anda por las 893 estrellas y sí tiene lanzamientos regulares. ProxSnap forma parte de la misma colección de utilidades pequeñas —Prox-Tools— y comparte con ProxLB algo práctico: el mismo esquema de configuración, así que si ya tienes ProxLB configurado, las credenciales te valen tal cual.
Es una herramienta deliberadamente pequeña. No tiene interfaz web, no tiene agente, no se queda residente. Es un binario que llamas, consulta la API, imprime y sale.
Antes de la herramienta conviene tener claro por qué esto importa, porque depende mucho de dónde vivan tus discos y la diferencia entre un caso y otro es enorme.
LVM-thin. Es el caso más peligroso y el más común en instalaciones de un solo nodo. El snapshot no ocupa nada al crearse, pero cada bloque que la máquina modifica después obliga a conservar la versión antigua dentro del thin pool. Si el pool se llena, no se degrada el rendimiento: las escrituras empiezan a fallar y los invitados se van a solo lectura o directamente se paran. Un snapshot olvidado en una máquina que escribe mucho es un incidente esperando su turno.
ZFS. Más benévolo, porque avisa. El snapshot retiene los bloques liberados y eso se ve en la columna USED de zfs list -t snapshot. No te tumba nada de golpe mientras tengas holgura, pero se come el espacio libre y, en un pool muy lleno, el rendimiento se resiente por fragmentación.
qcow2 sobre directorio o NFS. Los snapshots viven dentro del propio fichero, que engorda. Además cada capa añade indirección en las lecturas, así que la penalización no es solo de espacio.
Ceph RBD. El snapshot dispara copia en escritura en el pool: los objetos modificados se duplican y la escritura paga el peaje. En un clúster con réplica 3, cada giga retenido son tres gigas de verdad.
Y una obviedad que aun así hay que decir en voz alta: un snapshot no es una copia de seguridad. Vive en el mismo almacenamiento que el original, muere con él y no protege de nada que se lleve por delante el disco. Para eso está Proxmox Backup Server, y las dos cosas no compiten, se complementan.
La vía recomendada por el autor es su repositorio Debian, que integra la herramienta en apt y te da actualizaciones:
echo "deb https://repo.gyptazy.com/stable /" > /etc/apt/sources.list.d/proxlb.list
wget -O /etc/apt/trusted.gpg.d/proxlb.asc https://repo.gyptazy.com/repository.gpg
apt-get update && apt-get -y install proxsnapSí, el fichero de lista se llama proxlb.list: es el mismo repositorio para todas sus herramientas.
También hay paquete suelto. Aquí un aviso concreto, porque el README trae una errata: la URL que publica apunta a cdn.gyptazy.com/debian/proxclmc/... y devuelve un 404. La ruta buena, comprobada, es esta:
wget https://cdn.gyptazy.com/debian/proxsnap/proxsnap_1.0.0_amd64.deb
dpkg -i proxsnap_1.0.0_amd64.debLo que instala el paquete son dos cosas: /usr/bin/proxsnap y un changelog. Nada más. No hay unidad de systemd, ni temporizador, ni fichero de configuración de ejemplo, ni página de manual. El binario ocupa 5,2 MB y no declara dependencias, que es lo esperable de un ejecutable Rust enlazado estáticamente: se puede copiar a mano a un nodo y funciona.
Que no traiga temporizador no es un descuido menor, es la decisión de diseño. ProxSnap es una orden que ejecutas; la periodicidad es asunto tuyo.
Busca por defecto /etc/proxsnap/proxsnap.yaml, y con -c le pasas otra ruta:
proxmox_api:
hosts: virt01-de-ne01.example.com
user: proxsnap@pam
token_id: proxsnap
token_secret: ac1079bb-3333-3333-3333-8a3262da6077
ssl_verification: true
timeout: 10Dos comentarios sobre esto, porque el ejemplo original del proyecto trae ssl_verification: false y esa línea se copia sola.
El primero: no la desactives. Proxmox se instala con un certificado autofirmado y la tentación de saltarse la verificación es enorme, pero estás pasando un token con permiso de borrado por esa conexión. Ponle un certificado de verdad al clúster o instala la CA del nodo en la máquina que ejecuta ProxSnap.
El segundo: crea un usuario y un token para esto y nada más. Con un rol propio que tenga VM.Audit para poder ver los invitados y VM.Snapshot para poder borrar, y ninguna otra cosa. Nada de root@pam, y desde luego nada de un token con PVEAdmin heredado de otra integración. Si estás poniendo orden en esto, tenemos una guía entera sobre tokens, roles y 2FA en Proxmox que aplica igual aquí.
No hay más. Y ese es el mérito.
Inventario completo:
proxsnap -lImprime un recorrido nodo por nodo de las VMs y los contenedores, marcando cuáles tienen snapshots y mostrando el nombre de cada uno, su fecha de creación y su antigüedad. Es la vista que no existe en la interfaz de Proxmox, y por sí sola ya justifica tener el binario en un nodo.
Buscar los viejos, sin tocar nada:
proxsnap -d 2026-01-04Lista los snapshots anteriores a esa fecha. Va en seco por defecto: no borra ni modifica nada. Este es el comando que quieres en tu tarea programada.
Borrar:
proxsnap -d 2026-01-04 -rSolo con -r explícito se ejecuta el borrado, y cada eliminación queda registrada. Únicamente caen los snapshots que superan el corte de fecha.
El filtro es exclusivamente temporal. No hay exclusiones por nombre, ni patrones, ni listas blancas de invitados, ni forma de decirle «este snapshot déjalo en paz aunque sea de hace un año». Volveremos a ello, porque es la parte que hay que compensar con criterio.
La receta que propone el autor es un script con cron o systemd, y es lo razonable. La que usaríamos nosotros separa deliberadamente el inventario del borrado:
# /usr/local/bin/proxsnap-audit.sh
#!/bin/sh
set -eu
CORTE=$(date -d '30 days ago' +%Y-%m-%d)
proxsnap -d "$CORTE" | tee /var/log/proxsnap/audit-$(date +%F).logEse script no borra: deja un informe. Lo enganchas a un temporizador semanal y el informe se va a donde vaya el resto de vuestros registros —si tenéis Loki y Grafana delante de Proxmox, ahí— o a un correo que alguien lea de verdad.
# /etc/systemd/system/proxsnap-audit.timer
[Unit]
Description=Inventario semanal de snapshots del cluster
[Timer]
OnCalendar=Mon 08:00
Persistent=true
[Install]
WantedBy=timers.targetEl borrado, al principio, a mano y con el informe delante. Cuando lleves unos meses y compruebes que lo que sale en la lista es siempre basura de verdad, entonces te planteas automatizar el -r. Y aun así, con un corte generoso: treinta días para el informe, noventa para el borrado automático. La diferencia entre ambos umbrales es tu margen para que un humano diga «ese no».
Ese margen importa porque hay snapshots antiguos que están ahí a propósito. La foto base de una plantilla desde la que clonáis, el punto de retorno de una migración larga que todavía no se ha dado por buena, la máquina de un cliente que pidió por escrito conservar un estado concreto. ProxSnap no distingue ninguno de esos casos de un snapshot olvidado en marzo: para él son todos «anteriores a la fecha».
De ahí sale la única regla que de verdad hace falta: si un snapshot va a durar más de una semana, su nombre tiene que decir por qué. pre-upgrade-kernel-20260908 se puede borrar sin pensar dentro de tres meses. base-plantilla-debian13-NO-BORRAR te frena la mano. La convención de nombres no es burocracia, es lo que convierte una lista de fechas en una decisión.
Puedes, y conviene ser honesto al respecto. La API de Proxmox expone los snapshots de cada invitado, así que un bucle sobre /cluster/resources sacando snapshot de cada VM te da el inventario en un rato:
pvesh get /cluster/resources --type vm --output-format json \
| jq -r '.[] | "\(.node) \(.type) \(.vmid)"' \
| while read -r node type vmid; do
pvesh get "/nodes/$node/${type}/$vmid/snapshot" --output-format json \
| jq -r --arg v "$vmid" '.[] | select(.name != "current") | "\($v) \(.name) \(.snaptime)"'
doneEso funciona, no instala nada y lo entiende cualquiera de tu equipo. Lo que te da ProxSnap a cambio es que ya está escrito, formatea las antigüedades de forma legible, trata igual a VMs y contenedores, se ejecuta desde fuera del clúster —el script de arriba necesita pvesh, o sea, correr en un nodo— y el borrado con confirmación explícita ya está resuelto.
Si tienes tres nodos y te gusta el shell, el script te sobra. Si gestionas varios clústeres y quieres la misma orden en todos, el binario compensa.
Aquí toca ser claro, porque es el punto que decide si esto entra en producción o se queda en el laboratorio.
ProxSnap se publicó el 16 de enero de 2026. Todo su desarrollo cabe en una semana: el grueso de commits es del día 17 y el README se añadió el 22. Desde entonces no ha habido un solo cambio. No tiene lanzamientos ni etiquetas en GitHub —el 1.0.0 vive en el paquete Debian, no en el repositorio—, ronda las 21 estrellas, y el propio autor advierte en su página que no hay canal de soporte, ni seguimiento de incidencias, ni hoja de ruta.
Se puede leer de dos maneras y las dos son ciertas. Una: es una herramienta de doscientas líneas conceptuales que hace tres cosas contra una API estable, y no necesita cambiar. Software terminado, que existe. La otra: si mañana Proxmox cambia algo en su API de snapshots, no hay nadie de guardia, y el contraste con ProxLB —lanzamientos cada pocas semanas, decenas de incidencias abiertas y cerradas— sugiere dónde está la atención del autor.
Nuestra lectura práctica: para el modo -l, adelante sin reservas; lo peor que puede pasar es que un día imprima un error. Para el -r desatendido, exige lo mismo que a cualquier proceso que borre datos en tu plataforma: que alguien de tu equipo haya leído qué hace y que exista un informe previo. No por desconfianza en este proyecto en particular, sino porque un token con permiso de borrado corriendo solo a las tres de la mañana merece ese respeto sea de quien sea la herramienta.
El ecosistema alrededor de Proxmox se ha llenado de piezas y es fácil confundirlas. Con los snapshots, el reparto queda así:
| Herramienta | Qué aporta con los snapshots |
|---|---|
| Proxmox VE de serie | Crear, revertir y borrar por invitado. Sin vista global. |
| Proxmox Datacenter Manager | Vista unificada de invitados entre clústeres y operaciones de snapshot centrales, con árbol padre-hijo. Es la respuesta oficial y va en serio. |
| ProxSnap | Inventario de todo el clúster por antigüedad y limpieza por fecha. Una orden, sin servicio que mantener. |
| cv4pve-admin | Creación automática de snapshots con política y retención. |
| PegaProx | Gestión de snapshots dentro de un plano de control multi-clúster completo. |
| Proxmox Backup Server | Lo otro. Copias reales, fuera del almacenamiento del invitado. |
La pareja natural es la de cv4pve-autosnap y ProxSnap: uno crea con una política y borra lo que su propia política dice, el otro encuentra lo que se quedó fuera de cualquier política, que es justo lo que sobrevive. Y si ya tienes el Datacenter Manager desplegado, buena parte de la visibilidad la tienes cubierta por la vía oficial; ProxSnap sigue teniendo sentido como orden que se ejecuta sola en un temporizador, sin abrir ninguna interfaz.
Si vas montando el conjunto, el resto del mapa lo tenemos repasado: ProxSave para la configuración del propio host, Pulse para la monitorización y el chequeo de chunks de PBS para saber qué ocupa de verdad cada máquina en las copias.
ProxSnap no es una herramienta ambiciosa y no pretende serlo. Es un binario que responde a una pregunta que Proxmox no responde, y la responde bien.
Pero la herramienta es la parte fácil. Lo que arregla el problema de los snapshots olvidados es tener una política: quién puede crear uno, con qué nombre, cuánto vive por defecto, y quién mira la lista una vez al mes. Sin eso, ProxSnap solo te dará un informe más largo cada trimestre.
En las plataformas que gestionamos esa política es parte del servicio y no de la buena memoria de nadie: los snapshots tienen caducidad, las copias de verdad van a Proxmox Backup Server fuera del almacenamiento de producción, y el espacio libre de los pools está vigilado antes de que llegue al punto en el que empieza a doler. Si estás dimensionando tu plataforma o revisando cuánto puedes tardar en volver tras un incidente, cuéntanos cómo lo tienes montado y lo miramos contigo.
No. Solo lista, filtra por antigüedad y borra. Para crearlos con política y retención necesitas otra cosa, como cv4pve-autosnap.
Sí, recorre los dos tipos de invitado por igual en todo el clúster.
No. Habla por la API con un token, así que puede vivir en cualquier máquina Debian con acceso de red al clúster. De hecho, ejecutarlo desde fuera y no en un nodo de producción es lo más limpio.
El paquete publicado es solo amd64. Al ser código Rust y GPL, compilarlo para otra arquitectura es viable, pero no hay build oficial. Si tienes un Proxmox sobre arm64, cuenta con compilarlo tú.
Técnicamente sí, pero el filtro es solo por fecha y no admite exclusiones: cualquier snapshot anterior al corte cae, incluidos los que están ahí a propósito. Empieza dejando solo el modo informe programado, revisa unas cuantas semanas de listas, y automatiza el borrado con un umbral generoso cuando confíes en lo que sale.
En absoluto. Un snapshot vive en el mismo almacenamiento que el disco original y desaparece con él. Es un punto de retorno para un cambio, no protección ante un fallo de hardware, un cifrado por ransomware o un borrado.
VM.Audit y VM.Snapshot para el rol del token.
Asignar a tus VMs más CPU y RAM de la que el servidor tiene físicamente —overcommit— es lo que permite meter más máquinas en el mismo hardware. Con la CPU suele salir bien; con la memoria, hecho a la ligera, es la receta de un servidor que muere de golpe. Explicamos por qué la CPU se sobreasigna con tranquilidad y la RAM con mucho cuidado, y las herramientas (ballooning, KSM) para hacerlo con cabeza.
Ceder unas horas de una GPU suele significar crear un usuario, repartir claves SSH, revisar permisos y acordarse de retirarlo todo después. RunSnack reduce eso a ejecutar un script y pasar un enlace que abre una terminal en el navegador, dentro de un contenedor Docker con acceso a la GPU del anfitrión. Es una idea buena y pequeña, con una frontera de seguridad que su propio autor documenta sin adornos: repasamos qué resuelve, qué no, y cuándo la respuesta correcta sigue siendo una máquina virtual.
La microsegmentación es la estrategia; escribir las reglas es el oficio. Aquí bajamos al detalle práctico del firewall de Proxmox: el orden en que se evalúan las reglas, la dirección del tráfico, los grupos y los IPSets que lo hacen mantenible, y el NAT del SDN —SNAT de salida y redirección de puertos— que a veces sigue haciendo falta aunque IPv6 sea el futuro.