Cópias de segurança dos teus dados

33 min · 11 secções

Este guia fala da única cópia que te salva de verdade: a que sai do NAS.

Tudo o resto que o LGM-OS faz pelos teus dados vive dentro do mesmo dispositivo. O RAID aguenta que se avarie um disco, não que se avarie o dispositivo. Os snapshots desfazem uma eliminação, não um incêndio, um roubo, uma sobretensão que leve os discos à frente nem um ransomware que encripte o que o NAS tem montado. A cópia da configuração (nas-config-*.tar.gz) devolve o painel ao estado em que estava, e nem um único ficheiro teu.

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

3 cópias de cada dado · em 2 suportes diferentes · com 1 fora do edifício.

Num NAS doméstico, isto traduz-se em algo muito concreto:

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

Se puderes, sobe a fasquia para 3-2-1-1-0: uma das cópias desligada (um disco USB que se guarda numa gaveta ou fora de casa e só se liga para copiar — é a única coisa que um ransomware não consegue alcançar) e 0 erros, ou seja, restauros de teste que se fazem e se registam (secção 6).

2. O que copiar

Nem tudo merece sair do NAS: a cópia externa costuma ser o recurso mais caro e mais lento que tens. Ordena pelo que aconteceria se desaparecesse.

Dois pormenores que se esquecem sempre:

• Inclui a configuração do NAS. Transfere um nas-config-*.tar.gz (Painel de controlo → Cópia da configuração) para uma pasta que entre na cópia externa, ou agenda a tarefa de configuração para essa pasta. Sem ela, recuperar o dispositivo é reconstruir à mão utilizadores, permissões e partilhas.
• Para de escrever antes de copiar os dados de uma app. Uma base de dados copiada a quente pode ser restaurada corrompida. Para o contentor (ou usa o seu próprio dump agendado) e copia depois. Para ficheiros normais não é preciso.

E atenção à reciclagem de rede: vive dentro da própria pasta da casa, por isso é copiada com ela. Agenda uma tarefa «Esvaziar reciclagem antiga» (Painel de controlo → Tarefas agendadas) para que o que eliminaste há meses não continue a viajar para a tua cópia externa.

2 ante. A minha pasta em todo o lado (o «Drive» do NAS)

Antes de mais, a frase que tens de ler duas vezes: isto não é uma cópia de segurança.

Uma pasta sincronizada é um espelho vivo: o que guardas no portátil aparece no NAS e nos teus outros dispositivos, e o que eliminas num desaparece de todos. É exatamente o que queres para trabalhar —o ficheiro está onde tu estiveres— e exatamente o que não queres para te proteger: uma eliminação, uma encriptação ou um «guardar por cima» viajam tão depressa como um ficheiro novo. O que te protege disso são os instantâneos do NAS, que vão por sua conta, quase não ocupam espaço e que uma encriptação do portátil não alcança.

Configura-se em Cópias de segurança → Sincronização, lá em cima.

Como está feito

Por WebDAV, que o NAS já serve: marcas «WebDAV» na pasta da casa, escolhe-la aqui e fica publicada. No computador usa-se o rclone, que existe para Windows, Mac e Linux e é o mesmo programa que este NAS usa para tudo o resto. O painel dá-te a configuração feita, 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 ambiente de trabalho 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 tua casa ficar sem suporte.

A palavra-passe não sai do NAS. O texto que copias leva um espaço que preenches no próprio computador. Um texto que se copia e se cola acaba na área de transferência, num chat e numa captura de ecrã.

Os conflitos: nunca se deita nada fora

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

Escolher por ti e deitar 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 reciclagem e dão por perdido o que têm ao lado.

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

Cada computador envia um relatório ao terminar cada passagem, e o painel mostra um semáforo por dispositivo. Se um se cala, o NAS avisa. É a mesma razão que nos dispositivos de casa: uma pasta que deixou de sincronizar em março parece exatamente igual a uma que sincronizou há cinco minutos —os ficheiros continuam lá— e a diferença só aparece no dia em que procuras o que julgavas guardado.

O prazo é doze vezes o intervalo desse dispositivo: com cinco minutos, uma hora. Um portátil fechado durante um bocado não é um portátil avariado.

Pormenores que se pagam caro se não se conhecem

• A primeira passagem é diferente. Leva --resync e emparelha os dois lados; a partir daí não volta a ser usado. Pô-lo em todas as passagens transforma o espelho em «o que disser um dos dois lados», que é a ordem que apaga o trabalho do outro.
• Sincroniza como o utilizador do NAS, com as suas permissões: se essa pessoa não pode escrever na pasta, a sincronização também não pode.
• Deixar de sincronizar não elimina nada. Remover a pasta da lista corta o espelho; os ficheiros ficam no NAS e nos computadores.

2 bis. Os dispositivos de casa: copiar o portátil e o PC PARA o NAS

Tudo o que está acima trata de tirar do NAS o que já está lá dentro. Isto é ao contrário: que o portátil e o PC de casa deixem a sua cópia no NAS. E há uma razão para o tratar à parte: o disco de um portátil é o que mais se perde na casa toda —cai, molha-se, é roubado— e é o que quase ninguém copia.

Em Cópias de segurança → Dispositivos há um assistente que o deixa feito num passo: cria uma pasta da casa só para esse utilizador, põe-lhe o seu limite de espaço, liga o Time Machine se for um Mac e diz-te exatamente o que carregar nesse dispositivo. Não se inventa nenhum protocolo: o Time Machine e o Histórico de Ficheiros do Windows já sabem copiar para uma pasta de rede.

O que importa de verdade: dar conta de que deixou de copiar

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

• O Time Machine desiste em silêncio quando não encontra o disco várias vezes seguidas.
• O Histórico de Ficheiros do Windows desliga-se sozinho ao mudar de rede.
• A quota enche e a cópia deixa de escrever.

Nenhuma das três coisas faz barulho. Uma cópia parada em março e descoberta em dezembro são nove meses de fotos. Por isso cada dispositivo registado tem o seu semáforo —em dia, com atraso, SEM COPIAR— e o NAS avisa quando um se cala. O prazo define-se por dispositivo («espera-se a cada N dias») e o aviso não dispara antes de três vezes esse prazo: um portátil desligado no fim de semana não é um portátil avariado, e um sistema que grita por isso ensina a ignorá-lo.

Para saber quando copiou, o NAS olha para a data do mais recente que há na pasta desse dispositivo. Não é preciso instalar nada: o Time Machine e o Histórico de Ficheiros não contam a ninguém o que fazem, por isso ou se olha para a pasta ou não se sabe.

O script, se quiseres escolher tu as pastas

Para Linux, ou para quem quiser algo mais fino do 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 lhe disseres e conta ao NAS como correu. 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 nessa mesma noite em vez de ao fim de três prazos.

Copia com o que o sistema já traz —robocopy no Windows, rsync no Mac e no Linux— e não com um programa que seja preciso instalar e manter em cada portátil da casa. E as versões não são feitas pelo script: deixa um espelho, e as versões são os instantâneos do NAS, que já são feitos sozinhos, quase não ocupam espaço e que uma encriptação do PC não alcança.

O script leva dentro um token desse dispositivo. Serve só para dizer «copiei» —não dá acesso a nada— e deita-se fora removendo o dispositivo da lista.

O que isto NÃO faz

Não clona o disco inteiro de um PC nem permite arrancar a partir da cópia (bare metal). Copiam-se ficheiros, não sistemas. Se um portátil avariar, recuperas os teus documentos e as tuas fotos, mas o Windows ou o macOS têm de ser reinstalados.

E remover um dispositivo da lista não elimina a sua pasta nem o que já copiou: só deixa de ser vigiado. Eliminar os dados de alguém ao tirá-lo de uma lista é o tipo de surpresa que um sistema de cópias nunca pode dar.

3. Para onde copiar

A app trabalha com três tipos de destino: local (um caminho do NAS, tipicamente um disco USB montado), remoto por SSH (rsync contra 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: cópia recíproca. O teu NAS copia para casa do teu irmão e o dele copia para a tua. Cada um põe disco e eletricidade, 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 eliminar as suas próprias cópias)

A chave SSH e o token da nuvem vivem dentro do NAS, que é exatamente a máquina que se supõe comprometida quando chega uma encriptação. Um ransomware a sério não começa pelas tuas fotos: começa pelas cópias, e elimina-as com as tuas próprias credenciais antes de pedir o resgate.

Cada destino tem um interruptor Blindar este destino, e o que faz depende do tipo:

E o importante: testa-se, não se promete. O botão Testar o cadeado deixa um ficheiro isco no destino e tenta eliminá-lo. Que a eliminação falhe é o resultado bom. É a única forma de o saber: um lock_days guardado na configuração não demonstra que o bucket tem Object Lock, e uma chave «restringida» que ninguém testou quase nunca o está. O NAS repete esse teste uma vez por semana e avisa só se um destino que estava blindado deixar de o estar — alguém reinstalou o servidor e voltou a pôr a chave sem restringir, o bucket foi recriado sem Object Lock…

Para um destino por SSH, o painel dá-te feita a linha que tens de colar em ~/.ssh/authorized_keys do utilizador das cópias, no outro extremo. Escrevê-la à mão é onde se falha.

Cópias na nuvem

Cópias de segurança → Destinos → Adicionar destino → Nuvem. Há duas formas de ligar, conforme o fornecedor:

• Com a tua conta (Google Drive, OneDrive, Dropbox, Box, pCloud). O painel dá-te uma ligação, entras com a tua conta no site do fornecedor e colas de volta o endereço para o qual te redireciona. O NAS guarda a autorização, não a tua palavra-passe.
• Com chaves (S3, Wasabi, MinIO, Backblaze B2, WebDAV, MEGA). Colas a chave de acesso e a secreta que o serviço te dá. No S3 e no B2, o nome do bucket é o primeiro troço da pasta de destino: micubo/LGM-OS.

Como se guardam as versões. Num disco ou por SSH, cada cópia reutiliza os ficheiros que não mudaram através de ligações físicas (hard links), e assim uma versão diária ocupa só o que mudou. Na nuvem não há ligações físicas, por isso funciona de outra forma: actual/ é um espelho das tuas pastas e, sempre que um ficheiro é substituído ou eliminado, a versão anterior é posta de lado numa pasta com a data da cópia anterior. Não se perde nada, mas uma versão antiga contém só os ficheiros que mudaram depois, não a fotografia completa desse dia.

Encriptação ponto a ponto (opcional, e recomendada). Ao criar o destino podes ativar a encriptação: os nomes e o conteúdo são encriptados no NAS antes de carregar seja o que for e o fornecedor só vê dados ilegíveis — nem as tuas fotos nem os seus nomes. A chave é gerada pelo NAS, que ta mostra uma única vez como frase de recuperação: aponta-a fora do NAS (papel, gestor de palavras-passe). O NAS guarda-a para copiar todas as noites, mas se o NAS morrer, essa frase é a única coisa que abre a cópia; com ela e qualquer rclone recupera-se a partir de qualquer dispositivo. Decide-se ao criar o destino e não pode ser mudado depois: encriptar um destino com cópias feitas partiria o espelho em duas metades ilegíveis entre si. O explorador e o restauro funcionam igual com encriptação e sem ela.

Antes de começar: vê quanto ocupam as tuas pastas. Carregar 2 TB por uma fibra doméstica de 300 Mb de upload são uns quinze dias a pleno rendimento. O sensato é começar por copiar só o insubstituível (documentos, fotos) e deixar de fora o que se pode voltar a transferir.

O que ainda NÃO faz (e porque se diz aqui)

• Encriptação de uma pasta do próprio NAS ou de um destino por SSH. Aí cada versão é construída com ligações físicas contra a anterior, e uma encriptação por ficheiro muda o conteúdo em cada passagem: estragaria exatamente o que torna as versões baratas e possível restaurar um ficheiro solto. Na nuvem e num disco USB existe (ver acima e 5.1), porque aí a cópia é um espelho e não há ligações físicas a perder. Se o servidor remoto não for teu, encripta o disco no outro extremo (LUKS).
• Imagem do disco de sistema (bare metal). Perante um desastre, reinstala-se a partir da ISO e restaura-se a configuração; é rápido, mas não é «clonar e arrancar». Está explicado em disaster-recovery.md.

Sobre a privacidade do destino: o transporte vai encriptado quando copias por SSH, mas os ficheiros que chegam são legíveis para quem administrar esse dispositivo. Se o destino não for teu, encripta o disco de destino (LUKS no outro extremo, ou o próprio disco USB) e guarda essa palavra-passe fora do NAS (gestor de palavras-passe, papel numa gaveta).

4. Com que frequência

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

Agenda as cópias fora das tuas horas de uso e não todas ao mesmo tempo: uma cópia externa à mesma hora que um scrub deixa o NAS lento durante horas. Uma boa distribuição é cópia às 03:00 e scrub num domingo por mês às 05:00.

E algo que ninguém faz até lhe acontecer: ativa os alertas (Painel de controlo → Alertas, SMTP ou webhook). Uma tarefa de cópia que está há três meses a falhar em silêncio é exatamente tão útil como não ter cópia. O separador de estado da app avisa também quando não há nenhuma cópia configurada, quando a última falhou, quando uma tarefa está há demasiado tempo sem ser executada, quando está desativada ou quando o seu destino não está disponível.

5. Configurar uma cópia passo a passo

A app Cópias de segurança separa duas coisas, e vale a pena perceber porquê:

• Destinos — onde se guarda: o disco USB ou o servidor remoto. Definem-se uma vez e testam-se com o botão «Testar ligação», que não diz só se funciona: mostra passo a passo que verificação falha (a pasta, as permissões, a chave, o rsync do outro lado) e que comando executar para o resolver. Testa-os antes de confiares neles, e outra vez quando mudares alguma coisa: um USB desligado ou um servidor desligado é melhor descobri-lo aí do que às três da manhã.
• Tarefas — o que se copia e quando: pastas de origem (com exclusões opcionais), destino, horário e quanto se conserva — a retenção inteligente de fábrica, ou por número de versões ou por antiguidade em dias.

Cada tarefa tem ainda uma velocidade máxima em MB/s, no último passo do assistente. Deixa-a vazia e a cópia irá tão depressa quanto puder; põe-lhe um número e não passará disso. É o que queres quando a cópia vai para outro dispositivo ou para a nuvem e não queres que ocupe todo o upload de casa: com 100 Mb/s de upload (uns 12 MB/s), um limite de 6 MB/s deixa metade livre para o resto. Só trava as cópias: restaurar nunca é travado, porque aí há sempre alguém à espera.

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 entras em qualquer versão como se fosse uma pasta —que ficheiros havia nesse dia, com o seu tamanho e a sua data— e restauras a versão inteira ou só o que marcares, até um ficheiro solto.

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

1. Liga o disco. Se vier do Windows, formata-o em Armazenamento (ext4/Btrfs) ou deixa-o em NTFS/exFAT: o LGM-OS monta-o na mesma, mas **o NTFS e o exFAT não guardam permissões nem proprietários do Linux**, por isso o que restaurares chegará sem eles. Para cópias a sério usa um disco com formato Linux.
2. Cria um destino do tipo local com o caminho onde o disco está montado, e testa-o: o teste escreve de verdade nessa pasta, que é a única forma de saber que é possível.
3. Cria a tarefa: nome, pastas de origem, esse destino, horário e versões a conservar.
4. Lança-a à mão uma vez e verifica que termina. Confirma depois o tamanho no destino: se forem 4 GB de uma pasta de 400, revê que pastas escolheste como origem.

Se esse disco sair de casa, encripta-o. Quando a pasta do destino está num disco USB, ao criá-lo aparece «Encriptar o que é guardado neste disco». Com o interruptor ligado, os nomes e o conteúdo são encriptados no NAS antes de escrever seja o que for: um disco perdido ou roubado não se consegue ler. O disco continua no seu formato de sempre —exFAT, NTFS, ext4— e, com a frase de recuperação, abre-se em qualquer computador que tenha rclone, mesmo que o NAS já não exista. A frase é mostrada uma única vez, ao criar o destino: aponta-a fora do NAS e longe do disco, porque sem ela não se recupera nada. Decide-se ao criar e não pode ser mudado depois. Em contrapartida, esse destino guarda as versões como as da nuvem (um espelho actual/ e, com a data de cada passagem, o que foi substituído) em vez de com ligações físicas.

5.2 Para outro servidor por SSH (destino remoto)

Aqui estão 90 % das dúvidas, por isso vai com todo o pormenor. Vamos chamar NAS ao teu dispositivo e servidor remoto ao que recebe a cópia.

Passo 1 — Obtém a chave pública do NAS

Na app Cópias de segurança, ao criar um destino remoto, o NAS gera o seu próprio par de chaves SSH e mostra-te 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 a podem mostrar, porque o processo que atende a web corre sem privilégios. Copia-a tal como está, inteira e numa única linha: se ao colá-la se partir em duas, a autorização não vai funcionar.

Passo 2 — Cria o utilizador que vai receber a cópia (no servidor remoto)

Não uses o root nem o teu utilizador pessoal. Um utilizador dedicado e sem palavra-passe de acesso:

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

Passo 3 — Autoriza a chave (no servidor remoto)

A app dá-te este mesmo comando já montado com a tua chave, pronto a copiar e colar numa sessão SSH do servidor remoto aberta com o utilizador que vai receber a cópia:

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

Se preferires fazê-lo 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
# cola aqui a linha completa da chave pública e carrega em Enter e depois em Ctrl+D
sudo chmod 600 /home/copias/.ssh/authorized_keys

As permissões não são um pormenor estético: se .ssh não for 700 ou authorized_keys não for 600, o OpenSSH ignora a chave sem explicar porquê e vais ver um «Permission denied (publickey)» desconcertante.

Recomendado — limita o que essa chave pode fazer, acrescentando opções no início da mesma linha, antes de ssh-ed25519:

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

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

Nível avançado, se o servidor remoto não for totalmente teu: o rrsync fecha a chave num único diretório e em modo só de escrita, de modo que nem sequer consegue ler o resto do disco. No Debian 12 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…

Tem em conta que com -wo (só escrita) a cópia entra mas não podes restaurar pela mesma via: o restauro faz-se a partir do servidor remoto ou retirando essa restrição temporariamente. É uma troca consciente, não um esquecimento.

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

A primeira ligação vai pedir-te que aceites a impressão digital do servidor. Aceitá-la às cegas é aceitar qualquer dispositivo que se meta no meio, por isso obtém a verdadeira executando no servidor remoto:

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

Compara essa cadeia SHA256:… com a que o NAS te mostrar ao testar o destino. Ou coincidem ou não a aceites.

Passo 5 — Testa a ligação e guarda

Usa o botão de testar do destino na app: verifica que o NAS entra, que a pasta existe e que consegue escrever nela. Se preferires vê-lo a partir da consola do NAS, fá-lo como root e apontando para a chave gerida, que é a que as cópias vão usar (o processo privilegiado é quem executa o rsync, não o utilizador 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 — Cria a tarefa de cópia

Nome, pastas de origem, esse destino remoto, horário e quanto se conserva. Se o dispositivo de destino não for teu, encripta lá o disco que recebe a cópia (LUKS): o painel ainda não encripta a cópia na origem, e di-lo. Primeira execução à mão: a cópia inicial envia tudo e pode demorar horas ou dias conforme a linha de upload. As seguintes são incrementais (o rsync só envia o que mudou) e duram minutos. Se a primeira cópia pela internet for inviável, fá-la em local: leva o NAS ou um disco USB ao local do servidor remoto, copia pela rede local e depois muda o destino para a ligação remota — o rsync vai ver que quase tudo já lá está e só vai enviar as diferenças.

5.3 Retenção: a cópia não é um espelho

Um pormenor que decide se sobrevives a um ransomware ou não. Se a cópia se limitar a refletir a origem, um ficheiro que é eliminado (ou encriptado) hoje no NAS é eliminado (ou encriptado) esta noite também na cópia.

Defesas, da mais fraca para a mais forte:

1. Versões conservadas na tarefa: cada execução deixa uma versão e só são eliminadas as mais antigas quando se ultrapassa o número que tiveres definido. Com 7 versões diárias tens uma semana para dares conta de que algo se estragou; com 1 versão, nenhuma. Conta com o espaço: N versões ocupam mais do que uma, embora as partes que não mudam sejam partilhadas entre elas. A retenção inteligente (a de fábrica) faz isto sem números: guarda todas as cópias das últimas 24 horas, uma por dia durante 7 dias, uma por semana durante 4 semanas e uma 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. Conta «os últimos N períodos com cópias», como o restic: se o NAS esteve meses desligado, o que é anterior ao buraco não se deita fora só por ser velho.
2. Snapshots no destino: se o servidor remoto for outro NAS com ZFS ou Btrfs, que faça os seus próprios snapshots do diretório de cópias. É a proteção mais barata e a mais eficaz.
3. Uma cópia desligada: o disco USB da gaveta. Nada que não esteja ligado pode ser encriptado.

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

Uma cópia não verificada não é uma cópia: é uma pasta grande em que confias por fé. Os três indicadores que não demonstram nada são a tarefa a verde, o tamanho do destino e «o rsync não deu erro».

O botão Verificar de cada tarefa faz metade do trabalho sem mexer num byte: lê a cópia inteira do destino e verifica que bate certo com o que foi registado ao copiá-la (em disco e por SSH, o número de ficheiros e o tamanho da versão; na nuvem, a comparação entre o que pesa o espelho e o que pesa a origem). O resultado fica no cartão e no histórico, e se não bater certo o NAS avisa como avisa de uma cópia falhada. Deteta a cópia que ficou a meio, o destino que perdeu ficheiros e o disco que está a morrer — o que não consegue demonstrar é que os bytes dentro de cada ficheiro continuam a ser os bons, por isso a verificação complementa o teste a sério, não o substitui.

O único teste válido é restaurar de verdade e abrir o ficheiro restaurado. Com o explorador custa menos do que nunca: entra numa versão, marca três ficheiros ao acaso e restaura-os para uma pasta temporária.

E se o disco de destino estiver encriptado (LUKS), o teste inclui abri-lo com a sua palavra-passe: um disco encriptado cuja chave ninguém se lembra é espaço ocupado, não uma cópia.

O exercício de restauro automático (o NAS fá-lo sozinho)

Tudo o que está acima está certo e quase ninguém o faz. Por isso é o NAS que o faz: uma vez por mês pega em alguns ficheiros ao acaso da última cópia de cada tarefa, restaura-os de verdade para uma pasta temporária e compara-os com o original. Depois elimina o que foi restaurado e conta-o no relatório semanal.

Não é a verificação do botão Verificar —essa olha para o tamanho e para o número de ficheiros—. O exercício restaura, com os mesmos programas e o mesmo caminho que usarias no dia mau, e compara byte a byte com o original: é a única coisa que descobre um destino que aceita escritas e devolve lixo, uma chave de encriptação perdida ou um disco que lê mal exatamente o setor onde estavam as fotos.

Como evita incomodar e como evita mentir:

• Vinte ficheiros, meio giga e um quarto de hora no máximo. Numa cópia de dois teras não se nota; e como é ao acaso, num ano já se testou meia cópia.
• Só escolhe ficheiros que já existiam quando a cópia foi feita. Se mexeste no original depois, a cópia tem de ser diferente e compará-los daria uma falha inventada. Com essa regra, «diferente» só pode significar «a cópia está mal».
• Não mexe em nada. Restaura para uma pasta temporária e elimina-a ao terminar.
• O que não se pôde comparar não se dá por bom. Conta-se à parte: o número que se mostra como verificado é o dos que foram realmente comparados.

Vê-se em Cópias de segurança → Trabalhos, por baixo da lista, com um botão Testar agora caso não queiras esperar pelo mês. E aparece no relatório semanal na sua própria secção; se alguma cópia não voltar, chega também um aviso e a nota do relatório desce muito: uma cópia que existe e não volta é pior do que não ter cópia, porque ninguém está à procura de outra.

Plano de testes

Restauro de teste (mensal)

A partir da app: escolhe a tarefa, a versão que queres recuperar e uma pasta de destino nova — nunca por cima do original, porque se algo correr mal vais querer poder comparar os dois. O restauro corre como tarefa, com o seu progresso, tal como a cópia.

Depois abre alguns ficheiros: uma foto que se vê, um PDF que abre, um vídeo que reproduz. Um ficheiro de 4 MB que existe mas não abre é um ficheiro perdido. E elimina depois a pasta de testes, que ocupa o mesmo que o que foi restaurado.

Restauro completo de uma pasta (trimestral)

Restaura a partir da app uma pasta inteira para /mnt/<pool>/prueba-restauracion e compara-a com o original. A partir da consola 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 o conteúdo, não datas nem tamanhos)
sudo rsync -avnc --delete /mnt/tanque/documentos/ /mnt/tanque/prueba-restauracion/

# 3. Eliminar a pasta de testes quando terminares
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 ficheiros, o conteúdo é idêntico bit a bit. Atenção ao espaço: o teste duplica temporariamente o que restaurares, por isso escolhe uma pasta que caiba.

Uma nuance importante se restaurares 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 usa a última versão, ou compara só ficheiros que saibas que não tocaste.

Regista o resultado

Duas linhas por teste, onde quiseres, mas regista-as:

2026-07-25 · Restaurados 4 ficheiros da cópia remota · abrem bem · 3 min
2026-07-25 · Restauro completo de «documentos» (38 GB) · diff sem diferenças · 41 min

O dado que quase ninguém mede é o tempo de restauro. Saber que recuperar 2 TB pela internet são quatro dias muda decisões: talvez queiras a cópia local além da remota, ou um disco que possas ir buscar de carro.

O que fazer se o teste falhar

Falha o teste, não o dia do desastre: é exatamente para isso que serve. Revê as origens da tarefa (faltava uma pasta?), as permissões do destino, o histórico para ver se estava há semanas a falhar em silêncio e, se o disco de destino estiver encriptado, se a palavra-passe é a que julgas. Corrige, volta a copiar e volta a testar.

7. O que esta cópia não cobre

Com honestidade, para não seres apanhado de surpresa:

• Um ficheiro corrompido que é copiado corrompido. O rsync copia o que há. Contra isto estão os checksums do ZFS/Btrfs e os scrubs agendados, que detetam a corrupção na origem antes de se propagar.
• O que não escolheste como origem. Uma pasta da casa nova não entra sozinha em nenhuma tarefa: quando criares uma, acrescenta-a à tarefa que lhe corresponde ou vai ficar fora da cópia sem que ninguém te 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. Dimensiona a primeira cópia com isso em mente.
• As palavras-passe e o 2FA. A cópia da configuração não leva a chave de assinatura de sessões (é regenerada) e os teus códigos TOTP estão no teu telemóvel, não no NAS. Guarda os códigos de recuperação noutro sítio.

8. A cópia para a nuvem falha

Primeiro: a mensagem de erro, na app Cópias de segurança, diz agora o que a nuvem respondeu (sem espaço, autorização expirada, endereço errado…). Esse texto é o diagnóstico; o que está abaixo é para os casos que se repetem.

Nextcloud e outros WebDAV: usa uma palavra-passe de aplicação, não a da tua conta (Definições → Segurança → Dispositivos e sessões). Se o servidor estiver atrás de um proxy com limite de tamanho de carregamento, esse limite manda sobre qualquer definição do NAS.

Ver também

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