Caixa Seca

Fiz algumas melhorias no suporte aos sistemas de arquivos EXT nesta versão. - UUID é definido pelo mke2fs no momento da formatação se o programa não for pré-histórico (1.41.4+). - Quando uma imagem contendo outro sistema de arquivos é convertida para EXT2/3/4, ext_attr é habilitado e inodes de 256 bytes são usados [1] e, para EXT4, além de extent , que é mandatório, huge_file , flex_bg , uninit_bg , dir_nlink e extra_isize são habilitados. É o conjunto de recursos base da suíte e2fsprogs 1.41, que manteve-se na série 1.42 em dispositivos menores que 16 TiB. 64bit não é habilitado incondicionalmente [2] como na versão 1.43, nem metadata_csum como na 1.44. - No upgrade de EXT2 para EXT3, tamanho original do inode é mantido. Assim, imagens de distribuições muito velhas, que usem EXT2 com inodes de 128 bytes, têm mais chance de serem transplantadas com sucesso para EXT3. - Upgrade de EXT2 revisão 0 para EXT3/4 funciona. Apenas para exatidão do código mesmo, pois tais siste...

Mais recursos são preservados: 64bit , inline_data , metadata_csum , project , sparse_super2 . Ao restaurar imagens de sistemas de arquivos EXT num dispositivo igual ou maior do que 16 TiB (considerando blocos de 4 KiB), o programa comporta-se da seguinte forma. Sistema de origem EXT2 ou EXT3: - O programa abortará. EXT2 e EXT3 não suportam volumes dessa capacidade. A mensagem de erro recomendará adicionar mkfs=ext4 (exemplo: fsarchiver restfs imagem.fsa id=0,dest=/dev/sdxy,mkfs=ext4 ). É uma possível saída a partir do FSArchiver 0.8.5 . Sistema de origem EXT4: - Se e2fsprogs < 1.42, o programa abortará. É versão mínima que suporta 64bit . - Se e2fsprogs ≥ 1.42, os recursos 64bit e uninit_bg serão automaticamente habilitados, mesmo que não estejam presentes na imagem. O segundo é opcional, porém sem ele a formatação de dispositivos grandes demora uma eternidade (dependendo da velocidade, vários minutos!). Como trata-se de recurso antigo, presente desde o tempo em que ...

- Suporta FAT16/32. Adicionado levando em conta seu uso em sistemas UEFI , para o volume da partição ESP (EFI System Partition). - XFS V5 é restaurado mantendo a configuração -i sparse de acordo com o sistema original (desde a versão 0.6.24). - É possível especificar na linha de comando, na ação restfs , uuid= e label= , que permitem substituir os valores armazenados na imagem. Muito útil para XFS V5, pois possibilita restaurar o sistema de arquivos com um UUID aleatório sem precisar aumentar o kernel mínimo requerido rodando xfs_admin depois, pois o UUID será passado diretamente ao mkfs.xfs (≥ 4.3.0) na hora de criá-lo. Isso também evita incompatibilidade com o GRUB, que até recentemente não suportava meta_uuid. - Btrfs é restaurado preservando o UUID da imagem. Detalhe: mkfs.btrfs falha se já existir um sistema de arquivos com UUID igual, contudo. Nesse caso, a saída é especificar um novo através da opção uuid= . Excelente programa. O melhor para clonagem de sistemas...

Meus agradecimentos ao Francois Dupoux pela presteza em modificar o FSArchiver de modo a torná-lo compatível com XFS V5. A partir do FSArchiver 0.6.20 fica assim: - Imagens contendo XFS criadas com FSArchiver ≤ 0.6.19 são sempre restauradas como XFS V4. - XFS V4 sempre é criado com -n ftype=0 para garantir ampla compatibilidade. - Imagens criadas com FSArchiver ≥ 0.6.20 armazenam a versão do XFS. Dependendo da versão da suíte xfsprogs usada no momento da restauração, o comportamento é o seguinte: - Se a imagem contiver XFS V4, é idem acima. - Se a imagem contiver XFS V5, é restaurado mantendo a versão 5 se xfsprogs ≥ 4.3.0, porque apenas a partir dessa versão o mkfs.xfs permite definir o UUID no momento da criação do sistema de arquivos. Como em todos os blocos de metadados do XFS V5 o UUID está estampado, trocá-lo depois de ter sido criado (possível a partir de xfsprogs ≥ 4.2.0) joga o kernel mínimo necessário para o 4.3. Sem contar que o sistema de arquivos continua usando ...

Fazer meu script do FSArchiver funcionar com o Jessie. ✓

Em Miúdos de clonagens manuais de partições (II) , sugeri, para regerar o machine-id, deletar /etc/machine-id e reiniciar. O systemd recriaria-o com o conteúdo de /var/lib/dbus/machine-id . Este método funciona no openSUSE 12.3, mas não no Fedora 18. Nele, existem alguns problemas. 1) /var/lib/dbus/machine-id não existe mais. D-Bus e demais códigos que dependem do machine-id foram atualizados para usarem o arquivo presente em /etc . 2) /etc é somente leitura quando o código que regera-o durante o boot é executado ( machine_id_setup() ), ou seja, a criação automática não funcionará. 3) Ao deletar /etc/machine-id e recriá-lo no ambiente do SystemRescueCd, o label do SELinux ficará errado e o arquivo ficará inacessível para os daemons quando o sistema for carregado. O sintoma de /etc/machine-id inacessível se manifestará (dentre outras formas) assim: # systemctl status systemd-journald.service systemd-journald.service - Journal Service Loaded: loaded (/usr/lib/systemd/sy...

O script está no GitHub: https://github.com/marcosfrm/fsarchiver_linux Automatiza ideias da série de posts sobre o assunto: Clonagem manual de partições com o Partclone Clonagem manual de partições com o Partclone (II) Clonagem manual de partições com o Partclone (III) Clonagem manual de partições com o FSArchiver Miúdos de clonagens manuais de partições Miúdos de clonagens manuais de partições (II) Miúdos de clonagens manuais de partições (III)

Em Clonagem manual de partições com o Partclone (II) comentei que é recomendável mudar o UUID do sistema de arquivos quando ele for usado em mais de uma máquina. Uma medida de saneamento. Entretanto, existe outra informação que é prudente alterar: o machine-id. É um identificador único por instalação e que não deve mudar depois de definido. São dois arquivos relacionados: /var/lib/dbus/machine-id (D-Bus) /etc/machine-id (systemd) O primeiro foi o precursor. Depois, o systemd trouxe o seu em /etc . No openSUSE 12.3, /var/lib/dbus/machine-id e /etc/machine-id são diferentes, o que não faz sentido . Olhando o código do systemd, uma solução genérica me parece a seguinte: - Apagar /etc/machine-id . - Colocar um novo UUID em /var/lib/dbus/machine-id a cada restauração do sistema de arquivos. Durante o boot, o systemd detecta que /etc/machine-id não existe e cria-o automaticamente com o mesmo conteúdo de /var/lib/dbus/machine-id . Assim, existirá um único machine-id...

Pequenas atualizações nos posts: Clonagem manual de partições com o Partclone Clonagem manual de partições com o Partclone (II) Também válidas para: Clonagem manual de partições com o Partclone (III) Clonagem manual de partições com o FSArchiver Na hora de instalar o GRUB no disco do sistema de arquivos restaurado, estava assim: # chroot /mnt/fedora # <comando> # exit Porém não funciona num shell script. A solução, que até simplifica para poucos comandos: # chroot /mnt/fedora <comando> Agora funcionará em shell scripts. Na parte para desmontar tudo, restringi um pouco os pontos de montagem bind para o umount não reclamar que demais diretórios não são pontos de montagem: # umount /mnt/fedora/{dev,proc,sys} /mnt/fedora A partir da versão 2.23 (ainda não lançada enquanto escrevo) da suíte util-linux, o umount terá a opção -R (ou --recursive ) para este tipo de cenário: # umount -R /mnt/fedora

Tanto com um cat /proc/cpuinfo quanto o comando lscpu suas saídas precisam ser filtradas para termos um número para ser usado em scripts. Pois não é que existe uma forma mais simples? Apresento-lhes: # getconf _NPROCESSORS_ONLN Útil, por exemplo, para scripts com o FSArchiver , pois a opção -j <numero> pode ser automatizada para aproveitar o número de núcleos disponíveis e acelerar a (des)compressão da imagem. # fsarchiver -v -z 7 -j $(getconf _NPROCESSORS_ONLN) <resto> O comando getconf faz parte da glibc; ou seja, está presente em todas as distribuições.

Ler primeiro: Clonagem manual de partições com o Partclone Clonagem manual de partições com o Partclone (II) Agora que o FSArchiver 0.6.15 voltou a funcionar com EXT4, substituímos o Partclone na criação da imagem por: # fsarchiver -v -z 7 -j 2 savefs /mnt/rede/fedora.fsa /dev/sda1 E na restauração por: # fsarchiver -v -j 2 restfs /mnt/rede/fedora.fsa id=0,dest=/dev/sda1 Opções -z <numero> define o tipo de compressão. <numero> ALGORITMO 1 lzo -3 2 gzip -3 3 gzip -6 4 gzip -9 5 bzip2 -2 6 bzip2 -5 7 lzma -1 8 lzma -6 9 lzma -9 LZMA é o algoritmo mais eficiente. Também é o que mais exige processamento durante a compressão (a descompressão é rápida). -z 7 é no geral uma boa recomendação para máquinas recentes. -j <numero> define o número de threads que serão usadas para comprimir/descomprimir a imagem. Procure usar um número de threads que corresponda a qu...

O FSArchiver foi atualizado para funcionar com sistemas de arquivos EXT4 criados com versões recentes do mke2fs! Sistemas de arquivos EXT4 criados com meta_bg , dir_nlink , entre outros, agora são suportados. http://www.fsarchiver.org/Changelog Aproveito para corrigir um erro no post Programas para clonagem de sistemas de arquivos Linux . O FSarchiver precisa que a partição esteja desmontada para clonar o sistema de arquivos (é possível clonar no modo somente leitura, mas o ideal é desmontá-la). O  kernel sobre o qual o FSArchiver rodar precisa ter habilitado em sua configuração suporte a atributos extendidos e ACLs para o sistema de arquivos em questão. E é recomendável que o SELinux esteja desativado para evitar que o programa seja bloqueado ao ler/gravar os atributos. Assim, os labels do SELinux são corretamente salvos e recriados e tudo funcionará out-of-box. Caso ele falhe em salvar e/ou restaurar os atributos extendidos, todo o sistema de arquivos precisará sofrer um r...

Partimage → está obsoleto e morto. Não suporta EXT4 e trabalha no nível dos blocos, sem entender a estrutura do sistema de arquivos. Portanto não é uma ferramenta eficiente, pois armazena informações além dos dados em si do sistema de arquivos. Não protege os dados salvos com checksums. Partclone → bem melhor comparativamente. Entende a estrutura do sistema de arquivos, por isso salva apenas os dados. Não é, contudo, uma ferramenta dinâmica. Ele faz uma imagem espelho do sistema de arquivos original e não é capaz restaurá-la para partições menores nem redimensionar por conta o sistema de arquivos (precisa de ferramenta externa específica — resize2fs , xfs_growfs , etc). FSArchiver → seria o melhor se tivesse um desenvolvimento ativo. É um programa muito promissor, que implementa um modo de clonagem eficiente e totalmente dinâmico. Usa o kernel [1] para ler as informações de cada arquivo e armazena um conjunto arquivo/propriedade em seu formato de armazenamento de imagem. Ao re...