Saltar para o conteúdo
LGM-OS Enterprise
Casa Empresa
documentação

Quando já aconteceu alguma coisa.

Recuperação de desastres

11 min · 9 secções

O que cobre cada mecanismo

RiscoProteção
Eliminação acidental de ficheirosSnapshots + reciclagem de rede SMB
Falha de 1–2 discosRAID (mirror/RAID1/10, RAID-Z1/Z2) + alertas SMART
Corrupção silenciosaScrubs programados (checksums ZFS/Btrfs)
Perda do disco do sistemaCópia da configuração + reinstalação
Desastre total do dispositivoCópia externa dos dados (app Cópias de segurança) + reinstalação → procedimento

RAID não é backup: protege de falhas de disco, não de eliminações, ransomware nem incêndios. A cópia que sai do dispositivo configura-se e testa-se como explica backups.md; este guia é o que se faz quando já aconteceu alguma coisa.

Antes de acontecer alguma coisa

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

  1. Uma cópia externa configurada e testada com um restauro (backups.md).
  2. Um nas-config-*.tar.gz recente dentro dessa cópia externa (não só no NAS).
  3. Alertas por e-mail ou webhook ativos (Painel de controlo → Alertas): um disco que falha ou uma cópia que falha há um mês têm de te avisar.
  4. Apontado em algum sítio fora do NAS: nomes dos pools, nome do servidor, domínio DDNS e os códigos de recuperação do 2FA.

Disco de dados avariado

  1. Vais receber um alerta (Pool X en estado DEGRADED ou SMART crítico).
  2. Identifica o disco em Armazenamento → Proteção → Saúde e encriptação (número de série e estado de cada disco).
  3. Liga o disco novo. Se o dispositivo admitir troca a quente podes fazê-lo sem desligar; se não, desliga (Painel de controlo → Desligar e reiniciar), substitui e arranca.
  4. Armazenamento → Proteção → Saúde e encriptação → Discos de cada volume → «Substituir» no disco avariado, e escolhe o de reserva. A operação corre como tarefa em segundo plano: o resilver (ZFS) ou a cópia (Btrfs) pode demorar horas, e o pool continua em uso entretanto.
  5. Acompanha o progresso em Armazenamento (linha «scan») até o pool voltar a estar saudável. Não retires outro disco durante o processo: é o momento de menor redundância.

Se preferires a consola, o equivalente é zpool replace <pool> <disco-antigo> /dev/sdX em ZFS e btrfs replace start <devid> /dev/sdX /mnt/<pool> em Btrfs.

Reinstalar o sistema sem perder 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. Instala o LGM-OS num disco de sistema novo (install.sh ou a ISO).
  2. Restaura a configuração: Painel de controlo → Cópia da configuração → «Restaurar a partir de ficheiro…» com o teu último nas-config-*.tar.gz, e reinicia o serviço. Voltam os utilizadores, os grupos e as pastas da casa com as suas permissões; a chave de assinatura das sessões é gerada de novo (toda a gente terá de voltar a entrar).
  3. Importa os pools:
    • ZFS: zpool import -f <pool> (ou zpool import para os listar).
    • Btrfs: as mount units restauradas montam por etiqueta automaticamente; se não: mount /dev/disk/by-label/<pool> /mnt/<pool>.
  4. Volta a aplicar os serviços a partir da interface (SMB/NFS/WebDAV são reescritos ao guardar).

Começar do zero sem reinstalar

Quando o dispositivo está bem mas queres o painel como no primeiro dia —o NAS muda de dono, ou preferes refazer a configuração do zero—, não é preciso reinstalar: Painel de controlo → Repor as definições de fábrica. As contas são eliminadas, as pastas deixam de ser partilhadas e saem as aplicações e as definições; os volumes, com todos os teus dados, e a rede ficam.

Pede a tua palavra-passe, o teu código de dois passos e um código que só aparece no ecrã ligado ao NAS, por isso tens de estar à frente dele. Antes de mexer em alguma coisa, guarda as definições anteriores em /var/nas/apartados. Está tudo explicado no Guia de administração.

Se o NAS sair de casa, isto não elimina os teus dados: os volumes ficam com tudo lá dentro. Para os eliminar, elimina o pool em Armazenamento.

Desastre total do dispositivo

O NAS já não existe: incêndio, inundação, roubo, uma sobretensão que levou a placa e os discos, ou um ransomware que cifrou tudo o que o NAS tinha montado. Os dados não estão no dispositivo, estão na tua cópia externa, e o procedimento consiste em reconstruir o NAS à volta dela.

Requisito: uma cópia externa recente e testada. Se nunca restauraste a partir dela, hoje vais saber se serve. É exatamente o cenário que backups.md tenta evitar.

Ordem de trabalho

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

2. Instala o LGM-OS. Arranca a ISO e responde às quatro perguntas (nome do servidor, rede, utilizador de consola e disco do sistema). No fim, entra em https://<ip>:5001 e cria o administrador no assistente do primeiro acesso.

3. Restaura a configuração. Recupera o nas-config-*.tar.gz da cópia externa (está entre os ficheiros copiados; se a cópia for um disco USB, liga-o e tira-o de lá) e carrega-o em Painel de controlo → Cópia da configuração → «Restaurar a partir de ficheiro…». Depois:

sudo systemctl restart nas-backend

Voltam utilizadores, grupos, pastas da casa com as suas permissões, serviços, rede, tarefas programadas e alertas. Ainda não há dados nem pools: isso é o passo seguinte.

4. Cria 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 as apps fazem referência a caminhos /mnt/<pool>/…, e com outro nome seria preciso refazê-las uma a uma.

5. Volta a criar as pastas da casa a partir do Painel de controlo (continuam definidas depois do passo 3: basta guardá-las para serem criadas no volume novo com as suas permissões).

6. Restaura os dados com a app Cópias de segurança. Os destinos e as tarefas voltaram com a configuração do passo 3, por isso a app já sabe onde está a tua cópia. Dois avisos antes de começar:

  • Se o destino for remoto, o NAS novo tem uma chave SSH nova: autoriza-a no servidor remoto tal como da primeira vez (passo 3 de backups.md) ou nem sequer vai conseguir ler a cópia.
  • Se o destino for um disco USB, liga-o e confirma que o destino aparece como disponível.

Depois, para cada tarefa: escolhe a versão que quiseres (normalmente a última boa) e a pasta de destino. Começa pelo que é insubstituível — documentos e fotos — e deixa a coleção multimédia para o fim: assim tens o importante disponível em horas, mesmo que o resto demore dias. Se a tarefa estava cifrada, precisas da palavra-passe de cifragem; sem ela não há restauro possível.

Se preferires (ou precisares de) fazê-lo à mão a partir da consola, por exemplo com um disco USB montado em /mnt/usb-copia:

sudo rsync -aHAX --numeric-ids --info=progress2 \
     /mnt/usb-copia/<caminho-da-versão>/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 lá para dentro.

Se o destino remoto foi autorizado com rrsync -wo (só escrita), essa chave não consegue ler: restaura a partir do próprio servidor remoto ou retira temporariamente essa restrição do seu authorized_keys.

7. Volta a aplicar os serviços (SMB/NFS/WebDAV): guarda-os a partir da interface e confirma a partir de um PC que as partilhas se veem e que se consegue escrever nelas.

8. Apps Docker. Reinstala-as a partir do Centro de pacotes e, antes de as arrancares, restaura os seus dados sobre /var/nas/apps/<app>/. Arrancar uma app com a base de dados vazia e restaurá-la depois costuma acabar mal.

9. Acesso externo. O certificado do Let's Encrypt não é restaurado: volta a ser emitido sozinho a partir de Painel de controlo → Acesso externo assim que o domínio apontar para o novo IP (revê o DDNS e o reencaminhamento de portas do router novo).

10. Volta a pôr as cópias a funcionar. Confirma que os destinos estão disponíveis e que as tarefas ficam ativas e com horário. Um NAS restaurado sem cópia externa é um desastre meio recuperado: o próximo apanha-te tal como este.

11. Testa a cópia. Executa uma tarefa à mão e restaura um par de ficheiros da versão que acabou de criar. Fecha o círculo no mesmo dia, não «quando tiver um bocado».

Quanto demora

Valores indicativos, para ajustares as expectativas e decidires por onde começar:

FaseTempo típico
Instalar o LGM-OS a partir da ISO20–40 min
Restaurar a configuração e criar os pools15 min
Restaurar dados a partir de disco USB (USB 3, 2 TB)4–8 h
Restaurar dados pela internet (2 TB, linha de 30 Mbps de upload no outro extremo)3–5 dias

O restauro pela rede ser tão lento é a razão para teres também uma cópia local (ou uma que possas ir buscar de carro): a cópia remota é o teu seguro contra o incêndio, a local é a que te devolve ao trabalho no mesmo dia.

Restaurar ficheiros a partir de um snapshot

  • ZFS: os snapshots são visíveis em /mnt/<pool>/<dataset>/.zfs/snapshot/<nome>/ — copia o que precisares sem mexer em mais nada. rollback a partir da interface reverte o dataset inteiro (destrói os snapshots posteriores).
  • Btrfs: «Restaurar» cria /mnt/<pool>/restaurado-<data> com o conteúdo do snapshot; copia o que precisares e elimina essa pasta (é um subvolume: btrfs subvolume delete).

Cópia da configuração

Transfere-a à mão a partir de Painel de controlo → Cópia da configuração, ou automatiza-a: Painel de controlo → Tarefas programadas → tipo «backup» para /mnt/<pool>/backups (p. ex. semanal). Guarda essa pasta dentro da cópia externa: é a primeira coisa de que vais precisar no cenário anterior.

O que leva o nas-config-*.tar.gz

  • state/ — todo o estado de /var/nas/state: utilizadores e grupos, pastas da casa com as suas permissões por utilizador e grupo, SMB, NFS, WebDAV, SSH, firewall, rede, pools registados, tarefas programadas, alertas, notificações, App Store, SNMP, portal de acesso, UPS e bloqueio automático de IPs. É isto que se restaura.
  • etc/ — cópia dos ficheiros gerados (smb.conf, exports, nftables, sshd, htpasswd) **só como referência**: o restauro não os substitui, são reescritos sozinhos ao voltar a aplicar os serviços a partir da interface.

O que NÃO leva, de propósito

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

ChavePorque fica de fora
secretChave de assinatura dos JWT: quem a tiver pode falsificar sessões de administrador. É gerada uma nova ao arrancar.
revoked_tokensExpira com os próprios tokens e deixa de fazer sentido assim que a chave de assinatura muda.
lgm_updateGuarda o token de acesso ao git da atualização automática.
ups_secretPalavra-passe partilhada com o NUT; é gerada de novo ao voltar a aplicar a UPS.
job_slotsMarcas internas do planeador; refazem-se sozinhas.

Qualquer outra chave de estado entra na cópia por omissão, também as de funções futuras: a tabela é a única exceção e backend/tests/test_backup_state.py falha se alguém acrescentar estado novo sem decidir de que lado fica. Antes era ao contrário — uma lista de doze ficheiros a incluir — e as pastas da casa perdiam-se em silêncio em cada restauro.

Restaurar

Painel de controlo → Cópia da configuração → «Restaurar a partir de ficheiro…». Só se aceitam entradas state/<chave>.json do próprio formato (é recusado qualquer caminho que saia do diretório de estado) e as chaves protegidas da tabela são ignoradas mesmo que venham dentro do ficheiro. Depois: systemctl restart nas-backend e volta a aplicar os serviços a partir da interface.

⚠️ Esta cópia não inclui os teus dados: para isso existem os snapshots (dentro do dispositivo) e a cópia externa (fora dele).

O que continua sem cobertura

Com a cópia externa configurada, 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 a última cópia perde-se. Se copias de madrugada e o dispositivo arde às 20:00, vai-se o trabalho do dia. Aumenta a frequência do que não possas repetir.
  • O que não estava em nenhuma tarefa não está. Uma pasta da casa criada depois de configurar as cópias não entra sozinha: revê de vez em quando as origens das tuas tarefas.
  • Não há imagem do disco de sistema (bare metal): o LGM-OS é reinstalado a partir da ISO e a configuração é restaurada. É rápido, mas não é um «clonar e arrancar».
  • Se a cópia estava ao lado do NAS, o desastre também a levou. Uma cópia num USB sempre ligado ao dispositivo não sobrevive a um incêndio, a um roubo nem a um ransomware. Por isso, uma das cópias tem de estar fora.
  • Sessões e 2FA: a chave de assinatura é gerada de novo e toda a gente volta a entrar; os códigos TOTP estão no telemóvel de cada utilizador. Guarda os de recuperação à parte.
  • As chaves e os certificados do dispositivo são novos: é preciso voltar a autorizar a chave SSH do NAS no destino da cópia e voltar a emitir o certificado do Let's Encrypt.