- Para manter um Raspberry Pi em estado sem intervenção por semanas ou até anos, é preciso projetar com antecedência um caminho para recuperação automática em caso de falha
- O guia é uma série mais ampla sobre confiabilidade que substitui o artigo anterior sobre redução do desgaste do cartão SD, reunindo respostas por tipo de problema e dicas de monitoramento
- Os principais riscos se dividem em falha de conexão WiFi, interrupção de serviços, crashes causados por instabilidade de hardware, firmware ou drivers, e desgaste ou lotação do cartão SD
- Problemas com cartão SD podem ser mitigados escolhendo um microSD adequado, não usando swap, reduzindo gravações, usando um sistema de arquivos raiz somente leitura e executando fsck quando necessário
- Desativar journaling pode reduzir desgaste, mas aumenta o risco de corrupção do sistema de arquivos em crashes ou quedas de energia, portanto não se alinha ao objetivo de estabilidade de longo prazo
Pontos de falha a observar primeiro na operação de longo prazo
- Para manter um Raspberry Pi online por longos períodos, é preciso avaliar como o Pi vai se recuperar em cada situação de falha e também comparar os benefícios e riscos de cada solução
- O autor usa Raspberry Pi em casa como transmissor FM de baixa potência e monitor de energia de UPS, entre outras funções
- A série Raspberry Pi Reliability organiza os tipos de problemas vivenciados diretamente e as formas de resolvê-los, e também inclui dicas de monitoramento usando principalmente o Uptime Kuma
- A série tem como objetivo ser um guia mais abrangente que o artigo anterior sobre redução do desgaste do cartão SD, e os artigos vinculados funcionam como substitutos atualizados
Respostas por tipo de problema e escolhas a evitar
- Falha de conexão WiFi é um tipo de falha que deve ser considerado primeiro na operação de longo prazo
- Interrupção de serviços de software é uma área que exige uma estratégia de recuperação separada
- Instabilidade de hardware, firmware e drivers pode levar a crashes
- Cartões SD podem sofrer desgaste ou ficar completamente cheios, afetando o modo de operação
- Comece pela escolha do cartão microSD correto
- Não use o cartão SD como swap
- É possível considerar reduzir gravações no cartão SD, especialmente reduzindo gravação de logs, e tornar o sistema de arquivos raiz somente leitura
- Se você não usar um sistema de arquivos raiz somente leitura, deve verificar o sistema de arquivos com frequência
- Desativar serviços desnecessários ajuda tanto na estabilidade do software quanto na mitigação do desgaste do cartão SD
- Antes de aplicar uma intervenção invasiva, é preciso comparar primeiro riscos e benefícios
- Quando uma falha realmente ocorre, logging remoto é útil para identificar a causa
- Um post no Stack Exchange sugere desativar journaling no sistema de arquivos do Pi, mas isso deve ser evitado porque aumenta a possibilidade de corrupção do sistema de arquivos em crashes ou quedas de energia
1 comentários
Opiniões no Hacker News
Em vez disso, comecei a comprar Lenovo mini PC; com 18 cm x 18 cm x 3 cm, ainda é bem pequeno
Hoje em dia dá para encontrar bem barato, e ele vem com gabinete e refrigeração adequados: https://psref.lenovo.com/syspool/Sys/PDF/ThinkCentre/ThinkCe...
Uso um aqui ao lado, com i5-8500T, 32 GB de RAM e 2 SSDs, e em idle ele está consumindo 5 W com autotuning do
powertop: https://wiki.archlinux.org/title/powertopDá para adicionar uma conexão serial a um microcontrolador, mas isso deixa a solução menos elegante
Mais recentemente, também migrei meu NAS (N5105) e minha máquina de serviços (3215U) para mini PCs usados e Chromebooks desbloqueados comprados no eBay ou em mercados de pulgas. São baratos, mantêm o consumo baixo, e o desempenho de computação está em outro nível comparado ao Pi
Na Austrália aparecem milhares de unidades vindas de fim de leasing. Os chips 8500T e 8700T são excelentes, rodam Windows 11 oficialmente e têm transcodificação por hardware integrada, então são bons como servidor Plex
Um dos meus foi atualizado para 2 SSDs de 2 TB e 64 GB de RAM, e roda 24/7 sem problemas
O cartão SD provavelmente era a maior fonte de problemas e, considerando o custo de conectar algo como um SSD ao RPi, já não era mais custo-efetivo
O primeiro conselho não deveria ser ativar o modo de journaling do sistema de arquivos
O primeiro conselho deveria ser montar o sistema de arquivos como somente leitura, montar
/varem memória e enviar todos os logs para um nó adequado, com UPS de verdade e NUT rodando, em vez de gravá-los no RPi. Se o sistema de arquivos for somente leitura ou uma área temporária, quedas de energia se tornam praticamente inofensivasPara um único RPi pode ser exagero, mas o autor disse que usa vários pela casa
Também é uma boa ter partições de sistema A/B e fazer upgrades regravando a partição inteira, depois alternando a partição ativa. Assim, mesmo que a nova versão tenha um bug crítico, sempre sobra uma partição de sistema funcional e a recuperação fica fácil
Tenho usado bem esse método há mais de 20 anos em vários PCs pequenos/de placa única, em diversas funções
https://www.dzombak.com/blog/2021/11/Reducing-SD-Card-Wear-o...
/var, também é preciso usar tmpfs em lugares como/tmp. Isso deve aumentar bastante a vida útil do cartão SDComo você cria a nova imagem de disco, e faz login em cada dispositivo para atualizar ou existe alguma automação?
/varem memória pode fazer o dispositivo exceder a memória disponívelTalvez seja necessário mover
/var/lib/dockerpara um armazenamento secundárioEm 2011, criei um produto comercial que rodava nos primeiros plug computers da Global Scale Technologies
Vendi só 20 unidades, mas todas foram devolvidas por problemas de corrupção de cartão SD, e tive de mudar às pressas o sistema de arquivos raiz para somente leitura. Desde então passei a gostar dessa abordagem
Aquele produto comercial inicial era um produto de segurança residencial com alguns recursos bem pequenos de automação doméstica; em 2021, eu o publiquei como open source sob um novo nome, e hoje ele roda em computadores de placa única da linha Jetson: https://github.com/hcfman/sbts-install
Agora ele também inclui modelos YOLO avançados como gatilhos. Como era pensado para ser um produto independente, tinha suporte a HTTPS e também uma GUI que encapsulava todo o trabalho com certificados. Esse recurso continua na versão open source, facilitando o uso de certificados autoassinados em chamadas REST entre dispositivos
Também mantive e expandi a abordagem de overlayFS em memória com múltiplas partições, e fiz o processo de instalação instalar primeiro o sistema
sbts-base, para que outras pessoas possam usá-lo como seu sistema baseCom o tempo, o sistema começou a travar por 1 a 2 segundos a cada escrita em disco, e isso era bem sofrido
Para quem está pensando em fazer algo assim, eu recomendaria primeiro ver se não dá para resolver o que precisa com uma plaquinha pequena como um ESP32
O consumo de energia é muito menor, o preço fica na casa de poucos dólares, e é suficiente para muitos usos. Se você prefere o lado do Python, muitas placas oferecem suporte tanto a MicroPython quanto a CircuitPython
Vale a pena olhar, pois dá para reduzir o custo inicial de compra e a conta de luz contínua
Projetos feitos com microcontroladores foram décadas mais estáveis do que projetos baseados em Pi, e há menos preocupação de esquecer de mudar a configuração padrão de SSH e acabar virando parte de uma botnet. Acho que o padrão não era
pi:raspberry?Além de MicroPython, o suporte a no_std Rust para o ESP32C3 vem melhorando mês a mês. Para quem faz pequenos projetos de automação residencial por diversão, as restrições extras podem até tornar a experiência mais divertida e gratificante
Dito isso, para quem já está familiarizado com Linux, o Pi em geral é muito mais fácil e, na minha experiência, custa pelo menos umas 10 vezes mais. Também é preciso incluir na decisão as configurações adicionais para obter o mesmo nível de estabilidade, como boot por SSD, boot pela rede, sistema de arquivos raiz somente leitura e configuração de watchdog, além do consumo maior de energia, especialmente no Pi 5
Dá para rodar um servidor de gerenciador de senhas em um ESP32? Não dá. Pi-hole? Não. Controlador Unifi? Não
Esse tipo de recomendação parece imaginar que as pessoas usam o Pi para coisas como controlador de porta de garagem, mas sugerir reflexivamente o ESP32 como substituto do Pi não ajuda muito
Quando algo não funciona, não dá para conectar HDMI e teclado e depurar na hora em um ambiente Linux mainline com todos os utilitários comuns
Usei MicroPython pela primeira vez em vez de Arduino e gostei muito; surpreendentemente, é bem estável. Antes, meus projetos frequentemente quebravam a longo prazo por causa dos estados de energia do Wi-Fi, mas até agora não tive problemas nessa arquitetura com MicroPython
Dizer que “no fim quase sempre vira um script que verifica periodicamente se a conexão Wi-Fi está boa e, se não estiver, reinicia a interface Wi-Fi ou o Pi inteiro” não é gambiarra, é boa prática
Assim como servidores importantes em datacenters devem ter conexão fora de banda, como IPMI ou tomadas RPDU controláveis remotamente, servidores importantes em locais remotos de difícil acesso devem ter scripts de watchdog
Claro, é preciso ajustar ao caso de uso considerando o impacto de uma reinicialização e o tempo fora do ar até ela acontecer, e ao menos dá para registrar eventos anômalos para investigar depois
Quando implantei um RPi remoto, a primeira coisa que fiz foi um script simples de watchdog em Bash. Não era só para problemas de Wi-Fi, mas para dezenas de situações que podiam quebrar e ser corrigidas com uma reinicialização
Se não dá para confiar que o init gerencie os serviços, de onde vem a garantia de que o sistema fornece o serviço?
Dá para recriar isso com scripts, mas nós já passamos dessa fase. Menciono bastante o systemd, mas não é por preferência; também há alternativas
A maioria dos serviços não aproveita corretamente o ambiente em que existe. Parece que se espera uma customização específica do site, como declarar que um servidor web precisa de uma montagem específica
Uma diretiva frequentemente esquecida é
PartOf=. Ela permite vincular a reinicialização de um serviço ou recurso à de outroDe forma mais simples, imagino que o NetworkManager ofereça uma maneira de customizar verificações de Wi-Fi/portal. Talvez não seja necessário ir para uma solução totalmente radical
No caso do roteador, ele tenta se conectar ao SSID apropriado e envia ping ao roteador; se qualquer uma das duas coisas falhar, troca para outro roteador. Tenho dois roteadores iguais com a mesma configuração, e a alimentação fica ligada aos contatos NO/NC de um relé SPDT; se um falha, ele só muda o estado do relé e alterna para o outro
Se o roteador está vivo, o watchdog carrega a página de status do modem a cabo e envia ping para qualquer um de três IPs dentro da rede do ISP que parecem ser o CMTS ou equipamentos próximos, para verificar se a infraestrutura HFC está funcionando. Isso porque, se for uma falha que uma reinicialização não resolveria, eu não quero reiniciar à toa
Infelizmente, não encontrei uma forma de ter dois modems a cabo com o mesmo MAC e alternar entre eles, e o ISP também não permite dois modems na mesma conta; então, se o modem a cabo falhar, só resta reiniciá-lo e torcer
Acrescentei a isso um rack de baterias capaz de manter roteadores e modem funcionando por mais de 30 horas durante uma queda de energia e, desde que o montei em maio de 2020, ele ficou online quase o tempo todo. O código é horrível, mas na prática funciona de forma muito robusta
Coisas que nem código e projeto perfeitos conseguem impedir acontecem, e um watchdog timer quebra loops infinitos e faz o reset. Há coisas como bits sendo invertidos em espaçonaves ou quedas momentâneas de tensão, e no Raspberry Pi ainda é preciso se preocupar com corrupção do cartão SD
Pelo que sei, o Raspberry Pi tem um watchdog timer de hardware integrado. Arduino com certeza tem
Operei milhares de Pis em ambientes de produção por quase 10 anos, e agora estamos começando a migrar para x86
O custo-benefício do Pi já não é como antes. Apresentei essa experiência na recente State of Open Con: https://youtu.be/vX-qK9mxKZI
Nosso serviço ainda não usa isso, mas pela documentação parece bastante robusto e capaz de proteger os dados no disco/SD
Ainda estamos bastante satisfeitos com o Pi, e a migração para APIs mais abertas, como Mesa/DRM/KMS/FFmpeg, parece muito promissora agora que finalmente está ficando utilizável
Como o uso principal ainda é sinalização digital, desempenho bruto de processamento não importa tanto. A decodificação de vídeo, que é uma parte importante do custo, obviamente é acelerada, e a compatibilidade retroativa possível no Pi é excelente. Ainda temos clientes rodando Pi1B+ há quase 10 anos e usando a versão mais recente do SO que fornecemos
Também é preciso olhar para a vida útil, e nisso acho que ARM também deve durar mais que x86. Em termos de modularidade, ARM também é melhor que x86, porque é mais barato ter vários dispositivos pequenos
Mas, para escalabilidade, ou seja, viabilidade de negócio na economia atual, x86 é melhor que ARM
Além disso, todos os gráficos deveriam ser em termos de desempenho por watt. Dizer que a performance melhorou ao ir do 2 para o 4 não é novidade; o que importa é se o desempenho por watt melhorou
Visto assim, dá para perceber que o Raspberry Pi 5 não trouxe uma melhoria de desempenho por watt tão grande quanto se esperava. Parece que chegamos permanentemente a um pico na história da humanidade
Por fim, neste momento, a única esperança de algum avanço não está em desempenho, mas em abertura, com o JH7110, embora o suporte a 3D esteja atrasado
Mesmo sem fazer nada disso, alguns Pis funcionaram sem problemas por anos até serem substituídos por modelos novos
Meu gateway HomeKit/Zigbee e meu registrador de dados agora são Pi 4. No fim, parece que o essencial é ter um bom cartão SD e uma fonte de alimentação estável
Acho que o pibenchmark é uma boa fonte de informação: https://pibenchmarks.com/
Antes de comprar, é indispensável comparar cartões SD
Quando você opera dispositivos em quantidade suficiente, tudo que pode dar errado dá errado, e também aparecem novos modos de falha que você nunca teria imaginado
Esse provavelmente foi o motivo de tantos relatos de cartões corrompidos depois disso
Não fiz nada além de instalar o Raspbian no cartão microSD, configurar o Cups e conectar o USB à impressora. Outro deles gerencia uma impressora de rede. Depois disso, simplesmente deixei lá
Agora troquei a maioria para SSD. Caso contrário, parece demais um jogo de dados
Fiquei surpreso que a questão dos cartões SD não tenha sido a primeira, e ainda mais surpreso que o texto não recomende boot por USB
Tenho um Pi ligado quase 24/7 há anos, e atribuo a ausência de problemas a 1) ter configurado o Alpine para quase não tocar no disco, 2) não haver um cartão SD para corromper. Não sei por que USB é mais confiável, mas empiricamente foi o que aconteceu
O único motivo de falha é quando falta energia. Uma bateria que aguentasse só 10 minutos provavelmente seria mais que suficiente
Por exemplo, queria saber se você está falando de algo como https://wiki.alpinelinux.org/wiki/Installation#Diskless_Mode
Tirei o cartão e passei a usar esse Pi e o seguinte com SSD por USB. Foi meio assustador. Ainda assim, como eu disse acima, também tenho um Pi rodando como servidor Cups em microSD há anos sem problema
Meus dois RPis inicializam e rodam por USB, e funcionam bem há anos
Desde 2017, tenho mantido dois Pis rodando quase continuamente com os mesmos cartões SD. Houve umas 2 ou 3 quedas de energia.
Um é servidor DNS/de impressão, e o outro é Kodi, com a mídia em um NFS externo. A única coisa que fiz foi desligar todos os logs, e nunca tive problema.
Os dois usam cartões SanDisk de 2 GB. Lembro vagamente de ter pensado de forma ingênua algo como “menos espaço → menor densidade de bits → melhor confiabilidade”.
log2ram(github/azlux/log2ram) e estou satisfeito com o resultado.Ele monta um disco em RAM em
/vare só de vez em quando copia os logs do disco em RAM para o cartão SD. Com isso, consigo ver todos os logs sem ficar castigando o cartão SD.Ele fica ligado na maior parte do tempo, mas às vezes desligo por engano a fonte USB conectada. É uma fonte pequena de 5 portas, quase da mesma idade, e, na minha configuração, o botão liga/desliga é fácil demais de apertar.
Basicamente montei todos os logs e páginas web em tmpfs; o DB fica no cartão SD e é gravado a cada 5 minutos.
Ele passou por várias instalações, mas agora é um servidor DNS de backup. Olhando o sistema de arquivos, vejo que ele é usado como Pi-hole desde 2018 e, exceto por algumas reinicializações e mudanças de casa, roda praticamente 24/7.
Não escrevo nada no SD; mando tudo para a RAM em
/dev/shm. Se o Pi-hole cair, o que é raro, basta baixar as listas de novo — e, de qualquer forma, elas são baixadas diariamente.Mais tarde, também passei a usá-los como DNS local e nó do Tailscale. Já ficaram meses sem reiniciar, e o maior uptime foi de cerca de 11 meses. Foram muito robustos. Deixá-los ligados a um UPS certamente ajuda.
Foi dito que “manter um Raspberry Pi online por semanas, meses ou anos sem intervenção é uma espécie de arte”, mas eu inicializo um kernel NetBSD com sistema de arquivos embutido.
Por exemplo, uso o kernel INSTALL ou um kernel customizado. Logo após o boot, o cartão SD pode ser removido e, opcionalmente, faço
chrootpara um armazenamento conectado.Assim, ele roda por semanas, meses ou anos. Não passei pelos problemas que o autor do blog mencionou.
O único problema que encontrei foi no lado do conector de energia ao usar um case. Por exemplo, com um cabo de reposição, a conexão pode ficar fraca. Talvez isso tenha melhorado nos Pis mais recentes.
Mas dá para dizer que a maioria dos computadores é parecida. Cabos e conectores geralmente são peças frágeis e baratas. Se o movimento cortar a energia, o Pi reinicia automaticamente.