Gestió de snapshots en entorns virtualitzats amb VMware: neteja, riscos i automatització segura

Els snapshots a VMware són una eina molt potent per a entorns virtualitzats, però també una de les causes més freqüents de problemes de rendiment, consum d’emmagatzematge i operacions de recuperació fallides. Són útils, ràpids de crear i fàcils d’oblidar. I en un entorn on hi ha múltiples administradors o processos automatitzats, aquesta combinació sol acabar en cadenes de snapshots acumulats durant setmanes o mesos, consumint espai i complicant la vida al pitjor moment.

1. Entendre el que realment fa un snapshot en VMware

Un error comú és pensar en un snapshot com una “foto” estàtica de la màquina virtual. Tècnicament, a VMware un snapshot és un conjunt d’arxius que congelen l’estat dels discos virtuals en un moment concret, desviant les escriptures a un delta (-delta.vmdk) mentre la base (.vmdk) queda intacta.

Aquest delta creix segons el volum i tipus d’escriptura que rep la VM. En entorns amb bases de dades, servidors de correu o sistemes amb molta activitat d’I/O aleatori, un delta pot créixer diversos GB per hora. No hi ha compressió màgica: tot el que s’escriu des de l’snapshot ha d’ocupar espai.

A més, un snapshot no és una còpia de seguretat independent: si l’arxiu base es corromp o es perd, l’snapshot no serveix per si sol per recuperar la VM. Tampoc substitueix un backup coherent a nivell d’ aplicació.

Punts clau que convé recordar:

• Cada snapshot és un nou punt de fallada.
• Els deltes s’encadenen: un snapshot d’un altre snapshot afegeix més capes de latència i risc.
• Com més snapshots i més temps es mantinguin, més complex i lent serà consolidar-los.

2. Riscos reals d’acumulació

He vist més problemes per acumulació de snapshots que per crear-los. Els símptomes més freqüents:

Rendiment degradat:
Cada lectura pot implicar recórrer diverses capes de discos fins a arribar al bloc original. Amb dos o tres snapshots recents l’impacte és petit; amb deu encadenats durant setmanes, el retard en accessos aleatoris es torna notable, especialment a VMs amb molt trànsit de disc.

Consum inesperat d’emmagatzematge:
En un datastore ajustat, diversos snapshots oblidats poden consumir l’espai lliure en qüestió d’hores. Això és crític en clusters amb Storage DRS deshabilitat o amb polítiques estrictes de thin provisioning, on no hi ha marge de sobreassignació.

Fallades de consolidació:
Quan s’eliminen snapshots grans o antics, el procés de consolidació pot trigar hores i consumir alt I/O, bloquejant la VM o degradant el seu rendiment de forma visible per a l’usuari final. En casos extrems, la consolidació pot fallar i deixar arxius orfes que cal recompondre manualment.

3. Quan crear i quan evitar snapshots

Encara que VMware permeti fins a 32 snapshots per VM (depenent de la versió), a la pràctica no s’haurien de mantenir més d’1-3 simultàniament, i només durant períodes curts.

Casos on tenen sentit:

• Abans d’ aplicar pegats crítics de sistema operatiu o d’ aplicacions.
• Abans de canvis de configuració d’ infraestructura que es puguin revertir ràpidament.
• Com a pas intermedi en processos de clonació o migració on la finestra de reversió és breu.

Casos on és millor evitar-los:

• Backups diaris prolongats sense integració amb l’ hipervisor.
• Ambients de producció amb I/O intensiu que no es poden pausar per consolidar.
• Ús com a “còpia de seguretat a llarg termini”. Això gairebé sempre acaba en problemes d’espai o corrupció.

4. Neteja controlada i sense impacte innecessari

Eliminar un snapshot no és instantani: VMware ha de fusionar els blocs modificats a l’arxiu base. Aquest procés (consolidació) pot ser més lent que crear-lo, i si es fa sobre snapshots grans pot bloquejar I/O durant minuts o hores.

Bones pràctiques en l’ eliminació:

• Programar la consolidació en finestres de baixa activitat.
• Evitar eliminar diversos snapshots molt grans alhora.
• Si hi ha una cadena llarga, consolidar de forma esglaonada (eliminar-ne un o dos, esperar, després seguir).
• Monitoritzar el datastore durant el procés per detectar creixement temporal d’ arxius.

Una eina útil en vSphere és l’opció “Consolidate”, que força la fusió de deltes fins i tot si no apareixen snapshots a la GUI. Això és clau per a casos en què un procés de backup deixa arxius delta orfes.

5. Automatització segura

L’automatització és clau per mantenir entorns grans sota control, però en el cas de snapshots cal ser curós. Un script mal dissenyat pot esborrar snapshots útils o, al revés, deixar-ne centenars per una fallada de lògica.

Enfocaments recomanats:

• Scripts que enumeren snapshots per VM i la seva antiguitat, enviant alertes abans d’esborrar-los.
• Polítiques d’esborrat automàtic amb marge (per exemple, més de 3 dies d’antiguitat) i amb exclusions per a VMs específiques.
• Integració amb eines de backup que ja gestionen snapshots de forma consistent (Veeam, Commvault, Rubrik, etc.) i eviten cadenes llargues.

Exemple de control bàsic a PowerCLI:

Get-VM | Get-Snapshot | Where-Object {$_.Created -lt (Get-Date).AddDays(-3)} | 
ForEach-Object {
    Write-Host "Eliminant snapshot de $($_.VM.Name) creat el $($_.Created)"
    Remove-Snapshot -Snapshot $_ -Confirm:$false
}

Aquest tipus d’script s’ha d’executar sempre en mode de prova primer (-WhatIf) per evitar ensurts.

6. Monitorització proactiva

Als entorns grans, confiar que “algú es recordi” d’esborrar un snapshot és cridar els problemes. Cal tenir visibilitat contínua.

Mètriques útils a vigilar:

• Nombre d’instantànies per màquina virtual.
• Antiguitat màxima dels snapshots existents.
• Creixement dels deltes a GB.
• Espai lliure al datastore i tendència de consum.

vRealize Operations, scripts a PowerCLI i alertes a vCenter permeten configurar llindars clars, per exemple:

• Alerta si un snapshot supera 20 GB.
• Alerta si hi ha un snapshot amb més de 5 dies.

7. Casos límit i recuperació

Hi ha escenaris en què els snapshots es converteixen en un problema urgent:

• Un datastore crític al 95% d’ús per snapshots oblidats.
• Consolidació que falla repetidament per delta corrupte.
• Arxius orfes després d’un tall d’energia durant una operació de snapshot.

En aquests casos, convé tenir protocols clars:

• Pausar la VM si el risc de corrupció és alt.
• Moure arxius delta a un altre datastore temporal per alliberar espai.
• Fer servir vmkfstools per fusionar manualment, sempre en còpia, mai sobre l’ arxiu original.

La documentació oficial de VMware i KBs específiques per a cada error són imprescindibles aquí; cada cas de corrupció és diferent i requereix cura extrema per no perdre dades.

8. Estratègies d’automatització avançada

Quan es treballa amb centenars o milers de VMs, la gestió manual de snapshots és inviable. El repte no és només esborrar-los, sinó fer-ho de manera que no s’eliminin els que encara tenen una funció operativa i que el procés no afecti el rendiment.

8.1. Classificació automàtica per criticitat i ús

En lloc d’aplicar una política global (per exemple, “esborrar tot el de més de 3 dies”), és preferible classificar les VMs:

• Producció crítica: finestres de consolidació planificades, exclusions en processos automàtics.
• Desenvolupament i proves: eliminació automàtica agressiva (1-2 dies d’antiguitat).
• Backup temporal: gestionades per programari de còpia de seguretat, sense intervenció manual.

Això es pot implementar afegint etiquetes (Tags) a vSphere i filtrant en els scripts segons aquestes etiquetes.

Exemple amb PowerCLI:

$tagsProduccion = Get-Tag -Name "Prod-Critica"
Get-VM -Tag $tagsProduccion | Get-Snapshot | Where-Object {$_.Created -lt (Get-Date).AddDays(-7)} | 
ForEach-Object {
    # Només eliminar fora d' horari productiu
    if ((Get-Date).Hour -ge 22 -or (Get-Date).Hour -lt 6) {
        Remove-Snapshot -Snapshot $_ -Confirm:$false
    } else {
        Write-Host "Pendent esborrar: $($_.VM.Name) - fora de finestra"
    }
}

8.2. Integració amb processos de backup

Molts problemes venen que les solucions de backup creen snapshots per llegir els discos i no els consoliden correctament si alguna cosa falla. Per evitar cadenes llargues:

• Activar a l’ eina de backup el control de temps màxim de snapshot.
• Revisar logs de backup buscant missatges de snapshot no consolidat.
• Programar tasques a vCenter que revisin si hi ha snapshots pendents i enviïn un report a l’equip.

8.3. Automatització amb esdeveniments a vCenter

vCenter permet associar accions a esdeveniments, per exemple:

• Esdeveniment: “Snapshot creat” → Afegir una entrada a un registre central amb VM, data i usuari.
• Esdeveniment: “Snapshot eliminat” → Marcar al registre que s’ha tancat el cicle.

Això permet que els snapshots “fantasma” passin desapercebuts.

9. Configuracions que eviten problemes

Algunes configuracions simples eviten acumulacions perilloses:

9.1. Permisos restringits per crear snapshots

En molts entorns, qualsevol administrador de VM té permisos per crear snapshots, però no sempre saben les implicacions. Fer servir rols a vCenter que separin la capacitat de crear snapshots de la de gestionar la resta de la VM ajuda a controlar qui els genera.

9.2. Alertes proactives en vCenter

Configurar alarmes personalitzades:

• Trigger: VM Snapshot Size (GB) > 20
• Trigger: VM Snapshot Age > 3 dies
• Acció: enviar correu o missatge a un canal de Teams/Slack de l’equip.

A entorns on la càrrega de treball és alta, les alertes han d’estar afinades per evitar soroll. Un bon filtre és exigir que l’snapshot compleixi dues condicions (antiguitat i mida) per disparar l’alarma.

9.3. Revisió programada

Una tasca setmanal (automàtica o manual) per revisar:

• VMs amb més d’ un snapshot actiu.
• Snapshots sense descripció (molts es creen sense detallar el motiu i s’obliden).
• Discrepàncies entre els snapshots que reporta vCenter i els arxius delta al datastore.

Això últim és crític: una fallada a la base de dades de vCenter pot fer que no aparegui un snapshot, però sí que estigui consumint espai.

10. Polítiques de consolidació segura

Quan hi ha snapshots grans (50+ GB) o cadenes llargues, la consolidació s’ha de planificar:

• Esglaonada: esborrar un o dos snapshots i deixar que el sistema s’ estabilitzi abans de continuar.
• Amb control de càrrega: Fer servir esxtop o monitorització per verificar que el datastore i la controladora d’ emmagatzematge no estan saturats abans d’ iniciar.
• Amb backup previ: en casos crítics, fer backup a nivell de VM abans de consolidar. Una fallada en meitat del procés pot deixar la màquina inservible.

11. Recuperació després de fallades amb snapshots

Quan una consolidació falla:

• Identificar l’ snapshot o delta problemàtic.
  • Comprovar en el directori de la VM els arxius .vmdk i .vmsd.
• Revisar logs (vmware.log en el directori de la VM) per detectar errors específics.
• Fer servir vmkfstools per intentar consolidar manualment:

vmkfstools -i FMNAME-000002.fmdk-d FMNAME-vmdk.fmdk

Això crea un disc nou fusionant la cadena.

• Si el datastore és ple, moure el delta problemàtic a un altre datastore temporal abans d’iniciar l’operació.

Aquí cada cas és diferent: de vegades és més segur clonar la VM a partir d’un snapshot estable que intentar reparar tota la cadena.

12. Checklist per la gestió de snapshots en VMware

• Definir límits clars d’ antiguitat i mida segons tipus de VM.
• Automatitzar esborrats, però amb exclusions per etiqueta.
• Monitoritzar tant des de vCenter com al sistema de fitxers del datastore.
• Integrar control de snapshots amb processos de backup.
• Mantenir procediments documentats per a recuperació després de fallada de consolidació.
• Revisar permisos i limitar la creació de snapshots a personal autoritzat.
• Fer servir descripcions clares i estàndard en crear snapshots.