Backups dos seus dados

33 min · 11 seções

Este guia trata do único backup que salva você de verdade: o que sai do NAS.

Todo o resto que o LGM-OS faz pelos seus dados fica dentro do mesmo dispositivo. O RAID aguenta que um disco quebre, não que o dispositivo quebre. Os snapshots desfazem uma exclusão, não um incêndio, um roubo, uma sobretensão que leve os discos junto nem um ransomware que criptografe o que o NAS tem montado. O backup da configuração (nas-config-*.tar.gz) devolve o painel ao que era, e nem um único arquivo seu.

1. A regra 3-2-1 aplicada a este NAS

3 cópias de cada dado · em 2 mídias diferentes · com 1 fora do prédio.

Num NAS doméstico isso se traduz em algo bem concreto:

Os snapshots não contam como cópia: compartilham os discos com o original. Contam como histórico, que é outra coisa igualmente útil, mas para outro problema.

Se puder, aumente a aposta para 3-2-1-1-0: uma das cópias desconectada (um disco USB que fica guardado numa gaveta ou fora de casa e só é conectado para copiar — é a única coisa que um ransomware não consegue alcançar) e 0 erros, ou seja, restaurações de teste que são feitas e anotadas (seção 6).

2. O que copiar

Nem tudo merece sair do NAS: o backup externo costuma ser o recurso mais caro e mais lento que você tem. Ordene pelo que aconteceria se aquilo sumisse.

Dois detalhes que sempre se esquecem:

• Inclua a configuração do NAS. Baixe um nas-config-*.tar.gz (Painel de controle → Backup da configuração) para uma pasta que entre no backup externo, ou agende a tarefa de configuração para essa pasta. Sem ela, recuperar o dispositivo é reconstruir à mão usuários, permissões e compartilhamentos.
• Pare de escrever antes de copiar os dados de um app. Um banco de dados copiado a quente pode ser restaurado corrompido. Pare o contêiner (ou use o dump agendado dele mesmo) e copie depois. Para arquivos normais, não é preciso.

E cuidado com a lixeira de rede: ela fica dentro da própria pasta da casa, então é copiada junto. Agende uma tarefa “Esvaziar lixeira antiga” (Painel de controle → Tarefas agendadas) para que o que você excluiu há meses não continue viajando para o seu backup externo.

2 ante. Minha pasta em todo lugar (o “Drive” do NAS)

Antes de tudo, a frase que é preciso ler duas vezes: isto não é um backup.

Uma pasta sincronizada é um espelho vivo: o que você salva no notebook aparece no NAS e nos seus outros dispositivos, e o que você exclui em um desaparece de todos. É exatamente o que você quer para trabalhar —o arquivo está onde você estiver— e exatamente o que você não quer para se proteger: uma exclusão, uma criptografia ou um “salvar por cima” viajam tão rápido quanto um arquivo novo. O que protege você disso são os snapshots do NAS, que funcionam por conta própria, quase não ocupam espaço e que uma criptografia do notebook não alcança.

Isso é configurado em Backups → Sincronização, bem no alto.

Como é feito

Por WebDAV, que o NAS já serve: você marca “WebDAV” na pasta da casa, escolhe a pasta aqui e pronto, ela está publicada. No computador se usa o rclone, que existe para Windows, Mac e Linux e é o mesmo programa que este NAS usa para todo o resto. O painel lhe dá a configuração pronta, com o nome do NAS, a pasta e o intervalo já preenchidos.

Não há um programa próprio para instalar em cada dispositivo, e é de propósito: um cliente de desktop para três sistemas são três instaladores, três assinaturas e três atualizações para manter para sempre, e cada uma delas é uma nova forma de o NAS da sua casa ficar sem suporte.

A senha não sai do NAS. O texto que você copia tem uma lacuna que você preenche no próprio computador. Um texto que se copia e cola acaba na área de transferência, num chat e numa captura de tela.

Os conflitos: nada é jogado fora

Dois computadores mexem no mesmo arquivo sem se ver —um no avião, outro em casa—. Há duas políticas e nenhuma das duas exclui:

Escolher por você e jogar fora o trabalho do outro não é uma opção. Quando aparece um conflito, o NAS avisa dizendo onde está a outra versão: sem essa frase, as pessoas procuram na lixeira e dão por perdido o que está ao lado.

E o que um rclone bisync feito à mão não dá: saber se continua funcionando

Cada computador manda um relatório ao terminar cada passada, e o painel mostra um semáforo por dispositivo. Se um deles fica em silêncio, o NAS avisa. É o mesmo motivo que vale para os dispositivos de casa: uma pasta que parou de sincronizar em março parece exatamente igual a uma que sincronizou há cinco minutos —os arquivos continuam lá— e a diferença só aparece no dia em que você procura o que achava que estava guardado.

O prazo é doze vezes o intervalo desse dispositivo: com cinco minutos, uma hora. Um notebook fechado por um tempo não é um notebook quebrado.

Detalhes que custam caro se você não os conhece

• A primeira passada é diferente. Ela leva --resync e emparelha os dois lados; daí em diante não é usado de novo. Colocá-lo em todas as passadas transforma o espelho em “o que um dos dois lados disser”, que é a ordem que apaga o trabalho do outro.
• Sincroniza como o usuário do NAS, com as permissões dele: se essa pessoa não pode escrever na pasta, a sincronização também não pode.
• Parar de sincronizar não exclui nada. Tirar a pasta da lista corta o espelho; os arquivos ficam no NAS e nos computadores.

2 bis. Os dispositivos de casa: copiar o notebook e o PC PARA o NAS

Tudo o que está acima trata de tirar do NAS o que já está dentro dele. Isto é o contrário: que o notebook e o PC de casa deixem o backup deles no NAS. E há um motivo para tratar disso à parte: o disco de um notebook é o que mais se perde na casa inteira —ele cai, molha, é levado— e é o que quase ninguém copia.

Em Backups → Dispositivos há um assistente que deixa tudo pronto em um passo: cria uma pasta da casa só para esse usuário, define a cota de espaço dela, liga o Time Machine se for um Mac e diz exatamente o que clicar nesse dispositivo. Nenhum protocolo é inventado: o Time Machine e o Histórico de Arquivos do Windows já sabem copiar para uma pasta de rede.

O que importa de verdade: ficar sabendo que ele parou de copiar

Copiar os dois sistemas já sabiam. O que ninguém fazia era perceber que um dos dois parou, e é aí que os dados se perdem de verdade:

• O Time Machine desiste em silêncio quando não encontra o disco várias vezes seguidas.
• O Histórico de Arquivos do Windows se desliga sozinho ao mudar de rede.
• A cota enche e o backup para de escrever.

Nenhuma das três coisas faz barulho. Um backup parado em março e descoberto em dezembro são nove meses de fotos. Por isso cada dispositivo cadastrado tem seu semáforo —em dia, atrasado, SEM BACKUP— e o NAS avisa quando um deles fica em silêncio. O prazo é definido por dispositivo (“espera-se a cada N dias”) e o aviso só dispara depois de três vezes esse prazo: um notebook desligado no fim de semana não é um notebook quebrado, e um sistema que grita por isso ensina você a ignorá-lo.

Para saber quando ele copiou, o NAS olha a data do item mais novo na pasta desse dispositivo. Não é preciso instalar nada: o Time Machine e o Histórico de Arquivos não contam a ninguém o que fazem, então ou se olha a pasta ou não se sabe.

O script, se você quiser escolher as pastas

Para Linux, ou para quem quer algo mais fino que o Time Machine, o painel dá um script —quatro linhas de PowerShell ou de shell, com o nome do NAS e a pasta já preenchidos— que copia o que você mandar e conta ao NAS como foi. Com o script, o semáforo deixa de ser uma dedução e passa a ser um relatório: se o robocopy ou o rsync falharem, o aviso chega naquela mesma noite em vez de depois de três prazos.

Ele copia com o que o sistema já traz —robocopy no Windows, rsync no Mac e no Linux— e não com um programa que precise ser instalado e mantido em cada notebook da casa. E as versões não são feitas pelo script: ele deixa um espelho, e as versões são os snapshots do NAS, que já são feitos sozinhos, quase não ocupam espaço e uma criptografia do PC não alcança.

O script leva dentro um token desse dispositivo. Ele serve só para dizer “fiz o backup” —não dá acesso a nada— e é descartado ao tirar o dispositivo da lista.

O que isto NÃO faz

Não clona o disco inteiro de um PC nem permite iniciar a partir do backup (bare metal). Copiam-se arquivos, não sistemas. Se um notebook quebrar, você recupera seus documentos e suas fotos, mas o Windows ou o macOS precisam ser reinstalados.

E tirar um dispositivo da lista não exclui a pasta dele nem o que ele já copiou: só deixa de vigiá-lo. Excluir os dados de alguém ao tirá-lo de uma lista é o tipo de surpresa que um sistema de backup nunca pode dar.

3. Para onde copiar

O app trabalha com três tipos de destino: local (um caminho do NAS, tipicamente um disco USB montado), remoto por SSH (rsync para outro servidor) e nuvem (Google Drive, OneDrive, Dropbox, Box, pCloud, MEGA, WebDAV, Amazon S3, Wasabi, MinIO e Backblaze B2).

Um padrão que funciona muito bem e não custa dinheiro: backup recíproco. Seu NAS copia na casa do seu irmão e o dele copia na sua. Cada um entra com disco e luz, ninguém paga mensalidade, e as duas cópias estão a quilômetros de distância.

Blindar o destino (para que o NAS não possa apagar os próprios backups)

A chave SSH e o token da nuvem ficam dentro do NAS, que é justamente a máquina que se supõe comprometida quando chega uma criptografia. Um ransomware sério não começa pelas suas fotos: começa pelos backups, e os apaga com as suas próprias credenciais antes de pedir o resgate.

Cada destino tem uma chave Blindar este destino, e o que ela faz depende do tipo:

E o importante: testa-se, não se promete. O botão Testar o cadeado deixa um arquivo isca no destino e tenta apagá-lo. Que a exclusão falhe é o resultado bom. É a única forma de saber: um lock_days salvo na configuração não prova que o bucket tem Object Lock, e uma chave “restrita” que ninguém testou quase nunca está. O NAS repete esse teste uma vez por semana e avisa só se um destino que estava blindado deixar de estar — alguém reinstalou o servidor e colocou de novo a chave sem restrição, o bucket foi recriado sem Object Lock…

Para um destino por SSH, o painel lhe dá pronta a linha que é preciso colar em ~/.ssh/authorized_keys do usuário dos backups, na outra ponta. Escrevê-la à mão é onde se erra.

Backups na nuvem

Backups → Destinos → Novo destino → Nuvem. Há duas formas de conectar, conforme o provedor:

• Com a sua conta (Google Drive, OneDrive, Dropbox, Box, pCloud). O painel lhe dá um link, você entra com sua conta no site do provedor e cola de volta o endereço para o qual ele redireciona você. O NAS guarda a permissão, não a sua senha.
• Com chaves (S3, Wasabi, MinIO, Backblaze B2, WebDAV, MEGA). Você cola a chave de acesso e a secreta que o serviço lhe dá. No S3 e no B2, o nome do bucket é o primeiro trecho da pasta de destino: micubo/LGM-OS.

Como as versões são guardadas. Num disco ou por SSH, cada backup reaproveita os arquivos que não mudaram por meio de links físicos, e assim uma versão diária ocupa só o que mudou. Na nuvem não existem links físicos, então funciona diferente: actual/ é um espelho das suas pastas e, cada vez que um arquivo é substituído ou excluído, a versão anterior é separada numa pasta com a data do backup anterior. Nada se perde, mas uma versão antiga contém só os arquivos que mudaram depois, não a foto completa daquele dia.

Criptografia de ponta a ponta (opcional, e recomendada). Ao criar o destino você pode ativar a criptografia: os nomes e o conteúdo são criptografados no NAS antes de enviar qualquer coisa e o provedor só vê dados ilegíveis — nem suas fotos nem os nomes delas. A chave é gerada pelo NAS e mostrada a você uma única vez como frase de recuperação: anote-a fora do NAS (papel, gerenciador de senhas). O NAS a guarda para copiar toda noite, mas se o NAS morrer, essa frase é a única coisa que abre o backup; com ela e qualquer rclone você recupera a partir de qualquer dispositivo. Isso é decidido ao criar o destino e não pode ser mudado depois: criptografar um destino com backups feitos partiria o espelho em duas metades ilegíveis entre si. O explorador e a restauração funcionam igual com criptografia e sem ela.

Antes de começar: veja quanto ocupam as suas pastas. Enviar 2 TB por uma fibra doméstica de 300 Mb de upload são uns quinze dias a pleno vapor. O sensato é começar copiando só o insubstituível (documentos, fotos) e deixar de fora o que pode ser baixado de novo.

O que ainda NÃO faz (e por que isso é dito aqui)

• Criptografia de uma pasta do próprio NAS ou de um destino por SSH. Ali cada versão é construída com links físicos para a anterior, e uma criptografia por arquivo muda o conteúdo a cada passada: quebraria justamente o que torna as versões baratas e possível restaurar um arquivo avulso. Na nuvem e num disco USB ela existe (veja acima e 5.1), porque ali o backup é um espelho e não há links físicos a perder. Se o servidor remoto não é seu, criptografe o disco na outra ponta (LUKS).
• Imagem do disco do sistema (bare metal). Diante de um desastre, reinstala-se a partir da ISO e restaura-se a configuração; é rápido, mas não é “clonar e iniciar”. Isso está explicado em disaster-recovery.md.

Sobre a privacidade do destino: o transporte vai criptografado quando você copia por SSH, mas os arquivos que chegam são legíveis para quem administra aquele dispositivo. Se o destino não é seu, criptografe o disco de destino (LUKS na outra ponta, ou o próprio disco USB) e guarde essa senha fora do NAS (gerenciador de senhas, papel numa gaveta).

4. Com que frequência

A pergunta útil não é “com que frequência eu copio”, mas quanto trabalho estou disposto a perder. Essa é a frequência.

Agende os backups fora dos seus horários de uso e não todos ao mesmo tempo: um backup externo na mesma hora que um scrub deixa o NAS lento por horas. Uma boa divisão é backup às 03:00 e scrub num domingo por mês às 05:00.

E algo que ninguém faz até acontecer com ele: ative os alertas (Painel de controle → Alertas, SMTP ou webhook). Uma tarefa de backup que está falhando em silêncio há três meses é exatamente tão útil quanto não ter backup. A aba de estado do app também avisa quando não há nenhum backup configurado, quando o último falhou, quando uma tarefa está há tempo demais sem rodar, quando está desativada ou quando o destino dela não está disponível.

5. Configurar um backup passo a passo

O app Backups separa duas coisas, e vale a pena entender por quê:

• Destinos — onde fica guardado: o disco USB ou o servidor remoto. São definidos uma vez e testados com o botão “Testar conexão”, que não diz só se funciona: mostra passo a passo qual verificação falha (a pasta, as permissões, a chave, o rsync do outro lado) e qual comando executar para consertar. Teste-os antes de confiar neles, e de novo quando mudar alguma coisa: um USB desconectado ou um servidor desligado é melhor descobrir ali do que às três da manhã.
• Trabalhos — o que se copia e quando: pastas de origem (com exclusões opcionais), destino, horário e quanto se guarda — a retenção inteligente de fábrica, ou por número de versões ou por idade em dias.

Cada trabalho tem também uma velocidade máxima em MB/s, no último passo do assistente. Deixe-a vazia e o backup vai tão rápido quanto puder; coloque um número e ele não passa disso. É o que você quer quando o backup vai para outro dispositivo ou para a nuvem e você não quer que ele ocupe todo o upload da casa: com 100 Mb/s de upload (uns 12 MB/s), um limite de 6 MB/s deixa metade livre para o resto. Só freia os backups: restaurar nunca é freado, porque aí sempre há alguém esperando.

Cada execução deixa uma versão restaurável no destino e uma entrada no histórico (com data, tamanho e o erro exato se falhou). Com Explorar você entra em qualquer versão como se fosse uma pasta —que arquivos havia naquele dia, com tamanho e data— e restaura a versão inteira ou só o que marcar, até um arquivo avulso.

5.1 Para um disco USB ou outro pool (destino local)

1. Conecte o disco. Se ele vem do Windows, formate-o pelo Armazenamento (ext4/Btrfs) ou deixe-o em NTFS/exFAT: o LGM-OS o monta do mesmo jeito, mas **NTFS e exFAT não guardam permissões nem proprietários do Linux**, então o que você restaurar chegará sem eles. Para backups sérios, use um disco com formato Linux.
2. Crie um destino do tipo local com o caminho onde o disco está montado, e teste-o: o teste escreve de verdade nessa pasta, que é a única forma de saber que dá para escrever.
3. Crie o trabalho: nome, pastas de origem, esse destino, horário e versões a guardar.
4. Rode-o à mão uma vez e veja se termina. Confira depois o tamanho no destino: se forem 4 GB de uma pasta de 400, revise quais pastas você escolheu como origem.

Se esse disco sai de casa, criptografe-o. Quando a pasta do destino está num disco USB, ao criá-lo aparece “Criptografar o que é salvo neste disco”. Com a chave ligada, os nomes e o conteúdo são criptografados no NAS antes de escrever qualquer coisa: um disco perdido ou roubado não pode ser lido. O disco continua no formato de sempre —exFAT, NTFS, ext4— e, com a frase de recuperação, abre em qualquer computador que tenha rclone, mesmo que o NAS já não exista. A frase é mostrada uma única vez, ao criar o destino: anote-a fora do NAS e longe do disco, porque sem ela não se recupera nada. Isso é decidido ao criar e não pode ser mudado depois. Em troca, esse destino guarda as versões como as da nuvem (um espelho actual/ e, com a data de cada passada, o que foi substituído) em vez de com links físicos.

5.2 Para outro servidor por SSH (destino remoto)

Aqui estão 90 % das dúvidas, então vai com todos os detalhes. Vamos chamar de NAS o seu dispositivo e de servidor remoto o que recebe o backup.

Passo 1 — Obtenha a chave pública do NAS

No app Backups, ao criar um destino remoto, o NAS gera seu próprio par de chaves SSH e mostra a pública. É uma única linha, parecida com esta:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIB4o…9c2K nas@lgm-os

A privada fica no NAS, em /etc/nas/ssh, um diretório que só o root pode ler: nem o painel nem nenhuma rota da API conseguem mostrá-la, porque o processo que atende a web roda sem privilégios. Copie-a tal como está, inteira e em uma única linha: se ao colá-la ela se partir em duas, a autorização não vai funcionar.

Passo 2 — Crie o usuário que vai receber o backup (no servidor remoto)

Não use o root nem o seu usuário pessoal. Um usuário dedicado e sem senha de acesso:

sudo adduser --disabled-password --gecos "" copias
sudo install -d -m 750 -o copias -g copias /copias/nas    # pasta de destino

Passo 3 — Autorize a chave (no servidor remoto)

O app lhe dá este mesmo comando já montado com a sua chave, pronto para copiar e colar numa sessão SSH do servidor remoto aberta com o usuário que vai receber o backup:

mkdir -p ~/.ssh && chmod 700 ~/.ssh \
  && echo 'ssh-ed25519 AAAA…' >> ~/.ssh/authorized_keys \
  && chmod 600 ~/.ssh/authorized_keys

Se você preferir fazer isso a partir de outra conta com sudo, o equivalente é:

sudo install -d -m 700 -o copias -g copias /home/copias/.ssh
sudo -u copias tee -a /home/copias/.ssh/authorized_keys >/dev/null
# cole aqui a linha completa da chave pública e pressione Enter e depois Ctrl+D
sudo chmod 600 /home/copias/.ssh/authorized_keys

As permissões não são um detalhe estético: se .ssh não for 700 ou authorized_keys não for 600, o OpenSSH ignora a chave sem explicar por quê e você verá um “Permission denied (publickey)” desconcertante.

Recomendado — limite o que essa chave pode fazer, adicionando opções no começo da mesma linha, antes de ssh-ed25519:

restrict,from="203.0.113.10" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIB4o…9c2K nas@lgm-os

• restrict desativa redirecionamento de portas, agente, X11 e terminal interativo. O rsync continua funcionando (exige OpenSSH 7.2 ou posterior; o Debian 11 e o 12 cumprem isso de sobra).
• from="…" aceita essa chave só a partir do seu IP público. Se o seu IP é dinâmico, ele aceita o seu nome DDNS (from="micasa.duckdns.org") ou tire a opção.

Nível avançado, se o servidor remoto não é totalmente seu: o rrsync prende a chave num único diretório e em modo só escrita, de modo que ela não consegue nem ler o resto do disco. No Debian 12 ele vem com o pacote rsync em /usr/bin/rrsync (em versões anteriores, comprimido em /usr/share/doc/rsync/scripts/):

command="/usr/bin/rrsync -wo /copias/nas",restrict ssh-ed25519 AAAA…

Tenha em mente que com -wo (só escrita) o backup entra, mas você não consegue restaurar pelo mesmo caminho: a restauração é feita a partir do servidor remoto ou tirando essa restrição temporariamente. É uma troca consciente, não um esquecimento.

Passo 4 — Confira a impressão digital do servidor remoto

A primeira conexão vai pedir para você aceitar a impressão digital do servidor. Aceitá-la às cegas é aceitar qualquer dispositivo que se coloque no meio, então obtenha a verdadeira executando no servidor remoto:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Compare essa sequência SHA256:… com a que o NAS mostrar ao testar o destino. Ou coincidem, ou não a aceite.

Passo 5 — Teste a conexão e salve

Use o botão de testar do destino no app: ele verifica se o NAS entra, se a pasta existe e se consegue escrever nela. Se preferir ver isso pelo console do NAS, faça como root e apontando para a chave gerenciada, que é a que os backups vão usar (quem executa o rsync é o processo privilegiado, não o usuário de serviço):

sudo ssh -i /etc/nas/ssh/id_ed25519 -p 22 copias@servidor.example.com 'touch /copias/nas/.prueba && echo ok'

O que significa cada falha típica:

Passo 6 — Crie o trabalho de backup

Nome, pastas de origem, esse destino remoto, horário e quanto se guarda. Se o dispositivo de destino não é seu, criptografe lá o disco que recebe o backup (LUKS): o painel ainda não criptografa o backup na origem, e diz isso. Primeira execução à mão: o backup inicial manda tudo e pode levar horas ou dias conforme a linha de upload. Os seguintes são incrementais (o rsync só manda o que mudou) e duram minutos. Se o primeiro backup pela internet for inviável, faça-o localmente: leve o NAS ou um disco USB até o local do servidor remoto, copie pela rede local e depois mude o destino para a conexão remota — o rsync vai ver que quase tudo já está lá e só vai enviar as diferenças.

5.3 Retenção: o backup não é um espelho

Um detalhe que decide se você sobrevive a um ransomware ou não. Se o backup se limita a espelhar a origem, um arquivo que é excluído (ou criptografado) hoje no NAS é excluído (ou criptografado) esta noite também no backup.

Defesas, da menor para a maior:

1. Versões guardadas no trabalho: cada execução deixa uma versão e só as mais antigas são apagadas quando se passa do número que você definiu. Com 7 versões diárias você tem uma semana para perceber que algo quebrou; com 1 versão, nenhuma. Considere o espaço: N versões ocupam mais que uma, embora as partes que não mudam sejam compartilhadas entre elas. A retenção inteligente (a de fábrica) faz isso sem números: guarda todos os backups das últimas 24 horas, um por dia durante 7 dias, um por semana durante 4 semanas e um por mês durante 12 meses — recentes de sobra para um susto de hoje, e um ano de profundidade para o que se descobre tarde. Ela conta “os últimos N períodos com backups”, como o restic: se o NAS passou meses desligado, o que é anterior a esse buraco não é jogado fora só por ser velho.
2. Snapshots no destino: se o servidor remoto é outro NAS com ZFS ou Btrfs, que ele faça seus próprios snapshots do diretório de backups. É a proteção mais barata e a mais eficaz.
3. Um backup desconectado: o disco USB da gaveta. Nada que não esteja plugado pode ser criptografado.

6. Provar que o backup serve (a única parte que não é opcional)

Um backup não verificado não é um backup: é uma pasta grande em que você confia por fé. Os três indicadores que não provam nada são o trabalho em verde, o tamanho do destino e “o rsync não deu erro”.

O botão Verificar de cada trabalho faz metade do serviço sem mover um byte: lê o backup inteiro do destino e confere se bate com o que foi anotado ao copiá-lo (em disco e por SSH, o número de arquivos e o tamanho da versão; na nuvem, a comparação entre o peso do espelho e o peso da origem). O resultado fica no cartão e no histórico, e se não bater o NAS avisa como avisa de um backup que falhou. Ele detecta o backup que ficou pela metade, o destino que perdeu arquivos e o disco que está morrendo — o que ele não consegue provar é que os bytes dentro de cada arquivo continuam sendo os bons, então a verificação complementa o teste de verdade, não o substitui.

O único teste válido é restaurar de verdade e abrir o arquivo restaurado. Com o explorador isso custa menos do que nunca: entre numa versão, marque três arquivos ao acaso e restaure-os para uma pasta temporária.

E se o disco de destino é criptografado (LUKS), o teste inclui abri-lo com a senha dele: um disco criptografado cuja chave ninguém lembra é espaço ocupado, não um backup.

O teste de restauração automático (o NAS faz sozinho)

Tudo o que está acima é ótimo e quase ninguém faz. Por isso o NAS faz por você: uma vez por mês ele pega alguns arquivos ao acaso do último backup de cada trabalho, restaura-os de verdade para uma pasta temporária e os compara com o original. Depois apaga o que restaurou e conta isso no relatório semanal.

Não é a verificação do botão Verificar —essa olha o tamanho e o número de arquivos—. O teste de restauração restaura, com os mesmos programas e o mesmo caminho que você usaria no dia ruim, e compara byte a byte com o original: é a única coisa que descobre um destino que aceita gravações e devolve lixo, uma chave de criptografia perdida ou um disco que lê mal justamente o setor onde estavam as fotos.

Como ele evita incomodar e como evita mentir:

• Vinte arquivos, meio giga e quinze minutos no máximo. Num backup de dois teras isso nem se nota; e, como é ao acaso, em um ano metade do backup terá sido testada.
• Só escolhe arquivos que já existiam quando o backup foi feito. Se você mexeu no original depois, o backup tem que ser diferente, e compará-los daria uma falha inventada. Com essa regra, “diferente” só pode significar “o backup está errado”.
• Não mexe em nada. Restaura para uma pasta temporária e a apaga ao terminar.
• O que não pôde ser comparado não é dado como bom. Isso é contado à parte: o número que aparece como verificado é o dos que foram comparados de verdade.

Ele aparece em Backups → Trabalhos, abaixo da lista, com um botão Testar agora caso você não queira esperar o mês. E sai no relatório semanal, numa seção própria; se algum backup não volta, além disso chega um aviso e a nota do relatório cai bastante: um backup que existe e não volta é pior que não ter backup, porque ninguém está procurando outro.

Plano de testes

Restauração de teste (mensal)

Pelo app: escolha o trabalho, a versão que quer recuperar e uma pasta de destino nova — nunca por cima do original, porque se algo der errado você vai querer poder comparar os dois. A restauração roda como tarefa, com seu progresso, igual ao backup.

Depois abra alguns arquivos: uma foto que aparece, um PDF que abre, um vídeo que reproduz. Um arquivo de 4 MB que existe mas não abre é um arquivo perdido. E apague depois a pasta de testes, que ocupa o mesmo que o restaurado.

Restauração completa de uma pasta (trimestral)

Restaure pelo app uma pasta inteira para /mnt/<pool>/prueba-restauracion e compare-a com o original. Pelo console do NAS:

# 1. Comparar com o original: não deve listar diferenças
sudo diff -qr /mnt/tanque/documentos /mnt/tanque/prueba-restauracion

# 2. Verificação forte (compara conteúdo, não datas nem tamanhos)
sudo rsync -avnc --delete /mnt/tanque/documentos/ /mnt/tanque/prueba-restauracion/

# 3. Apagar a pasta de testes quando terminar
sudo rm -rf /mnt/tanque/prueba-restauracion

No passo 2, -c compara checksums (lento, mas honesto) e -n não muda nada: se esse comando não listar arquivos, o conteúdo é idêntico bit a bit. Atenção ao espaço: o teste duplica temporariamente o que você restaurar, então escolha uma pasta que caiba.

Um detalhe importante se você restaurar uma versão antiga: as diferenças com o original de hoje são normais (é o que mudou desde então). Para esta comparação use a última versão, ou compare só arquivos que você sabe que não mexeu.

Anote o resultado

Duas linhas por teste, onde quiser, mas anote-as:

2026-07-25 · Restaurados 4 arquivos do backup remoto · abrem bem · 3 min
2026-07-25 · Restauração completa de “documentos” (38 GB) · diff sem diferenças · 41 min

O dado que quase ninguém mede é o tempo de restauração. Saber que recuperar 2 TB pela internet leva quatro dias muda decisões: talvez você queira o backup local além do remoto, ou um disco que possa ir buscar de carro.

O que fazer se o teste falhar

Falhe o teste, não o dia do desastre: é exatamente para isso que ele serve. Revise as origens do trabalho (faltava uma pasta?), as permissões do destino, o histórico para ver se ele estava falhando em silêncio havia semanas e, se o disco de destino for criptografado, se a senha é a que você acha. Corrija, copie de novo e teste de novo.

7. O que este backup não cobre

Com honestidade, para que não pegue você de surpresa:

• Um arquivo corrompido que é copiado corrompido. O rsync copia o que existe. Contra isso existem os checksums do ZFS/Btrfs e os scrubs agendados, que detectam a corrupção na origem antes que ela se propague.
• O que você não escolheu como origem. Uma pasta da casa nova não entra sozinha em nenhum trabalho: quando você criar uma, adicione-a ao trabalho que lhe corresponde, ou ela vai ficar fora do backup sem que ninguém avise.
• O tempo de upload. Uma linha doméstica de 300 Mbps de download costuma ter 30 de upload: uns 10 GB por hora no melhor dos casos. Dimensione o primeiro backup com isso em mente.
• As senhas e o 2FA. O backup da configuração não leva a chave de assinatura de sessões (ela é gerada de novo) e os seus códigos TOTP estão no seu celular, não no NAS. Guarde os códigos de recuperação em outro lugar.

8. O backup na nuvem falha

Primeiro: a mensagem de erro, no app Backups, agora diz o que a nuvem respondeu (sem espaço, permissão expirada, endereço errado…). Esse texto é o diagnóstico; o que vem abaixo é para os casos que se repetem.

Nextcloud e outros WebDAV: use uma senha de aplicativo, não a da sua conta (Configurações → Segurança → Dispositivos e sessões). Se o servidor estiver atrás de um proxy com limite de tamanho de envio, esse limite manda sobre qualquer configuração do NAS.

Veja também

• Recuperação de desastres — o que fazer quando já aconteceu.
• Guia de administração — snapshots, scrubs, alertas.