Graças ao ZFS, a perda de dados foi de apenas 10 minutos

 (mastodon.social)
3 pontos por GN⁺ 2023-08-24 | 1 comentários | Compartilhar no WhatsApp
  • Um SSD de 2 anos morreu de repente, mas com replicação incremental do ZFS foi possível reviver o sistema em um novo drive, e a perda real ficou em cerca de 10 minutos
  • A estrutura fazia snapshots a cada 10 minutos de todo o sistema de arquivos e os enviava para o NAS, com automação usando zrepl
  • Snapshots salvam o estado de um sistema em execução em um ponto específico no tempo e, ao transmitir apenas as mudanças, permitem replicação em segundo plano até mesmo em uma rede doméstica
  • O processo de restauração exigiu deixar um zfs receive de 625GiB rodando durante a noite e restaurar até a wrapper key de criptografia, ficando longe de uma recuperação automática
  • O ZFS tem alto custo inicial de adoção e manutenção, mas mostrou um efeito real de recuperação de desastre ao restaurar até o estado de trabalho após uma falha de drive

Depois da falha do SSD, restaram apenas 10 minutos de perda

  • No momento em que foi abrir o notebook para enviar um e-mail, a tela estava travada em preto e, após reiniciar, confirmou que o SSD de 2 anos havia morrido
  • Depois de restaurar o sistema em um novo drive, foi possível voltar a usá-lo, e a perda total de dados ficou em cerca de 10 minutos
  • O notebook restaurado inicializou do ponto em que havia parado, e até as abas do navegador recuperaram o trabalho inacabado da noite anterior
  • Como em um anúncio de Chromebook de 12 anos atrás, a ideia de continuar o estado anterior em um novo dispositivo realmente funcionou nesta falha

Uma estrutura mais próxima de replicação do que de backup

  • Em vez de simplesmente fazer backup do drive, foi usado um método de replicação de todo o sistema de arquivos
  • No último inverno, foi montado um armazenamento de rede doméstico para backups periódicos dos computadores usados em trabalho criativo e, entre várias opções, foi escolhida a replicação incremental do ZFS
  • O ZFS consegue criar com eficiência snapshots de um ponto específico no tempo mesmo em sistemas em execução
  • Depois, ao enviar para outra máquina, não retransmite todos os dados, mas envia apenas os dados alterados

Envio para o NAS a cada 10 minutos com zrepl

  • A automação da criação de snapshots e do envio ao NAS foi feita com zrepl
  • A configuração tirava snapshots a cada 10 minutos de todo o sistema de arquivos e os enviava
  • Graças aos snapshots incrementais, era possível manter a réplica atualizada mesmo executando em segundo plano na rede doméstica
  • A última execução levou 14 segundos para a transmissão e enviou cerca de 64MiB

O peso do trabalho manual revelado no processo de restauração

  • Restaurar o sistema foi um processo que exigiu aprendizado e dependeu bastante de trabalho manual
  • Foi necessário deixar um zfs receive de 625GiB rodando durante a noite
  • Como os snapshots estavam criptografados no computador de origem, o NAS não podia ler o conteúdo
  • Para usar o backup de fato, também foi preciso restaurar a wrapper key de criptografia
  • O processo de restauração foi bastante angustiante até a primeira confirmação de que os dados podiam ser descriptografados

Custo de adoção e troca de hardware

  • A configuração inicial do ZFS exigiu substituir todo o sistema de arquivos, então o custo inicial foi alto
  • A manutenção exige bastante conhecimento relacionado e envolve procedimentos operacionais com trabalho manual
  • Ainda assim, foi sorte ter configurado a replicação antes da primeira falha do SSD, e este caso mostrou as vantagens do ZFS
  • O drive que morreu era originalmente um WD_BLACK SN850 incluído no pedido da Framework
    • Já havia visto no fórum da Framework casos preocupantes de esse drive morrer de repente ou se tornar incapaz de inicializar
  • No mesmo dia, recebeu da Amazon em cerca de 3 horas um SK Hynix P41 SSD e um Sabrent NVMe enclosure

Leituras relacionadas

1 comentários

 
GN⁺ 2023-08-24
Comentários do Hacker News

  • Como está usando ZFS, acabou ficando mais preparado do que outros usuários de SSDs WD ou 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

  • Pouco antes de deixar completamente o mundo Linux, comecei a explorar aos poucos esse iceberg chamado btrfs, e achei bem interessante
    Ele parecia ter bastante potencial em vários recursos, como inovação em backups, configurações de disco etc. O btrfs não é ZFS, mas há sobreposição de funcionalidades e ele também fica perto de ser um “ZFS dos pobres”. Além disso, como o ZFS tem uma situação meio ambígua em relação a licença, empacotamento e inclusão no kernel, em certos sistemas operacionais o btrfs funciona de forma muito mais sensata
    Certa vez, em um Linux User Group, comentei que precisei puxar o cabo de energia para reiniciar um computador, levei uma bronca enorme por causa dessa atitude idiota e me recomendaram usar ZFS. Mas, considerando que aquele sistema era um Raspberry Pi, talvez a opinião sobre qual das duas atitudes era mais sensata possa mudar

    • Dizem que o Pi pode sofrer corrupção do sistema de arquivos, mas nunca vi isso pessoalmente, porque sempre que instalo uma imagem rodo um script que monta tmpfs em vários lugares e desativa a maioria dos logs inúteis
      Desde que você não maltrate o cartão SD, esses equipamentos continuam rodando com muita estabilidade. ZFS parece realmente incrível, mas, mesmo que um dia eu compre um NAS, acho que não vou querer gastar dinheiro em um equipamento capaz de rodar ZFS, então provavelmente vou acabar usando apenas RAID e ext4
      Evitei o btrfs por muito tempo porque, a cada poucos meses, via algum post dizendo “BTRFS destruiu meus dados” e depois uma discussão sobre se a culpa era ou não do btrfs. Parece que hoje em dia vejo menos posts assim, então talvez seja hora de olhar de novo
    • Pergunto por curiosidade: o que fez você deixar completamente o mundo Linux? O que a “comunidade” poderia aprender com essa experiência para melhorar para outras pessoas?
    • A única coisa de que realmente não gosto no btrfs é que ele tende a gerar fragmentação
      Especialmente em imagens esparsas de VM; para esse uso, acho que zvol é muito melhor

  • Alguns anos atrás houve a praga dos capacitores, e agora fico pensando se estamos passando por uma praga dos dispositivos de armazenamento
    Está ficando absurdo como todos os dispositivos de armazenamento estão piorando cada vez mais. A WD está estragando HDDs com SMR, e os fabricantes dizem que 3 anos de operação para SSDs e HDDs já é tempo demais, e não é piada. Só este ano, um SSD Kingston morreu; tudo bem, ele tinha uns 8 anos, mas um HDD portátil da WD também morreu em cerca de 2 anos
    Hoje a internet está cheia de problemas de perda de dados e vida útil. Há 20 anos, HDDs também não eram coisas para durar para sempre, mas pelo menos me lembro de que certamente duravam mais do que a vida útil do computador comprado junto com eles

    • Os discos rígidos de hoje têm muito mais sorte do que os de 20 anos atrás
      Vinte anos atrás foi a era dos infames drives IBM Deathstar, em que o revestimento magnético literalmente se soltava dos pratos. Havia também os terríveis drives Maxtor que morriam em 1 ou 2 anos e, depois que a Seagate comprou a Maxtor, os drives da Seagate também ficaram instáveis por um tempo. Eu administrava um servidor com uns 8 discos e precisava trocar, continuamente, cerca de um por ano
      Em contraste, hoje ajudo a administrar um servidor ZFS com mais de 20 drives, e a vida útil dos drives fica em torno de 4 a 5 anos. Além disso, naquela época os computadores ficavam obsoletos muito mais rápido. Hoje, um computador de 6 anos ainda é perfeitamente utilizável, mas naquela época até um computador de 3 anos já dava uma diferença perceptível
    • Não precisa se preocupar. Logo os chips também começarão a apresentar mau funcionamento depois de alguns anos
      Estamos esbarrando nos limites de escalabilidade, e o crescimento exponencial está desacelerando
    • Pessoalmente, lembro que no passado os HDDs meus e das pessoas ao meu redor às vezes falhavam
      Hoje quase não vejo isso acontecer com SSDs. Até um SSD Intel antigo, do fim dos anos 2000, conhecido por ter muitos problemas, ainda funciona perfeitamente no mesmo MacBook antigo que usei por alguns anos e depois dei à minha mãe. Fico curioso para saber como estão os dados reais
    • Todos os drives WD que comprei nos últimos 10 anos funcionaram como esperado. Isso inclui os modelos para NAS comprados depois da adoção de SMR, porque me certifiquei de que eram Plus ou Pro, não apenas Red
      Também tive sorte com SSDs, mas em desktops ainda costumo manter o diretório /home e o array RAID em discos giratórios antigos, então uso apenas SSDs pequenos
      Houve duas exceções. Tirei dois WD Red anteriores ao SMR de um NAS antigo para substituí-los por discos maiores e os guardei, completamente funcionais, em sacos antiestáticos dentro de uma gaveta. Cerca de 2,5 anos depois precisei de discos de reserva e, ao testá-los, nenhum dos dois funcionava; um estava completamente morto e o outro mal era reconhecido, mas não podia ser lido. O primeiro não aparecia de jeito nenhum quando conectado; limpei todos os contatos, incluindo os pinos da PCB controladora, mas não adiantou, então acabei descartando. O segundo só pôde ser reutilizado depois de uma reformatação completa, mas nem com testdisk havia como recuperar os dados antigos. Nunca tinha passado por isso nem esperava algo assim, então, sinceramente, fiquei bem preocupado
    • Há cerca de 20 anos também existia o HGST “Deathstar”, um drive tão ruim que chegou a gerar uma ação coletiva
      Discos sempre morriam de forma aleatória, e esse foi um dos motivos pelos quais a Sun criou o ZFS

  • Resumindo bem, a thread no Mastodon aponta para https://zrepl.github.io
    “zrepl é uma solução integrada e completa para replicação ZFS”

    • Alguém sabe como zrepl e sanoid/syncoid diferem, além do fato de o zrepl ser escrito em Go e o sanoid/syncoid serem scripts em Perl?
    • Parece que é preciso se comunicar com um daemon rodando no servidor de armazenamento
      Por exemplo, seria ótimo se desse para usar S3 diretamente como armazenamento

  • Zrepl é um dos grandes motivos pelos quais consigo viver como nômade digital com tranquilidade
    Um script que roda aproximadamente uma vez por noite abre um pool ZFS protegido por LUKS com cabeçalho separado e copia todos os snapshots. Esse enclosure NVME fica sempre em uma “bolsa” que nunca sai de perto de mim
    Graças a essa configuração e ao NixOS, consigo provisionar um notebook novo idêntico em cerca de 10 minutos. Recentemente também adicionei replicação off-site, então, mesmo que eu seja assaltado de forma totalmente violenta, a chance de perda séria de dados é quase zero
    Zrepl é um software realmente excelente. É fácil de começar a usar, mas sofisticado e poderoso o bastante para permitir ajustar todos os controles se necessário. Faltam elogios para ele

    • Parece muito mais seguro do que a situação da maioria das pessoas, em que um roubo, incêndio, enchente ou outro desastre já acaba com tudo
    • Você já usou sanoid/syncoid? O que Zrepl oferece a mais em comparação com eles?
    • Seria ótimo se você escrevesse um post explicando como essa configuração funciona. Parece bem interessante

  • Será que fazer um snapshot a cada 10 minutos do sistema de arquivos pode ter contribuído para a morte do SSD?

    • O ZFS é especial e, como usa copy-on-write, o custo de criar snapshots é baixo
      Intuitivamente, mesmo tirando snapshots com muita frequência, a quantidade adicional de escritas deve ser bem pequena. Ainda assim, seria bom ter alguma medição científica
      Em alguns servidores que eu administrava antigamente, eu fazia snapshots com ZFS a cada minuto, a cada hora e diariamente. Os snapshots por minuto eram apagados depois de 60 minutos, e uma tarefa cron em outra máquina fazia backup dos snapshots horários e diários. Os snapshots horários eram mantidos por cerca de 72 horas, e os diários eram mantidos para sempre. Os snapshots por minuto serviam para desfazer erros manuais durante migrações SQL, e funcionavam bem
      Ainda uso ZFS em um servidor FreeBSD, mas meus projetos atuais têm pouco tráfego e mudanças importantes de dados são raras, então no meu servidor pessoal eu tiro snapshots manualmente cerca de uma vez por semana e aciono manualmente o backup em outro servidor. Além disso, hoje faço snapshot apenas da parte do sistema de arquivos que contém os bancos PostgreSQL e os dados da aplicação. Já não me preocupo muito com os dados do sistema operacional. Se houver uma falha grave de hardware, reinstalo o SO; mantenho registradas as configurações importantes e faço com que o script de backup copie esses valores quando roda, em vez de outras coisas diversas
    • É pouco provável
      Snapshots não escrevem muito, e tanto SSDs quanto ZFS usam copy-on-write. Ou seja, o custo das escritas depois de um snapshot é o mesmo de antes do snapshot
      Mas falta contexto. Tanto SSDs quanto ZFS não gostam de ficar cheios ou quase cheios. Se os dados de trabalho tinham cerca de 650 GB e o drive era de 1 TB, os snapshots poderiam facilmente ter levado o uso do drive para mais de 90%. Isso por si só pode ter deixado o ZFS em uma situação ruim
    • Pelo que entendo, tirar um snapshot no ZFS significa escrever um objeto de metadados e algumas referências de dados
      Supondo 100 GB de dados, blocos de 128K e ponteiros de 64 bits, os dados novos escritos durante um snapshot ficariam mais ou menos na casa de 5 MB. Fazendo isso 6 vezes por hora, 52.560 vezes por ano, para ver se seria suficiente para causar desgaste prematuro do drive, dá cerca de 256 GB por ano. Isso provavelmente é menos de 1% da resistência de escrita de um SSD. Então eu ficaria surpreso se snapshots a cada 10 minutos fossem uma causa importante
      Posso estar errado, e fiz essa estimativa com ajuda de uma fonte não muito confiável. Correções são bem-vindas. Ainda assim, se a minha estimativa estiver acima do real e, mesmo assim, for improvável que afete a vida útil, talvez a questão em si não tenha tanta importância
    • É pouco provável. Um snapshot basicamente marca os blocos gravados mais recentemente e impede que os blocos anteriores sejam modificados
      Como o ZFS é copy-on-write, alterações em arquivos geram as mesmas escritas, só que alguns dados antigos deixam de ser apagados
    • Segundo um comentário em algum site aleatório laranja[1], o tamanho mínimo de escrita dos chips flash modernos pode ser cerca de 100 MB
      Nesse caso, uma escrita de 5 MB a cada 10 minutos vira, na prática, 600 MB por hora, 4,8 TB em uma jornada de trabalho de 8 horas, 24 TB em uma semana de 40 horas e, em um drive de 1 TB, 3,43 DWPD em tempo real; ao longo de 2 anos em tempo real, seriam 2500 TBW[2]
      A resistência oficial de escrita do SN850 é 600 TBW, mas é claro que esse valor provavelmente é conservador por motivos de garantia. Coincidentemente, 2500 TB também é um valor de resistência comum em muitos SSDs desse mercado. No geral, não parece algo completamente impossível
      Se ele ainda estiver vivo, fico curioso para saber o que o controlador diz nos dados SMART. No Linux, executar apt install smartmontools; smartctl -s on /dev/sda; smartctl -A /dev/sda deve imprimir uma tabela[4]. No Windows, basta instalar o CrystalDiskInfo[3]
      1: https://news.ycombinator.com/item?id=29165202
      2: DWPD: drive writes per day, TBW: Total Bytes Written - in terabytes
      3: https://crystalmark.info/en/software/crystaldiskinfo/
      4: “Pre-fail” significa que o valor deve mudar logo antes de uma falha, e “Old_age” significa que é um valor que indica idade; não significa “isso é ruim e vai falhar em breve” nem “este drive é velho”. Todos os itens sempre mostram Pre-fail e Old_age. Acho que, muito tempo atrás, alguém deveria ter mudado isso para “somewhat_boolean” e “life_remain”

  • Eu normalmente faço backups incrementais do Time Machine da Apple para um servidor Synology com discos giratórios
    Quando vou fazer algo arriscado ou atualizar a máquina, às vezes também espelho o drive interno em um SSD externo. Esse método funciona bem. A restauração pelo Time Machine pode ser bem lenta, mas a maior parte dos dados importantes está no Git e em repositórios hospedados, então isso não foi um grande problema. Às vezes uso o Time Machine quando quero reverter um único arquivo
    Também tenho um daqueles infames[0] drives SanDisk, mas não uso para nada importante. Ele só tem mais ou menos uma biblioteca de jogos. Como sou usuário de Mac, jogos não são um fator grande, e eu não vou chorar se eles morrerem
    [0] https://arstechnica.com/gadgets/2023/08/sandisk-extreme-ssds-are-worthless-multiple-lawsuits-against-wd-say/

    • Eu também uso Time Machine. Baixei o app https://tclementdev.com/timemachineeditor/ e configurei para acionar manualmente backups do TM sempre que a máquina estiver ociosa
      Parece funcionar muito melhor do que os backups automáticos da Apple ou os backups baseados em horário
    • Eu desisti do Time Machine. Mesmo usando atalk etc. no Synology, quase nunca funcionou direito por mais de um ou dois meses

  • Meus snapshots são criptografados no computador original. É legal que o NAS não consiga lê-los
    Então, para usar o backup, eu também precisei restaurar a wrapper key de criptografia. Sem brincadeira, foi bem assustador até eu receber a primeira confirmação de que conseguia descriptografar os dados
    Não se deve presumir que um método de backup personalizado funciona até verificar que é realmente possível restaurar os dados periodicamente

    • O mesmo vale para backups que não são personalizados
    • Eu sempre só pensava que deveria guardar uma cópia do cabeçalho LUKS em um disco separado, por precaução

  • O futuro próximo do Linux aqui é o bcachefs
    https://bcachefs.org/

    • O que o bcachefs faz melhor que BTRFS ou ZFS?
    • Para chamar de futuro próximo, ele já está em desenvolvimento há 7 anos e ainda não foi aceito upstream
      O trabalho para entrar no upstream está em andamento, porém
    • Há um breve resumo de por que deveríamos ficar animados? Algum recurso interessante?

  • “Foi bem assustador até eu receber a primeira confirmação de que conseguia descriptografar os dados” soa como se o procedimento tivesse sido menos testado e menos documentado do que o ideal
    Isso não é tão raro em sistemas domésticos ou desktops pessoais. Ainda assim, em um servidor de produção, você provavelmente não quer descobrir o procedimento de restauração na hora, de improviso

    • Exato. Eu sabia que tinha todos os ingredientes necessários para a restauração e até tinha feito um teste 6 meses antes, mas no começo copiei a chave errada
      Quando ela falhou ao carregar, bateu um breve desespero, mas logo percebi o erro. Nesses momentos de falha, vem uma clareza em que todas as lacunas do processo ficam gritante e dolorosamente óbvias