Gracias a ZFS, la pérdida de datos fue de apenas 10 minutos

 (mastodon.social/@chromakode)
3 puntos por GN⁺ 2023-08-24 | 1 comentarios | Compartir por WhatsApp
  • Un SSD de 2 años murió de repente, pero gracias a la replicación incremental de ZFS se pudo revivir el sistema en una unidad nueva, con una pérdida real de unos 10 minutos
  • La arquitectura consistía en tomar snapshots cada 10 minutos de todo el sistema de archivos y enviarlos a un NAS; para la automatización se usó zrepl
  • Los snapshots guardan el estado de un sistema en ejecución en un punto específico y transfieren solo los cambios, lo que permitió la replicación en segundo plano incluso en una red doméstica
  • El proceso de restauración estuvo lejos de ser una recuperación automática: hubo que ejecutar durante la noche un ZFS receive de 625 GiB y restaurar también la wrapper key de cifrado
  • Aunque ZFS tiene una carga alta de adopción inicial y mantenimiento, este caso muestra su efecto de recuperación ante desastres, incluso restaurando el estado de trabajo tras una falla real de la unidad

La pérdida tras la falla del SSD fue de 10 minutos

  • Al abrir la laptop para enviar un correo, la pantalla estaba congelada en negro; tras reiniciar, se confirmó que el SSD de 2 años había muerto
  • Después de restaurar el sistema en una unidad nueva, pudo volver a usarse, y la pérdida total de datos fue de unos 10 minutos
  • La laptop recuperada arrancó justo en el punto donde se había interrumpido, y las pestañas del navegador recuperaron el trabajo incompleto de la noche anterior
  • La idea de continuar el estado anterior en un dispositivo nuevo, como en un anuncio de Chromebook de hace 12 años, realmente funcionó en esta situación de falla

Una estructura más cercana a la replicación que a un backup

  • En lugar de simplemente hacer backup de la unidad, se usó un método de replicación de todo el sistema de archivos
  • El invierno pasado se construyó almacenamiento de red doméstico para hacer backups periódicos de computadoras usadas para trabajo creativo, y entre varias opciones se eligió la replicación incremental de ZFS
  • ZFS puede crear snapshots eficientes de un punto en el tiempo incluso en un sistema en ejecución
  • Luego, al enviarlos a otra máquina, no vuelve a transferir todos los datos, sino solo los datos modificados

Envío al NAS cada 10 minutos con zrepl

  • Para automatizar la creación de snapshots y el envío al NAS se usó zrepl
  • La configuración consistía en tomar y transferir snapshots cada 10 minutos de todo el sistema de archivos
  • Gracias a los snapshots incrementales, aun ejecutándose en segundo plano en la red doméstica, la réplica podía mantenerse actualizada
  • La última ejecución tardó 14 segundos en transferirse y envió alrededor de 64 MiB

La carga de trabajo manual que apareció durante la restauración

  • Restaurar el sistema fue un proceso que requirió aprendizaje y dependió en buena medida de trabajo manual
  • El proceso de ZFS receive de 625 GiB tuvo que ejecutarse durante toda la noche
  • Los snapshots estaban cifrados por la computadora original, por lo que el NAS no podía leer su contenido
  • Para usar realmente el backup, también hubo que restaurar la wrapper key de cifrado
  • Hasta la primera confirmación de que los datos podían descifrarse, el proceso de restauración fue muy angustiante

Costo de adopción y reemplazo de hardware

  • La configuración inicial de ZFS tuvo un costo de arranque alto, porque requería reemplazar todo el sistema de archivos
  • Su mantenimiento exige bastante conocimiento relacionado y procedimientos operativos que incluyen trabajo manual
  • Aun así, fue una suerte haber configurado la replicación antes de que el SSD fallara por primera vez, y este caso dejó en evidencia las ventajas de ZFS
  • La unidad que murió era una WD_BLACK SN850 incluida originalmente en el pedido de Framework
    • En el foro de Framework había visto casos preocupantes de esta unidad muriendo repentinamente o quedando incapaz de arrancar
  • Ese mismo día recibió por Amazon un SSD SK Hynix P41 y un Sabrent NVMe enclosure en unas 3 horas

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-08-24
Opiniones de Hacker News

  • Como usa ZFS, está mejor preparado que otros usuarios de SSD de WD o SanDisk
    https://petapixel.com/2023/08/08/sandisk-portable-ssds-are-failing-so-frequently-we-can-no-longer-recommend-them/
    https://www.theverge.com/22291828/sandisk-extreme-pro-portable-my-passport-failure-continued
    https://news.ycombinator.com/item?id=37042587
    https://www.theverge.com/23837513/western-digital-sandisk-ssd-corrupted-deleted-questions
    https://news.ycombinator.com/item?id=37188736

  • Justo antes de dejar por completo el mundo de Linux, empecé a explorar poco a poco el iceberg llamado btrfs, y me pareció bastante interesante.
    Se veía con mucho potencial en varias funciones, como innovación en backups y configuración de discos. btrfs no es ZFS, pero tiene áreas que se superponen en funcionalidad y también se acerca a un “ZFS para pobres”. Además, ZFS es algo ambiguo en cuanto a licencias, empaquetado y su inclusión dentro del kernel, así que en ciertos sistemas operativos btrfs resulta mucho más razonable.
    Una vez, en un Linux User Group, comenté que había tenido que desenchufar el cable de alimentación para reiniciar una computadora, y me regañaron muchísimo por esa estupidez y me recomendaron usar ZFS. Aunque, considerando que ese sistema era una Raspberry Pi, quizá cambie la opinión sobre cuál de las dos acciones era la más sensata.

    • Se dice que las Pi pueden sufrir corrupción del sistema de archivos, pero cada vez que instalo una imagen ejecuto un script que monta tmpfs en varias partes y desactiva la mayoría de los logs inútiles, así que nunca lo he visto directamente.
      Mientras no se maltrate la tarjeta SD, estos equipos siguen funcionando de forma muy estable. ZFS se ve realmente genial, pero aunque algún día compre un NAS, no creo que quiera gastar dinero en un equipo capaz de correr ZFS, así que probablemente terminaría usando RAID y ext4.
      Evité btrfs durante mucho tiempo porque cada pocos meses veía publicaciones de “BTRFS destruyó mis datos” y luego discusiones sobre si realmente era culpa de btrfs. Últimamente parece que veo menos de esas publicaciones, así que quizá ya sea hora de volver a echarle un vistazo.
    • Pregunto por curiosidad: ¿qué fue lo que te llevó a dejar por completo el mundo de Linux? ¿Qué podría aprender la “comunidad” de esa experiencia para mejorar para otras personas?
    • Lo único que realmente no me gusta de btrfs es que es propenso a la fragmentación.
      Especialmente en imágenes dispersas de VM, y para ese uso creo que zvol es mucho mejor.

  • Hace unos años tuvimos la plaga de capacitores, y ahora parece que estamos pasando por una plaga de almacenamiento.
    Es absurdo cómo todos los dispositivos de almacenamiento se están volviendo cada vez peores. WD está arruinando los HDD con SMR, y los fabricantes dicen que 3 años de tiempo de funcionamiento para SSD y HDD ya es demasiado; y no es broma. Solo este año se murió un SSD Kingston, que bueno, tenía unos 8 años, pero también murió un HDD portátil WD después de unos 2 años.
    Hoy Internet está lleno de problemas de pérdida de datos y vida útil. Hace 20 años los HDD tampoco eran algo eterno, pero al menos recuerdo que claramente duraban más que la vida útil práctica de la computadora con la que los comprabas.

    • Los discos duros de hoy tienen mucha más suerte que los de hace 20 años.
      Hace 20 años era la época de los infames discos IBM Deathstar, en los que el recubrimiento magnético literalmente se desprendía de los platos. También estaban los terribles discos Maxtor que morían en 1 o 2 años, y después de que Seagate compró Maxtor, durante un tiempo los discos Seagate también se volvieron inestables. Administraba un servidor con unos 8 discos y tenía que reemplazar uno casi cada año.
      En cambio, ahora ayudo a administrar un servidor ZFS con más de 20 discos, y la vida útil de los discos es de aproximadamente 4 a 5 años. Además, en esa época las computadoras se volvían obsoletas mucho más rápido. Hoy una computadora de 6 años sigue siendo perfectamente usable, pero entonces una computadora de 3 años ya se sentía bastante vieja.
    • No hay que preocuparse. Pronto los chips también empezarán a fallar después de unos años.
      Estamos chocando con los límites de escalamiento y el crecimiento exponencial se está desacelerando.
    • Personalmente, recuerdo que antes también se me averiaban de vez en cuando los HDD, tanto a mí como a gente cercana.
      Ahora casi nunca me pasa eso con SSD. Incluso un SSD Intel viejo de finales de los 2000, conocidos por tener muchos problemas, todavía funciona sin problemas en el mismo MacBook antiguo que usé durante años y luego le di a mi madre. Me da curiosidad saber cómo serán los datos reales.
    • Todos los discos WD que compré en los últimos 10 años funcionaron como esperaba. Eso incluye los de NAS comprados después de la introducción de SMR, porque me aseguré de que fueran Plus o Pro, no simplemente Red.
      También he tenido suerte con los SSD, pero en la desktop sigo dejando el directorio /home y el arreglo RAID en discos giratorios antiguos, así que uso SSD pequeños.
      Hubo dos excepciones. Saqué dos WD Red anteriores a SMR de un NAS viejo para reemplazarlos por discos más grandes; estaban en perfecto estado y los guardé en bolsas antiestáticas dentro de un cajón. Unos 2,5 años después necesitaba un disco de repuesto, los saqué y revisé, y ninguno de los dos funcionaba: uno estaba completamente muerto y el otro apenas era reconocido, pero no se podía leer. El primero no aparecía en absoluto al conectarlo; limpié todos los contactos, incluidos los pines de la PCB del controlador, pero no sirvió de nada, así que terminé tirándolo. El segundo solo pudo reutilizarse después de un reformateo completo, pero ni con testdisk hubo forma de recuperar los datos anteriores. Nunca había vivido ni esperado algo así, y sinceramente me preocupa bastante.
    • Hace unos 20 años también existían los HGST “Deathstar”, discos tan malos que hasta hubo una demanda colectiva.
      Los discos siempre morían de forma aleatoria, y esa también fue una de las razones por las que Sun creó ZFS.

  • En un resumen muy breve, el hilo de Mastodon apunta a https://zrepl.github.io.
    “zrepl es una solución integrada todo en uno para replicación ZFS”.

    • ¿Alguien sabe en qué se diferencian zrepl y sanoid/syncoid, aparte de que zrepl está escrito en Go y sanoid/syncoid son scripts en Perl?
    • Parece que hay que comunicarse con un demonio que corre en el servidor de almacenamiento.
      Por ejemplo, sería genial poder usar S3 directamente como almacenamiento.

  • Zrepl es una gran razón por la que puedo vivir como nómada digital con tranquilidad.
    Cada noche, aproximadamente una vez, se ejecuta un script que abre un pool ZFS protegido con LUKS y con un encabezado separado, y copia todos los snapshots. Ese enclosure NVME siempre está en una “bolsa” que no se separa de mí.
    Gracias a esta configuración y a NixOS, puedo provisionar una laptop nueva idéntica en unos 10 minutos. Hace poco también agregué replicación offsite, así que incluso si me asaltaran de una forma totalmente grave, la posibilidad de una pérdida seria de datos sería casi cero.
    Zrepl es un software realmente excelente. Es fácil empezar a usarlo, pero si hace falta es lo bastante sofisticado y potente como para tocar todos los puntos de ajuste. No me alcanzan los elogios.

    • Parece mucho más seguro que la mayoría de la gente, para quienes un solo robo, incendio, inundación u otro desastre puede ser el fin.
    • ¿Has probado sanoid/syncoid? ¿Qué aporta Zrepl frente a ellos?
    • Estaría bueno que escribieras cómo funciona esta configuración. Suena bastante interesante.

  • ¿Es posible que haber tomado snapshots del sistema de archivos cada 10 minutos haya contribuido a la muerte del SSD?

    • ZFS es especial y, como usa copy-on-write, el costo de crear snapshots es bajo
      Intuitivamente, parecería que incluso tomar snapshots muy frecuentes añade bastante poca escritura extra. Aun así, sería bueno contar con mediciones científicas.
      En algunos servidores que administraba antes, hacía snapshots con ZFS cada minuto, cada hora y cada día. Eliminaba los snapshots por minuto después de 60 minutos, y mediante una tarea cron en otra máquina respaldaba los snapshots horarios y diarios. Conservaba los snapshots horarios unas 72 horas, y los diarios de forma permanente. Los snapshots por minuto eran para revertir errores manuales durante migraciones SQL, y funcionaban bien.
      Hoy sigo usando ZFS en servidores FreeBSD, pero mis proyectos actuales tienen poco tráfico y los cambios importantes de datos son raros, así que en mi servidor personal hago snapshots manuales más o menos una vez por semana y disparo manualmente el respaldo desde otro servidor. Además, ahora solo hago snapshots de la parte del sistema de archivos que contiene la base de datos PostgreSQL y los datos de la aplicación. Los datos del sistema operativo ya no me preocupan tanto. Si ocurre una falla grave de hardware, reinstalo el OS, tengo anotados los valores de configuración importantes y hago que el script de respaldo copie esos valores en lugar de otras cosas varias cuando se ejecuta.
    • Es poco probable
      Los snapshots no escriben mucho, y tanto los SSD como ZFS usan copy-on-write. Es decir, el costo de escritura después de un snapshot es el mismo que antes del snapshot.
      Sin embargo, falta contexto. Ni los SSD ni ZFS se llevan bien con estar llenos o casi llenos. Si los datos de trabajo eran unos 650 GB y el disco era de 1 TB, los snapshots podrían haber hecho que el uso del disco superara fácilmente el 90%. Eso por sí solo podría haber hecho que ZFS se sintiera incómodo.
    • Según entiendo, tomar un snapshot en ZFS consiste en escribir un objeto de metadatos y algunas referencias a datos
      Si asumimos 100 GB de datos, bloques de 128K y punteros de 64 bits, los datos nuevos escritos durante el snapshot serían aproximadamente del orden de 5 MB. Hacer eso 6 veces por hora, 52,560 veces al año, daría unos 256 GB anuales si uno calcula si eso alcanza para causar desgaste prematuro del disco. Probablemente sea menos del 1% de la resistencia de escritura de un SSD. Así que me sorprendería que los snapshots cada 10 minutos fueran una causa importante.
      Podría estar equivocado, y estimé esto con ayuda de una fuente no muy confiable. Se agradecen correcciones. Aun así, si mi estimación está por encima de la realidad y, pese a eso, es poco probable que afecte la vida útil, quizá el punto en sí no tenga mucho sentido.
    • Es poco probable. Un snapshot básicamente marca los bloques escritos más recientemente y evita que los bloques anteriores se modifiquen
      ZFS es copy-on-write, así que al modificar archivos se producen las mismas escrituras; simplemente algunos datos existentes no se eliminan.
    • Según un comentario[1] en cierto sitio web naranja al azar, el tamaño mínimo de escritura de los chips flash modernos podría ser de unos 100 MB
      Entonces, una escritura de 5 MB cada 10 minutos en realidad se convertiría en 600 MB por hora, 4.8 TB por jornada laboral de 8 horas, 24 TB por semana de 40 horas, y en un disco de 1 TB eso sería 3.43 DWPD en tiempo real; durante 2 años en tiempo real, serían 2500 TBW[2].
      La resistencia oficial de escritura del SN850 es de 600 TBW, aunque por temas de garantía seguramente es una cifra conservadora. Casualmente, 2500 TB también es una cifra de resistencia común en muchos SSD de este mercado. En conjunto, no suena como algo totalmente imposible.
      Si aún está vivo, me daría curiosidad saber qué dice el controlador en los datos SMART. En Linux, ejecutar apt install smartmontools; smartctl -s on /dev/sda; smartctl -A /dev/sda debería imprimir una tabla[4]. En Windows, basta con instalar CrystalDiskInfo[3].
      1: https://news.ycombinator.com/item?id=29165202
      2: DWPD: escrituras de disco por día, TBW: Total Bytes Written, en terabytes
      3: https://crystalmark.info/en/software/crystaldiskinfo/
      4: “Pre-fail” significa que se supone que el valor debe cambiar justo antes de una falla, y “Old_age” significa que es un valor que indica antigüedad; no significa “esto está mal y va a fallar pronto” ni “este disco es viejo”. Todos los elementos siempre muestran Pre-fail y Old_age. Creo que hace mucho alguien debió haberlos renombrado a “somewhat_boolean” y “life_remain”.

  • Normalmente hago respaldos incrementales de Apple Time Machine a un servidor Synology con discos giratorios
    Cuando hago algo riesgoso o actualizo la máquina, a veces también espejo el disco interno en un SSD externo. Este método funciona bien. Restaurar desde Time Machine puede ser bastante lento, pero la mayor parte de mis datos importantes está en Git y en repositorios alojados, así que no ha sido gran problema. A veces uso Time Machine cuando quiero revertir un solo archivo.
    También tengo uno de los infames[0] discos SanDisk, pero no lo uso para nada importante. Solo contiene cosas como almacenamiento de juegos. Como soy usuario de Mac, los juegos no son un factor importante, y si eso muere no voy a llorar.
    [0] https://arstechnica.com/gadgets/2023/08/sandisk-extreme-ssds-are-worthless-multiple-lawsuits-against-wd-say/

    • Yo también uso Time Machine. Descargué la app https://tclementdev.com/timemachineeditor/ e hice que dispare manualmente respaldos de TM cada vez que la máquina está inactiva
      Parece funcionar mucho mejor que los respaldos automáticos o basados en horario de Apple.
    • Yo abandoné Time Machine. Incluso usando atalk y demás en Synology, casi nunca me funcionó correctamente por más de uno o dos meses

  • Mis snapshots están cifradas en la computadora original. Está buenísimo que el NAS no pueda leerlas.
    Por eso, para usar el backup también tuve que restaurar la wrapper key de cifrado. Sin mentir, fue bastante aterrador hasta que tuve la primera confirmación de que podía descifrar los datos.
    No hay que asumir que un método de backup personalizado funciona hasta comprobar que realmente se pueden restaurar los datos periódicamente.

    • Lo mismo aplica para los backups no personalizados.
    • Siempre pensé que debería guardar una copia del header de LUKS en un disco aparte, por si acaso.

  • El futuro cercano de Linux aquí es bcachefs.
    https://bcachefs.org/

    • ¿Qué hace bcachefs mejor que BTRFS o ZFS?
    • Para llamarlo futuro cercano, ya lleva 7 años en desarrollo y todavía no fue aceptado upstream.
      Aunque el trabajo para incorporarlo upstream sí está en curso.
    • ¿Hay un resumen breve de por qué habría que entusiasmarse? ¿Tiene alguna función interesante?

  • “Fue bastante aterrador hasta que tuve la primera confirmación de que podía descifrar los datos” suena a que el procedimiento estaba menos probado y menos documentado de lo ideal.
    No es algo tan raro en sistemas domésticos o desktops personales. Aun así, en un servidor de producción no querrías tener que improvisar en el momento cómo hacer la restauración.

    • Correcto. Sabía que tenía todos los elementos necesarios para restaurar, y había hecho una prueba seis meses antes, pero al principio copié la clave incorrecta.
      Cuando falló la carga, por un momento se me vino el mundo abajo, pero enseguida me di cuenta del error. En esos momentos de falla aparece una claridad en la que todos los huecos del proceso se vuelven dolorosamente evidentes.