Proxmox Backup Server: respaldo y recuperación para virtualización empresarial

Una infraestructura de virtualización puede tener excelentes servidores, alta disponibilidad, almacenamiento redundante y networking empresarial.

Pero todavía falta responder una pregunta fundamental:

¿qué ocurre cuando necesitamos recuperar información que ya se perdió, borró o corrompió?

High Availability puede ayudarnos ante la falla de un host.

Ceph puede proporcionar redundancia en la capa de almacenamiento.

Los snapshots pueden ayudarnos en determinados cambios operativos.

Pero ninguno de estos elementos sustituye una estrategia de respaldo.

Dentro del ecosistema Proxmox existe una plataforma diseñada específicamente para este propósito:

Proxmox Backup Server o PBS.

PBS permite proteger máquinas virtuales, contenedores y determinados sistemas físicos utilizando mecanismos como:

  • Backups incrementales
  • Deduplicación
  • Compresión
  • Verificación de integridad
  • Cifrado
  • Políticas de retención
  • Sincronización hacia otros repositorios
  • Restauración de máquinas y archivos

En esta guía de la Biblioteca Virtual Sistro 2.0 explicamos cómo funciona Proxmox Backup Server, qué problema resuelve y cómo debería integrarse dentro de una arquitectura empresarial de virtualización.

Conoce las soluciones de Virtualización Empresarial de Sistro

¿Qué es Proxmox Backup Server?

Proxmox Backup Server es la plataforma especializada de Proxmox para respaldo y recuperación.

Está diseñada para trabajar especialmente bien con Proxmox VE y permite respaldar:

  • Máquinas virtuales KVM
  • Contenedores LXC
  • Hosts físicos mediante Proxmox Backup Client

Se administra desde una interfaz web independiente y utiliza repositorios denominados Datastores para almacenar los respaldos.

Consulta soluciones Proxmox VE en Sistro

Proxmox VE y Proxmox Backup Server son plataformas diferentes

Este punto es importante.

Proxmox VE ejecuta las máquinas virtuales y contenedores.

Proxmox Backup Server protege esas cargas.

Podemos visualizarlo así:

Cluster Proxmox VE
↓
Red de Backup
↓
Proxmox Backup Server
↓
Datastore de respaldo

Separar virtualización y respaldo ayuda a evitar que la misma falla afecte simultáneamente a producción y a sus copias de seguridad.

¿Por qué no utilizar solamente los backups integrados de Proxmox VE?

Proxmox VE dispone de mecanismos de backup.

Sin embargo, Proxmox Backup Server agrega capacidades especializadas para administrar una infraestructura de respaldo de manera más eficiente.

Entre ellas destacan:

  • Deduplicación global
  • Transferencia incremental
  • Compresión
  • Verificación programada
  • Pruning
  • Garbage Collection
  • Sincronización entre servidores PBS
  • Cifrado
  • Restauración granular
  • Administración centralizada

¿Cómo funcionan los backups incrementales?

Una primera ejecución necesita transferir la información necesaria para construir el respaldo inicial.

Después, las siguientes ejecuciones pueden transmitir únicamente bloques nuevos o modificados.

Esto reduce:

  • Tráfico de red
  • Tiempo de respaldo
  • Uso de almacenamiento
  • Carga sobre la infraestructura

Pero existe una característica importante.

Aunque los datos se transfieren incrementalmente, cada snapshot de backup puede representar lógicamente un punto completo de restauración.

Esto permite seleccionar directamente el punto que queremos recuperar sin pensar en una cadena tradicional de archivos full + incremental como ocurre en otras arquitecturas.

¿Qué es deduplicación?

La deduplicación evita almacenar repetidamente los mismos bloques de información.

Imaginemos veinte máquinas virtuales Windows.

Muchas pueden contener grandes cantidades de información idéntica:

  • Archivos del sistema operativo
  • Librerías
  • Aplicaciones
  • Datos repetidos

Proxmox Backup Server divide los datos en chunks y puede reutilizar bloques idénticos que ya se encuentran almacenados.

Esto puede reducir considerablemente el espacio necesario cuando existen múltiples VMs con contenido similar.

Deduplicación no significa una relación fija de ahorro

No deberíamos prometer algo como:

“10 TB se convertirán en 2 TB”.

La eficiencia depende completamente de los datos.

Un ambiente con múltiples sistemas operativos similares puede deduplicar muy bien.

Un repositorio compuesto por:

  • Video
  • Archivos ya comprimidos
  • Información cifrada
  • Datos únicos

puede obtener menos ahorro.

Por eso el datastore debe dimensionarse utilizando capacidad real, crecimiento y retención.

Compresión

PBS también puede comprimir la información para optimizar almacenamiento y transferencia.

La combinación de:

Incremental + Deduplicación + Compresión

es una de las principales razones por las que Proxmox Backup Server puede utilizar el almacenamiento de manera eficiente.

¿Qué es un Datastore?

Un Datastore es el repositorio lógico donde PBS almacena los backups.

Dentro de él podemos encontrar snapshots correspondientes a:

  • VMs
  • Contenedores
  • Hosts

La arquitectura física que sostiene al datastore debe diseñarse de acuerdo con el proyecto.

Por ejemplo:

  • Discos locales
  • ZFS
  • Storage dedicado
  • Repositorios diseñados específicamente para backup

No dimensionemos PBS solamente por capacidad

Supongamos que actualmente existen 10 TB de máquinas virtuales.

No podemos concluir automáticamente:

“Necesitamos un PBS de 10 TB”.

También debemos conocer:

  • Cantidad diaria de cambios
  • Retención
  • Crecimiento
  • Número de VMs
  • Frecuencia de respaldo
  • Deduplicación esperada
  • Compresión
  • Ventanas de backup
  • Velocidad de restauración requerida

Retención: ¿cuántos backups necesito conservar?

Proxmox Backup Server permite construir políticas de retención mediante criterios como:

  • Últimos backups
  • Horarios
  • Diarios
  • Semanales
  • Mensuales
  • Anuales

Esto permite construir políticas adaptadas a las necesidades de la empresa.

Ejemplo de política de retención

Una empresa podría decidir conservar:

  • Las últimas ejecuciones recientes
  • Backups diarios
  • Backups semanales
  • Backups mensuales
  • Determinados respaldos anuales

No existe una política universal.

La retención debe responder a:

riesgo + regulación + RPO + RTO + capacidad + negocio.

¿Qué es Prune?

Prune aplica las reglas de retención y determina qué snapshots ya no deben conservarse.

Pero eliminar la referencia a un backup no significa necesariamente que todos sus bloques se eliminen inmediatamente.

Algunos chunks todavía pueden ser utilizados por otros snapshots.

¿Qué es Garbage Collection?

Garbage Collection identifica información almacenada que ya no está siendo utilizada por snapshots válidos y permite liberar ese espacio.

Por eso Prune y Garbage Collection cumplen funciones relacionadas pero diferentes.

Una política de backup empresarial debe programar y monitorear ambos procesos.

Un job exitoso no significa automáticamente un backup sano

Este es uno de los errores más comunes en cualquier plataforma de respaldo.

El dashboard puede indicar:

Backup completed successfully.

Pero todavía debemos preguntarnos:

¿los datos almacenados continúan íntegros?

Verification Jobs

PBS dispone de mecanismos de verificación que utilizan checksums para comprobar la integridad de los datos almacenados.

Estas verificaciones pueden programarse.

El objetivo es identificar problemas antes del día en que realmente necesitemos restaurar.

Backup sin prueba de restauración es solamente una esperanza

La verificación de bloques es muy importante.

Pero una estrategia empresarial debería ir todavía más lejos.

Debemos realizar periódicamente pruebas como:

  • Restaurar una VM completa
  • Restaurar un archivo
  • Arrancar la VM recuperada
  • Comprobar aplicaciones
  • Validar bases de datos
  • Medir tiempo de recuperación

Esto nos permite comprobar si el RTO esperado es realista.

¿Qué es RPO?

Recovery Point Objective responde:

¿cuánta información podemos permitirnos perder?

Si hacemos backup una vez cada 24 horas, podemos perder hasta aproximadamente un día de cambios dependiendo del momento de la falla.

Si una aplicación necesita un RPO mucho menor debemos aumentar la frecuencia o diseñar mecanismos adicionales.

¿Qué es RTO?

Recovery Time Objective responde:

¿cuánto tiempo puede permanecer detenido el servicio?

Tener backup no garantiza un RTO de cinco minutos.

El tiempo de recuperación depende de:

  • Tamaño de la VM
  • Storage del PBS
  • Red
  • Storage destino
  • Número de restauraciones simultáneas
  • Aplicación
  • Procedimiento operativo

RPO y RTO deben definirse antes de comprar hardware

Esta conversación cambia completamente el diseño.

No es lo mismo proteger:

10 VMs pequeñas que pueden recuperarse durante todo el día

que:

50 VMs donde el ERP debe recuperarse en menos de una hora.

Restauración de máquinas virtuales

PBS puede utilizarse para restaurar una VM completa después de diferentes escenarios.

Por ejemplo:

  • Eliminación accidental
  • Corrupción
  • Error de actualización
  • Falla de almacenamiento
  • Problema del sistema operativo
  • Incidente de seguridad

El objetivo es regresar a un punto conocido y validado.

Restauración granular

No siempre necesitamos recuperar toda una máquina.

En muchos escenarios únicamente necesitamos un archivo o directorio.

La recuperación granular puede reducir enormemente el tiempo operativo cuando la pérdida es pequeña.

No tendría sentido restaurar una VM completa de varios terabytes solamente para recuperar un documento eliminado.

Encryption: proteger también el repositorio

PBS utiliza TLS para proteger las transferencias y permite además utilizar cifrado del lado del cliente.

Esto puede ser especialmente interesante cuando los respaldos se almacenan o sincronizan hacia infraestructura que no queremos considerar completamente confiable.

El cifrado adicional debe configurarse expresamente y las llaves deben protegerse correctamente.

Una llave de cifrado perdida puede convertirse en un problema de recuperación.

La llave también forma parte del plan de Disaster Recovery

No basta con proteger los backups.

Debemos proteger:

  • Llaves de cifrado
  • Credenciales
  • Documentación
  • Procedimientos
  • Accesos administrativos

Una copia perfectamente cifrada pero sin la llave necesaria para recuperarla puede resultar inútil.

Proxmox Backup Server y ransomware

Una estrategia contra ransomware no debería depender de una sola herramienta.

PBS incorpora características que ayudan a limitar determinados riesgos.

Por ejemplo, los bloques existentes almacenados no se reescriben simplemente porque un cliente comprometido envíe un nuevo backup.

Pero eso no significa que instalar PBS por sí solo nos haga inmunes al ransomware.

Seguimos necesitando:

  • Separación de credenciales
  • Permisos mínimos
  • Redes de administración
  • Backups remotos
  • Copias externas
  • Monitoreo
  • MFA donde corresponda
  • Pruebas de recuperación
  • Segmentación

El PBS no debería compartir todas las credenciales con producción

Si un atacante obtiene privilegios administrativos sobre toda la infraestructura y además puede administrar el sistema de backup, el riesgo aumenta considerablemente.

Por eso recomendamos tratar al repositorio de respaldo como una infraestructura de seguridad.

No solamente como:

otro servidor más.

¿Dónde instalar Proxmox Backup Server?

Existen diferentes posibilidades.

Pero para una infraestructura productiva crítica debemos analizar cuidadosamente si queremos que producción y backup compartan exactamente el mismo hardware y storage.

Una arquitectura más clara puede utilizar:

Cluster Proxmox VE
↓
Red de backup
↓
Servidor PBS dedicado

Esto separa los dominios de falla.

¿Puedo virtualizar PBS?

Técnicamente existen escenarios donde PBS puede ejecutarse como máquina virtual.

Pero debemos analizar la dependencia que creamos.

Si PBS vive dentro del mismo cluster y almacenamiento que debe proteger, una falla completa de esa infraestructura puede dejar temporalmente inaccesible tanto producción como el servidor de backup.

Por eso, para ambientes importantes, solemos preferir revisar una plataforma de respaldo con mayor independencia física o lógica.

Ceph no sustituye PBS

Este punto conecta directamente con nuestro artículo anterior.

Ceph replica información para mantener disponible el almacenamiento.

Si eliminamos una VM correctamente desde la plataforma, Ceph puede replicar perfectamente esa eliminación.

Si una aplicación corrompe sus datos, la redundancia de almacenamiento no recupera automáticamente el estado anterior.

Por eso:

Redundancia ≠ Backup.

Consulta Proxmox + Ceph: cuándo conviene una infraestructura HCI

High Availability tampoco sustituye PBS

HA intenta recuperar una carga cuando falla un nodo.

Pero si la VM fue eliminada o sus datos están dañados, reiniciarla en otro nodo no resuelve el problema.

Por eso:

Disponibilidad ≠ Protección de datos.

Consulta Proxmox cluster de 3 nodos: hardware, quorum y HA

Snapshots tampoco sustituyen el backup

Un snapshot puede ser muy útil antes de:

  • Actualizar una aplicación
  • Cambiar configuración
  • Realizar mantenimiento
  • Instalar software

Pero si el snapshot permanece en el mismo almacenamiento que la VM, comparte gran parte del mismo dominio de falla.

Un problema grave en el storage puede afectar a ambos.

Un backup debe formar parte de una estrategia separada de protección.

Proxmox Backup Server remoto

PBS permite sincronizar Datastores entre diferentes servidores.

Esto permite construir arquitecturas como:

Site principal
PBS 1
↓
Site secundario
PBS 2

Los Sync Jobs pueden copiar los puntos de restauración entre ubicaciones.

Así una falla física completa del sitio principal no necesariamente destruye todas las copias disponibles.

Backup local + backup remoto

Una arquitectura empresarial puede considerar:

Primera copia → PBS local

Segunda copia → PBS remoto

Tercera capa → otro medio o ubicación según criticidad

La arquitectura debe diseñarse de acuerdo con riesgo y presupuesto.

La regla 3-2-1

Una estrategia ampliamente utilizada consiste en pensar en:

3 copias de los datos

2 tipos o ubicaciones de almacenamiento

1 copia fuera del sitio principal

PBS dispone de mecanismos de sincronización y también soporta estrategias con medios adicionales como tape para ayudar a construir arquitecturas de este tipo.

Tape sigue teniendo utilidad

Aunque parezca una tecnología antigua, las cintas siguen utilizándose en determinadas infraestructuras empresariales para:

  • Retención de largo plazo
  • Archivo
  • Segunda clase de medio
  • Copias transportables
  • Almacenamiento fuera del sitio

Proxmox Backup Server dispone de soporte para infraestructura de tape compatible.

La restauración desde cinta puede ser considerablemente más lenta que desde disco, por lo que debe utilizarse de acuerdo con el RTO requerido.

Sync no debe confundirse con backup independiente sin analizar permisos

Copiar respaldos hacia otro PBS es muy útil.

Pero debemos revisar:

  • Dirección de sincronización
  • Credenciales
  • Permisos
  • Retención
  • Eliminaciones
  • Cifrado
  • Conectividad

La arquitectura de seguridad del segundo repositorio es tan importante como la sincronización misma.

Una segunda copia debe tener su propia política de retención

Copiar automáticamente todo y aplicar exactamente las mismas reglas de eliminación en ambos lugares puede reducir nuestra protección ante determinados errores humanos.

Debemos decidir qué queremos conservar localmente y qué queremos mantener durante más tiempo en el repositorio remoto.

Proxmox Backup Server y Veeam

Migrar a Proxmox no obliga automáticamente a abandonar cualquier estrategia de respaldo existente.

Si una empresa ya utiliza Veeam debemos analizar:

  • Compatibilidad
  • Licenciamiento
  • Procesos actuales
  • RPO
  • RTO
  • Retención
  • Experiencia operativa
  • Inversiones existentes

Puede haber proyectos donde PBS sea la solución principal.

Otros pueden conservar Veeam.

Y algunos pueden utilizar diferentes herramientas para necesidades diferentes.

Consulta nuestro servicio de Migración a Proxmox VE

Ejemplo 1: pequeña empresa con cinco VMs

Supongamos:

  • 5 VMs
  • 1 servidor Proxmox
  • ERP
  • Active Directory
  • Servidor de archivos

Incluso sin cluster HA, PBS puede aportar muchísimo valor.

De hecho, para una empresa pequeña puede ser más importante contar primero con un backup realmente probado que invertir inmediatamente en alta disponibilidad.

Ejemplo 2: cluster Proxmox de tres nodos

Tenemos:

  • 3 nodos
  • 25 VMs
  • HA
  • Storage compartido
  • Aplicaciones productivas

Aquí PBS debe diseñarse como una capa independiente.

HA protege disponibilidad.

PBS protege puntos anteriores de los datos.

Ejemplo 3: Proxmox + Ceph

Tenemos un cluster hiperconvergente con storage distribuido.

Ceph proporciona redundancia.

PBS puede almacenar copias históricas fuera del cluster.

La arquitectura puede ser:

Proxmox + Ceph
↓
PBS físico independiente
↓
PBS remoto

Ahora estamos separando disponibilidad, protección y recuperación de sitio.

Ejemplo 4: empresa migrando desde VMware

Supongamos:

  • VMware vSphere
  • 50 VMs
  • Veeam
  • SAN
  • 3 hosts

La migración hacia Proxmox no debería eliminar el sistema de backup antes de que exista una estrategia destino validada.

Podemos evaluar PBS y, cuando corresponda, conservar tecnologías existentes durante la transición.

Consulta nuestro checklist antes de migrar VMware a Proxmox

Ejemplo 5: empresa con segundo sitio

Una organización dispone de:

  • Data center principal
  • Oficina secundaria
  • Conectividad entre ambos

Podemos evaluar un PBS en cada ubicación y sincronizar respaldos de acuerdo con las políticas de recuperación.

El ancho de banda entre sedes y la ventana disponible deben formar parte del dimensionamiento.

El networking también importa en backup

Un backup de varias decenas de terabytes no debe diseñarse utilizando únicamente la capacidad de los discos.

También debemos evaluar:

  • 1 GbE
  • 10 GbE
  • 25 GbE
  • Ventanas de respaldo
  • Restauraciones
  • Sincronización remota
  • Contención con tráfico productivo

El requisito más exigente puede no ser el backup diario.

Puede ser tener que restaurar varias VMs rápidamente durante una contingencia.

Diseña la red pensando también en restore

Supongamos un PBS capaz de leer a varios gigabytes por segundo.

Si está conectado mediante una interfaz de 1 GbE, la red puede convertirse en el límite de restauración.

Por eso el RTO afecta también el diseño de networking.

¿SSD, HDD o NVMe para PBS?

No existe una respuesta universal.

La decisión depende de:

  • Capacidad
  • Número de VMs
  • Frecuencia
  • Ventana de respaldo
  • RTO
  • Concurrencia
  • Presupuesto

Un repositorio masivo de largo plazo puede tener necesidades distintas de un PBS que debe restaurar máquinas críticas a gran velocidad.

ZFS en Proxmox Backup Server

PBS puede utilizar ZFS como parte de determinadas arquitecturas de almacenamiento.

Esto permite aprovechar funciones de integridad y administración de discos de ZFS.

Pero ZFS tampoco elimina la necesidad de una segunda copia.

El mejor filesystem no transforma un único servidor en una estrategia completa de Disaster Recovery.

Monitorización de PBS

Un servidor de backup necesita supervisión continua.

No basta con instalarlo y asumir que seguirá funcionando.

Debemos revisar:

  • Jobs fallidos
  • Capacidad disponible
  • Errores de disco
  • Prune
  • Garbage Collection
  • Verification Jobs
  • Sync Jobs
  • Alertas
  • Tiempos de backup
  • Tiempos de restauración

Consulta nuestro servicio de Soporte Administrado Proxmox VE

Errores comunes con Proxmox Backup Server

1. Instalar PBS y nunca probar una restauración

Un backup debe demostrarse mediante recuperación.

2. Guardar todo en el mismo storage de producción

Compartimos el mismo dominio de falla.

3. Confundir Ceph con backup

Replicación y respaldo resuelven problemas distintos.

4. Confundir snapshots con backup

Un snapshot local no proporciona necesariamente independencia ante una falla del storage.

5. Llenar el datastore casi al 100%

Necesitamos capacidad para crecimiento y operación.

6. No ejecutar Verification Jobs

La integridad debe comprobarse periódicamente.

7. No monitorear Prune y Garbage Collection

La retención y recuperación de espacio deben mantenerse.

8. Utilizar las mismas credenciales administrativas en todas partes

La plataforma de backup merece aislamiento.

9. No tener copia remota

Una falla física del sitio puede afectar la única copia disponible.

10. Diseñar solamente la velocidad de backup

La velocidad de restauración puede ser todavía más importante.

Checklist antes de implementar PBS

  • Número de hosts Proxmox
  • Número de VMs y contenedores
  • Capacidad utilizada
  • Cambio diario de datos
  • Crecimiento
  • RPO
  • RTO
  • Frecuencia de backup
  • Retención
  • Velocidad de red
  • Storage del repositorio
  • Deduplicación esperada
  • Necesidad de cifrado
  • Segundo sitio
  • Sync Jobs
  • Pruebas de restore
  • Monitoreo
  • Protección frente a ransomware
  • Política 3-2-1
  • Responsable operativo

Preguntas que Sistro debería hacer antes de diseñar el backup

  1. ¿Cuántas máquinas virtuales necesitas proteger?
  2. ¿Cuántos TB utilizas actualmente?
  3. ¿Cuánto crecen tus datos cada mes?
  4. ¿Cada cuánto necesitas un punto de recuperación?
  5. ¿Cuánto tiempo puede estar detenida cada aplicación?
  6. ¿Qué VMs son críticas?
  7. ¿Necesitas recuperación granular?
  8. ¿Existe un segundo sitio?
  9. ¿Qué ancho de banda existe entre sedes?
  10. ¿Ya utilizas Veeam u otra plataforma?
  11. ¿Qué retención necesitas?
  12. ¿Necesitas cifrado?
  13. ¿Cómo protegerás las credenciales y llaves?
  14. ¿Quién comprobará diariamente los jobs?
  15. ¿Cuándo fue tu última prueba real de restauración?

Después podemos dimensionar correctamente servidores, discos, red, retención y repositorios.

Arquitectura empresarial recomendada como punto de partida

Una infraestructura puede evolucionar hacia:

Cluster Proxmox VE
↓
Storage SAN / ZFS / Ceph
↓
PBS local independiente
↓
PBS remoto o segunda copia
↓
Pruebas periódicas de recuperación

El diseño exacto dependerá del proyecto.

Servicios Proxmox en Sistro

Virtualización Empresarial
https://sistro.net/virtualizacion

Soluciones Proxmox VE
https://sistro.net/proxmox

Instalación y Configuración Proxmox VE
https://sistro.net/proxmox/instalacion-proxmox-ve

Migración a Proxmox VE
https://sistro.net/proxmox/migracion-proxmox-ve

Soporte Administrado Proxmox VE
https://sistro.net/proxmox/soporte-administrado-proxmox-ve

Artículos relacionados de Biblioteca Virtual Sistro 2.0

Proxmox cluster de 3 nodos: hardware, quorum y HA

Proxmox + Ceph: cuándo conviene una infraestructura HCI

Migrar VMware a Proxmox: checklist antes de la primera VM

Recomendación final

Proxmox Backup Server es una pieza muy importante para transformar una plataforma Proxmox en una infraestructura empresarial realmente protegida.

Pero instalar PBS no es suficiente.

Una estrategia correcta necesita combinar:

Backup + Retención + Verificación + Restore + Copia remota + Seguridad + Monitoreo.

También debemos separar claramente cuatro conceptos:

HA mantiene servicios disponibles

Ceph mantiene redundancia de almacenamiento

Snapshots facilitan determinados puntos operativos

Backup permite recuperar estados anteriores de la información

Son tecnologías complementarias.

La pregunta más importante no es:

“¿El backup terminó correctamente?”

La pregunta realmente importante es:

“¿Cuánto tardamos en recuperar la empresa si mañana perdemos una máquina crítica?”

¿Quieres diseñar Proxmox Backup Server para tu empresa?

En Sistro Networks podemos analizar tu número de VMs, capacidad, retención, RPO, RTO, networking, segundo sitio y estrategia de Disaster Recovery.

Podemos diseñar PBS desde cero o integrarlo dentro de un cluster Proxmox existente.

También podemos evaluar si conviene conservar Veeam u otra plataforma de respaldo que ya forme parte de tu infraestructura.

Consulta nuestros servicios de implementación Proxmox VE

Preguntas frecuentes

¿Qué es Proxmox Backup Server?

Es la plataforma especializada de Proxmox para realizar respaldo y recuperación de máquinas virtuales, contenedores y determinados hosts físicos.

¿Los backups de PBS son incrementales?

Los datos se transfieren incrementalmente y se deduplican en el servidor. Cada snapshot continúa representando un punto completo de restauración mediante referencias a los chunks necesarios.

¿Qué es la deduplicación?

Es un mecanismo que evita almacenar varias veces bloques idénticos, ayudando a reducir el consumo de almacenamiento.

¿PBS reemplaza Ceph?

No. Ceph proporciona almacenamiento distribuido y redundancia. PBS proporciona respaldo y recuperación histórica.

¿Ceph reemplaza PBS?

No. Si una VM se elimina, se corrompe o sufre ransomware, la redundancia de Ceph no equivale a disponer de un backup histórico.

¿PBS puede verificar los backups?

Sí. Proxmox Backup Server dispone de Verification Jobs y utiliza checksums para comprobar la integridad de los datos almacenados.

¿PBS puede tener una copia en otro sitio?

Sí. Los servidores PBS pueden utilizar Remotes y Sync Jobs para mantener copias en otras ubicaciones.

¿PBS cifra los backups?

Las comunicaciones utilizan TLS y PBS soporta cifrado adicional del lado del cliente. Este cifrado debe configurarse y las llaves deben protegerse correctamente.

¿PBS protege contra ransomware?

PBS incorpora características útiles para reducir determinados riesgos, pero debe combinarse con segregación de permisos, copias remotas, monitoreo, seguridad y pruebas de restauración.

¿Proxmox Backup Server sustituye Veeam?

No existe una respuesta universal. PBS está especialmente integrado con Proxmox, mientras que empresas que ya utilizan Veeam pueden tener razones técnicas u operativas para conservarlo. La decisión debe analizarse según la infraestructura.