Esta resposta é uma lista de verificação de alguns problemas que precisariam ser testados, não tendo sido mencionados em outro lugar. Agora posso descontar com prazer as menções de "backup" / etc, que também não detalham como restaurá-lo. Eu não testei para ver se esta lista de verificação está completa .
As etapas a seguir também ignoram os termos & outras mudanças que eu vejo no etckeeper durante atualizações de pacotes, como não especificamente mencionado na questão. Pelo menos existem provavelmente sistemas mais simples onde isso não é um problema, como roteadores rodando o OpenWrt.
- Suposição: esse backup inclui especificamente
/etc
.
- Suposição: você também sabe como vai lidar com qualquer referência a sistemas de arquivos, por exemplo que pode ter sido recriado com um UUID diferente, em
/etc/fstab
.
- Suposição: o sistema de destino não inclui nenhum usuário extra , quando comparado ao backup. Por exemplo. é uma nova instalação do sistema operacional, seu usuário inicial é criado com o mesmo nome (e UID) e nenhum serviço adicional foi adicionado ao SO durante uma atualização. Isto é provavelmente verdade dentro de uma versão estável do Debian, mas certamente não é confiável para uma distribuição de lançamento.
- Suposição: o processo de instalação é totalmente determinístico w.r.t. UIDs designados (ordem de instalação de pacotes), e isto não é afetado por nenhuma nova atualização nos repositórios. Eu acredito que os gerenciadores de pacotes usuais são deterministas. Novamente, o Debian estável é provavelmente confiável, um release não é, e entre eles existe uma área de incerteza. Você também pode organizar a mesma versão do instalador, sem acesso a repositórios de atualização (durante a restauração e quando você instalou o sistema original).
- Você já deve ter instalado a (s) ferramenta (s) de restauração para seu backup:).
- As etapas abaixo também assumem os arquivos de senhas shadow tradicionais do Linux. Os sistemas BSD usam nomes de arquivos diferentes. Alguns sistemas Linux de propósito especial introduziram um estilo significativamente diferente .
- Certifique-se de poder inicializar em algum "modo de recuperação", sem usar nenhuma senha definida em
/etc
, e você não precisa de nada mais complexo para acessar o backup. Estamos brincando com fogo aqui. Não sei como a criptografia de disco lidará com isso, embora o uso da mesma senha que o backup possa ajudar. Observe que as etapas abaixo não funcionarão se forem executadas a partir de um "sistema separado ".
-
mv /etc/ /etc.installer # can be removed later
-
mkdir /etc && chmod 755 /etc
-
ID_FILES=passwd group shadow
-
for i in $ID_FILES; do cp /etc.installer/${i} /etc; done
- Agora, para cada arquivo
i
in $ID_FILES
, você pode restaurar /etc/${i}
de seu backup para o sistema de destino.
- Agora você pode restaurar todos os arquivos, incluindo suas informações de propriedade.
- Agora você pode reaplicar os marcadores do SELinux ou equivalente, se necessário.
Se o backup for um repositório do etckeeper (e nenhum arquivo adicional), a etapa 12 é copiar / clonar para /etc
e, em seguida, executar etckeeper init
. Você provavelmente poderia pular etapas 10-12.
OpenWrt
Backup / restauração de configuração do sistema é suportado em roteadores OpenWrt, com um recurso específico na interface da Web.
No meu sistema OpenWrt 15.05.1, vejo que os únicos usuários que possuem arquivos em /etc
(ou em qualquer outro lugar) são root
e nobody
. Deve ser seguro assumir que uma nova instalação do OpenWrt já inclui esses usuários.
Não sei se as configurações do OpenWrt que adicionaram usuários extras seriam tratadas corretamente por essa ferramenta.