Recuperação de desastres

11 min · 9 seções

O que cada mecanismo cobre

RAID não é backup: protege contra falhas de disco, não contra exclusões, ransomware nem incêndios. O backup que sai do dispositivo é configurado e testado seguindo backups.md; este guia é o que se faz quando algo já aconteceu.

Antes que algo aconteça

Cinco minutos hoje, horas a menos de angústia no dia ruim:

1. Um backup externo configurado e testado restaurando (backups.md).
2. Um nas-config-*.tar.gz recente dentro desse backup externo (não só no NAS).
3. Alertas por e-mail ou webhook ativos (Painel de controle → Alertas): um disco que falha ou um backup que está falhando há um mês precisam avisar você.
4. Anotado em algum lugar fora do NAS: nomes dos pools, nome do servidor, domínio DDNS e os códigos de recuperação do 2FA.

Disco de dados com falha

1. Você receberá um alerta (Pool X en estado DEGRADED ou SMART crítico).
2. Identifique o disco em Armazenamento → Proteção → Saúde e criptografia (número de série e estado de cada disco).
3. Conecte o disco novo. Se o dispositivo aceitar troca a quente, você pode fazer isso sem desligar; se não, desligue (Painel de controle → Desligar e reiniciar), substitua e ligue.
4. Armazenamento → Proteção → Saúde e criptografia → Discos de cada volume → “Substituir” no disco com defeito, e escolha o reserva. A operação roda como tarefa em segundo plano: o resilver (ZFS) ou a cópia (Btrfs) pode levar horas, e o pool continua em uso enquanto isso.
5. Acompanhe o progresso em Armazenamento (linha “scan”) até o pool voltar a ficar saudável. Não retire outro disco durante o processo: é o momento de menor redundância.

Se você preferir o console, o equivalente é zpool replace <pool> <disco-viejo> /dev/sdX no ZFS e btrfs replace start <devid> /dev/sdX /mnt/<pool> no Btrfs.

Reinstalar o sistema mantendo os dados

Quando o disco do sistema morre, mas os discos de dados estão intactos. Os pools vivem nos discos de dados; o sistema é substituível:

1. Instale o LGM-OS em um disco de sistema novo (install.sh ou a ISO).
2. Restaure a configuração: Painel de controle → Backup da configuração → “Restaurar a partir de arquivo…” com seu último nas-config-*.tar.gz, e reinicie o serviço. Voltam os usuários, os grupos e as pastas da casa com suas permissões; a chave de assinatura das sessões é gerada de novo (todo mundo vai precisar entrar outra vez).
3. Importe os pools:
• ZFS: zpool import -f <pool> (ou zpool import para listá-los).
• Btrfs: as mount units restauradas montam por rótulo automaticamente; se não: mount /dev/disk/by-label/<pool> /mnt/<pool>.
4. Reaplique os serviços pela interface (SMB/NFS/WebDAV são reescritos ao salvar).

Começar do zero sem reinstalar

Quando o dispositivo está bem, mas você quer o painel como no primeiro dia — o NAS vai mudar de dono, ou você prefere refazer a configuração do zero —, não é preciso reinstalar: Painel de controle → Restaurar configurações de fábrica. As contas são excluídas, as pastas deixam de ser compartilhadas e os aplicativos e as configurações são removidos; os volumes, com todos os seus dados, e a rede ficam.

Pede sua senha, seu código de verificação em duas etapas e um código que só aparece na tela conectada ao NAS, então é preciso estar na frente dele. Antes de mexer em qualquer coisa, guarda as configurações anteriores em /var/nas/apartados. O Guia de administração explica tudo.

Se o NAS for embora da sua casa, isto não apaga seus dados: os volumes ficam com tudo dentro. Para apagá-los, exclua o pool em Armazenamento.

Desastre total do dispositivo

O NAS não existe mais: incêndio, inundação, roubo, uma sobretensão que levou placa e discos, ou um ransomware que criptografou tudo o que o NAS tinha montado. Os dados não estão no dispositivo, estão no seu backup externo, e o procedimento consiste em reconstruir o NAS em volta dele.

Requisito: um backup externo recente e testado. Se você nunca restaurou a partir dele, hoje vai descobrir se ele serve. É exatamente o cenário que backups.md tenta evitar.

Ordem de trabalho

1. Hardware. Não precisa ser idêntico ao anterior. Você precisa de discos de dados com pelo menos a capacidade do que vai restaurar e de um disco para o sistema.

2. Instale o LGM-OS. Inicie pela ISO e responda às quatro perguntas (nome do servidor, rede, usuário do console e disco do sistema). Ao terminar, acesse https://<ip>:5001 e crie o administrador no assistente de primeiro acesso.

3. Restaure a configuração. Recupere o nas-config-*.tar.gz do backup externo (ele está entre os arquivos copiados; se o backup for um disco USB, conecte-o e pegue de lá) e envie-o em Painel de controle → Backup da configuração → “Restaurar a partir de arquivo…”. Depois:

sudo systemctl restart nas-backend

Voltam usuários, grupos, pastas da casa com suas permissões, serviços, rede, tarefas agendadas e alertas. Ainda não há dados nem pools: isso é o próximo passo.

4. Crie os pools com os mesmos nomes. Armazenamento → “Criar volume”. É importante que o nome coincida com o de antes: as pastas da casa, as exportações e os aplicativos fazem referência a caminhos /mnt/<pool>/…, e com outro nome seria preciso refazê-los um por um.

5. Recrie as pastas da casa pelo Painel de controle (continuam definidas depois do passo 3: basta salvá-las para que sejam criadas no volume novo com suas permissões).

6. Restaure os dados com o app Backups. Os destinos e as tarefas voltaram com a configuração do passo 3, então o app já sabe onde está seu backup. Dois avisos antes de começar:

• Se o destino for remoto, o NAS novo tem uma chave SSH nova: autorize-a no servidor remoto igual à primeira vez (passo 3 de backups.md), ou ele não vai conseguir nem ler o backup.
• Se o destino for um disco USB, conecte-o e verifique se o destino aparece como disponível.

Depois, para cada tarefa: escolha a versão que quiser (normalmente a última boa) e a pasta de destino. Comece pelo que é insubstituível — documentos e fotos — e deixe a coleção de mídia para o final: assim você tem o importante disponível em horas, mesmo que o resto leve dias. Se a tarefa era criptografada, você precisa da senha de criptografia; sem ela não há restauração possível.

Se você preferir (ou precisar) fazer à mão pelo console, por exemplo com um disco USB montado em /mnt/usb-copia:

sudo rsync -aHAX --numeric-ids --info=progress2 \
     /mnt/usb-copia/<ruta-de-la-versión>/documentos/ /mnt/tanque/documentos/

Cuidado com as barras finais: origen/ copia o conteúdo dessa pasta para dentro do destino; sem a barra, copiaria a pasta inteira para dentro.

Se o destino remoto foi autorizado com rrsync -wo (somente escrita), essa chave não pode ler: restaure a partir do próprio servidor remoto ou retire temporariamente essa restrição do authorized_keys dele.

7. Reaplique os serviços (SMB/NFS/WebDAV) salvando-os pela interface e verifique em um PC se os compartilhamentos aparecem e se dá para gravar neles.

8. Apps Docker. Reinstale-os pela Central de pacotes e, antes de iniciá-los, restaure os dados deles em /var/nas/apps/<app>/. Iniciar um app com o banco de dados vazio e restaurá-lo depois costuma acabar mal.

9. Acesso externo. O certificado do Let’s Encrypt não é restaurado: ele é emitido de novo sozinho em Painel de controle → Acesso externo assim que o domínio apontar para o novo IP (revise o DDNS e o redirecionamento de portas do roteador novo).

10. Deixe os backups rodando de novo. Verifique se os destinos estão disponíveis e se as tarefas ficam ativas e com horário. Um NAS restaurado sem backup externo é um desastre recuperado pela metade: o próximo pega você do mesmo jeito que este.

11. Teste o backup. Execute uma tarefa manualmente e restaure alguns arquivos da versão que ela acabou de criar. Feche o ciclo no mesmo dia, não “quando tiver um tempinho”.

Quanto tempo leva

Valores aproximados, para você ajustar as expectativas e decidir por onde começar:

A restauração pela rede ser tão lenta é o motivo de ter também um backup local (ou um que você possa ir buscar de carro): o backup remoto é seu seguro contra o incêndio, o local é o que faz você voltar ao trabalho no mesmo dia.

Restaurar arquivos de um snapshot

• ZFS: os snapshots ficam visíveis em /mnt/<pool>/<dataset>/.zfs/snapshot/<nome>/ — copie o que precisar sem mexer em mais nada. O rollback pela interface reverte o dataset inteiro (destrói os snapshots posteriores).
• Btrfs: “Restaurar” cria /mnt/<pool>/restaurado-<data> com o conteúdo do snapshot; copie o que precisar e exclua essa pasta (é um subvolume: btrfs subvolume delete).

Backup da configuração

Baixe-o manualmente em Painel de controle → Backup da configuração, ou automatize: Painel de controle → Tarefas agendadas → tipo “backup” para /mnt/<pool>/backups (por exemplo, semanal). Guarde essa pasta dentro do backup externo: é a primeira coisa de que você vai precisar no cenário anterior.

O que vai no nas-config-*.tar.gz

• state/ — todo o estado de /var/nas/state: usuários e grupos, pastas da casa com suas permissões por usuário e grupo, SMB, NFS, WebDAV, SSH, firewall, rede, pools registrados, tarefas agendadas, alertas, notificações, App Store, SNMP, portal de acesso, nobreak e bloqueio automático de IPs. É isso que é restaurado.
• etc/ — cópia dos arquivos gerados (smb.conf, exports, nftables, sshd, htpasswd) **só como referência**: a restauração não os sobrescreve, eles são reescritos sozinhos ao reaplicar os serviços pela interface.

O que NÃO vai, de propósito

Só segredos do dispositivo e estado descartável; nunca configuração:

Qualquer outra chave de estado entra no backup por padrão, inclusive as de funções futuras: a tabela é a única exceção e backend/tests/test_backup_state.py falha se alguém adicionar um estado novo sem decidir de que lado ele fica. Antes era o contrário — uma lista de doze arquivos a incluir — e as pastas da casa se perdiam silenciosamente a cada restauração.

Restaurar

Painel de controle → Backup da configuração → “Restaurar a partir de arquivo…”. Só são aceitas entradas state/<chave>.json do próprio formato (qualquer caminho que saia do diretório de estado é recusado) e as chaves protegidas da tabela são ignoradas mesmo que venham dentro do arquivo. Depois: systemctl restart nas-backend e reaplique os serviços pela interface.

⚠️ Este backup não inclui seus dados: para isso existem os snapshots (dentro do dispositivo) e o backup externo (fora dele).

O que continua sem cobertura

Com o backup externo configurado, o desastre total deixa de ser um beco sem saída. Mesmo assim, convém saber onde estão os limites:

• O que aconteceu desde o último backup se perde. Se você faz backup de madrugada e o dispositivo pega fogo às 20:00, o trabalho do dia se vai. Aumente a frequência do que você não puder repetir.
• O que não estava em nenhuma tarefa não está lá. Uma pasta da casa criada depois de configurar os backups não entra sozinha: revise as origens das suas tarefas de vez em quando.
• Não há imagem do disco do sistema (bare metal): o LGM-OS é reinstalado pela ISO e a configuração é restaurada. É rápido, mas não é um “clonar e ligar”.
• Se o backup estava junto do NAS, o desastre o levou também. Um backup num USB conectado permanentemente ao dispositivo não sobrevive a um incêndio, a um roubo nem a um ransomware. Por isso um dos backups tem que ficar fora.
• Sessões e 2FA: a chave de assinatura é gerada de novo e todo mundo entra outra vez; os códigos TOTP estão no celular de cada usuário. Guarde os de recuperação à parte.
• As chaves e os certificados do dispositivo são novos: é preciso autorizar de novo a chave SSH do NAS no destino do backup e emitir de novo o certificado do Let’s Encrypt.