Copias de seguridad de volúmenes persistentes en Kubernetes: herramientas, CronJobs y patrones de RESTauración

En esta entrada explico de forma práctica cómo planificar y operar de manera fiable las copias de seguridad de volúmenes persistentes en Kubernetes. La palabra clave foco Kubernetes-Persistent-Volume-Backups se establece al principio, porque las copias de seguridad de almacenamiento en contenedores tienen requisitos, riesgos y patrones de RESTauración diferentes a las copias de seguridad clásicas de sistemas de archivos. El público objetivo son administradores, ingenieros de sistemas y operadores: al final deben poder decidir qué herramientas y procesos se adaptan a sus SLAs y cómo operacionalizar la rutina, las pruebas y las estrategias de reversión.

Por qué las copias de seguridad de volúmenes persistentes en Kubernetes son diferentes

PersistentVolume (PV) es en Kubernetes el objeto de almacenamiento abstracto; un PersistentVolumeClaim (PVC) es la solicitud de una aplicación a un PV. StorageClass describe la provisión (p. ej. basado en bloques o NFS). En sistemas clásicos usted protege sistemas de archivos o dispositivos de bloque directamente. En Kubernetes se añaden complejidades adicionales:

• Ciclos de vida volátiles: los Pods/StatefulSets pueden volver a enlazarse dinámicamente.
• Múltiples rutas de acceso: las exportaciones NFS/SMB y el almacenamiento basado en bloques se comportan de forma diferente ante las instantáneas.
• Consistencia de la aplicación: las bases de datos requieren quiesce o instantáneas coordinadas.

Estas diferencias implican: la herramienta de backup, el mecanismo de instantáneas y los patrones de RESTauración deben estar coordinados.

Copias de seguridad de volúmenes persistentes en Kubernetes: resumen de herramientas

Existen tres enfoques comunes, que pueden complementarse o sustituirse entre sí:

• CSI-Snapshots: instantáneas puntuales soportadas por el proveedor de almacenamiento a través del Container Storage Interface (CSI). Adecuadas para copias rápidas y consistentes a nivel de bloques; no sustituyen a un backup externo si se desea protección adicional frente a fallos del almacenamiento.
• Operadores de backup como Velero o Kasten: orquestan instantáneas, protegen metadatos y pueden copiar volúmenes a repositorios externos (almacenamiento de objetos). Velero es de código abierto y ampliamente utilizado; Kasten es comercial y ofrece más integraciones.
• Backups a nivel de archivo/imagen con RESTic/Borg/rsync: montar el volumen en un Job/Pod y copiar los archivos a un repositorio. Adecuado para NAS/comparticiones de archivos y cuando las instantáneas CSI nativas no están disponibles.

Los criterios de elección son RTO (Recovery Time Objective), RPO (Recovery Point Objective), tipo de almacenamiento (NAS vs bloque), requisitos de cifrado y cumplimiento. Las instantáneas CSI ofrecen RTOs bajos; los repositorios externos aumentan la resiliencia frente a fallos de almacenamiento.

CSI-Snapshots vs. copias de seguridad reales

Una instantánea CSI es una operación de metadatos que implementa internamente el backend de almacenamiento. Es rápida y a menudo consistente para volúmenes individuales. Por qué no siempre basta:

• Las instantáneas residen en el mismo backend: un fallo de hardware o del clúster puede dañar tanto los datos de origen como los de la instantánea.
• Las instantáneas por lo general no están versionadas como los backups en almacenamiento de objetos; las políticas de retención pueden ser más complejas.
• Para consistencia entre aplicaciones (p. ej. bases de datos distribuidas) se requieren mecanismos de quiesce coordinados.

Por eso muchos equipos combinan instantáneas CSI (para RESTauraciones rápidas) con copias de seguridad externas periódicas (para recuperación ante desastres).

CronJobs de backup en Kubernetes: patrones y buenas prácticas

Para copias de archivos sencillas o backups complementarios los operadores usan CronJobs de Kubernetes (objeto de Kubernetes para jobs programados). Son importantes la idempotencia, el bloqueo, el registro y códigos de salida claros.

Ejemplo: CronJob que monta un PVC en un Pod de copia de seguridad y ejecuta rsync hacia un NAS. Este patrón es adecuado para NFS-PV o cuando no existen CSI‑Snapshots.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: pvc-rsync-backup
spec:
  schedule: "0 2 * * *" # täglich 02:00
  jobTemplate:
    spec:
      template:
        spec:
          RESTartPolicy: OnFailure
          volumes:
            - name: data
              persistentVolumeClaim:
                claimName: my-app-pvc
          containers:
            - name: backup
              image: alpine:3.18
              command: ["/bin/sh", "-c"]
              args:
                - |
                  set -euo pipefail
                  mountpoint -q /data || (echo "PVC not mounted"; exit 2)
                  rsync -a --delete /data/ /backup-nfs/my-app/$(date +%F)/
              volumeMounts:
                - name: data
                  mountPath: /data
          nodeSelector:
            backup: "true"

Por qué funciona este patrón: Un Job monta el PVC en un Pod independiente, realiza una copia a nivel de archivos y escribe en un recurso NAS separado que está fuera del almacenamiento de Kubernetes. Esto desacopla la retención de las copias de seguridad del backend del PV.

Cuándo falla: cuando hay archivos abiertos, los datos se escriben de forma inconsistente (WAL de la base de datos no vaciado), o el Pod de copia de seguridad se ejecuta en un Node que no tiene rutas de red adecuadas hacia el NAS.

Complementos prácticos para CronJobs

• Bloqueo con ConfigMap/Lease, para evitar que varios Jobs se ejecuten simultáneamente.
• Registro expuesto (p. ej. stdout → Log‑Collector) y política de códigos de salida (Exit‑Code-Policy), para evitar fallos silenciosos.
• Límites de recursos (Resource Limits) y NodeSelectors para estabilidad de red e I/O.

Ejemplo: bloqueo con ConfigMap

Un bloqueo sencillo puede implementarse mediante una ConfigMap o un Lease. Este patrón impide la ejecución paralela de Jobs:

#!/bin/bash
set -euo pipefail
LOCK_NAME=my-backup-lock
NAMESPACE=backup
# Try to create ConfigMap as lock
kubectl -n "$NAMESPACE" create configmap "$LOCK_NAME" --from-literal=owner=$(hostname) --dry-run=client -o yaml | kubectl apply -f -
# Check owner (simple approach)
OWNER=$(kubectl -n "$NAMESPACE" get configmap "$LOCK_NAME" -o jsonpath='{.data.owner}')
if [ "$OWNER" != "$(hostname)" ]; then
  echo "Another backup is running (owner=$OWNER)"; exit 3
fi
# Run backup here
# On exit (trap) delete lock

Patrones de RESTauración: RESTauración de PVC, clonación y recuperación de la aplicación

La RESTauración tiene varios niveles: recuperación del volumen, re-vinculación del Pod/StatefulSet y reconstrucción de la aplicación (p. ej. recuperación de base de datos). Tres patrones comunes:

1. RESTauración de volumen a través del backend de almacenamiento (CSI Snapshot RESTore): Snapshot → nuevo PV → PVC se vincula al nuevo PV. Ventaja: rápida, a nivel de bloque. Desventaja: posiblemente los mismos riesgos del almacenamiento.
2. Objeto/Repositorio → RESTauración a nivel de archivos: copiar la copia de seguridad desde un object storage o NAS a un nuevo PVC. Ventaja: comprobación sencilla antes de montar en producción. Desventaja: tiempo requerido.
3. RESTauración con conocimiento de la aplicación: p. ej. RESTauración puntual (Point‑in‑Time) de DB con reproducción de WAL. Aquí la RESTauración debe RESTablecer el estado de la aplicación (esquema, logs, índices).

Ejemplo: RESTaurar un PVC desde una copia de seguridad de objetos (nivel de archivos)

Pasos:

• Crear un nuevo PVC con la misma StorageClass, pero con un nombre temporal.
• Arrancar un Pod que monte el PVC y copie la copia de seguridad al volumen.
• Realizar comprobaciones de integridad (sumas de verificación, recuento de archivos).
• Apuntar la aplicación productiva y sustituir el PVC o ajustar el Deployment.

# Beispiel: RESTore-Skript im RESTore-Pod
set -euo pipefail
BACKUP_PATH=/backup-nfs/my-app/2026-07-27/
TARGET=/data
rsync -a --delete "$BACKUP_PATH" "$TARGET/"
# einfache Integritätsprüfung
find "$TARGET" -type f -exec sha256sum {} ; > /tmp/RESTore.sha256
# optional: vergleichen mit manifestierter Prüfsumme

Consistencia para bases de datos y NAS: Quiesce, Flush y WAL

En bases de datos, una mera copia de archivos a menudo es insuficiente. Se requieren:

• Quiesce oder Flush: indicar a la aplicación que vacíe los cachés (p. ej. MySQL FLUSH TABLES WITH READ LOCK), para que los archivos sean consistentes.
• WAL/Transaction Logs: Para Point-in-Time‑Recovery (PITR) los registros de transacciones deben archivarse por separado.

En comparticiones de archivos NAS (NFS/SMB) pueden surgir problemas adicionales: descriptores abiertos, bloqueos de archivos y UID/GID distribuidos. El job de backup debe manejar archivos abiertos y, idealmente, iniciar procesos coordinados para el momento de la copia.

NAS‑How‑To: Mejores prácticas, resolución de problemas y lista de verificación

El NAS en Kubernetes suele proporcionarse mediante NFS o SMB. Ese tipo de comparticiones de archivos tiene trampas propias que causan problemas con regularidad en la operación.

Aspectos que debe priorizar

• Consistencia de UID/GID: los IDs de usuario y grupos deben coincidir entre el clúster y el NAS o gestionarse mediante una capa de mapeo; de lo contrario, los permisos no serán correctos tras la RESTauración.
• Comprobar descriptores abiertos: antes del backup debe identificar descriptores de archivos abiertos y bloqueos, porque rsync/Copy podría copiar datos inconsistentes.
• Cuotas y monitorización: los volúmenes destino NAS deben supervisarse; si no, el almacenamiento de backup se llenará y los jobs fallarán silenciosamente.

Pasos concretos de verificación (resolución de problemas)

Comandos de ejemplo que ayudan en la resolución de problemas:

# offene Handles auf einem gemounteten NAS prüfen
lsof +D /data | head
# prüfen, welche Prozesse auf NFS Dateien halten
fuser -m /data
# Platz prüfen auf NAS-Mount
df -h /backup-nfs
# Berechtigungen eines Beispieldatei prüfen
stat -c '%U %G %a' /data/somefile

Interpretación: lsof/fuser muestran procesos con descriptores abiertos. Si procesos de BD importantes mantienen logs abiertos, antes del backup debe realizarse un Flush/Quiesce o emplearse mecanismos de snapshot o soportados por el proveedor.

Rsync: chunking y rendimiento

Para conjuntos de archivos muy grandes ayuda dividir y transferir en paralelo, combinado con un destino que deduplica (p. ej. NAS con deduplicación o almacenamiento de objetos con dedupe). Ejemplo de GNU Parallel con rsync:

# chunked rsync: find list of top-level dirs and sync in parallel
cd /data
find . -maxdepth 1 -mindepth 1 -type d -print0 | 
  xargs -0 -n1 -P4 -I{} rsync -a --delete "{}" /backup-nfs/my-app/$(date +%F)/"{}"

Precaución: la sincronización paralela puede generar picos de I/O; ajuste el número de procesos paralelos a los límites de I/O del nodo.

Lista de verificación para backups NAS

• Previo: comprobar cuotas de almacenamiento; planificar espacio destino > 2× el tamaño de backup esperado.
• Antes del job: comprobar descriptores abiertos (lsof/fuser) y ejecutar flush de la base de datos.
• Durante el job: medir logging, códigos de salida y tasa de transferencia.
• Después del job: verificar sumas de comprobación, conteo de archivos y limpieza de retenciones (Purge).

Velero & Repositorio de objetos: Kurzer Praxis‑Workflow

Velero (Open Source) orquesta backups a nivel de clúster de recursos y volúmenes. Para PVs Velero utiliza CSI‑Snapshots (si están disponibles) o backups de volúmenes basados en plugins. Los pasos típicos son:

1. Instalar con el plugin del proveedor (p. ej. S3/MinIO/AWS S3).
2. Configurar los horarios de backup e integración RESTic/CSI para los datos de volúmenes.
3. Realizar ejercicios de RESTauración periódicos.

Ejemplo de CLI: copia de seguridad de un Namespace incluyendo volúmenes (Velero & RESTic):

# Velero Backup starten
velero backup create myapp-backup-$(date +%F) --include-namespaces my-app-namespace --snapshot-volumes
# Status prüfen
velero backup get
# RESTore (in Test-namespace)
velero RESTore create --from-backup myapp-backup-2026-07-27 --namespace-mappings my-app-namespace:RESTore-test

Velero ofrece gestión de metadatos y una orquestación de RESTauraciones sencilla; la integración con RESTic es recomendable si desea almacenar a nivel de archivos en un almacenamiento de objetos.

Kubernetes-Persistent-Volume-Backups: Monitoring, Metriken und Alerts

Operationalizar significa medir indicadores. Métricas importantes:

• Backup success rate (proporción de trabajos exitosos).
• Backup duration (duración por trabajo).
• RESTore duration y RESTore success rate.
• Repository free space y Growth rate.

Prometheus es adecuado para la recopilación; ejemplo de AlertRule para backups fallidos:

groups:
- name: backup.rules
  rules:
  - alert: BackupFailures
    expr: increase(kube_job_status_failed{job="pvc-rsync-backup"}[24h]) > 0
    for: 1h
    labels:
      severity: page
    annotations:
      summary: "Backup-Job fehlgeschlagen"
      description: "Mindestens ein Backup-Job ist innerhalb der letzten 24h fehlgeschlagen."

Importante: las alertas deben estar vinculadas a runbooks que verifiquen si se trata de problemas de configuración/almacenamiento o de una caída de red transitoria.

RESTore‑Validation: Automatisierte Prüfungen und Testplan

La validación es obligatoria. Una prueba de recuperación debe ejecutar siempre de forma automatizada los siguientes pasos:

1. Realizar la RESTauración en un namespace de aislamiento.
2. Montar el PVC RESTaurado y ejecutar comprobaciones de integridad de archivos (sumas de comprobación, recuento de archivos).
3. Prueba básica de la aplicación: endpoint de salud, ejecutar un proceso de negocio mínimo.
4. Consistencia de la BD: comprobar índices, estado de replicación, WAL/lag de replicación.
5. Registro de tiempos: documentar el tiempo requerido (para informes RTO).

Ejemplo de Smoke‑Check como script (véase más arriba en el artículo). Automatice estas pruebas en una pipeline CI/CD o como parte de la cadena de jobs de backup, para que las comprobaciones de sanidad diarias se ejecuten sin intervención manual.

Praxisfälle, Risiken und typische Stolperfallen

Causas frecuentes de backups/RESTores fallidos:

• Repositorio de backup lleno o NAS: los jobs fallan silenciosamente cuando no hay espacio.
• RESTricciones de red: los jobs de backup en nodos sin acceso al almacenamiento de objetos o al NAS no pueden completarse.
• Desajuste de permisos tras la RESTauración: UID/GID o ACLs no coinciden, las aplicaciones no arrancan.
• Códigos de salida ignorados: CronJobs que no exportan errores parecen exitosos aunque las operaciones de copia hayan fallado.

Lista de comprobación antes del despliegue en producción:

• Mapeo de SLA: definir RTO/RPO.
• Probar el aprovisionamiento de almacenamiento (CSI Snapshot & RESTore).
• Verificar la ruta de red desde el nodo de backup hasta el repositorio.
• Implementar verificación automatizada de RESTauraciones.

Aspectos de seguridad y cumplimiento

El cifrado, la gestión de claves y el registro de accesos son obligatorios para datos sensibles. Los repositorios deberían estar cifrados del lado del servidor; además es recomendable almacenar las claves por separado, por ejemplo en un HSM o en Vault (HashiCorp Vault es una herramienta de gestión de secretos que administra las claves de forma segura). Los registros de auditoría y las sumas de comprobación ayudan a demostrar el cumplimiento.

Estrategia de rollback y de emergencia

Una RESTauración puede fallar. Planifique rollbacks escalonados:

1. Conmutación por error a un standby (si está disponible).
2. RESTauración en un namespace aislado para validación.
3. Conmutar la producción al PVC probado solo después de pruebas de humo exitosas.

Documente los pasos del despliegue y las responsabilidades, de modo que en caso de incidente no se pierda tiempo en coordinaciones.

Recomendaciones y conclusión

En resumen, recomiendo la siguiente hoja de ruta pragmática:

1. Defina RTO/RPO y verifique la funcionalidad de StorageClass/CSI‑Snapshot.
2. Combine CSI‑Snapshots (para RESTauraciones rápidas) con copias de seguridad en repositorios externos (para escenarios de DR y cumplimiento).
3. Utilice CronJobs solo para copias de seguridad a nivel de fichero cuando CSI no esté disponible; implemente mecanismos de locking y un registro limpio (logging).
4. Medidas específicas para NAS: comprobar handles abiertos, garantizar la consistencia de UID/GID y planificar transferencias por fragmentos (chunked transfer).
5. Automatice y pruebe regularmente las rutas de RESTauración; integre pruebas de humo en las CI/CD‑Pipelines.

Con esta estructura reduce los riesgos operativos y crea procesos de RESTauración repetibles que hacen manejable el día a día de administradores y equipos de operaciones.

Lecturas adicionales y opciones de enlaces internos

Esta entrada está concebida como una guía técnica y puede ampliarse con artículos existentes sobre mantenimiento de copias de seguridad, arquitectura de red para ventanas de copia de seguridad y validación de RESTauraciones. Aquí puede ser útil insertar enlaces internos a listas de verificación y playbooks de RESTauración.

Preguntas frecuentes

Las preguntas y respuestas más importantes para una orientación rápida se encuentran en la sección siguiente.