Backup retention policies

Última revisión PBS: 2026-10-20, 13:15CEST, configuración y capacidad por metadata. Las demás políticas conservan referencia histórica de 2026-08-01, pendiente de revalidación.

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): configuración observada20oct13:15CEST

Lectura pasiva: CT186 running en proxmox, propietario resuelto mediante API de cluster antes de consultar PBS. Se leyeron selección PVE, prune/sync y statvfs; no se ejecutaron backups, poda, GC, verify, restore ni cambios de calendario. Configuración no acredita que cada ejecución haya terminado o sea restaurable.

Selección de los siete jobs PVE

Todos están habilitados, con destino pbs y política por job keep-last=3, keep-weekly=4, keep-monthly=3.

Job / horario	VMID seleccionados
backup-lxc-terra · 01:00	123,155,204,212,213,301,302,303,214,215,216,218,217,219,220
backup-node2-terra · 02:00	200
backup-wp-pulse-281 · 02:00	281
backup-vm-terra · 03:00	208,171
Job de CT100 · 04:30	100
Edge · 05:00	270,271,280
Misc · 05:30	110,172,186,251,305

CT186 está ahora seleccionado en el job05:30: sustituye la afirmación de agosto que lo excluía. Esto no prueba que su copia finalice ni que incluya los chunks de los datastores. No se ha revalidado aquí el contenido de sus mounts ni un restore. La selección CT100 es sólo metadata PVE; el trabajo paralelo de Vera no se toca.

Retención PBS y segunda historia local

Job PBS	Datastore	Horario	Política observada
main-prune	main	daily	daily2, weekly1
archive-prune	archive	daily	daily7, weekly8, monthly12
main-to-archive	destino archive	06:00	remoto local-self, datastore origen main

La política del servidor puede eliminar snapshots aunque el job PVE declare más retención; ambas capas importan. Los contadores keep seleccionan versiones por periodo, no garantizan una ventana continua si faltan ejecuciones válidas. archive se alimenta del sync de main: queda resuelto el TODO de agosto sobre su origen. La retención daily14 de aquel documento ya no describe la actual.

Archive usa el loop/ext4 del montaje protegido sobre TerraMaster, según la evidencia del guard y recuperación. La lectura actual encuentra dos entradas superpuestas en /archive (bind/ext4 y loop0/ext4); statvfs refleja capacidad de1,5TiB. No se interpreta ese montaje superpuesto como dos copias. Tampoco constituye una ubicación offsite ni hace independiente del NAS la historia de archive.

Path consultado	Total GiB	Disponible GiB (f_bavail)	Libre GiB (f_bfree)
/datastore	475,54	155,50	155,50
/archive	1510,82	186,35	258,05

Son muestras puntuales, no tendencia ni presupuesto de crecimiento. En archive, libre y disponible difieren: no se suman ni se presume que todo el libre sea utilizable por el servicio. No se ha reducido retención ni elevado umbrales.

La revisión del19oct observó GC/prune/sync correctos y verify de main17oct/archive18oct; son resultados fechados, no revalidados por consultar la configuración hoy. Detalle y límites de recuperación.

Historial de julio/agosto: main tuvo presión de capacidad y reducciones sucesivas de política; los650GB/41% y archive54% publicados entonces son históricos. Las muestras actuales de esta sección sustituyen esas cifras como referencia vigente.

Historial local de mantenimiento revisado20oct17:59 CEST

La lectura acotada de logs locales corrobora archive prune OK del20oct00:00:01. El GC iniciado a las00:00 tiene registro de fin00:02:31 con estado UNKNOWN y sin terminal de éxito verificado: no sustituye al GC correcto fechado del19oct ni demuestra bytes recuperables. El horario daily procede de la lectura histórica del19oct23:52–23:58; no se revalidó su configuración actual ni se forzó ejecución, retención o limpieza.

Resto del documento: referencia histórica de agosto

Las secciones siguientes conservan su fecha de origen y no se han revalidado en esta pasada. En particular, ubicaciones de observabilidad y recursos de VM208 pueden haber cambiado: consultar el inventario fechado actual y la cobertura de CT217 antes de usarlas como procedimiento de recuperación o descripción del runtime.

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 (verificado en vivo 2026-08-01: script presente, cron activo). 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, ahora 192.168.0.XXX). 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.