Bom dia a todos, estou tentando criar um arquivo tar para um backup completo do /, no entanto alguns arquivos são pulados por causa do erro “permission denied”
Como eu posso fazer para incluir esses arquivos no tar, mesmo com a permissão negada e mantendo as permissões atuais?
Esse é o comando que eu usei:
root@lucas-Inspiron-5447:/mnt/lfs-backup# tar -cf OOSbackup-12-01-2020-11-00.tar.xz /mnt/lfs -v
Esse é um dos arquivos que deu erro:
tar: /mnt/lfs/proc/sys/net/ipv6/route/flush: Função open falhou: Permissão negada
Se quiser o output completo até o momento que eu cancelei o comando com ^C devido aos erros de permissão, me fala que eu mando
Estou fazendo esse backup para eu poder fazer testes sem preocupações, já que eu já tive que reiniciar do zero 3 vezes depois que tudo já estava pronto (digamos que não é uma boa ideia sair mechendo com as libraries)
O objetivo é poder restaurar tudo para um momento funcional com um simples tar -xf
Estou rodando o comando pelo Linux Mint para fazer a cópia da partição em que o sistema Linux From Scratch 9.0-systemd está armazenado
Também aceito sugestões de outros métodos para fazer um backup completo dessa partição
Se esses arquivos pulados forem das pastas /proc, /sys, /dev ou um swapfile (se o tiver criado), não há com que se preocupar. Os conteúdos dessas pastas são gerados novamente a cada boot e apenas refletem o hardware do PC e os programa que estão rodando por cima dele.
1 curtida
Então quando eu restaurar o backup com tar -xf o sistema irá gerar as files que faltam?
Vou tentar gerar o tar então, se ele pular arquivos fora dessas pastas eu aviso.
Obrigado!
Estranho só que tanto o /proc quanto o /sys deveriam estar vazios, pois os arquivos são criados apenas na memória no momento em que são montados…
Ah, como dica, o xz é muito demorado para comprimir, eu sempre faço os backups do meu disco sem compressão, ou se necessário usa compressao lzo que é comprime relaativamente bem com extrema velocidade.
Olha minha “cola” para criar e recuperar backups de partição:
--- Fazer backup
mount /dev/sda1 sdaa1
tar cpf "/media/rod/3xpansion/20180521_rootdir.tar" sdaa1/
tar tvf "/media/rod/3xpansion/20180521_rootdir.tar"
----recuperar
mount /dev/sda1 sdaa1
cd sdaa1
rm -Rf *
cd -
tar xpf "/media/rod/3xpansion/rootdir_2018.02.24.tar" -C sdaa1/ --numeric-owner --strip 1
Como você está montando em /mnt/lfs, talvez seja necessário usar a opção --strip 2 na recuperação do backup.
Ah sim, sempre que eu faço, alguns arquivos realmente não são adicionados ao backup devido a permissões, e realmente não tem problema.
1 curtida
Eu fui fazer o backup como já estava fazendo para desta vez ignorar os erros, mas na hora do kcore (o arquivo de mais de 100 TB que na verdade não existe) o tar fechou dizendo que não havia mais armazenamento. Por algum motivo, a minha partição do mint(sda2) lotou em vez de lotar a sda6. Então eu deletei o arquivo que ficou pela metade, entrei no chroot, montei a sda6 e rodei “(lfs chroot) root:/mnt/backup# tar --exclude=‘/proc’ --exclude=‘/sys’ --exclude=‘/dev’ -cf Backup-12-01-2020-16-22.tar.xz / -v --xz”, já que
No final, o backup deu certo!
⠀
A todos, muito obrigado pela ajuda!
⠀
⠀
PS: Só deu um probleminha com o Mint, que depois do reboot o cinnamon não abre mais. Desinstalei pelo tty1, mas não da para reinstalar (o louco do sistema inventou alguma coisa para encher a partição). Mas isso eu resolvo com um live usb depois.
1 curtida
Muito obrigado pela ajuda, vou tentar isso no próximo backup e para restaurar o que eu fiz antes de sua resposta (vide o comentário marcado como solução)
Mas por que só “rm -rf /mnt/lfs/*” seguido de cd e “tar -xf arquivo” não é suficiente para restaurar?
Se o caminho do arquivo foi salvo no no backup, vc precisa removê-lo. Senão quando entrar no raiz, terá apenas uam pasta /mnt/lfs e dentro dela todos os arquivos do sistema raiz. Se você extrair o backup com --strip 2, ele já cria os arquivos no lugar certo. No meu exemplo eu usei strip 1 pois mandei criar o backup de uma pasta.
O --numeric-owner é para informar na extração para usar essa informação, em vez de tentar achar o usuário e converter o nome do usuário para o número do usuário durante o processo. Isso garante que as permissões de arquivos continuem as mesmas, mesmo que você use outras distribuições live. Exemplo, o usuário “rod” pode ser id 1000 em uma instalação, mas na outra (que eu estiver extraindo) pode ser 1001. Daí vai melecar todo o processo.
Não entendi o “chroot”. No processo de backup e restauração você não precisa montar com chroot, senão vai ter problemas mesmo com o /proc e /sys e outros sistemas de arquivos que por ventura tenham sido montados durante o processo… É bem simples: inicia o live, monta a partição de destino do backup, monta a partição do sistema de arquivos, usa os comandos, fechou!
Recuperação: inicia o live, monta a partição que tem os arquivos de backup, monta a partição de destino, extrai tudo no destino. Reinicia e bola pra frente! (considerando que está apenas instalando em cima de uma instalação que já tinha bootloader instalado certinho)
Será que o problema foi o chroot então? Na primeira tentativa eu não usei o chroot, mas ele já estava aberto em outra janela do terminal. Depois de a minha partição do mint encher com não sei o que (o arquivo tar foi criado no lugar certo. Talvez algum arquivo temporário?) e o tar interromper por causa disso, eu refiz o processo dentro do chroot, mas com --exclude dessa vez.
Como o backup final foi feito no chroot, acho que não terá problema só extrair sem o --strip né?
Quando você monta o chroot, é equivalente a você iniciar o computador naquela partição. Vai ter arquivos abertos, precisa montar o /proc /sys /run, etc… Enfim, vai dar praticamente a mesma complicação de você fazer backup do sistema de dentro do próprio sistema! Pode inclusive entrar em loop com o arquivo de backup tentando adicionar o próprio arquivo de backup e acontecer de criar um arquivo até o limite do espaço em disco (que é o que eu acredito que aconteceu aí).
Se você inicia por outro sistema operacional, assim que você monta a partição raiz do outro sistema, todos os arquivos estão fechados e o /proc, /sys /run e /tmp estarão provavelmente vazios já! Então não precisa dar exclude.
Descobri o que aconteceu lá: o tar foi criado no /root (eu devo ter esquecido de dar cd) e tentou copiar o /proc/kcore, que tem 100TB. Aí encheu o hd mesmo. Já deletei o arquivo errado e vou refazer o backup sem o chroot então
Estranhamente, o disco ainda reporta que está sem espaço. Mesmo eu já tendo deletado esse arquivo de 200GB.
O arquivo foi parar em um diretório escondido em /.Trash-0/files.
Rodando rm -rf /.Trash-0 corrigiu o problema do disco cheio
