Recuperar ficheiros em Linux em 2026: ext4, Btrfs, XFS e ZFS, procedimentos verificados

A recuperação de dados em Linux ocupa um lugar singular no panorama de 2026. Ao contrário dos ecossistemas Windows e macOS, onde os utilizadores lidam sobretudo com NTFS, ReFS ou APFS, o administrador Linux faz malabarismo diário com ext4, btrfs, XFS, ZFS e, por vezes, f2fs em cargas embebidas. Cada um destes sistemas de ficheiros impõe um procedimento de recuperação distinto, com rendimentos muito diferentes. Este artigo documenta o procedimento de recuperação para cada uma das quatro famílias principais, com as ferramentas certas, as janelas temporais úteis e os limiares a partir dos quais convém orientar-se para um laboratório profissional ou forense.

O que está em jogo não é apenas técnico. O Linux faz funcionar a maioria dos servidores web ativos, e uma grande parte das estações de trabalho de programadores corre Ubuntu 24.04 LTS, Fedora 41, Debian 13 ou Arch — todos ambientes em que uma eliminação acidental (rm -rf, oops), uma partição formatada por engano ou uma corrupção ext4 após um corte de energia podem paralisar um projeto inteiro. A boa notícia: a comunidade open source mantém um arsenal maduro de ferramentas, e a recuperação em volumes íntegros é frequentemente boa quando a intervenção é rápida.

Afiliação transparente. A Save My Disk recebe uma comissão se adquirir uma licença através dos links EaseUS deste artigo. O EaseUS Data Recovery Wizard 17.2 reconhece as partições ext4, Btrfs e XFS em modo de leitura desde novembro de 2024 — útil para utilizadores dual-boot Windows/Linux sem um ambiente Linux secundário disponível. Para a recuperação Linux nativa, recomendamos o SystemRescue + extundelete/ext4magic/btrfs-restore de acordo com a nossa metodologia pública.

ext4 a fundo: journal, inodes, extents e janelas de recuperação

O sistema de ficheiros ext4, padrão em Ubuntu, Debian e Mint desde 2009, assenta numa estrutura comprovada: um superbloco principal no início da partição, duplicado a cada 128 MB, mais um journal (por omissão journal=data writeback ou journal=ordered) que regista os metadados antes da sua escrita definitiva. Quando um ficheiro é eliminado via rm ou unlink(), o inode correspondente é marcado como livre mas os seus extents (os intervalos de blocos contíguos que contêm os dados) permanecem no lugar — até que uma nova escrita os recicle. É esta latência que torna a recuperação possível.

A janela útil depende de três fatores mensuráveis. Primeiro fator: a taxa de escrita no volume. Numa estação de trabalho de programação ativa (compilações, gravações do IDE, registos do systemd), uma estação ativa escreve tipicamente centenas de MB por hora fora da hibernação, o que significa um risco significativo de reciclagem de blocos em 4 a 6 horas. Num servidor de produção de baixa atividade (sobretudo de leitura), a janela estende-se para 48 ou mesmo 96 horas. Segundo fator: o modo do journal. O modo data=journal protege melhor os dados recentes mas abranda globalmente as escritas; o modo data=writeback, padrão no Ubuntu Server, oferece garantias pós-incidente mais fracas. Terceiro fator: o tamanho dos extents. Os ficheiros >1 GB usam tipicamente árvores de extents profundas (3 a 5 níveis) cuja corrupção torna a reconstituição mais dispendiosa.

O extundelete 0.2.4 mantém-se a ferramenta de referência para a recuperação ext4 simples. O seu funcionamento explora o journal ext4 para identificar os blocos libertados recentemente e reatribuí-los a um diretório de recuperação. Comando padrão:

sudo extundelete /dev/sdX1 --restore-all --output-dir ~/recup

Numa eliminação ext4 recente (Ubuntu 24.04, Debian 13, kernel 6.5 a 6.9), o extundelete recupera uma boa parte dos ficheiros pequenos (<100 MB) quando executado em minutos; passadas algumas horas, o rendimento cai abruptamente.

O ext4magic 0.3.2 complementa o extundelete em volumes maiores ou com extents fragmentados. O seu motor reconstrói os inodes a partir do journal e dos inodes órfãos (ext4 orphan list):

sudo ext4magic /dev/sdX1 -j /dev/sdX1 -a $(date -d "1 hour ago" +%s) -r -d ~/recup

A opção -a define o timestamp de referência (tipicamente 1 hora antes da eliminação), -r ativa a recuperação recursiva, -d o diretório de saída. O ext4magic recupera normalmente mais do que o extundelete graças a um melhor tratamento da hierarquia.

Btrfs e a armadilha do Copy-on-Write: snapshots ou nada

O Btrfs, padrão no Fedora Workstation desde a versão 33, no openSUSE Tumbleweed e em algumas instalações desktop do Ubuntu, funciona segundo um modelo radicalmente diferente. Cada escrita cria uma nova cópia do bloco e atualiza a tabela de ponteiros — é o Copy-on-Write (CoW). Consequência imediata: uma eliminação só remove o ponteiro, e o extent original pode sobreviver muito tempo enquanto subvolumes ou snapshots existentes o referenciarem.

A melhor defesa continuam a ser os snapshots automáticos. No Fedora 41, o Snapper cria por omissão um snapshot antes de cada dnf update, o que cobre as perdas de ficheiros de sistema. No openSUSE, o Snapper vai mais longe com snapshots horários dos volumes home. O restauro é um único comando:

sudo btrfs subvolume snapshot /.snapshots/42/snapshot /home/eric-restored

Sem snapshot, a situação complica-se mas não é desesperada. O btrfs-restore (pacote btrfs-progs) explora o superbloco e as árvores residuais para recuperar os extents órfãos:

sudo btrfs-restore -t <btrfs-superblock-offset> /dev/sdX1 ~/recup-btrfs

Para identificar os superblocos disponíveis: btrfs-find-root /dev/sdX1. Este binário lista as roots coerentes que o btrfs-restore pode seguir. Em Btrfs (Fedora 41, openSUSE Tumbleweed, Ubuntu 24.10), o btrfs-restore sem snapshot recupera notavelmente menos do que o ext4magic — mas com um snapshot disponível, o restauro é completo para os ficheiros cobertos.

XFS e xfs_undelete: a comunidade Red Hat colmata a lacuna

O XFS, criado pela Silicon Graphics em 1993 e adotado pelo Red Hat Enterprise Linux como sistema de ficheiros padrão desde o RHEL 7, sofreu durante muito tempo da ausência de uma ferramenta undelete nativa. O journal XFS, otimizado para cargas intensivas em I/O e ficheiros muito grandes (até 8 exabytes), regista os metadados de forma compacta mas não preserva os blocos eliminados como o ext4 faz.

A ferramenta xfs_undelete publicada no GitHub pela comunidade Red Hat em 2024 (versão 1.5 lançada em fevereiro de 2026) mudou o jogo. Analisa os journals recentes e os agrupamentos de extents para reconstruir os inodes eliminados há menos de 24 horas.

sudo xfs_undelete -l /dev/sdX1 -d ~/recup-xfs -t $(date -d "30 minutes ago" +%s)

Em XFS (RHEL 9.4, Rocky Linux 9.4, Oracle Linux 9), o xfs_undelete recupera mais nos ficheiros pequenos do que nos grandes. O declínio nos ficheiros grandes explica-se por um flushing de extents XFS mais agressivo em comparação com o ext4. Para cargas de base de dados ou virtualização, onde o XFS é típico, a recomendação prática continua a ser: dar prioridade aos snapshots LVM (lvcreate -s) e aos backups incrementais Borg ou restic, em vez de contar com o xfs_undelete.

ZFS: a filosofia snapshot-first

O ZFS, disponível nativamente em FreeBSD e Solaris, e via zfs-dkms ou zfs-linux em Ubuntu, Proxmox VE e TrueNAS Core, adota uma abordagem radicalmente diferente: tudo assenta em snapshots, desduplicação e compressão integradas no pool. Eliminar um ficheiro só liberta realmente os blocos quando todos os snapshots que os referenciam são também eliminados. Esta propriedade é simultaneamente a grande força do ZFS para a recuperação e a sua armadilha para administradores negligentes.

O procedimento padrão para recuperar um ficheiro eliminado em ZFS exige dois comandos:

zfs list -t snapshot tank/home
zfs rollback tank/home@snapshot-pre-rm

ou, sem destruir o estado atual:

zfs clone tank/home@snapshot-pre-rm tank/home-recovery

Em ZFS (TrueNAS Core 13.3, Proxmox VE 8.2, Ubuntu 24.04 com raiz ZFS), a recuperação é completa quando existe um snapshot que cobre o período, e impossível caso contrário. Nenhuma ferramenta de terceiros consegue recuperar um bloco ZFS libertado definitivamente sem snapshot — é um limite criptográfico ligado à arquitetura do pool.

Distribuições e ferramentas de recuperação: SystemRescue, CAINE, Kali

Arrancar a partir de uma pen USB de recuperação continua a ser o primeiro passo crítico num sistema Linux em que o volume de raiz está afetado. Três distribuições partilham os casos de uso em 2026.

O SystemRescue 11.04 (maio de 2026, kernel 6.9 LTS) reúne o arsenal mais completo: testdisk, photorec, ddrescue, extundelete, ext4magic, btrfs-progs 6.9, xfs_undelete, zfs-dkms, smartctl, GParted e um ambiente Xfce leve para a análise visual. Imagem ISO de 1,2 GB, arranque por USB em 25 a 30 segundos consoante o hardware.

O CAINE 13.0 acrescenta uma camada forense rigorosa. O sistema monta todos os volumes em leitura por omissão, o que elimina o risco de escritas acidentais. Indispensável para casos com implicações jurídicas (eliminação fraudulenta, investigação interna, cautela RGPD).

O Kali Linux 2026.1 mantém-se válido para fluxos de trabalho que combinam recuperação e investigação pós-incidente — suspeita de exfiltração, ransomware lateral, post-mortem de segurança. O seu foco ofensivo (Metasploit, Burp Suite, Aircrack) torna-o menos enxuto do que uma ferramenta de recuperação dedicada, mas o ecossistema de pacotes mantém-se muito vasto.

Recuperação por sistema de ficheiros Linux

A tabela abaixo resume o comportamento de recuperação por sistema de ficheiros, com base nas ferramentas documentadas, na sua mecânica de journaling/CoW e no consenso das análises públicas. Desmontar sempre em minutos e criar uma imagem com ddrescue antes de qualquer análise.

Fonte das especificações ext4: documentação ext4 do kernel.org. Documentação btrfs-progs: btrfs.wiki.kernel.org.

Casos especiais: cifragem LUKS, RAID por software e LVM

Três configurações comuns complicam o procedimento e merecem atenção específica.

Cifragem LUKS. Se o volume estiver sob LUKS (padrão no Ubuntu 24.04 LTS Full Disk Encryption, Fedora 41 com /boot e raiz cifrados), o mapeamento tem de ser aberto primeiro, antes de qualquer manipulação: cryptsetup luksOpen /dev/sdX1 cryptroot e depois trabalhar em /dev/mapper/cryptroot. A frase-passe é indispensável. Sem ela, nenhuma recuperação é possível — nem mesmo em laboratório — exceto explorando uma possível vulnerabilidade de firmware específica do modelo de SSD.

RAID por software mdadm. Os volumes RAID 0, 1, 5, 6 ou 10 têm de ser montados antes da análise: mdadm --assemble --scan ou mdadm --assemble /dev/md0 /dev/sd[abcd]1. Para os RAID degradados ou com um disco em falta, mdadm --assemble --force tenta a montagem com os superblocos disponíveis. Assim que /dev/md0 estiver ativo, o procedimento é idêntico ao do simples volume subjacente.

LVM. Os volumes lógicos LVM têm de ser ativados: vgscan, depois vgchange -ay, depois lvscan para identificar os LV a analisar. Se um LV foi eliminado com lvremove, a opção lvm vgcfgrestore -f /etc/lvm/backup/<vg> <vg> restaura a tabela de configuração a partir do backup automático do LVM — uma operação não destrutiva enquanto nenhuma nova escrita tiver ocorrido desde a eliminação.

FAQ — Perguntas frequentes sobre a recuperação Linux

Qual a primeira ação após uma eliminação acidental em Linux?

Desmontar imediatamente o sistema de ficheiros (umount /dev/sdX1) ou, se o volume de raiz estiver afetado, arrancar o SystemRescue ou o CAINE por USB. Qualquer escrita adicional — incluindo journalctl, atime ou backup rsync — pode sobrescrever inodes ainda recuperáveis.

O extundelete ainda funciona em ext4 em 2026?

Sim em ext4 padrão, mas o seu desempenho degrada-se em volumes >8 TB com árvores de extents profundas. O ext4magic 0.3.2 assume com um rendimento tipicamente melhor graças à reconstrução hierárquica a partir do journal.

Como recuperar um subvolume Btrfs eliminado?

Três casos: 1) snapshot disponível → btrfs subvolume snapshot, restauro completo instantâneo. 2) sem snapshot, eliminação recente → btrfs-restore -t explora o residual CoW. 3) eliminação antiga ou extents reciclados → btrfs-find-root e depois btrfs-restore com rootid específico.

O ZFS e o XFS oferecem soluções equivalentes ao ext4?

Não segundo a mesma lógica. ZFS = snapshot-first: completo com um snapshot, impossível sem. XFS = xfs_undelete 1.5 desde 2024, que recupera mais nos ficheiros pequenos do que nos grandes.

Que distribuição Linux para a recuperação em 2026?

SystemRescue 11.04 (arsenal completo, kernel 6.9 LTS), CAINE 13.0 (modo forense rigoroso com bloqueador de escrita), Kali Linux 2026.1 (recuperação + investigação pós-incidente).

Veredicto: o Linux recupera bem quando há preparação, mal quando se improvisa

A recuperação Linux em 2026 depende menos da ferramenta do que de duas decisões tomadas a montante. Primeira decisão: a escolha do sistema de ficheiros segundo o perfil de risco. Para uma estação de trabalho de utilizador sem snapshots automáticos, ext4 + ext4magic oferece o melhor compromisso em ficheiros pequenos eliminados de fresco. Para um servidor ou estação de trabalho configurados por um administrador, Btrfs ou ZFS com snapshots horários automatizados (Snapper, sanoid/syncoid, zfs-auto-snapshot) entrega uma recuperação quase completa em segundos.

Segunda decisão: a rapidez de intervenção. Num volume ativo, a janela útil conta-se em minutos, não em horas. A regra que resume tudo: desmontagem imediata, imaging com ddrescue, análise sobre a imagem — nunca sobre o volume de origem. Um administrador que domina o SystemRescue ou o CAINE, que automatiza os seus snapshots e que sabe identificar o sistema de ficheiros de destino em menos de 30 segundos ultrapassa a grande maioria dos incidentes sem intervenção paga.

Para os casos para além do perímetro do software — corrupção física do disco, RAID degradado sem superbloco, cifragem sem chave — orientar-se para um laboratório continua a ser indispensável. Conte com 600 a 2.200 € na Ontrack, DriveSavers ou Recoveo para um caso Linux clássico com disco físico intacto, e até 5.000 € para configurações combinadas LUKS + RAID + LVM.