Arquitetura do Sistema de Arquivos: Inodes e Blocos

No ecossistema Linux, o armazenamento de dados em disco é abstraído através de duas estruturas fundamentais: blocos (blocks) e nós de índice (inodes). Enquanto os blocos representam a menor unidade de alocação para os dados reais do arquivo (geralmente compostos por setores contíguos de 4KB), os inodes atuam como repositórios de metadados. É crucial compreender que o nome do arquivo não reside no inode, mas sim no bloco de diretório que o referencia.

Estrutura e Metadados do Inode

Cada inode armazena atributos vitais sobre o arquivo, incluindo tipo, permissões (leitura, escrita, execução), identificadores de proprietário (UID) e grupo (GID), contagem de links, tamanho em bytes, ponteiros para os blocos de dados e três carimbos de data/hora principais:

• mtime (Modify Time): Última alteração no conteúdo do arquivo.
• ctime (Change Time): Última alteração nos metadados (ex: permissões ou proprietário).
• atime (Access Time): Última leitura ou acesso ao arquivo.

A inspeção detalhada dessas propriedades pode ser realizada através do utilitário stat:

$ stat relatorio.csv
  File: relatorio.csv
  Size: 2048       Blocks: 8          IO Block: 4096   regular file
Device: fd01h/64769d   Inode: 88341205    Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/   admin)   Gid: ( 1000/   admin)
Access: 2023-10-12 09:15:22.123456789 -0300
Modify: 2023-10-12 09:10:05.987654321 -0300
Change: 2023-10-12 09:10:05.987654321 -0300

Alocação, Identificação e Fluxo de Acesso

Durante a formatação de uma partição, o sistema operacional reserva uma área específica para a tabela de inodes. O tamanho de cada inode é tipicamente 128 ou 256 bytes, mas o foco administrativo deve ser a quantidade total disponível, verificável via df -i. O kernel do Linux não utiliza nomes de arquivos para operações de baixo nível; ele resolve o nome para um número de inode, valida as permissões no metadado e, por fim, lê os blocos de dados apontados.

Essa separação entre nome e inode permite operações avançadas, como a exclusão de arquivos com caracteres especiais ou corrompidos no nome, utilizando o número do inode diretamente:

$ ls -i
88341205 arquivo_com_espaco .txt  99213445 script.sh
$ find . -maxdepth 1 -inum 88341205 -exec rm -f {} +

Links Físicos e Links Simbólicos

A arquitetura de inodes também dita o comportamento dos links no Linux. Um link físico (hard link) é simplesmente uma nova entrada de diretório que aponta para um inode já existente. Ambos os nomes compartilham os mesmos dados e metadados, e a exclusão de um não afeta o outro até que a contagem de links chegue a zero. Por outro lado, um link simbólico (soft link) é um arquivo distinto com seu próprio inode, cujo conteúdo é apenas o caminho de texto para o arquivo alvo. Se o alvo for removido, o link simbólico torna-se órfão (broken link).

Estratégias de Recuperação de Dados

A exclusão acidental de arquivos exige abordagens distintas dependendo do sistema de arquivos subjacente.

Restauração em Sistemas da Família EXT

Para partições formatadas em ext3 ou ext4, a ferramenta extundelete analisa o journal e os inodes marcados como excluídos para reconstruir os dados. Abaixo, demonstramos a compilação e uso em um ambiente corporativo:

# Preparação do disco e instalação de dependências
$ sudo fdisk /dev/vdc
$ sudo mkfs.ext3 /dev/vdc1
$ sudo mkdir -p /mnt/restauracao && sudo mount /dev/vdc1 /mnt/restauracao
$ sudo dnf install -y e2fsprogs-devel gcc-c++ make

# Compilação do utilitário
$ wget https://sourceforge.net/projects/extundelete/files/extundelete/0.2.4/extundelete-0.2.4.tar.bz2
$ tar -xjf extundelete-0.2.4.tar.bz2 && cd extundelete-0.2.4
$ ./configure --prefix=/opt/extundelete && make && sudo make install

# Simulação de desastre e recuperação
$ echo "dados criticos" > /mnt/restauracao/planilha.csv
$ sudo rm -f /mnt/restauracao/planilha.csv
$ sudo umount /mnt/restauracao
$ sudo /opt/extundelete/bin/extundelete /dev/vdc1 --restore-file planilha.csv

Backup e Restauração nativa em XFS

O XFS, padrão em distribuições modernas como RHEL/CentOS 7+, não possui ferramentas de "undelete" de código aberto confiáveis. A estratégia mandatória é o uso de backups nativos com xfsdump e xfsrestore. O xfsdump suporta níveis de backup (0 para completo, 1-9 para incrementais) e exige que o sistema esteja montado.

# Configuração e Backup Nível 0 (Completo)
$ sudo mkfs.xfs /dev/vdd1
$ sudo mkdir -p /mnt/dados_xfs && sudo mount /dev/vdd1 /mnt/dados_xfs
$ sudo xfsdump -l 0 -f /backup/xfs_vdd1.dump /dev/vdd1 -L "Backup_Diario" -M "Fita_01"

# Cenário de perda total e restauração
$ sudo rm -rf /mnt/dados_xfs/*
$ sudo xfsrestore -f /backup/xfs_vdd1.dump /mnt/dados_xfs

Gestão e Análise de Logs do Sistema

A telemetria e o registro de eventos no Linux são centralizados no diretório /var/log/. O daemon rsyslog orquestra a maioria dos logs do kernel e de serviços, enquanto aplicações específicas (como servidores web ou proxies) mantêm seus próprios formatos.

Facilities e Severidades no Rsyslog

A configuração do rsyslog baseia-se na combinação de facilities (origem da mensagem) e severidades (nível de criticidade). As facildiades incluem auth (autenticação), kern (kernel), cron (tarefas agendadas) e local0-7 (uso personalizdao). As severidades variam de 0 (EMERG - sistema inutilizável) a 7 (DEBUG - informações detalhadas de depuração). Quanto menor o número, maior a criticidade do evento.

Análise de Logs de Usuário e Serviços

Para auditoria de acesso, arquivos binários como /var/log/wtmp e /var/run/utmp são consultados através de utilitários como last, lastb, who e w. Logs de texto, como /var/log/secure (autenticação SSH/sudo) ou /var/log/messages (eventos gerais), são frequentemente processados com ferramentas de filtragem como grep, awk e sed, ou ingeridos por plataformas de análise dedicadas.

Gerenciamento Moderno com Systemd Journal

Em sistemas baseados em systemd, o journald captura logs de todas as unidades (units), kernel e stdout/stderr de serviços, armazenando-os em formato binário estruturado. O utilitário journalctl substitui a necessidade de ler múltiplos arquivos de texto, oferecendo filtros precisos:

# Exibir logs do serviço SSH nas últimas duas horas, em ordem cronológica
$ journalctl -u sshd.service --since "2 hours ago"

# Filtrar mensagens do kernel com severidade de erro ou superior
$ journalctl -k -p err

# Rastrear logs de um processo específico pelo PID e acompanhar em tempo real
$ journalctl _PID=1234 -f

# Inspecionar falhas da inicialização anterior do sistema (útil para diagnosticar kernel panics)
$ journalctl -b -1 -p crit