92 es la mitad de 99

Proxmox Best Practice Part 3 – Backup Strategies (Estrategias de copia de seguridad): Mantenga los datos seguros

Bienvenido de nuevo a las mejores prácticas para su servidor Proxmox o clúster Proxmox, hoy analizamos el tema de la copia de seguridad en detalle. Para ello, necesitamos, como ya saben, a los colegas de aquí:

Servidor de copia de seguridad Proxmox (PBS)

PBS es la solución de copia de seguridad profesional de Proxmox y definitivamente debería estar en su radar. Los principales beneficios no son solo la charla de marketing, sino que en realidad marcan la diferencia en la práctica:

  • Desduplicación: Los bloques de datos idénticos se almacenan solo una vez, a menudo ahorrando hasta 90% Espacio de almacenamiento
  • Copias de seguridad incrementales: Solo se realiza una copia de seguridad de los cambios, lo que reduce drásticamente el tiempo de copia de seguridad
  • encriptación: Cifrado AES-256-GCM del lado del cliente, incluso si alguien compromete su servidor de copia de seguridad
  • Limitación del ancho de banda: Sus copias de seguridad se ejecutan en segundo plano sin que los sistemas de producción sufran
  • Verificar trabajos: Verificación automática de integridad: siempre sabe si sus copias de seguridad son realmente útiles
  • Políticas de retención: Las reglas de eliminación inteligentes aseguran que no se hunda en el caos de la copia de seguridad
  • GUI web: Una interfaz de usuario moderna que es realmente divertida de usar

Configuración de PBS (configuración básica)

Requisitos de hardware y planificación

Antes de comenzar, debe pensar en el hardware. Un servidor PBS es tan bueno como el hardware en el que se ejecuta. Aquí hay requisitos mínimos realistas que han demostrado su eficacia en la práctica:

Recomendaciones mínimas de hardware para PBS:

  • CPU: 4 núcleos (más si desea hacer una copia de seguridad de muchas máquinas virtuales en paralelo)
  • RAM: Mínimo absoluto de 8 GB, 16 GB + si quieres hacerlo «en serio»
  • Almacenamiento: Un SSD rápido para metadatos, discos duros grandes para los datos de copia de seguridad reales
  • Red: Gigabit Ethernet como mínimo, mejor 2.5 o 5 GBE y 10GbE si está moviendo constantemente grandes cantidades de datos

La instalación en sí es agradablemente sencilla. Definitivamente debe instalar PBS en un servidor físico separado: tener un PBS virtualizado en el mismo clúster Proxmox del que se supone que debe hacer una copia de seguridad es como tener un extintor de incendios vacío en la casa en llamas. ??

# Agregar el eco del repositorio Proxmox Backup Server "deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription" > /etc/apt/sources.list.d/pbs.list wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg/proxmox-release-bookworm.gpg apt update && apt install proxmox-backup-server # Primera configuración - crear un usuario administrador proxmox-backup-manager crear backup@pbs --email admin@example.com proxmox-backup-manager acl update / Backup@pbs --role Admin

Optimizar la configuración de almacenamiento

La configuración del almacenamiento está en el corazón de su sistema de copia de seguridad. Vale la pena invertir algo de tiempo aquí. ZFS es a menudo la mejor opción aquí, ya que le da instantáneas, compresión y checksumming fuera de la caja. Ya habíamos discutido esto en detalle en la segunda parte (Almacenamiento).

# Cree un grupo de ZFS para un rendimiento óptimo # Refleja dos discos y usa NVMe para caché y log zpool para crear backup-pool \ mirror /dev/sdb /dev/sdc \ cache /dev/nvme0n1p1 \ log /dev/nvme0n1p2 # El almacén de datos con ajustes de retención sofisticados proxmox-backup-manager datastore crea backup-storage /backup-pool/data \ --gc-schedule 'diario' \ --prune-schedule 'diario' \ --keep-diario 7 \ --keep-weekly 4 \ --keep-monthly 12 \ --keep-yearly 2 \ --notify-user backup@pbs

Configurar trabajos de copia de seguridad

Configuración básica

Ahora se está poniendo interesante: los trabajos de copia de seguridad reales. Aquí es donde usted decide si su sistema de copia de seguridad se convertirá en un compañero confiable o una fuente de frustración constante!

La variante CLI le da mucho más control sobre los parámetros. ¡La limitación del ancho de banda es particularmente importante! Nadie quiere copias de seguridad para cerrar el resto de la red.

# Trabajo de copia de seguridad con todos los parámetros importantes pvesh create /cluster/backup \ --schedule "02:00" \ --storage backup-pbs \ --mode snapshot \ --all 1 \ --compress zstd \ --protected 1 \ --notes-template "{{cluster}}: {{nombre del huésped}} - {{job-id}}" \ --mailnotification always \ --mailto admin@example.com \ --bwlimit 50000 # Limitación del ancho de banda de 50 MB/s

Alternativamente, también puede hacer todo convenientemente a través de la interfaz web: Centro de datos → Copia de seguridad → Añadir. Esto es a menudo más claro, especialmente para los principiantes.

Parámetros importantes explicados

Estos parámetros son cruciales para un sistema de copia de seguridad en funcionamiento, por lo que aquí están los más importantes en detalle:

Calendario: Aquí se utiliza el formato estándar Cron. 0 2 * * * Significa a las 2:00 a.m. todos los días. Planifique sus tiempos de copia de seguridad para que no entren en conflicto con otras tareas intensivas en mantenimiento.

modas: Aquí hay tres opciones que todas tienen sus ventajas y desventajas:

  • instantánea: La máquina virtual continúa ejecutándose, obtienes una instantánea consistente. Ideal para sistemas productivos.
  • suspendido: La máquina virtual se pausa brevemente. Máxima consistencia, pero corta interrupción.
  • parar: La máquina virtual se está apagando. Recomendado solo para sistemas no críticos.

Comprimir: Aquí tienes que equilibrar la velocidad y la eficiencia:

  • lz4 es rápido y requiere poca CPU, pero se comprime menos
  • zstd Comprime mucho mejor, pero necesita más potencia de cómputo

Protegido: Protege la copia de seguridad de la eliminación accidental. Siempre debe activarlo para copias de seguridad importantes.

BWLimit: El límite de ancho de banda en KB/s. 50000 corresponde a unos 50 MB/s, lo que se adapta a su infraestructura de red.

Habilitar la verificación de copia de seguridad

Una copia de seguridad sin verificación es como un paracaídas sin un certificado de prueba: solo nota que no funciona cuando realmente lo necesita, lo que puede ser demasiado tarde en el peor de los casos. PBS le ayuda porque puede verificar automáticamente la integridad de sus copias de seguridad.

# Verificar el trabajo para la integridad automática de la copia de seguridad pvesh crear /admin/verificar \ --store backup-storage \ --schedule 'weekly' \ --outdated-after 7 \ --ignore-verified

El trabajo Verificar se ejecuta una vez a la semana y comprueba todas las copias de seguridad de más de 7 días. Las copias de seguridad ya verificadas se omiten para ahorrar tiempo.

Implementar la regla de copia de seguridad 3-2-1

Entendiendo la Regla 3-2-1

La regla 3-2-1 no es solo un truco de marketing, sino una práctica probada de décadas de experiencia con la pérdida de datos. Establece lo siguiente:

  • 3 Copias de sus datos (1 original + 2 copias de seguridad)
  • 2 diferentes tipos de medios/almacenamiento (no todos en la misma tecnología)
  • 1 Respaldo fuera del emplazamiento (separado geográficamente: incendio, inundación, robo)

Aplicación práctica

En un entorno Proxmox típico, esto podría verse así:

  1. Datos primarios: En su servidor Proxmox con ZFS y redundancia
  2. Copia de seguridad local: En el servidor PBS en el mismo centro de datos/oficina
  3. Copia de seguridad fuera del sitio: Sincronización de PBS con un sitio externo o proveedor de nube

La configuración remota es relativamente sencilla, pero hay que prestar atención a la conexión de red. Una conexión inestable puede hacer que tus trabajos de sincronización sean una pesadilla.

# Configurar copia de seguridad remota - Huella dactilar desde el servidor de destino pvesh create /admin/remote \ --name offsite-backup \ --host backup.external.com \ --userid backup@pbs \ --password "secure_password" \ --fingerprint AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:88:99:AA:BB:CC:DD # Trabajo de sincronización con limitación de ancho de banda - se ejecuta por la noche cuando poco está pasando en pvesh create /admin/sync \ --remote offsite-backup \ --remote-store production \ --store local-backup \ --schedule "04:00" \ --rate-in 10000 \ --burst-in 15000 \ --comment "Nighty Offsite-Sync"

Estrategias avanzadas de copia de seguridad

Configurar la retención de copias de seguridad

Las políticas de retención a menudo se subestiman, pero son extremadamente importantes. Sin reglas significativas, acumula gigabytes de copias de seguridad antiguas a lo largo de los años que ya nadie necesita. Al mismo tiempo, no desea eliminar accidentalmente la única copia de seguridad utilizable del mes pasado.

Una estrategia probada es el método «abuelo-padre-hijo»: muchas copias de seguridad nuevas, menos antiguas, muy pocas antiguas. PBS hace esto automáticamente por usted.

# Configurar la sofisticada política de retención proxmox-backup-manager datastore update backup-storage \ --keep-last 3 \ # Mantener siempre las últimas 3 copias de seguridad (emergencias) --mantener-hora 24 \ # Copias de seguridad 24 horas (último día) --manténgase al día 7 \ # 7 copias de seguridad diarias (última semana) --keep-weekly 4 \ # 4 copias de seguridad semanales (último mes) --keep-monthly 12 \ # 12 copias de seguridad mensuales (el año pasado) --keep-yearly 5 # 5 copias de seguridad anuales (archivo a largo plazo)

Gestión del ancho de banda

En los entornos de producción, a menudo tiene que presupuestar con un ancho de banda limitado. Las copias de seguridad no deben ralentizar los sistemas de producción, sino que tampoco deben durar para siempre. La configuración del tráfico te ayuda a encontrar el equilibrio adecuado.

# Configurar la configuración del tráfico en el servidor PBS tc qdisc add dev eth0 root handle 1: htb default 30 tc class add dev eth0 parent 1: classid 1:1 htb rate 1000mbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 800mbit ceil 1000mbit tc class add dev eth0 parent 1:1 classid 1:20 htb rate 200mbit ceil 400mbit # iptables -A SALIDA -p tcp --dport 8007 -j CLASIFICACIÓN --set-class 1:20

Esta configuración reserva 80% el ancho de banda para el tráfico normal y limita las copias de seguridad a un máximo de 40% – con la posibilidad de utilizar el tráfico no utilizado.

Integración de copias de seguridad con almacenamiento

Optimizaciones específicas del almacenamiento

Diferentes tipos de almacenamiento tienen diferentes fortalezas. Utilice esto para su ventaja almacenando metadatos y grandes bloques de datos en diferentes medios.

# Almacenes de datos separados para diferentes requisitos # Fast NVMe for metadata and small files proxmox-backup-manager datastore create vm-backups-meta \ /nvme/backup-meta \ --gc-schedule 'diario' \ --prune-schedule 'diario' # Big RAID para el almacén de datos real de backup proxmox-backup-manager crea vm-backups-data \ /raid/backup-data \ --gc-schedule 'weekly' \ --keep-daily 14 \ --keep-weekly 8 \ --keep-monthly 24 # Trabajo de copia de seguridad que excluye archivos innecesarios pvesh crear /cluster/backup \ --schedule "02:00" \ --storage backup-pbs \ --mode snapshot \ --compress zstd \ --notes-template "{{cluster}}: {{nombre del huésped}} ({{modo}}})" \ --protected 1 \ --exclude-path "/tmp/*,/var/log/*,/var/cache/*" # Ahorra espacio y tiempo

Estrategias de copia de seguridad por tipo de almacenamiento

instantáneas LVM-Thin

Los volúmenes delgados LVM son ampliamente utilizados y proporcionan una funcionalidad de instantánea simple. El truco consiste en mantener las instantáneas solo durante el tiempo que realmente las necesites, ya que pueden afectar al rendimiento.

# Copia de seguridad automatizada de instantáneas LVM con solución de problemas create_lvm_backup() { local vmid=$1 local disk_path="/dev/pve/vm-${vmid}-disk-0" local snap_name="vm-${vmid}-snap-$(fecha +%Y%m%d-%H%M%S)" echo "Crear copia de seguridad para VM $vmid..." # Compruebe si hay suficiente espacio para la instantánea si ! lvcreate --test --snapshot --name $snap_name --tamaño 10G $ruta_disco; luego eco "Error: ¡No hay suficiente espacio para la instantánea!" volver 1 fi # Crear instantánea - es cuasi instantáneo lvcreate --snapshot --name $snap_name --tamaño 10G $disc_path # Copia de seguridad desde la instantánea con el indicador de progreso dd if=/dev/pve/$snap_name bs=64k status=progress ?? \ gzip -c > /backup/vm-${vmid}-$(fecha +%Y%m%d).img.gz # Eliminar instantánea inmediatamente para obtener rendimiento lvremove -f /dev/pve/$snap_name echo "Copia de seguridad para VM $vmid completado." } # Uso para VM 100: # create_lvm_backup 100

Instantáneas de ZFS

ZFS es mucho más elegante aquí: las instantáneas no cuestan prácticamente nada y puedes hacer copias de seguridad incrementales. Esto ahorra mucho tiempo y ancho de banda, especialmente con máquinas virtuales grandes.

# Estrategia de copia de seguridad incremental de ZFS inteligente zfs_incremental_backup() { conjunto de datos locales=$1 local remote_host=$2 local current_snap="${dataset}@backup-$(fecha +%Y%m%d-%H%M%S)" local last_snap=$(lista zfs -t snapshot -o nombre -s creación ?? grep ${dataset}@ ?? tail -1) echo "Crear ZFS Backup para $conjunto de datos..." # Crear una nueva instantánea - toma milisegundos zfs snapshot $current_snap si [ -n "$last_snap" ]; luego echo "Enviar copia de seguridad incremental desde $last_snap» # Transferir solo los cambios - enviar zfs mucho más rápido -i $last_snap $current_snap ?? \ ssh $remote_host "zfs recibir -F copia de seguridad /${conjunto de datos##*/}" más eco "Enviar copia de seguridad completa inicial" # La primera copia de seguridad es siempre envío completo de zfs $current_snap ?? \ ssh $remote_host "zfs recibir copia de seguridad /${conjunto de datos##*/}" fi # Limpiar las instantáneas - mantener sólo los últimos 7 locales old_snaps=$(lista zfs -t snapshot -o nombre -s creación ?? grep ${dataset}@ ?? head -n -7) si [ -n "$old_snaps" ]; luego echo "Eliminar viejas instantáneas..." echo "$old_snaps" ?? mientras se lee snap; hacer zfs destruir $snap done fi echo "Copia de seguridad ZFS para $conjunto de datos completado." } # Automatización para todos los conjuntos de datos de VM zfs_replicate_all() { echo "Iniciar replicación ZFS para todas las VMs..." para el conjunto de datos en $(lista zfs -H -o nombre ?? grep "tank/vm-"); hacer zfs_incremental_backup $dataset backup-server.local done echo "Replicación ZFS completada." }

Monitoreo y Alerta

Supervisar el estado de la copia de seguridad

Un sistema de reserva sin supervisión es como un detector de humo sin baterías: solo se observa que no funciona cuando es demasiado tarde. Por lo tanto, debe configurar comprobaciones automáticas.

# Script de monitoreo de estado de copia de seguridad #!/bin/bash check_backup_status() { echo "Comprobar el estado de la copia de seguridad..." # Buscar trabajos fallidos en las últimas 24 horas local failed_jobs=$(pvesh get /cluster/backup --output-format json ?? \ jq -r '.[] ?? select(.state == "error") ?? .id') si [ -n "$fail_jobs" ]; luego eco "ALARMA: Los trabajos de copia de seguridad fallaron: $fail_jobs» # Enviar correo electrónico echo "Trabajos de copia de seguridad $Failed_jobs falló. Por favor, compruebe!" ?? \ mail -s "ALERTA DE FALLO DE RESPUESTA" admin@example.com # Opcional: Alerta al sistema de monitorización curl -X POST "https://monitoring.example.com/alert" \ -H "Tipo de contenido: application/json" \ -d "{\"message\":\"Fallos de copia de seguridad: $fail_jobs\", \"severity\":\"critical\"}" return 1 else echo "Todos los trabajos de backup se ejecutan normalmente." return 0 fi } # Realizar como un trabajo cron cada 2 horas # 0 */2 * * * /usr/local/bin/check_backup_status.sh

Verificación del estado del servidor de copia de seguridad de Proxmox

Los controles de salud regulares le ayudarán a identificar los problemas antes de que se vuelvan críticos. Debe vigilar el espacio de almacenamiento, el rendimiento y el estado del servicio. Por ejemplo, podría verse así:

# Chequeo Integral de Salud PBS pbs_health_check() { echo "=== Chequeo de Salud PBS $(fecha) ===" # Datastore Status and Storage echo "--- Datastore Status ---" proxmox-backup-manager datastore list echo "--- Storage ---" df -h ?? grep -E "(backup ?? pbs)" ?? mientras se lee la línea; hacer uso=$(eco $línea ?? awk '{print $5}' ?? tr -d '%') si [ $uso -gt 85 ]; luego eco "ADVERTENCIA: $línea - memoria casi llena!" más eco "OK: $línea" fi hecho # Procesos en curso eco "--- Procesos activos de copia de seguridad ---" local active_jobs=$(ps aux ?? grep -E "(proxmox-backup ?? pbs)" ?? grep -v grep ?? wc -l) echo "Trabajos activos: $active_jobs» # Verificar el estado de los trabajos ---" pvesh get /admin/verify --output-format json ?? \ jq -r '.[] ?? "Job \(.id): \(.state) (última versión: \(.last_run_endtime // "never"))» # probar el rendimiento de la red a objetivos remotos eco "--- pruebas de red ---" si comando -v iperf3 > /dev/null; luego echo "Ancho de banda de prueba a objetivos de copia de seguridad..." # iperf3 -c backup-remote.com -t 10 -f M fi echo "=== Health Check Ende ===" }

Planificación de la recuperación en casos de desastre

Recuperación completa del sistema

Llegará el día en que tendrá que restaurar todo su sistema. Sí, por supuesto, eso nunca sucede; bueno, siempre es la primera vez en algún momento. La preparación lo es todo aquí: pruebe periódicamente sus planes de recuperación en caso de catástrofe en un entorno aislado.

# Recuperación completa del clúster después del fallo total restore_cluster() { local backup_location=$1 echo "Iniciar la recuperación del clúster desde $backup_location» # 1. Preparar la nueva instalación de Proxmox echo "Paso 1: Sistema básico instalado (paso manual)" # 2. Restaurar la configuración del clúster echo "Paso 2: Restaurar la configuración del clúster..." si [ -f "$backup_location/cluster-config.tar.gz" ]; luego alquitrán -xzf "$backup_location/cluster-config.tar.gz" -C /etc/pve/ systemctl reload pve-cluster fi # 3. Restaurar la configuración de almacenamiento echo "Paso 3: Restaurar piscinas de almacenamiento..." # Aquí necesita personalizar su configuración de almacenamiento específica # 4. Restaurar máquinas virtuales individualmente echo "Paso 4: Recuperación de VM..." si [ -f "$backup_location/vm-list.txt" ]; luego mientras se lee vmid; hacer eco "Recuperar VM $vmid..." local backup_file="$backup_location/vm-${vmid}-latest.vma.gz" si [ -f "$backup_file" ]; luego qmrestore "$backup_file" $vmid --almacenamiento local-lvm echo "VM $vmid restaurado" más eco "ADVERTENCIA: Copia de seguridad para VM $vmid no encontrado!" fi done < "$backup_location/vm-list.txt" fi echo "Recuperación del clúster completada. Por favor, compruebe los servicios!" }

Automatizar la validación de copias de seguridad

¿Lo mencioné hoy? No importa, no puedes decir lo suficiente: Las pruebas periódicas de sus copias de seguridad son esenciales. Nada es más frustrante que descubrir una copia de seguridad corrupta solo en caso de una emergencia.

El PBS también validará automáticamente para usted, pero agregará hasta 100% También me resulta difícil irme. Al menos debería considerar hacer restauraciones reales de vez en cuando, por ejemplo, a través de su entorno de prueba / estadificación, solo entonces puede realmente dormir tranquilamente.

# Pruebas de copia de seguridad automatizadas con prueba VM backup_validation() { local test_vmid=9999 # Reserve VM-ID para las pruebas local datastore="backup-storage" echo "Start backup validation..." # Encuentra la última copia de seguridad local latest_backup=$(proxmox-backup-client list --repository $almacén de datos ?? \ grep "vm/$test_vmid" ?? sort -r ?? head -1 ?? awk '{print $1}') si [ -z "$latest_backup" ]; luego echo "No se encontró copia de seguridad para la máquina virtual de prueba, use cualquier copia de seguridad de la máquina virtual" latest_backup=$(proxmox-backup-client list --repository $almacén de datos ?? \ grep "vm/" ?? head -1 ?? awk '{print $1}') fi si [ -z "$latest_backup" ]; luego eco "FEHLER: No se han encontrado copias de seguridad!" return 1 fi echo "Test Backup: $latest_backup» # Prueba de recuperación (sin inicio) si qmrestore --archive "$datastore:backup/$latest_backup» $test_vmid --almacenamiento local-lvm; luego echo "Recuperación exitosa, prueba VM start..." # Inicio de la prueba de VM qm start $test_vmid sleep 30 si el estado qm $test_vmid ?? grep -q "correr"; luego eco "SUCCESS: Validación de copia de seguridad exitosa - VM se inicia correctamente" qm stop $prueba_vmid qm destruir $test_vmid --purge return 0 else echo "FEHLER: VM no se inicia después de la recuperación" sqm destruir $test_vmid --purge return 1 fi else echo "FEHLER: Recuperación fallida" retorno 1 fi }

Optimización del rendimiento

Ajuste del rendimiento de la copia de seguridad

La sintonización del rendimiento en las copias de seguridad es a menudo un acto de equilibrio entre la velocidad, la carga del sistema y el impacto de la red. Aquí hay configuraciones comprobadas para diferentes escenarios.

# Optimizar la configuración de la copia de seguridad en todo el centro de datos (Homelab) # /etc/pve/datacenter.cfg max_workers: 3 # No más de 3 trabajos paralelos de copia de seguridad bandwidth_limit: 200 # Ancho de banda total de 200 MB/s para todos los trabajos ionice: 7 # Prioridad de E/S más baja (0-7) lockwait: 180 # Espere 3 minutos para las cerraduras

Estos ajustes evitan que sus copias de seguridad sobrecarguen sus sistemas de producción. Con un hardware más potente, puede ajustar los valores en consecuencia, los datos del ejemplo anterior son una configuración de laboratorio doméstico bastante simple sin hardware de servidor de alto rendimiento. En un servidor relativamente actualizado, por ejemplo, esto también podría verse así:

# Optimizar la configuración de la copia de seguridad en todo el centro de datos (servidor) # /etc/pve/datacenter.cfg max_workers: 6 # No más de 6 trabajos paralelos de copia de seguridad bandwidth_limit: 1500 # 1500MB/s ancho de banda total para todos los trabajos (Almacenamiento NvME) ionice: 4 # Prioridad de E/S media (0-7) lockwait: 60 # Espere 1 minuto para las cerraduras

Optimizaciones específicas del almacenamiento

Diferentes tecnologías de almacenamiento necesitan diferentes optimizaciones. Lo que es bueno para los SSD NVMe puede ser contraproducente con discos duros giratorios. Aquí hay algunos ejemplos:

# Optimice los programadores de E/S para diferentes tipos de almacenamiento # Para los SSD NVMe: mq-deadline es en su mayoría óptimo echo mq-deadline > /sys/block/nvme0n1/queue/scheduler # Para los SSD SATA: none o mq-deadline echo none > /sys/block/sda/queue/scheduler # Para discos duros giratorios: bfq o cfq echo bfq > /sys/block/sdb/queue/scheduler # Optimizar readahead para grandes bloques de acceso secuencial --setra 4096 /dev/sda # 2MB readahead # Para cargas de trabajo de copia de seguridad a menudo útiles echo 32 > /sys/block/sda/queue/nr_requests

Solucionar problemas comunes

Colgar trabajos de copia de seguridad

Colgar trabajos de copia de seguridad es un problema clásico. Esto generalmente se debe a bloqueos, problemas de red o sistemas de almacenamiento sobrecargados.

# Identificar y tratar trabajos colgantes find_hanging_jobs() { echo "Buscar trabajos colgantes de copia de seguridad..." # Los procesos de vzdump de larga duración encuentran ps aux ?? grep vzdump ?? grep -v grep ?? mientras leen la línea; hacer pid=$(eco $línea ?? awk '{print $2}') tiempo de ejecución=$(ps -o etime= -p $pid ?? tr -d ' ') echo "Job PID $pid ha estado funcionando desde: $tiempo de ejecución» # Los trabajos que duran más de 6 horas son sospechosos si [[ $tiempo de ejecución =~ ^[0-9][0-9]:[0-9][0-9]:[0-9][0-9]$ ]]; luego eco "ADVERTENCIA: trabajo $pid corre muy largo!" fi hecho # Compruebe los archivos de bloqueo si [ -f /var/lock/vzdump.lock ]; luego echo "Vzdump-Lock found, check process..." local lock_pid=$(cat /var/lock/vzdump.lock) si ! matar -0 $lock_pid 2>/dev/null; luego echo "Lock file is orphaned, delete it..." rm /var/lock/vzdump.lock fi fi } # Limpieza de emergencia para sistemas completamente suspendidos emergency_backup_cleanup() { echo "NOTFALL: Finalizar todos los procesos de copia de seguridad!" killall -9 vzdump killall -9 proxmox-backup-cliente rm -f /var/lock/vzdump.lock rm -f /tmp/vzdumptmp* echo "Cleanup completed - check the logs!" }

Gestión del espacio de almacenamiento

Los almacenes de datos de copia de seguridad completos también son un problema común. La recolección de basura y la poda deben ejecutarse automáticamente, pero a veces aún debe intervenir manualmente.

# diagnosticar y corregir storage_cleanup() { almacén de datos local=$1 echo "Análisis del Espacio de Almacenamiento para $almacén de datos..." # Consumo de memoria actual df -h $(proxmox backup manager datastore list ?? grep $almacén de datos ?? awk '{print $3}') # Encuentre los grupos de copia de seguridad más grandes echo "Grupos de copia de seguridad más grandes:" you -sh /backup/$almacén de datos/* ?? sort -hr ?? head -10 # Run Garbage Collection hace eco manualmente de "Start Garbage Collection..." proxmox-backup-manager garbage-collect $almacén de datos # Los fragmentos huérfanos encuentran eco "Buscar fragmentos huérfanos..." proxmox-backup-manager datastore verify $almacén de datos # Espacio de almacenamiento después de la limpieza echo "Espacio de almacenamiento después de la limpieza:" df -h $(proxmox backup manager datastore list ?? grep $almacén de datos ?? awk '{print $3}') # Ejecutar trabajos de Prune manualmente cuando no se ejecuta automáticamente echo "Ejecutar trabajos de Prune..." proxmox-backup-client prune --repository $almacén de datos \ --keep-diario 7 --keep-weekly 4 --keep-monthly 12 } # Monitoreo de almacenamiento con Alertas monitor_storage_space() { para el almacén de datos en $(proxmox backup manager datastore list ?? awk 'NR>1 {print $1}'); hacer ruta local=$(proxmox backup manager datastore list ?? grep $almacén de datos ?? awk '{print $3}') uso local=$(df)$path" ?? awk 'NR==2 {print $5}' ?? tr -d '%') echo "Datastore $almacén de datos: ${utilización}% Evidenciado" si [ $uso -gt 90 ]; A continuación, haga eco de "CRITIQUE: $Almacén de datos de más de 90 años% ¡Lleno de eso! # Aquí puede eliminar automáticamente las copias de seguridad antiguas elif [ $uso -gt 80 ]; luego eco "ADVERTENCIA: $almacén de datos de más de 80% full" fi hecho }

Diagnóstico de problemas de red

Los problemas de red también podrían ser la razón de copias de seguridad lentas o fallidas. Aquí hay herramientas y técnicas para ayudarle a diagnosticar.

# Diagnósticos de red completos para conexiones de copia de seguridad network_backup_diagnosis() { local target_host=$1 echo "=== Diagnóstico de red para $target_host ===" # Accesibilidad básica eco "--- Ping Test ---" si ping -c 5 $target_host > /dev/null; luego echo "Host $target_host es accesible" ping -c 5 $target_host ?? tail -1 else echo "FEHLER: Anfitrión $target_host no accesible!" volver 1 fi # prueba de ancho de banda con eco iperf3 "--- prueba de ancho de banda ---" si comando -v iperf3 > /dev/null; luego echo "Ancho de banda de prueba a $target_host..." tiempo de espera 30s iperf3 -c $target_host -t 20 -f M 2>/dev/null ?? \ grep "sender" ?? awk '{print "Subir: " $7 " " $8}' tiempo de espera 30s iperf3 -c $target_host -t 20 -f M -R 2>/dev/null ?? \ grep "receiver" ?? awk '{imprimir "Descargar: " $7 " " $8}' más eco "iperf3 no instalado - instalar con: apt instalar iperf3" fi # Prueba de latencia eco "--- Análisis de latencia ---" local avg_latency=$(ping -c 100 $target_host ?? tail -1 ?? awk -F'/' '{print $5}') echo "Latencia media: ${avg_latency}ms" si (( $(eco)$avg_latency > 100" ?? bc -l) )); luego eco "ADVERTENCIA: La alta latencia podría afectar el rendimiento de la copia de seguridad # Disponibilidad del puerto para PBS echo "--- Pruebas del puerto ---" para el puerto en 8007 8008; hacer si timeout 5s bash -c "</dev/tcp/$target_host/$puerto»; luego echo "Puerto $puerto: ABIERTO" más eco "Puerto $puerto: CERRADO o filtrado" fi hecho # MTU-Discovery echo "--- MTU-Test ---" para el tamaño en 1472 1500 9000; hacer si ping -c 1 -M do -s $tamaño $target_host > /dev/null 2>&1; luego eco "MTU $tamaño: OK" más eco "MTU $tamaño: Fragmentación requerida" fi hecho }

Problemas con el certificado SSL/TLS

PBS utiliza HTTPS para todas las conexiones. Las emisiones de certificados son un obstáculo común, especialmente con los certificados autofirmados.

# Diagnóstico del certificado SSL y reparación check_pbs_certificates() { local pbs_host=$1 echo "=== Verificación del certificado SSL para $pbs_host ===" # Obtener detalles del certificado echo "--- Información del certificado ---" local cert_info=$(echo openssl s_client -servername $pbs_host -conectar $pbs_host:8007 2>/dev/null ?? \ openssl x509 -noout -dates -subject -issuer) echo "$cert_info» # Comprobar la validez del certificado local expiry_date=$(eco)$cert_info" ?? grep "notAfter" ?? cut -d'=' -f2) local expire_seconds=$(fecha -d)$expire_date" +%s) local now_seconds=$(fecha +%s) días locales_hasta_caducidad=$((((expiry_seconds - now_seconds) / 86400 ))) echo "El certificado expira en: $días_hasta_días de caducidad" si [ $days_until_expiry -lt 30 ]; luego eco "ADVERTENCIA: ¡El certificado expirará pronto!" fi # Huella dactilar para la configuración remota echo "--- Huella dactilar para la configuración remota ---" Huella dactilar local=$(echo openssl s_client -servername $pbs_host -conectar $pbs_host:8007 2>/dev/null ?? \ openssl x509 -noout -fingerprint -sha256 ?? cut -d'=' -f2) echo "Fingerprint: $huella dactilar" } # Generar nuevo certificado autofirmado regenerate_pbs_certificate() { local pbs_host=$1 echo "Generar nuevo Certificado Auto-Firmado para $pbs_host..." # Copia de seguridad del antiguo certificado cp /etc/proxmox-backup/proxy.pem /etc/proxmox-backup/proxy.pem.backup.$(fecha +%Y%m%d) # Crear nuevo certificado openssl req -x509 -newkey rsa:4096 -keyout /tmp/proxy.key -out /tmp/proxy.crt \ -days 3650 -nodos -subj "/CN=$pbs_host" # Combinar certificado y clave cat /tmp/proxy.crt /tmp/proxy.key > /etc/proxmox-backup/proxy.pem # Eliminar archivos temporales rm /tmp/proxy.key /tmp/proxy.crt # Service restart systemctl restart proxmox-backup-proxy echo "Nuevo certificado instalado. Nueva huella dactilar:" check_pbs_certificates $pbs_host ?? grep "Huella digital:" }

Mejores prácticas TL:DR

Definitivamente debes prestar atención a esto

Estos son los puntos clave que determinan el éxito o el fracaso de su sistema de copia de seguridad:

Hardware & Infraestructura:

  • PBS siempre en hardware separado, nunca en el sistema en el que se realiza la copia de seguridad
  • RAM suficiente para la deduplicación (al menos 16 GB para entornos de producción)
  • SSD rápidos para metadatos, HDD grandes para datos de copia de seguridad
  • Conexiones de red redundantes si es posible

Configuración:

  • Configurar correctamente las políticas de retención desde el principio: después es tedioso
  • Habilitar la limitación de ancho de banda para no interferir con los sistemas productivos
  • Configurar trabajos de verificación: una copia de seguridad no probada no es una copia de seguridad
  • Habilitar notificaciones por correo electrónico para todos los eventos críticos

Seguimiento:

  • Controles automáticos de salud al menos diarios
  • Monitoreo de almacenamiento con alertas a >80% ocupación
  • La prueba regular restaura en el ambiente aislado
  • Revisar periódicamente los archivos de registro: tomar en serio las advertencias

Seguridad:

  • Habilitar el cifrado del lado del cliente para datos confidenciales
  • Credenciales separadas para usuarios de copia de seguridad: sin derechos de administrador
  • Reglas de firewall solo para los puertos necesarios (8007, 8008)
  • Copias de seguridad externas con transferencia segura (claves SSH en lugar de contraseñas)

Evitar errores frecuentes de principiante

Error «PBS virtualizado»: Nunca ejecute PBS en el mismo clúster Proxmox del que se supone que debe hacer una copia de seguridad. Es como un cinturón de seguridad hecho de chicle.

La mentalidad Set and Forget: Las copias de seguridad necesitan mantenimiento regular. Verifique al menos mensualmente para ver si todo está funcionando.

Falta de limitación de ancho de banda: Los trabajos de copia de seguridad sin límites pueden paralizar su red de producción.

Ninguna prueba restaura: No sabe si sus copias de seguridad funcionarán hasta que las pruebe. La Ley de Murphy es especialmente aplicable a las copias de seguridad. ??

Políticas de retención poco claras: Define desde el principio cuánto tiempo quieres conservar algo. El crecimiento infinito de los archivos de copia de seguridad es una pesadilla.

Con estos conceptos básicos, tiene una base sólida para su sistema de copia de seguridad Proxmox. Invierta tiempo en una configuración adecuada: lo diré, su futuro se lo agradeceré, ya sea a través de un sueño tranquilo y relajado o, a más tardar, cuando se produzca la primera emergencia.

Finalización y recursos avanzados

Proxmox es una herramienta poderosa, pero con gran poder viene una gran responsabilidad. (winker) Las mejores prácticas que se muestran aquí son el resultado de la experiencia en la práctica. Comience con lo básico y gradualmente trabaje hasta llegar a las funciones avanzadas.

Sus próximos pasos:

  1. Construir un entorno de prueba / estadificación: Pruebe todas las configuraciones en un entorno separado
  2. Implementar el monitoreo: Supervise su sistema desde el principio
  3. Estrategia de copia de seguridad de prueba: Realiza pruebas de restauración periódicas
  4. Únete a la Comunidad: El foro de Proxmox es muy útil

Así que recuerda: Tómese su tiempo, lo básico Entiende antes que tú Configuraciones más complejas se desvanece. El Guía de administración de Proxmox Como sitio web que he enlazado varias veces en el artículo como referencia también vale oro. Echa un vistazo en el foro alrededor, Si tiene alguna pregunta. También hay un punto de entrada para Canal de YouTube.

Las partes restantes de esta serie de artículos que también he vinculado aquí de nuevo para usted: Parte 1: red | Parte 2: almacenamiento | Parte 3: respaldo | Parte 4: seguridad | Parte 5: rendimiento

Stephan
|
| | | | | | | | |
a la cima | página de inicio | para buscar