A página 2 deste tutorial da comunidade muda a questão de «como executo dd?» para «o que vale realmente a pena proteger?». O utilizador já tinha um NVMe grande em funcionamento e preocupava-se muito mais com a perda de DADOS do que com a perda do SO arrancável. O conselho de gelbuilding foi evitar reparticionar o NVMe de arranque em funcionamento, proteger primeiro os DADOS/AppData e só manter um clone bruto do sistema se o benefício em termos de tempo de recuperação justificar o espaço adicional necessário para a cópia de segurança.
Essa prioridade está de acordo com a arquitetura atual do ZimaOS. O SO dispõe de ranhuras de sistema A/B para uma recuperação rápida, enquanto os dados de utilizador insubstituíveis, o AppData e os metadados de armazenamento ficam fora dessas imagens de sistema imutáveis. Um clone de todo o disco pode devolver a máquina rapidamente a um ponto exato, mas não substitui cópias de segurança independentes e versionadas dos DADOS.
O dd clona todo o dispositivo, não apenas as pequenas ranhuras do SO
O tutorial original utiliza um comando conceptualmente semelhante a:
dd if=/dev/NVME_DEVICE | gzip > USB_BACKUP.img.gzSe o sistema estiver num NVMe de 1 TB, o processo de criação da imagem bruta continua a ler todo o dispositivo de blocos. A compressão pode reduzir o tamanho do ficheiro, mas o destino e o processo de cópia de segurança ficam dependentes da disposição física do disco, em vez de apenas dos poucos gigabytes utilizados pelas partições de sistema do ZimaOS.
Não reparticione um sistema ativo e saudável apenas para tornar o dd mais pequeno
gelbuilding considerou o reparticionamento do NVMe de arranque em funcionamento uma operação de alto risco, pois um erro pode causar indisponibilidade ou perda de dados. Se a disposição atual funcionar, faça cópias de segurança verificadas dos dados antes de alterar os limites das partições.
Proteja os DADOS e o AppData antes do clone do SO
Se a sua prioridade for a capacidade de recuperação, faça cópias de segurança de:
- ficheiros de utilizador e conjuntos de armazenamento;
- AppData, bases de dados e configurações que não possam ser recriados facilmente;
- exportações importantes específicas de cada aplicação;
- metadados de armazenamento do ZimaOS, como
local-storage.db, quando relevante; - e, depois, opcionalmente, de todo o disco do sistema.
As orientações atuais do ZimaOS para a regra 3-2-1 suportam cópias de segurança agendadas para destinos independentes e pontos de restauro versionados.
Utilize o modelo atual de cópia de segurança 3-2-1 do ZimaOS.
O ZimaOS atual já dispõe de recuperação de sistema A/B
O ZimaOS utiliza duas ranhuras de sistema com aproximadamente 6 GB cada. Se uma das ranhuras falhar, o guia de recuperação atual permite ao utilizador arrancar a partir da ranhura alternativa através do GRUB.
Utilize o procedimento atual de recuperação de sistema A/B.
Uma reinstalação limpa pode recriar o SO, mas não reproduz automaticamente a sua configuração exata
Como observou constgen, um SO imutável pode muitas vezes ser simplesmente reinstalado. O contraponto de gelbuilding foi o tempo de recuperação: um clone do disco pode restaurar exatamente as aplicações, a configuração e o estado do sistema tal como foram capturados, enquanto uma reinstalação pode exigir o remapeamento do AppData, a reinstalação das aplicações e a religação dos metadados de armazenamento.
Ambas são estratégias de recuperação válidas; cada uma otimiza aspetos diferentes.
Um disco de arranque dedicado e pequeno simplifica a clonagem de todo o disco
gelbuilding recomendou, eventualmente, mover o ZimaOS para um dispositivo dedicado pequeno, de 32–64 GB, mantendo o armazenamento NVMe/RAID de grande capacidade para DADOS/AppData. O mínimo exato para a instalação atual do ZimaOS é de pelo menos 25 GB.
Isto separa o SO descartável do armazenamento de dados de grande capacidade e torna a imagem completa do sistema muito mais pequena.
Os comandos de restauro bruto são destrutivos
Restaurar uma imagem dd escreve diretamente sobre o disco de destino. Selecionar o destino /dev/... errado pode destruir outra unidade. O tutorial original foi partilhado explicitamente para fins de teste, e estes comandos só devem ser utilizados depois de identificar os discos pelo modelo e número de série, mantendo os DADOS preservados noutro local.
Teste o procedimento de recuperação, não apenas a criação da cópia de segurança
Uma cópia de segurança só é útil se souber como restaurá-la. Para os DADOS, restaure ficheiros representativos. Para uma imagem bruta do sistema, teste o procedimento em suportes sobresselentes, se possível, em vez de descobrir pressupostos relativos ao dispositivo ou ao caminho durante uma falha real.
Perguntas frequentes sobre clones e cópias de segurança do ZimaOS
É necessário um clone completo do disco do sistema para proteger os dados do ZimaOS?
Não. As cópias de segurança de DADOS/AppData e dos metadados de armazenamento são independentes das partições de sistema A/B e têm maior prioridade para as informações insubstituíveis.
Porque haveria eu de manter um clone bruto do SO?
Pode reduzir o tempo de recuperação ao restaurar exatamente a configuração do sistema e das aplicações capturada, em vez de a reconstruir manualmente.
Devo reparticionar um NVMe em funcionamento apenas para tornar o clone mais pequeno?
A recomendação original foi não o fazer; faça primeiro uma cópia de segurança dos DADOS e evite alterações desnecessárias às partições em funcionamento.
