Proxmox Backup Server: guía completa para proteger un entorno Proxmox VE

Un vistazo en 45 segundos

• Proxmox Backup Server (PBS) es el sistema de copias del propio equipo de Proxmox: producto aparte del hipervisor, con su interfaz, su API y su cliente de línea de comandos. Núcleo en Rust, licencia AGPLv3, suscripción opcional para el repositorio enterprise y el soporte.
• Trocea todo en chunks identificados por su SHA-256, así que un bloque repetido se guarda una sola vez en todo el datastore, venga de la copia de anoche o de otra máquina distinta.
• Tras la primera copia, todas las demás son incrementales para siempre: en máquinas encendidas, el dirty bitmap de QEMU le dice a PVE qué bloques han cambiado sin releer el disco entero.
• La retención va en dos tiempos: prune decide qué snapshots viven y la recolección de basura libera el espacio de los bloques que ya no referencia nadie, con un margen de 24 horas y 5 minutos.
• El cifrado del lado cliente (AES-256-GCM) hace que el servidor guarde datos que no puede leer, lo que abre la puerta a una copia en infraestructura ajena sin ceder confidencialidad.
• La 4.2, de abril de 2026, sacó el backend S3 de la fase de vista previa y le puso soporte oficial, cifrado en los sync jobs de tipo push y procesado de varios grupos a la vez.
• Restaurar tiene tres velocidades: completa, live-restore (la VM arranca mientras se copia por detrás) y recuperación de ficheros sueltos desde el navegador de la copia.

---

Un entorno de Proxmox VE en producción acaba siempre en la misma conversación: las copias. Y ahí mucha gente se queda en el vzdump que trae el hipervisor de serie, que funciona, que ha salvado bastantes fines de semana, y que tiene un techo bajo: cada ejecución escribe un volcado completo. Con eso, guardar treinta días de historial de una flota mediana es una cuestión de cuántos discos estás dispuesto a comprar.

Proxmox Backup Server rompe ese techo cambiando la unidad de trabajo: en lugar de ficheros de volcado, guarda bloques direccionados por su contenido. De ahí sale todo lo demás, la deduplicación, los incrementales que no envejecen, la verificación de integridad y la réplica barata a otra ubicación.

Esta guía recorre el sistema entero, del formato en disco a la restauración, con el criterio de despliegue que aplicamos cuando montamos la plataforma de un cliente. Si lo que buscas es la explicación corta de las tres piezas centrales, la tienes en Proxmox Backup Server a fondo; aquí vamos al detalle operativo.

Dónde se queda vzdump

Conviene tener claro qué gana uno al añadir un servidor más a la ecuación, porque no es gratis en hardware ni en operación.

La tabla se resume en una frase: con vzdump el coste de guardar historial crece en línea recta y con PBS se aplana enseguida. Todo lo demás —la verificación, el live-restore, los namespaces— viene detrás de esa decisión de formato.

Cómo guarda PBS los datos

El contenedor de todo es el datastore: un directorio sobre un sistema de ficheros local, normalmente ZFS, donde se escriben las copias. Dentro no hay imágenes de disco. Hay bloques y listas de bloques.

Cada flujo de datos se trocea y de cada trozo se calcula un SHA-256 que hace de nombre. Si ese hash ya existe en el almacén, no se escribe nada: el índice del snapshot apunta al bloque que ya estaba. Como el nombre sale del contenido, dos bloques idénticos son literalmente el mismo fichero, y da igual que vengan de la copia de ayer, de otra máquina del clúster o de otro namespace.

Hay dos formas de trocear, según lo que se esté guardando:

El troceado variable es lo que salva la deduplicación en datos de ficheros. Si insertas un byte al principio de un fichero grande y los cortes fueran fijos, todos los bloques posteriores se desplazarían y ninguno coincidiría con los de ayer; con el hash rodante los límites se recolocan solos y el resto del fichero sigue deduplicando.

Cada bloque se comprime con zstd antes de escribirse, así que un chunk de 4 MiB casi nunca ocupa 4 MiB en disco. Y si activas el cifrado del lado cliente, se cifra con AES-256-GCM en el nodo de origen. Un detalle fino del diseño: en las copias cifradas el hash se calcula sobre el contenido en claro concatenado con la clave, y no sobre el resultado cifrado, que es lo que permite seguir deduplicando datos que el servidor no puede leer.

Namespaces: varios inquilinos, un solo almacén

Dentro de un datastore puedes crear namespaces, que son subdivisiones lógicas con permisos propios. Sirven para separar clústeres, clientes o entornos sin renunciar a la deduplicación, porque el almacén de bloques sigue siendo uno solo para todos. Es la pieza que hace viable el multi-tenant en un proveedor y también la que ordena una casa con producción y preproducción en el mismo sitio. Lo desarrollamos en varios clústeres en un solo datastore, incluida la parte incómoda: compartir almacén concentra el dominio de fallo y alarga las tareas de mantenimiento, que son del datastore entero.

Cuánto ocupa de verdad cada máquina

La pregunta llega siempre, sobre todo si repercutes el coste. Y la interfaz no la responde: te enseña el uso total del datastore y el tamaño provisionado de cada disco, dos cifras entre las que hay un agujero enorme. Con la deduplicación en marcha, «lo que ocupa la VM 100» no es un número único, porque hay bloques que sostienen a la vez la 100 y la 214. Lo que sí se puede calcular es cuánto suman en disco los bloques distintos que referencia un objeto, y para eso está la herramienta que analizamos en PBS_Chunk_Checker. Ojo con usar esas cifras para facturar sin más: sumadas se pasan, porque lo compartido aparece en la cuenta de todos.

Por qué la copia diaria tarda minutos

Con el formato claro, la velocidad se explica sola. Tras la primera copia, el cliente pregunta al servidor qué bloques ya tiene y solo sube los que faltan. Eso ya sería un incremental para siempre, aunque haya que leer el disco entero para saber qué ha cambiado.

En máquinas encendidas ni eso hace falta. QEMU mantiene un dirty bitmap con los bloques modificados desde la copia anterior, así que PVE lee únicamente esas zonas. De ahí salen las ventanas de minutos en discos de cientos de gigas.

Hay dos matices que conviene conocer antes de prometerle nada a nadie:

• El bitmap vive en el proceso de la VM. Si la máquina se apaga o se reinicia por completo, el bitmap se pierde y la siguiente copia vuelve a leer el disco entero. Sigue siendo incremental en lo que se transfiere —los bloques que ya están no se reenvían—, pero la lectura es completa y la ventana se alarga. Es normal, no es un fallo.
• Copiar en caliente compite con la carga. Cuando arranca la copia, QEMU instala un filtro copy-before-write: antes de que la máquina sobreescriba un bloque que aún no se ha copiado, hay que salvarlo. Si el destino va lento y la VM escribe mucho, la VM se resiente. Para eso está el fleecing, que aparca esos datos en una imagen local rápida en vez de mandarlos directamente al destino:

vzdump 123 --fleecing enabled=1,storage=local-lvm

El almacenamiento de fleecing debe ser local, rápido, de aprovisionamiento fino y con soporte de descarte (LVM-thin, RBD o ZFS). En bases de datos ocupadas es la diferencia entre una copia nocturna transparente y una llamada al día siguiente.

Para contenedores, la aceleración equivalente es el modo de detección de cambios. En el modo clásico se reescribe un pxar completo cada vez; en modo metadata el cliente compara los metadatos con la copia anterior y solo lee los ficheros que han cambiado:

vzdump 123 --storage pbs-local --pbs-change-detection-mode metadata

Acelera muchísimo los contenedores con muchos ficheros pequeños. La letra pequeña: el formato de archivo es otro, así que alternar entre modos en el mismo grupo rompe la cadena de comparación y empeora la deduplicación mientras convivan snapshots de los dos formatos. Elige uno y quédate con él.

Y un recordatorio que no depende de PBS: una copia consistente a nivel de bloque no garantiza una base de datos íntegra. Instala el guest agent para que congele el sistema de ficheros y, si hay motores de base de datos serios, añade su propio volcado. Lo tratamos aparte en backups consistentes de bases de datos.

Verificar: la tarea que casi nadie programa

Un snapshot que figura en la lista puede estar dañado. Los discos degradan bits en silencio, el hardware falla y el fichero sigue ahí, con su tamaño y su fecha, hasta el día que lo necesitas.

Los verify jobs releen los bloques, recalculan sus hashes y los comparan con los índices. Un snapshot verificado queda marcado como tal, y si algo no cuadra se marca como fallido, con la ventaja de que la siguiente copia volverá a subir los bloques dañados en vez de referenciar basura.

Opciones que merece la pena tocar:

• Saltar lo ya verificado y fijar un plazo de re-verificación, para que el trabajo diario no relea el datastore entero pero los snapshots antiguos vuelvan a pasar por el aro cada cierto tiempo. La documentación de Proxmox recomienda re-verificarlo todo al menos una vez al mes, aunque la comprobación anterior fuera bien, precisamente porque los soportes se degradan con el tiempo.
• read-threads y verify-threads, entre 1 y 32, con uno y cuatro por defecto. Subirlos acorta la tarea en cabinas con muchos husillos o en NVMe, y la deja inservible si te pasas en un servidor justo de CPU o de IOPS.

Programa la verificación fuera de la ventana de copia y fuera de la recolección de basura. Las tres tareas compiten por el mismo disco y ninguna mejora por adelantar a las otras.

Retención: prune decide, la recolección de basura libera

Aquí es donde más gente se confunde, y la confusión sale cara porque termina en «he borrado copias y el disco sigue lleno».

Son dos procesos distintos. El prune aplica la política de retención y elimina snapshots, o sea, listas de bloques. La recolección de basura recorre el datastore y borra los bloques a los que ya no apunta ningún snapshot vivo. Hasta que no corre la segunda, el espacio no vuelve.

Las reglas se combinan entre sí y se procesan en orden:

Una política de keep-last 3, keep-daily 14, keep-weekly 8 y keep-monthly 12 cubre de sobra a una pyme y, con la deduplicación trabajando, cuesta una fracción de lo que costaría en copias completas. La retención se puede definir en el propio storage de PVE, junto al resto de la configuración del datastore:

pbs: pbs-local
        server 10.20.0.30
        datastore tank
        content backup
        namespace produccion
        fingerprint aa:bb:cc:dd:...
        prune-backups keep-last=3,keep-daily=14,keep-weekly=8,keep-monthly=12

Elige un sitio y solo uno: si defines la retención en el storage de PVE y además en un prune job del PBS, acabarás con dos políticas peleándose por el mismo grupo y con snapshots desapareciendo antes de tiempo.

La recolección de basura trabaja en dos fases. Primero marca: recorre los índices de todos los snapshots vivos y refresca el tiempo de acceso de cada bloque referenciado. Después barre: recorre el almacén y borra los bloques cuyo tiempo de acceso sea anterior al corte, que está en 24 horas y 5 minutos antes del inicio de la tarea. Ese margen existe para no llevarse por delante bloques que una copia en curso acaba de escribir pero todavía no ha indexado.

Dos consecuencias prácticas. Una, el espacio no aparece justo después de podar; si acabas de borrar mucho, lanza la recolección y espera. Y dos, la fase de marcado es intensiva en operaciones de metadatos sobre millones de ficheros pequeños, que es exactamente lo que un disco mecánico peor lleva. Vuelve más abajo, en el dimensionado, porque no es un detalle menor.

Sacar la copia de casa

Una copia que vive en el mismo edificio que la infraestructura que protege no sobrevive a un incendio, ni a una inundación, ni a un ransomware que se pasee por la red local con credenciales de administrador. Para eso existe la regla 3-2-1, y la segunda ubicación es su parte cara y la que más se pospone.

PBS la resuelve con sync jobs, trabajos que replican snapshots entre datastores de dos servidores. Van en dos sentidos:

• Pull: el servidor remoto tira de los datos del origen. Es el que recomendamos por defecto, porque el destino no necesita quedar expuesto y el origen comprometido no tiene credenciales de escritura sobre la copia buena.
• Push: el origen empuja hacia el remoto. Útil cuando el destino no puede alcanzar al origen por red, con la contrapartida de que el origen sí guarda credenciales del destino. Desde la 4.2 los snapshots se pueden cifrar al vuelo en el propio push, lo que quita hierro a mandar datos a un destino que no controlas del todo.

Solo viajan los bloques que faltan en destino, así que replicar el incremental diario de una flota entera cabe en un enlace normal. Y desde la 4.2, un sync job procesa varios grupos en paralelo con worker-threads, que es lo que de verdad aprovecha un enlace con latencia alta donde antes el trabajo iba de grupo en grupo dejando el ancho de banda sin usar.

A partir de ahí, la tercera copia admite formatos distintos:

• Almacenamiento de objetos compatible con S3 como backend del datastore. Dejó de ser vista previa en la 4.2 y ahora está soportado oficialmente, con contadores de peticiones y tráfico en el resumen del datastore para que la factura no sea una sorpresa. Necesita una cache local persistente, así que reserva disco rápido para ella. Lo detallamos en backups offsite a S3 con sync paralelo.
• Cinta, con pools de medios, catálogo y cifrado gestionado por el propio PBS. Sigue siendo la respuesta más barata a «guárdame esto siete años» y la única que se desconecta del todo.
• Datastores extraíbles, para quien quiere un aislamiento físico sin montar una biblioteca de cintas: se conecta el disco, se sincroniza, se desconecta y se guarda bajo llave.

Y el cifrado del lado cliente es lo que hace cómodo todo lo anterior. Los datos salen cifrados del nodo con una clave que solo tienes tú, y el servidor de destino guarda algo que no puede abrir aunque alguien se lleve el disco físico. Enlaza con la lógica del cifrado en reposo: el dato viaja y reposa cifrado. La contrapartida es implacable, si pierdes la clave pierdes las copias, así que imprime la paper key que genera el cliente y guárdala fuera del entorno que estás protegiendo. Una clave custodiada dentro del clúster que se ha quemado no es una clave.

Restaurar: tres caminos y una prueba

La copia solo vale por lo que se puede recuperar de ella, y aquí es donde la integración con el hipervisor se nota.

Restauración completa. La clásica: eliges el snapshot y la máquina vuelve, al mismo nodo o a otro, al mismo almacenamiento o a otro. El tiempo depende de lo que haya que mover.

Live-restore. La VM arranca en cuanto empieza la restauración y sus discos se van rellenando por detrás mientras ya está dando servicio:

qmrestore pbs-local:backup/vm/123/2026-09-15T22:00:00Z 123 --live-restore

Durante ese rato el rendimiento de lectura es peor, porque cada bloque que aún no ha llegado hay que ir a buscarlo al servidor de copias. A cambio, el servicio vuelve en segundos en lugar de en una hora. Un aviso que la documentación no esconde: si la restauración falla a media faena, la máquina se queda en un estado indefinido y hay que empezar de cero. Es una herramienta para recuperar servicio rápido, no para ahorrarse la restauración ordenada.

Recuperación de ficheros sueltos. El botón File Restore abre un navegador dentro de la copia y permite bajarse un fichero o un directorio comprimido sin tocar la máquina. En contenedores lee el pxar directamente; en máquinas virtuales arranca una VM mínima temporal para montar la imagen de disco de forma aislada, que es la manera limpia de leer un sistema de ficheros ajeno sin exponer el host. Resuelve la mayoría de los incidentes reales, que casi nunca son desastres y casi siempre son alguien que ha borrado la carpeta equivocada.

Fuera de PVE, proxmox-backup-client protege también hosts Linux físicos a nivel de ficheros contra el mismo datastore, con la misma deduplicación y el mismo cifrado:

proxmox-backup-client backup root.pxar:/ \
  --repository copias@[email protected]:tank \
  --ns produccion

Y queda lo que ninguna función del producto hace por ti: restaurar de verdad, de vez en cuando, en un entorno aparte. La verificación te dice que los bloques están sanos. Solo un simulacro te dice que la máquina arranca, que el servicio levanta y que el procedimiento está escrito con la claridad suficiente para ejecutarlo un domingo a las tres de la mañana. Es la misma disciplina que sostiene cualquier objetivo de RTO y RPO que hayas firmado.

Dimensionar el servidor de copias

PBS se instala en veinte minutos y ahí es donde mucha gente da por terminada la arquitectura. Lo que decide si el sistema aguanta a los dos años es otra cosa.

Hardware separado, siempre. El servidor de copias no va como máquina virtual dentro del clúster que protege, ni su datastore se apoya en el almacenamiento de ese clúster. Si comparten destino, el fallo que te obliga a restaurar es el mismo que se lleva las copias por delante. Es la regla que más veces vemos incumplida y la que peor envejece.

Los metadatos mandan. Un datastore es un almacén con decenas de miles de directorios y millones de ficheros pequeños. Las copias y las restauraciones son secuenciales y perdonan un disco mecánico; la verificación y sobre todo la fase de marcado de la recolección de basura son otra historia, porque recorren metadatos a lo bestia. Con discos grandes y lentos, una recolección puede pasar de minutos a la noche entera.

ZFS con la cabeza. Es el sistema de ficheros natural aquí: suma de comprobación de todo lo escrito, scrub periódico y RAID-Z o espejos según lo que priorices. Dos consejos con nombre y apellidos. Uno, un special vdev en NVMe para los metadatos cambia por completo el comportamiento de la recolección de basura y de la verificación; lo explicamos en tiering en ZFS. Y dos, no actives la deduplicación de ZFS: PBS ya deduplica antes de escribir, así que solo pagarías la tabla de dedup en RAM sin ganar nada. La comparación completa está en deduplicación y compresión en ZFS.

Red y RAM. 10 GbE entre el clúster y el servidor de copias deja de ser un capricho en cuanto tienes que restaurar algo grande con prisa. De RAM, lo que pida ZFS para su ARC más margen; PBS en sí no es un devorador de memoria, el ARC sí.

Y la configuración del clúster también se copia. Un datastore lleno de VMs no te devuelve la definición de la red SDN, ni el firewall, ni los usuarios. Merece la pena guardar aparte la configuración de PVE y del propio PBS, que es de lo que va ProxSave.

Lo que revisamos antes de dar por buena una plataforma

Nuestra lista corta, en el orden en que la recorremos:

1. El servidor de copias está fuera del clúster que protege, con su propio almacenamiento y su propia alimentación.
2. Hay una segunda ubicación con un sync job en modo pull, y la política de retención del destino es al menos tan larga como la del origen.
3. La verificación está programada, con re-verificación mensual de lo antiguo, y alguien recibe el aviso cuando falla. Un trabajo que falla en silencio no existe.
4. Prune y recolección de basura están programados, en horarios distintos, y la política vive en un solo sitio.
5. El cifrado del lado cliente está activo para todo lo que salga de la infraestructura, y la clave, con su copia impresa, está fuera del entorno protegido.
6. La huella del certificado del servidor está anotada en el storage de PVE, para que un cambio inesperado dé error en vez de conectarse a cualquier cosa.
7. Las cuentas de los sync jobs tienen permisos mínimos, de lectura en origen y sin capacidad de borrar en destino.
8. Hay un simulacro de restauración con fecha en el calendario, no una intención.

Ninguno de los ocho puntos exige comprar nada. Exigen decidir, escribirlo y revisarlo cada cierto tiempo.

Errores que vemos una y otra vez

• El datastore sobre el mismo almacenamiento del clúster. Ahorra un servidor y anula el propósito entero.
• Retención definida por duplicado, en el storage de PVE y en un prune job, con el consiguiente «faltan snapshots y nadie los ha borrado».
• Recolección de basura sin programar. El disco se llena, alguien poda a lo bruto, el disco sigue lleno y empieza el nerviosismo.
• Verificación desactivada porque «tarda mucho». Tarda mucho porque el datastore está sobre discos lentos sin special vdev; el problema es ese, no la verificación.
• La clave de cifrado guardada dentro del clúster protegido, que es como dejar la llave de la caja fuerte dentro de la caja fuerte.
• Ningún simulacro de restauración. El día del incidente se descubre que el procedimiento estaba en la cabeza de quien está de vacaciones.
• Alertas apagadas tras una racha de falsos positivos, que es la forma más silenciosa de quedarse sin copias durante meses.

PBS o Veeam

La comparación es inevitable y la respuesta honesta depende del perímetro, no de cuál sea mejor producto.

Si tu entorno es Proxmox de arriba abajo, PBS es difícil de discutir: lo hace el mismo equipo que el hipervisor, aprovecha información que solo tiene QEMU y cubre los contenedores, que en una casa Proxmox suelen ser la mitad del inventario. Si arrastras un parque mixto, con hipervisores de otro fabricante conviviendo con Proxmox y servidores físicos que también hay que proteger, tener una única consola y un único contrato tiene un valor operativo real, y ahí Veeam sigue siendo la plataforma más completa. Es además una opción sensata durante una migración a Proxmox, cuando durante meses conviven las dos plataformas.

La decisión no tiene por qué ser excluyente. Hay casas donde PBS lleva el día a día de Proxmox y una plataforma comercial cubre lo que queda fuera, y funciona bien mientras alguien tenga claro qué protege cada cosa y ninguna carga se quede en tierra de nadie.

Preguntas frecuentes

¿Puedo instalar PBS en el mismo nodo que Proxmox VE? Técnicamente se puede, y para un laboratorio vale. En producción no: si ese nodo se pierde, se van las máquinas y sus copias a la vez. Servidor aparte y, además, una réplica en otra ubicación.

¿Cuánto espacio me va a ahorrar la deduplicación? Depende de lo parecidas que sean tus cargas y de cuánto cambien a diario, así que cualquier cifra genérica es humo. La propia interfaz de PBS muestra el factor de deduplicación del datastore en cuanto llevas unas semanas de copias, y esa es la única cifra que sirve para dimensionar la tuya. Lo que sí es seguro es la forma de la curva: el primer snapshot cuesta caro y los siguientes cuestan poco, así que alargar la retención es mucho más barato de lo que la aritmética ingenua dice.

¿Por qué no baja el espacio libre después de podar? Porque podar solo elimina snapshots, no bloques. El espacio lo libera la recolección de basura, que borra los bloques que ya no referencia nadie y respeta un margen de 24 horas y 5 minutos para no tocar lo que una copia en curso acaba de escribir.

Si borro un backup antiguo, ¿se estropean los siguientes? No. Cada snapshot lleva su propia lista completa de bloques, así que no hay cadenas frágiles como en los incrementales clásicos. Borrar el de hace tres meses no invalida el de anoche; simplemente, los bloques que solo usaba aquel quedan huérfanos y desaparecen en la siguiente recolección.

¿Es seguro guardar mis copias en infraestructura que no controlo? Con el cifrado del lado cliente, sí: los datos se cifran en tu nodo antes de salir y el servidor guarda algo que no puede leer. La condición es que la clave y su copia impresa vivan fuera del entorno protegido, porque sin ella no hay recuperación posible para nadie, tú incluido.

¿Cada cuánto debería verificar y restaurar de prueba? Verificación continua sobre lo nuevo y un repaso completo mensual de lo antiguo, que es lo que recomienda Proxmox. Simulacro de restauración, al menos trimestral, y siempre después de un cambio gordo en la plataforma. Alterna: un trimestre una máquina entera, el siguiente una recuperación de ficheros sueltos.

¿PBS sustituye a Veeam? En un entorno Proxmox puro, es la opción nativa y la más eficiente, y además cubre los contenedores LXC que el plug-in de Veeam para Proxmox VE deja fuera. En un parque mixto con otros hipervisores y servidores físicos, una consola única sigue teniendo sentido. Son perímetros distintos más que competidores directos.

Fuentes

• Technical Overview — Proxmox Backup Server (chunks fijos de 4 MiB, troceado dinámico con Buzhash, índices .fidx y .didx, hash de los bloques cifrados).
• Maintenance Tasks — Proxmox Backup Server (verify jobs con read-threads y verify-threads, opciones keep-*, fases de marcado y barrido y margen de 24 h 5 min).
• Managing Remotes — Proxmox Backup Server (remotes y sync jobs en modo pull y push).
• Encryption — Proxmox Backup Server (cifrado del lado cliente con AES-256-GCM y paper key).
• Roadmap — Proxmox Backup Server (4.2 del 29 de abril de 2026: backend S3 con soporte oficial, cifrado en sync jobs push y procesado concurrente de grupos).
• Backup and Restore — Proxmox VE (modos de copia, fleecing, --live-restore, recuperación de ficheros y --pbs-change-detection-mode).
• Considerations and Limitations — Veeam Plug-in for Proxmox VE (sin soporte de contenedores LXC, plantillas, clones enlazados ni discos iSCSI o en passthrough).

---

¿Tienes Proxmox en producción y la copia es lo único que nadie ha revisado a fondo? Diseñamos la estrategia entera —datastore dimensionado, retención, verificación, réplica fuera de sitio y simulacros— sobre infraestructura en España. Echa un vistazo a nuestra página de Proxmox Backup Server y a la de continuidad y recuperación, o cuéntanos cómo está montado y te decimos qué cambiaríamos.