Crea tu propio sistema de respaldos – Parte 1: estrategia antes de los scripts

• La importancia de los respaldos suele estar subestimada
• Muchas personas se conforman con la dependencia de la nube y no reconocen su responsabilidad en la protección de los datos
• Confiar en una simple copia sin establecer un plan de respaldos implica un riesgo alto
• Los métodos de respaldo de disco completo o de archivos individuales tienen ventajas y desventajas propias
• Un respaldo confiable tiene como elementos clave el uso de snapshots y contar con almacenamiento externo

---

La importancia de los respaldos y la realidad

• Los respaldos son un área que mucha gente no toma con la seriedad suficiente
• Se pierden enormes cantidades de datos por métodos incorrectos o errores conceptuales (por ejemplo, RAID no es un respaldo)
• Los datos son un activo importante que debe preservarse de distintas maneras

Malentendidos sobre la nube y los respaldos

• A menudo se deja toda la información en la nube sin preguntar realmente cómo se están protegiendo esos datos
• Incluso los principales proveedores de nube aplican un modelo de responsabilidad compartida
  • Ellos brindan seguridad de la infraestructura, pero la responsabilidad de proteger los datos recae en el usuario
• En entornos como la nube, servidores privados o Kubernetes, el riesgo de no tener respaldos también es frecuente

La experiencia del autor con la recuperación de datos

• Ha vivido varios casos de pérdida de datos: incendios en centros de datos, inundaciones en salas de servidores, terremotos, ransomware, ataques maliciosos y errores de administradores
• En servidores conectados a internet (e-commerce, correo, etc.), tanto la integridad de los datos como la continuidad del servicio son importantes
• Un respaldo no es una simple copia. En especial, copiar archivos de una base de datos en uso aumenta la posibilidad de que no se puedan recuperar

Preguntas esenciales para definir una estrategia de respaldo

• "¿Cuánto riesgo estás dispuesto a asumir?", "¿Qué datos debes proteger?", "¿Cuánto tiempo de inactividad es aceptable si se pierden los datos?", "¿Cuánto espacio de almacenamiento hay disponible?"
• Guardar el respaldo en la misma máquina no sirve si la máquina falla. Respaldar hacia almacenamiento externo es más seguro
• También hay que considerar factores prácticos como el ancho de banda de red, la velocidad de recuperación y el espacio de almacenamiento

Disco completo vs respaldo por archivos

Respaldo de disco completo

• Ventajas
  • Permite una recuperación completa. Se puede restaurar rápidamente el sistema a un estado anterior
  • Es útil en combinación con sistemas de virtualización. Soluciones como Proxmox facilitan este tipo de respaldo completo
  • Algunas soluciones también permiten la recuperación de archivos individuales desde un respaldo completo
• Desventajas
  • En servidores físicos se requiere tiempo de inactividad
  • Consume mucho espacio y guarda incluso datos innecesarios
  • Según las características del sistema de archivos, puede ser lento o presentar problemas de compatibilidad

Respaldo por archivos individuales

• Ventajas
  • Puede hacerse con utilidades básicas del sistema (tar, cp, rsync, etc.)
  • Permite respaldar solo los cambios, reduciendo el espacio y el volumen de transferencia
  • Ofrece flexibilidad para recuperar archivos específicos, moverlos, comprimirlos y deduplicarlos
  • Puede operarse sin interrumpir el sistema
• Desventajas
  • Una copia simple puede requerir mucho espacio de almacenamiento
  • Respaldar un sistema de archivos en uso sin snapshots puede causar inconsistencias y errores

Respaldos con snapshots

• Cuando el objetivo del respaldo es un sistema de archivos en uso, los datos pueden cambiar entre el “inicio” y el “fin” del respaldo, rompiendo la consistencia de los datos
• En bases de datos abiertas como MySQL o incluso historiales del navegador, hay casos en los que copiar archivos no permite una recuperación posible
• Para garantizar un respaldo consistente, primero hay que aprovechar la función de snapshot del sistema de archivos
• Métodos representativos
  • Snapshots nativos del sistema de archivos (sistemas compatibles con BTRFS, ZFS)
  • Snapshots de LVM: pueden desperdiciar espacio y existe la posibilidad de interrupciones del sistema al eliminar el snapshot
  • DattoBD: a veces presenta problemas de estabilidad, pero puede usarse en combinación con UrBackup

Método de respaldo: Push vs Pull

• Push: el sistema a respaldar se conecta al servidor y envía los datos
• Pull: un servidor central de respaldos se conecta a cada servidor y realiza el respaldo
• Por seguridad, es más seguro el enfoque Pull, donde el servidor de respaldos bloquea accesos externos y solo accede a los clientes cuando es necesario
  • Para evitar que los datos de respaldo sean eliminados en caso de intrusión o ransomware, también se conservan por largo plazo snapshots del propio servidor de respaldos

Características principales de un sistema de respaldo recomendado

• Recuperación inmediata y procesamiento rápido
• Almacenamiento en ubicación externa (aunque los snapshots locales se mantienen para rollback inmediato)
• Se recomienda no usar nubes comerciales como Google Drive o Dropbox. Los datos deben mantenerse bajo control propio
• Gestión eficiente del espacio con compresión, deduplicación y similares
• Debe minimizarse la cantidad de componentes adicionales necesarios para operar

Próximas entregas

• Se presentarán distintos escenarios de respaldo, además de los servidores realmente usados, configuraciones principales y diversos programas y tecnologías
• En la próxima entrega se explicará cómo construir un servidor de respaldos basado en FreeBSD

[GN⁺]

Comentarios de Hacker News

• Las máquinas que necesariamente tienen que hacer respaldos en modo "push" deben estar restringidas para que solo puedan acceder a su propio espacio, y más importante aún, el servidor de respaldos debe conservar sus propios snapshots del sistema de archivos durante cierto tiempo por seguridad; así, incluso en el peor caso de que la carga de trabajo se vea comprometida, acceda al servidor de respaldos y borre los respaldos para pedir rescate, todavía quedan snapshots en el servidor. Mi método preferido es permitir que el cliente solo escriba respaldos nuevos y no pueda borrar nada; los borrados se gestionan con un procedimiento aparte (manual o con cron, por ejemplo). Esto puede implementarse en rsync/ssh con la función de comando permitido en .ssh/authorized_keys.

  • Yo uso ambas cosas. Sí, hay que guardar el respaldo en dos lugares, pero esa estructura de respaldo dual era justo lo que buscaba desde el principio. Las fuentes de respaldo hacen push a una ubicación intermedia, y el almacenamiento principal de respaldos hace pull desde ahí. La ubicación intermedia conserva snapshots, pero con poca capacidad, y ni el almacenamiento principal ni las fuentes se autentican entre sí en absoluto; cada uno solo puede autenticarse con la ubicación intermedia y tampoco hay autenticación en sentido inverso. Aunque una o dos de esas tres ubicaciones sean comprometidas, es muy probable que la restante siga a salvo. Los respaldos de certificados los trato completamente por separado para que nunca terminen todos en servidores conectados a internet. Los datos realmente importantes además tienen respaldo offline adicional. La separación estructural vuelve más incómoda la verificación real del respaldo, pero el almacenamiento de respaldos valida checksums periódicamente y envía los resultados al host intermedio, comparándolos con los hashes generados en el host original para detectar eventos de corrupción. Con esta configuración termino teniendo una especie de respaldo "semi-offline" en el que la fuente no puede dañar directamente los propios snapshots del respaldo.

  • Otra opción es usar un contenedor separado o un usuario dedicado solo para respaldos. Por ejemplo, systemd-nspawn puede usarse como una jail chroot ligera, y dentro incluso se puede bloquear por completo la ejecución de rm. Basta con crear un chroot con pacman/pacstrap, y administrarlo con systemd-nspawn/machinectl. Este enfoque es flexible porque permite, casi igual que con systemd normal, controlar acceso, restringir rutas de archivos, limitar memoria/CPU, permitir acceso solo desde ciertos rangos de IP, detallar condiciones de arranque y mucho más. También se pueden aprovechar subvolúmenes de BTRFS y, si hace falta, separar completamente todo el sistema con systemd-vmspawn. Automatizar clonaciones con importctl también es muy cómodo.

  • Yo prefiero un modelo pull en el que “el servidor de respaldos no tiene absolutamente ningún privilegio sobre los servidores respaldados”. Aunque el servidor en producción sea comprometido con privilegios de root, el sistema de respaldo no se ve afectado.

  • Yo uso rclone copy para los respaldos, con una API key que no tiene permisos para borrar objetos. Si sincronizas con algo como rclone sync, podrías terminar borrándolo todo, así que este método es más seguro.

  • Ojalá syncoid tuviera una opción donde “el cliente solo copie snapshots/respaldos y el borrado lo administre directamente el servidor de respaldos”. Ahora mismo hay que dar permisos de borrado y eso es una lástima.

• Sorprendentemente, muchísima gente no considera importantes los respaldos. Pasa tanto en empresas grandes como pequeñas. Una empresa a la que asesoro, con ingresos anuales de 1,000 millones de euros, no tenía respaldos propios y dependía solo de copias de disco irregulares hechas por su proveedor de datacenter. Nunca habían hecho por su cuenta una prueba de restauración. Hace poco, por un error de un usuario, se perdió por completo la base de datos de producción, y el respaldo más reciente era de cuatro días antes, así que tuvieron que reconstruir todas las transacciones de ese periodo. Pero incluso después de algo así, nadie quedó en shock; simplemente siguieron como si nada.

  • Parece que piensan que está bien siempre que no sea realmente fatal para el negocio.

  • También es común ver que complican excesivamente los requisitos de respaldo.

  • Quizá también se deba a temas legales. Por litigios o por obligaciones de conservación legal, el propio respaldo puede convertirse en un factor de riesgo.

  • Es un efecto secundario de las políticas de recuperación ante desastres auditadas para SOC 2. En una empresa donde trabajé, revisamos las políticas de recuperación ante desastres de todos los equipos, todas aprobadas para SOC 2, y la conclusión fue que, si ocurría un incidente realmente grande, cerrar la empresa e irse a casa probablemente sería más rápido que una recuperación normal.

  • Si de verdad perdieron cuatro días completos de una base de datos de producción, me pregunto si los clientes no se enfurecieron. En una empresa de ese tamaño suena como un golpe enorme, así que me da curiosidad saber cómo lo manejaron realmente.

• Gracias por compartir esto. Llevo 10 años desarrollando software de respaldo y recuperación ante desastres, y hay una frase que siempre sale: “nunca le diría a un amigo que construya su propia solución de backup/DR”. Montar BCDR está lleno de trampas fáciles de pasar por alto. Quiero compartir algunos puntos clave. Un respaldo no es “recuperación ante desastres”. Cuando ocurre un incidente real, tienes que poder restaurar en minutos u horas para mantener la confianza del negocio. El tiempo objetivo de recuperación (RTO) y el punto objetivo de recuperación (RPO) son la clave. La simple replicación de archivos con rsync copy no produce un respaldo puntual porque el sistema de archivos sigue cambiando constantemente. Un respaldo puntual correcto necesita ser “crash-consistent” o “application-consistent”; en el segundo caso, las aplicaciones importantes guardan su estado en disco y se configuran para detenerse durante el respaldo. Funciones como Microsoft VSS cubren esta parte. Nunca hay que confiar ciegamente en una copia con rsync ni siquiera en respaldos crash-consistent. A los dispositivos de almacenamiento siempre se les aplica la ley de Murphy, así que es indispensable tener respaldos en varias ubicaciones (estrategia 3-2-1). Por experiencia directa, todos los tipos de disco fallan. Los NVMe SSD > SSD > HDD pueden ser más durables en ese orden, pero no hay excepciones. Tengo mucho más que escribir, pero ya es tarde y lo dejo hasta aquí.

  • La analogía 3-2-1 es de otra época. Hoy la cantidad de ubicaciones para guardar datos es ilimitada, así que son aún más importantes los snapshots locales, la replicación remota y los respaldos dobles o triples con métodos distintos. Yo uso snapshots base con zfs y además Borg, y con esa combinación alcanza para casi cualquier desastre.

  • Esa frase me recordó algo parecido que escuché en un concierto de Alice in Chains. Las soluciones BCDR son un símbolo de confianza entre empresas. Estos sistemas protegen datos por decenas o cientos de billones, y si yo fuera CTO nunca pondría los respaldos de una empresa en manos de un enfoque open source. El gasto de TI de las empresas aumenta gradualmente en línea con el valor de la mayoría de sus activos y con sus estrategias contra el vendor lock-in. Por experiencia profesional, en prevención de ransomware lo esencial es la inmutabilidad, los respaldos WORM, y también he visto muchos casos problemáticos en TI gubernamental por incumplimiento normativo. Los proveedores de BCDR usan el ransomware como argumento de venta, pero la verdadera inmutabilidad se demuestra cuando los datos se replican entre varios espacios. Ahí es donde la estrategia 3-2-1 muestra su valor. Me gustaría escuchar más opiniones sobre principios adicionales de respaldo.

  • Si usas un NAS, es mejor no poner en ambos lados discos duros del mismo fabricante y del mismo modelo.

  • Estoy completamente de acuerdo con “los respaldos en varias ubicaciones son imprescindibles (3-2-1)”. Pero para la mayoría de las personas el “1” (offsite) es prácticamente imposible, y al final, salvo que uses un servicio de backup, ya ni vale la pena montar respaldos por tu cuenta. No conozco a nadie fuera de mi ciudad que vaya a tener una computadora encendida 24/7 y además administrarla por mí.

  • Sobre “nunca deberías confiar en rsync copy ni siquiera en respaldos con consistencia de crash”, al final eso lleva a la conclusión de que, como todos los sistemas y servicios se pueden reconstruir con herramientas de infraestructura, basta con respaldar activamente la base de datos y el almacenamiento de archivos/objetos. Respaldar VMs completas de forma compleja no tiene mucho sentido real.

• Es un texto limpio, pero le falta un punto importante: un sistema de respaldo realmente bueno debe tener claro qué tan rápido y con qué procedimiento se puede restaurar. Lo he visto muchas veces: la gente se tranquiliza porque “el respaldo está bien”, pero al restaurar solo recuperan una parte o tardan varios días, causando pérdidas enormes. Una herramienta llamada restic permite respaldos tipo snapshot con deduplicación a nivel de archivo, así que es útil cuando no tienes un sistema de archivos con snapshots como ZFS. Y cuando el respaldo es de tipo “push”, el ransomware puede borrar también el respaldo, así que el modelo correcto es “pull”. Si va a ser push, me parece mejor usar medios de solo lectura (como Bluray) o al menos tener recuperación puntual posible con auto-snapshot/ZFS.

  • Aunque el ransomware pueda borrar incluso el respaldo push, no hay problema si restringes bien los permisos del servidor. Borg y Restic permiten garantizar modo append-only por ssh, y localmente voy rotando discos de respaldo offline como última línea de defensa. El método real está aquí.

  • Me pregunto si, usando el modo append-only de restic y haciendo el pruning periódicamente solo dentro del servidor, entonces no haría falta usar el modelo pull. Según entiendo, esa es la recomendación oficial de restic para prevenir ransomware.

  • “La velocidad de restauración” realmente depende mucho del requisito. Si el respaldo de las fotos familiares tarda seis meses en restaurarse, a mí me parece bien.

  • En lugar de medios de solo lectura, otra alternativa es un servidor push con permisos restringidos. Por ejemplo, permitir en ssh solo scp, limitarlo a un entorno chroot y hacer respaldos con rotación diaria de carpetas; así, aunque haya ransomware, no puede borrar los datos antiguos. Yo también manejo mi procedimiento de respaldo con un servidor ssh que solo permite chroot + scp, y además uso en paralelo medios de solo lectura.

• Yo no necesito un sistema de respaldo aparte; me bastaría con una forma estandarizada y eficiente de reunir 25 años de fotos de una familia de cuatro personas (teléfonos, cámaras, descargas, escaneos, etc.). Hasta ahora no he encontrado un método que me deje satisfecho.

  • Yo tengo Immich montado en un NAS, y respaldo diariamente los medios y el dump de la base de datos de Immich en AWS S3 Deep Archive. Immich ofrece suficiente funcionalidad tipo Google Photos, y si agregas fotos de escritorio o escaneos al NAS, Immich las importa automáticamente. Para un usuario de HN, configurarlo no debería ser difícil.

  • Bromeando con si “25 años de fotos” era una unidad de datos norteamericana, en realidad señalaría que sí necesitas obligatoriamente un sistema de respaldo. Yo hago correr syncthing en malla entre gnu/linux/windows/android, hago snapshots periódicos del archivo en dos VMs Debian y luego un respaldo secundario con borgbackup. Mi RPO es de 24 horas, aunque podría reducirse si quisiera. Eso sí, en dispositivos Apple esta configuración no encaja porque syncthing no puede correr en segundo plano. En mi caso son 500 GB de fotos y decenas o cientos de GB de otros documentos, pero gracias a los respaldos basados en diffs resulta eficiente.

  • Las descargas y los escaneos, si no son realmente importantes, al final son datos desechables. Los teléfonos y cámaras se sincronizan con Nextcloud, y hago que el respaldo funcione solo en mi red doméstica. Después el NAS hace un respaldo diario y un health check. El último paso es usar un respaldo en la nube confiable o un disco en otra casa. Con eso ya queda listo el respaldo secundario.

  • Soluciones self-hosted como PhotoPrism o Immich sirven mucho para deduplicar fotos y hacer búsquedas/etiquetado. Para respaldo en la nube puedes usar la combinación Backblaze B2 + Cryptomator, con almacenamiento cifrado y un script casero de subida. Sale como a 1 dólar al mes por TB.

  • Yo uso syncthing; oficialmente Android no está soportado, pero con una versión fork funciona bien. Además recomiendo ente.io o autoalojar immich para respaldo de fotos. Los documentos conviene gestionarlos aparte con algo como paperless ngx.

• Dirvish es un wrapper ligero de rsync que realmente vale la pena probar. Ofrece excelentes funciones de rotación, incrementales, retención, scripts de pre/postproceso y más. Lleva más de 20 años salvando mis datos. Encaja muy bien con los puntos planteados en el artículo. sitio oficial de dirvish, sitio oficial de rsync

  • Me da curiosidad en qué aspectos dirvish es más fácil o mejor que rsync.

• Yo resolví de forma bastante floja, pero funcional, tanto fallas de hardware como robos. Uso una combinación de almacenamiento temporal dentro del desktop, disco externo en casa y disco externo offsite (todos Samsung T7 Shield). Hago una copia diaria con robocopy /MIR al almacenamiento temporal o al terminar el trabajo, respaldo semanal al externo y una vez al mes intercambio el externo offsite.

  • Los discos externos deberían ser al menos de lotes distintos, o mejor todavía de modelos distintos. Si son del mismo modelo y lote, suele haber más probabilidades de que fallen al mismo tiempo, especialmente cuando les metes una carga enorme durante una recuperación.

• Me cayó bien el timing para compartir mi configuración de Arch Linux y mi estrategia de respaldo. También publiqué scripts de automatización de configuración/respaldo y una capa de automatización para borg.

  • Yo automaticé con python + borg snapshots de 51 dispositivos de bloque en una SAN, respaldos de 71 sistemas de archivos y sincronización con S3. La restauración la probé realmente desde una ubicación offsite, incluso arrancando VMs, y todo funcionó sin problemas. La automatización sigue siendo compleja e incompleta, así que la velocidad de recuperación es lenta, pero lo monté a un costo muy bajo. borg de verdad es potentísimo. Cualquiera puede intentar algo así y al final resulta muy económico.

• Los datos valiosos que tengo no llegan a 100 MiB, así que respaldo dos veces por semana solo rutas seleccionadas con tar + compresión + cifrado, y mantengo una rotación de unos cuantos meses. Los guardo dentro y fuera de casa, y casi no requieren inspección ni mantenimiento. Es una configuración razonable que se automatiza sin problema con un script sh de unas pocas líneas.

  • Si mañana yo muriera de repente, vale la pena pensar qué datos realmente merecería la pena que mi familia o mis descendientes recuperaran. Tal vez, más que cientos de miles de archivos, basten unas cuantas fotos, videos y textos verdaderamente importantes.

  • Este comentario me hizo replantearme qué datos son realmente valiosos para mí. Mis fotos, incluso comprimidas, ocupan varios GB como mínimo; los contactos o las cosas menos importantes son pequeñas, y en general lo demás podría perderse sin problema. Debería guardar mejor las claves de recuperación, pero curiosamente mis cuentas más importantes ni siquiera tienen claves de recuperación. Solo las fotos ya rondan los 2 TB (la desgracia de ser fotógrafo aficionado).

• La parte más difícil de la consistencia de respaldos es que, en la práctica, es casi imposible respaldar datos de aplicaciones de forma consistente sin tumbar el servicio. Con snapshots de disco, en ese instante algún servicio puede quedar capturado a media escritura, así que al restaurar hay una probabilidad alta de volver a un estado corrupto. Los dumps de base de datos alivian bastante este problema, pero a menudo hay que hacerlos desde fuera del servicio, así que pueden coincidir con una consulta en curso. Si alguien tiene experiencia práctica con esto, me gustaría escucharla.

  • En general, las bases de datos son bastante robustas para esto, así que me parece que incluso tomando snapshots de disco en cualquier momento suelen ser suficientes como respaldo. Lo que sí me preocuparía son situaciones especiales como cachés sin batería, pero hoy en día, en estructuras tipo cloud, eso casi no existe y no suele ser un problema.

  • La estrategia también cambia según si, además de la BD, hay otros estados de la aplicación que deban capturarse o no, por ejemplo si también hay que respaldar la caché. pg_dump/mysqldump sí permiten hacer snapshots seguros de bases de datos en vivo, pero son algo lentos y generan dumps más grandes, entre otras cargas. Para evitar esto, también he visto usar en bases PostgreSQL grandes una réplica de solo lectura dedicada a respaldos: se detiene la replicación, se ejecuta el respaldo y luego se reanuda la replicación.