Cómo resolver picos de I/O y uso de swap en VPS durante backups nocturnos sin aumentar disco

Por · Publicado el · 8 min de lectura

Reloj de arena en primer plano sobre una mesa, con una persona desenfocada al fondo
Reloj de arena simboliza el escalonado de backups para reducir picos de I/O Foto: Thirdman / Pexels

¿Sufres picos de I/O y uso de swap en tu VPS durante los backups nocturnos y no quieres (o no puedes) aumentar el disco? Aquí tienes un diagnóstico práctico y acciones para reducir la contención de I/O, limitar la concurrencia y ajustar el sistema — ionice/nice, bwlimit, snapshots y parámetros del kernel — manteniendo tus backups fiables.

Síntomas: cómo identificar que hay competencia por I/O y swap

Durante la ventana de backup el sistema se vuelve lento, el load average sube y procesos comunes quedan bloqueados esperando al disco. La memoria libre cae y la swap crece. Suele haber compresión, copia de archivos grandes o snapshots compitiendo con la base de datos y servicios de producción.

Si este es el caso, el objetivo es reducir los picos y repartir la escritura/lectura en el tiempo sin aumentar el volumen de almacenamiento.

Diagnóstico rápido (10 minutos) para localizar el cuello de botella

Ejecuta estas mediciones durante el backup. Busca colas de I/O altas, procesos con I/O intenso y presión de memoria que derive en swap.

Si el disco del proveedor tiene límite de burst, puede agotarse y provocar latencias elevadas.

# Utilização detalhada do disco (filas, espera, %util)
iostat -xy 5 3

# Pressão de memória e swap (cs, si/so)
vmstat 5 5; free -h; swapon --show

# Processos que mais fazem I/O (root requerido)
iotop -oPa

# Por processo: escrita/leitura por segundo
pidstat -d 5 3

# Histórico, se sysstat estiver habilitado
sar -b 1 10

Causas comunes en VPS durante backups

En la mayoría de incidentes existe una combinación de factores. Identificar el origen orienta la mitigación adecuada.

  • Backup que lee y comprime todo de una vez (tar/gzip, restic/borg con paralelismo alto).
  • rsync sin límite de banda y múltiples procesos barriendo el FS, provocando churn de cache.
  • Snapshots COW (p. ej. LVM) mantenidos por horas mientras la base sigue escribiendo — aumenta el I/O por copy-on-write.
  • Compresión intensa (gzip -9/xz) que genera más lectura/escritura y compite por CPU/I/O.
  • Concurrencia con otras rutinas nocturnas (updatedb, logrotate con compresión, ETLs, VACUUMs).
  • Disco de la VPS alcanzando el límite de rendimiento/burst del proveedor, elevando latencias.
  • Swappiness alto que empuja páginas a swap durante picos de cache y compresión.

Correcciones inmediatas para esta noche (sin aumentar disco)

La meta es suavizar los picos. Limita el I/O y CPU del job de backup, reduce la concurrencia y mejora la eficiencia de lectura/escritura.

Aplica los cambios de forma gradual y monitoriza el impacto; prioriza las acciones que afecten más con menor riesgo.

  • Forzar baja prioridad de I/O/CPU en el backup con ionice (clase idle) y nice (+15 o +19).
  • Limitar el throughput de rsync/restic/borg (por ejemplo: --bwlimit) para evitar barridos agresivos.
  • Reducir concurrencia: una tarea a la vez; evita varrer y comprimir simultáneamente en múltiples directorios.
  • Excluir caches, temporales y archivos rotados recientes del conjunto de backup.
  • Usar compresión más ligera y rápida (zstd en nivel moderado) para menos I/O por byte.
  • Programar ventanas distintas para logrotate, VACUUM/ETL y backups, evitando solapamientos.
# Exemplos (ajuste caminhos e limites ao seu ambiente)
# rsync: limitar banda, priorizar CPU/I/O baixos
ionice -c3 nice -n 15 rsync -aHAX --delete \
  --bwlimit=20m --info=progress2 --exclude-from=/etc/backup.excludes \
  /dados/ user@backup:/repositorio/host1/

# restic: reduzir concorrência e I/O
IONICE="ionice -c3" NICE="nice -n 15" \
$IONICE $NICE restic backup /dados \
  --limit-bandwidth 20Mi \
  --compression max --pack-size 16Mi \
  --one-file-system

Estrategia robusta: snapshot rápido + subida incremental controlada

Separar la captura del estado (snapshot) del envío al destino reduce el tiempo de I/O intenso en el host. Usa un snapshot corto y un upload incremental con límites.

Con snapshot LVM, mantén el snapshot el menor tiempo posible para reducir copy-on-write. Después realiza el upload incremental (restic/borg) con limitación de I/O y banda.

Acción Efecto esperado Riesgo/Observación
Snapshot corto (minutos) Minimiza COW y el I/O en el host Requiere planificación de consistencia (p. ej.: flush de la BD)
Upload incremental con límite Redistribuye el I/O en el tiempo El backup tarda más (necesita ventana mayor)
Compresión moderada (zstd) Menos CPU por byte y I/O más estable Los archivos quedan algo mayores que con gzip -9
Exclusiones bien definidas Menos datos escaneados y escritos Cuidado de no excluir lo necesario
Una tarea por vez Evita competencia interna Orquesta dependencias/timers

Ajustes del kernel y del sistema de ficheros para reducir swap y writeback

Usa estos ajustes con precaución y prueba antes en producción. El objetivo es evitar que el kernel empuje memoria a swap durante picos transitorios y suavizar los flushes agresivos.

Configura swappiness baja/moderada, ajusta los dirty ratios y valora usar noatime en el filesystem para reducir escrituras de metadatos.

  • vm.swappiness entre 10 y 30 suele evitar swap prematura en servidores.
  • vm.dirty_background_ratio y vm.dirty_ratio controlan cuándo el kernel empieza a escribir páginas sucias.
  • noatime/relatime reducen escrituras de actualización de acceso.
  • Readahead ajustado evita lecturas innecesarias en secuencias cortas.
# Teste temporariamente (até reboot)
sudo sysctl vm.swappiness=20
sudo sysctl vm.dirty_background_ratio=5
sudo sysctl vm.dirty_ratio=20

# Persistir (edite com cuidado)
echo -e "vm.swappiness=20\nvm.dirty_background_ratio=5\nvm.dirty_ratio=20" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Programación, orquestación y visibilidad continuas

Evita la superposición de jobs nocturnos. Usa timers con aleatoriedad y dependencias. Mide de forma continua para confirmar que la mitigación funcionó.

Convierte crons en timers, usa RandomizedDelaySec para repartir la carga y WantedBy/After para ordenar tareas. Guía práctica: migrar cron a systemd timers.

  • Separa ventanas: logrotate/compresión, VACUUM/ETL y backup.
  • Límite de concurrencia por host: como máximo un job pesado.
  • Alertas por latencia de disco, uso de swap y cola de I/O.
  • Revisa las decisiones tras 1–2 ciclos de backup con datos reales.

Cuando el problema es el disco de la VPS (límites del proveedor)

Algunos volúmenes tienen rendimiento variable por burst/IOPS provisionadas. Si el burst se agota, la latencia aumenta incluso para cargas ligeras. En ese caso suavizar I/O ayuda, pero hay que entender el techo del proveedor.

  • Si el burst sostenido del disco es bajo, aumenta la ventana (–bwlimit) para repartir la escritura.
  • Evita múltiples jobs con I/O simultáneos; serializa backups y compresiones.
  • Considera separar disco de datos y disco temporal para backups, cuando sea posible.

Preguntas frecuentes

¿Un alto uso de swap siempre significa falta de RAM?

No siempre. En picos de caché y compresión, el kernel puede mover páginas menos usadas a swap incluso con RAM disponible, según la swappiness y la presión de writeback. Ajustar swappiness, reducir concurrencia y limitar I/O suele estabilizar sin aumentar memoria.

¿ionice y nice solucionan el problema por sí solos?

Ayudan a dar prioridad a servicios críticos cuando hay disputa, pero no reducen la cantidad de datos procesados. Combínalos con límites de banda (bwlimit), reducción de concurrencia, exclusiones y compresión más ligera para suavizar el perfil de I/O del backup.

¿Es seguro mantener un snapshot LVM por horas?

Cuanto más tiempo esté activo el snapshot, más bloques COW se escribirán, aumentando I/O y el riesgo de llenar el área de snapshot. Prefiere snapshots cortos seguidos inmediatamente del upload incremental. Monitoriza el uso del snapshot y dimensiona el área COW con margen.

¿Debo desactivar la swap para evitar lentitud?

Desactivar la swap puede causar OOM kills en picos de memoria. Es mejor reducir swappiness, limitar concurrencia y suavizar el I/O. Una swap pequeña y usada raramente es aceptable. Si la swap se usa constantemente, investiga el consumo de memoria y ajusta servicios.

¿Qué compresión usar en el backup nocturno?

zstd en nivel moderado suele ofrecer buena relación entre tamaño y velocidad, con menos CPU e I/O por byte comparado con gzip en niveles altos. Ajusta el nivel y la concurrencia para mantener baja la latencia de disco durante la ventana de backup.

¿rsync local también necesita --bwlimit?

Incluso en local, rsync puede barrer metadatos intensamente y calentar la página de caché, afectando a otros procesos. Usar --bwlimit y prioridad baja (ionice/nice) ayuda a repartir el trabajo y reducir la competencia por disco.

¿Quieres estabilizar tus backups nocturnos sin explotar el I/O?

Hablemos de tu escenario. Podemos revisar tu job de backup, aplicar límites de I/O, ajustar swappiness y orquestar timers, manteniendo el coste actual de disco.

Cuéntame tu caso

Ver también