Skip to content

Backup retention policies

Last updated: 2026-07-12

Documento canónico de cuánto tiempo se conserva cada cosa. Si un día necesitas restaurar de hace 3 semanas y no encuentras, mira aquí primero.

Backups VM/LXC (PBS)

Definidos a nivel de cluster (pvesh get /cluster/backup), ejecutados desde pvescheduler. Storage destino: pbs: → PBS en 192.168.0.186 (datastore main). (El NFS terramaster en .237 es storage aparte y ningún job de backup lo usa.)

Job Schedule Targets Keep policy
backup-lxc-terra 01:00 daily LXC 123 (cf), 155 (wg) last=7, weekly=4, monthly=3
backup-node2-terra 02:00 daily LXC 200 (n8n) last=7, weekly=4, monthly=3
backup-vm-terra 03:00 daily VM 208 (media), 171 (ha) last=7, weekly=4, monthly=3
backup-wp-pulse-281 02:00 daily LXC 281 (wp-pulse DR; excluye /srv/wp-pulse/sites, re-pullable) last=7, weekly=4, monthly=3
Vera (04:30) 04:30 daily LXC 100 (Vera/clawdbot) last=7, weekly=4, monthly=3
edge caddy/rp (05:00) 05:00 daily LXC 270 (caddy), 271 (caddy), 280 (rp) last=7, weekly=4, monthly=3
misc CTs (05:30) 05:30 daily LXC 102, 110, 172, 251 last=7, weekly=4, monthly=3

Retención uniforme: los 7 jobs (lado PVE) usan keep-last=7, keep-weekly=4, keep-monthly=3.

Ajuste 2026-07-17 — datastore main al 86%: el datastore llegó a 558/650 GB (86%, alerta pbs_datastore_main_high firing) sobre el pool ZFS zfs-ha ya apretado (84% CAP, 74% frag). Causa: acumulación normal de backups en un volumen capado a 650 GB (refquota) dentro de un pool pequeño. Fix (no se subió el umbral, se atacó la causa): el prune-job del PBS main-prune se bajó a keep-daily=5, keep-weekly=3, keep-monthly=3 — más agresivo que la política PVE por-job (7/4/3), así que gobierna la retención efectiva del datastore. Luego prune (eliminó 31 snapshots) + GC. El prune dejó 138.8 GB de chunks pendientes que el GC diario reclama tras la gracia de 24 h → datastore ~62 %; el pool bajó a 82 %. Palanca de fondo pendiente: el pool (854 GB) es pequeño para lo que respalda — si vuelve a apretar, la solución real es más disco o mover el datastore fuera de zfs-ha. Comandos: proxmox-backup-manager prune-job update main-prune --keep-daily 5 --keep-weekly 3 --keep-monthly 3 → ... prune-job run main-prune → ... garbage-collection start main.

LXC 186 (PBS mismo) NO tiene backup — es el destino. Si muere, redesplegar desde cero apuntando a la storage del datastore preexistente.

mailnotification: failure en TODOS los jobs (2026-07-12): solo notifican por mail cuando algo falla. Estado se ve en morning report o vía pvesh get /nodes/proxmox/tasks --type vzdump (los jobs viven en pmx-50).

Hueco de CT100 cerrado (2026-07-12): LXC 100 (Vera/clawdbot) ya tiene su propio job a las 04:30. Antes quedaba fuera de cobertura. También entraron en cobertura los edge caddy/rp (270/271/280, job 05:00) y los CTs misc (102/110/172/251, job 05:30).

Guests decomisados (ya no existen ni se respaldan): LXC 253 (era clawdbot → migrado a CT100) y LXC 249 (beszel, retirado).

PBS verify-jobs: configurados en PBS UI, corren semanalmente. Verifican integridad de chunks. Si fallan, quedan visibles en la PBS UI (no hay regla Prometheus dedicada hoy; las alertas PBS activas son pbs_datastore_main_high/critical).

Replicación PVE (zfs-send incremental)

Definida en /etc/pve/replication.cfg. Schedule */15 (cada 15 min). NO es backup — es snapshot incremental para failover rápido. Solo guarda último snapshot común.

Source Target Guests
proxmox2 → proxmox LXC 123, 155 replica every 15 min
proxmox → proxmox2 VM 171 (HA) replica every 15 min

VM 208 NO replica (12 GB RAM, 140 GB disk → demasiado pesado para replicar cada 15 min en Celeron N5095).

Loki — logs

Config /home/monxas/appdata/loki-config/loki-config.yaml. Compactor con retention enabled.

  • Retention: 30 días (limits_config.retention_period: 720h).
  • Reject samples >7d old: reject_old_samples_max_age: 168h (rechaza ingesta de logs viejos).
  • Compaction interval: 10 min.
  • Delete API: habilitada (deletion_mode: filter-and-delete). Procedimiento de delete request en proxmox_issues.md #15.

Prometheus — métricas

Config /home/monxas/appdata/prometheus/prometheus.yml.

  • Retention: 30d / 5GB (lo que toque primero).

journald — local en hosts

/etc/systemd/journald.conf en proxmox-50, proxmox2-51, VM 208.

  • Vacuum semanal: journalctl --vacuum-time=14d desde homelab-cleanup weekly cron.

Docker logs

/etc/docker/daemon.json en VM 208 con log-opts: - max-size: 10m - max-file: 3

= máx 30MB por container antes de rotar. Suficiente para una semana de actividad normal.

logrotate — varlogs

/etc/logrotate.d/* y limpieza extra en weekly cron homelab-cleanup: - Logs rotados (*.gz, *.N) >30d → borrados.

Detalles en log-rotation-config.md.

vzdump logs

/var/log/vzdump/*.log. Cleanup automático en weekly homelab-cleanup: - Borra logs de VMs/LXCs que ya no existen en el cluster. - No hay límite por edad (los activos se conservan).

n8n alert log (in-memory + sqlite)

Beszel Alert Direct Webhook (LXC 200) guarda últimas 200 entradas en staticData.alertLog del workflow. Se sobrescribe FIFO. Legacy — el flujo central de alertas es ahora Alertmanager (ver alerting-flow.md); beszel fue decomisado.

Healthchecks pings

/home/monxas/appdata/healthchecks en VM 208. Retention según plan self-hosted: por defecto 100 últimos pings + log retención 90d.

Monitor de frescura de backups (backup-freshness.sh)

/usr/local/sbin/backup-freshness.sh en pmx (proxmox-50), cron diario 09:00. Verifica que cada guest crítico tiene un backup en PBS más reciente que 48h; si algo está viejo o ausente alerta a Telegram vía el bot de Vera (CT100). Críticos (🔴): 100, 208, 270, 271, 280. Detalles en alerting-flow.md.

Lo que NO se guarda en ningún sitio

  • Compose files post-edit en producción sin commit: si editas compose.yaml en disco y no commiteas a stacks repo, no hay backup. Esto es por diseño — git es la fuente de verdad.
  • Configs runtime no versionadas: /home/monxas/appdata/promtail/config.yml, /home/monxas/appdata/loki-config/loki-config.yaml, /home/monxas/appdata/prometheus/prometheus.yml. Si VM 208 muere, hay que reconstruir esos ficheros (vienen incluidos en el backup PBS, así que ESTÁN cubiertos vía vzdump).
  • secrets.local.md: en disco, no en git. Backup vía vzdump de VM 208.

Lo que potencialmente debería tener backup off-site (no implementado)

  • Terramaster (PBS chunks): single-point-of-failure. Si se rompe el NAS, pierdes los 30+ días de PBS history. Mitigación pendiente: copia off-site del NAS (rclone/borg mensual a disco USB externo). Aún NO implementada. Anotado en tech-debt.md cuando se decida.