Este tópico de abril de 2026 começou como uma publicação ampla de um “novo utilizador sobrecarregado pelo ZimaOS”, abrangendo cópias de segurança e correio eletrónico autoalojado. O problema do correio eletrónico acabou por se tornar secundário: o utilizador conseguiu pôr o Mailcow a funcionar suficientemente bem para as suas necessidades. A questão técnica por resolver era a Cópia de segurança do ZimaOS, na qual os tamanhos apresentados eram inconsistentes, a primeira execução normalmente terminava e as execuções posteriores podiam bloquear sem atividade adicional do disco.
A fonte é especialmente útil porque o utilizador testou mais do que um ZimaBoard 2, várias unidades internas e externas, um destino de rede Synology e, mais tarde, o ZimaOS 1.6.1. Por isso, o problema não deve ser resumido a um único disco USB defeituoso ou a um caminho de rede incorreto.
O utilizador queria uma cópia de segurança simples para recuperação após um desastre, não um formato de arquivo
O fluxo de trabalho pretendido era simples: iniciar manualmente uma cópia de segurança ao estilo 1:1, preservar a estrutura de pastas reconhecível, evitar encriptação ou pacotes opacos e conseguir recuperar rapidamente se um ZimaBoard 2 inteiro falhasse.
Esta expectativa é diferente da de um software de cópia de segurança com versões, que mantém intencionalmente cópias históricas. Quando a retenção de versões está ativada, a utilização do destino pode legitimamente exceder o tamanho do conjunto de dados de origem atual.
O problema do lado do servidor de correio acabou por ser separado
A publicação original também descrevia dificuldades em substituir o Synology Mail Plus. O Zima-Jerry sugeriu o Stalwart, mas o utilizador precisava especificamente de obtenção por POP3. A 16 de abril, o utilizador relatou que o Mailcow estava a funcionar e que as outras aplicações eram satisfatórias.
Vale a pena preservar esse resultado, pois evita que a discussão posterior sobre a Cópia de segurança seja interpretada erradamente como prova de que o próprio Mailcow causou o problema de armazenamento.
Os tamanhos do destino da cópia de segurança não correspondiam à realidade
Numa placa, cerca de 800 GB na fonte correspondiam a aproximadamente 2,7 TB no diretório de destino. Noutra, cerca de 105 GB na fonte pareciam estar em falta, com uma diferença de aproximadamente 2 GB no destino.
A retenção de versões pode explicar algum crescimento, mas não uma segunda execução bloqueada
A Zima-Jerry perguntou se a função «versão reservada» estava ativada. Manter versões anteriores pode legitimamente fazer com que um destino de cópia de segurança seja maior do que a fonte ativa atual.
No entanto, o utilizador da fonte reiniciou posteriormente o teste com um disco USB externo recentemente formatado e documentou uma falha diferente: a primeira cópia de segurança foi concluída, mas a segunda copiou alguns dados e depois deixou de avançar.
O teste USB limpo reproduziu a falha da segunda execução
O utilizador eliminou tarefas antigas, reiniciou o ZimaBoard 2, formatou uma unidade externa e criou uma nova cópia de segurança manual com versões ativadas. A primeira execução demorou quase dois dias e copiou com êxito cerca de 1,25 TB.
Depois de desligar e voltar a ligar a unidade através de Ficheiros, a segunda execução copiou algumas alterações, mas a barra de progresso bloqueou e o LED de atividade USB apagou-se. O mesmo comportamento tinha ocorrido com o destino Synology.
A IceWhale escalou o comportamento da cópia de segurança
A Zima-Jerry agradeceu ao utilizador pelos testes controlados e disse que o problema seria encaminhado para a equipa de desenvolvimento para investigação.
Uma resposta posterior relacionada com a IceWhale separou duas áreas problemáticas conhecidas: fazer uma cópia de segurança de tudo /media/ZimaOS-HD tinha anteriormente incluído conteúdo de pipes/sockets do Docker, e a precisão da apresentação do progresso da cópia de segurança ainda precisava de ser melhorada.
Fazer uma cópia de segurança de toda a unidade do sistema não é o mesmo que criar uma imagem do sistema restaurável
A discussão acabou por se centrar na recuperação após desastre. Uma resposta da equipa explicou que fazer uma cópia de segurança cega de todo o disco do sistema inclui ficheiros descartáveis do Docker/runtime e não fornece automaticamente um fluxo de trabalho compatível que permita «restaurar esta pasta e fazer com que todo o sistema ZimaOS volte exatamente ao estado anterior».
Para o planeamento de recuperação após desastre, distinga dados do utilizador, dados das aplicações, bases de dados, configuração e imagens de contentores substituíveis.
Metadados de recuperação de armazenamento alterados no ZimaOS 1.6.0
Uma resposta oficial posterior afirmou que, a partir do ZimaOS 1.6.0, as informações que descrevem como um dispositivo de armazenamento deve ser montado passaram também a ser gravadas no próprio armazenamento. O objetivo era facilitar o reconhecimento do armazenamento RAID ou de disco único após um problema no disco do sistema.
Isto melhora a recuperação do conjunto, mas não transforma o RAID numa cópia de segurança nem corrige, por si só, o bloqueio da Cópia de segurança na segunda execução do utilizador.
O utilizador continuou a reproduzir o problema no ZimaOS 1.6.1
A 27 de abril, o autor original informou que a primeira cópia de segurança continuava a funcionar, mas a segunda execução e as seguintes ficavam bloqueadas durante mais de seis horas, sem qualquer atividade de escrita adicional. Fechar e reabrir a Cópia de segurança podia apresentar o destino como 0 B.
Afirmaram que o padrão tinha sido testado com quatro unidades internas, duas unidades USB externas e três sistemas ZimaBoard 2.
O fluxo de trabalho atual da cópia de segurança evoluiu
A documentação atual do ZimaOS descreve agora tarefas de cópia de segurança agendadas para destinos locais, USB, NAS e na nuvem, como parte de uma estratégia 3-2-1.
Utilize o fluxo de trabalho atual da cópia de segurança do ZimaOS e as opções de destino, em vez de presumir que a interface das versões 1.5.x/1.6.1 funciona atualmente da mesma forma.
O guia atual, por si só, não prova que todos os problemas históricos da segunda execução mencionados neste tópico tenham sido corrigidos; por isso, verifique o comportamento real do restauro na versão que utiliza.
Verifique a cópia de segurança fora da barra de progresso
- compare, sempre que possível, o número de ficheiros na origem e no destino;
- verifique a capacidade real do destino, em vez de consultar apenas a interface da Cópia de segurança;
- teste uma segunda e uma terceira execução incremental/com versões;
- restaure ficheiros representativos noutra localização;
- documente separadamente de que forma devem ser salvaguardadas as bases de dados e as definições das aplicações.
Perguntas frequentes sobre a cópia de segurança do ZimaOS
O problema na origem ocorreu apenas com um NAS Synology?
Não. O utilizador reproduziu bloqueios semelhantes com uma unidade USB externa.
A primeira cópia de segurança falhou?
A primeira execução controlada foi concluída; o problema recorrente surgiu em execuções posteriores.
O problema desapareceu no ZimaOS 1.6.1?
Não. O autor original afirmou explicitamente que o problema continuava a reproduzir-se nesse caso.
Um destino de cópia de segurança pode legitimamente ser maior do que a origem atual?
Sim, quando a retenção de versões está ativada, mas isso não explica todos os sintomas de apresentação ou de tarefas bloqueadas no tópico.
