Como recuperar permissões e ACLs perdidos após restauração de backup em servidor Linux sem interromper serviços (passo a passo)

Por Kevin Marcondes · Publicado em 28/10/2026 · 9 min de leitura

Como recuperar permissões e ACLs perdidos após restauração de backup em servidor Linux sem interromper serviços? Corrija metadados (permissões, donos, ACLs e xattrs) de forma segura, mantendo processos no ar. Veja como diagnosticar o que mudou, restaurar apenas atributos a partir de um snapshot ou referência confiável e validar o resultado antes de encerrar o incidente.

O que realmente se perde quando o backup ignora metadados

Quando a restauração não preserva metadados, você perde modos (chmod), donos e grupos (chown), ACLs, atributos estendidos (xattrs) e, em ambientes com SELinux, contextos. Serviços continuam rodando, mas reaberturas de arquivos e novos writes podem falhar.

Sintomas comuns ajudam a priorizar a correção imediata. Use-os para definir o escopo e reduzir riscos de alterações amplas e desnecessárias.

• 403/401 no web server após restore do site mesmo com conteúdo íntegro.
• Serviços que não criam arquivos em diretórios de spool/cache por falta de permissões.
• Banco de dados não acessa diretório de dados por dono errado.
• Scripts systemd não rodam porque perderam o bit de execução.
• ACLs finas de pastas compartilhadas sumiram, quebrando acessos de equipe.

Como diagnosticar quais permissões e ACLs foram perdidos?

O diagnóstico compara o estado atual com uma referência confiável. Vale um snapshot LVM, um backup anterior com metadados ou um servidor gêmeo. Sem referência, colete sinais de risco e priorize áreas críticas.

Verifique se o filesystem suporta ACLs e se não está montado com noacl. Gere inventários de permissões e ACLs para comparar e versionar. Se você ainda não tem snapshots automatizados, veja o guia de snapshots LVM com Restic em S3.

# 1) Verifique opções de montagem (procure 'acl' ou 'noacl')
findmnt -no SOURCE,FSTYPE,OPTIONS /

# 2) Liste donos/permissões rapidamente (ex.: webroot)
find /var/www -xdev -printf '%m %u:%g %p\n' | head -n 20

# 3) Inspecione ACLs atuais (prefixos absolutos com -p)
getfacl -R -p /var/www | head -n 40

# 4) Se tiver um snapshot montado em /mnt/snap, gere dumps p/ diff
getfacl -R -p /mnt/snap/var/www > /root/acl.ref
getfacl -R -p /var/www         > /root/acl.now

diff -u /root/acl.ref /root/acl.now | sed -n '1,200p'

Como recuperar metadados a partir de um snapshot sem parar serviços?

Restaurar apenas metadados é possível e seguro para serviços em execução porque chmod/chown/setfacl são operações atômicas nos inodes. Execute como root e teste em um diretório de prova antes.

A estratégia: montar o backup em modo somente leitura, aplicar atributos sem copiar conteúdo e regravar ACLs/xattrs. Faça um backup dos metadados atuais para rollback rápido. Para sincronizações, lembre do rsync com -A -X; para cenários de migração com mínima indisponibilidade, veja o passo a passo de migração de host Docker com rsync.

• Monte o snapshot/backup como leitura (ro).
• Salve metadados atuais (ACLs/xattrs) para rollback.
• Aplique atributos com cp --attributes-only.
• Restaure ACLs com setfacl --restore e xattrs com setfattr --restore.
• Use escopo cirúrgico: um caminho por vez (ex.: /srv/app, /var/www).

# Exemplo: restaurar metadados de /srv/app a partir de /mnt/snap/srv/app
# 0) Backups de metadados atuais (rollback)
getfacl  -R -p /srv/app > /root/acl.before
getfattr --dump -R /srv/app > /root/xattr.before || true

# 1) Aplique donos/permissões/tempos SEM tocar no conteúdo
cp -a --attributes-only /mnt/snap/srv/app/. /srv/app/

# 2) Restaure ACLs a partir do snapshot
getfacl -R -p /mnt/snap/srv/app | setfacl --restore=-

# 3) Restaure atributos estendidos (xattrs)
getfattr --dump -R /mnt/snap/srv/app > /root/xattr.dump || true
setfattr --restore=/root/xattr.dump  || true

Restaurar ACLs e atributos estendidos com segurança

As ACLs controlam permissões finas além do trio dono/grupo/outros. Os xattrs incluem marcações como capabilities e, em algumas distros, rótulos de MAC. Erros podem bloquear acessos; valide sempre com testes em diretórios menores antes.

Se SELinux estiver habilitado, reetiquete contextos após restaurar xattrs/ACLs. Em AppArmor, revise perfis se diretórios mudaram.

• Use getfacl -R -p no snapshot e setfacl --restore no alvo.
• Para xattrs, combine getfattr --dump e setfattr --restore.
• Em SELinux, rode restorecon -RF no escopo afetado.
• Evite aplicar em / recursivamente; trabalhe por componentes.

# ACLs e xattrs de um diretório compartilhado
getfacl -R -p /mnt/snap/data/shared | setfacl --restore=-
getfattr --dump -R /mnt/snap/data/shared > /root/shared.xattrs || true
setfattr --restore=/root/shared.xattrs || true

# SELinux (se aplicável)
command -v getenforce >/dev/null 2>&1 && restorecon -RF /data/shared || true

E se eu não tiver um snapshot com metadados corretos?

Sem uma referência, reconstituir metadados exige critérios. Para binários e arquivos de pacotes, recupere padrões da base do gerenciador. Para dados de aplicação, adote políticas conservadoras e revise em revisão por pares.

Em sistemas baseados em RPM, os metadados de pacotes podem ser restabelecidos a partir do banco local. Em Debian/Ubuntu, reinterprete dpkg-statoverride e considere reinstalações controladas em janela de manutenção.

• RPM (RHEL/CentOS/Fedora): use rpm --setperms -a e rpm --setugids -a.
• Debian/Ubuntu: consulte dpkg-statoverride --list para diretórios com overrides.
• Para apps: adote padrões seguros (dirs 750/755, files 640/644) e ajuste exceções.
• Revise capabilities (getcap/setcap) se sua stack usar file capabilities.

# RPM-based: restaurar donos e permissões padrão de pacotes
rpm --setperms -a
rpm --setugids -a

# Debian/Ubuntu: listar overrides registrados
dpkg-statoverride --list | sed -n '1,50p'

# Capabilities (se usados)
getcap -r /usr/bin 2>/dev/null | sed -n '1,50p'

Como evitar que isso volte a acontecer no próximo backup?

Evite perdas repetidas garantindo que seu backup preserve metadados. Ferramentas devem capturar ACLs e xattrs e restaurá-los por padrão. Além disso, gere dumps de referência de ACL/xattrs junto do backup para auditoria.

Teste restaurações em ambiente de homologação periodicamente. Use snapshots para reduzir janelas de inconsistência e minimizar cópias ativas de serviços. Para uma implantação robusta, veja o serviço de backups incrementais e criptografados.

• Rsync: use -aAX (archive + ACLs + xattrs) e valide com --dry-run.
• Tar/bsdtar: inclua --acls e --xattrs ao criar/extrair.
• Anexe dumps: getfacl --absolute-names e getfattr --dump no mesmo job.
• Documente escopo: evite /proc, /sys, /dev, /run e mounts efêmeros.
• Agende testes de restauração com systemd timers e snapshots LVM.

# Exemplo de sincronização que preserva metadados (somente leitura no destino antes)
rsync -aAX --numeric-ids --info=SKIP,NAME --dry-run /origem/ /destino/

# Dumps anexos no job de backup
getfacl  -R --absolute-names /srv/app > /backup/refs/acl.srv-app
getfattr --dump -R              /srv/app > /backup/refs/xattr.srv-app

Verificações finais e auditoria pós-correção

Valide que serviços conseguem criar e ler arquivos. Procure por bits perigosos e inconsistências. Gere um relatório final comparando ACLs antes/depois e arquive em local seguro.

Se unidades systemd ou configs foram afetadas, um reload é suficiente; não precisa restartar serviços se o conteúdo não mudou. Para ambientes com containers, veja práticas de bind mounts no guia de mover volumes Docker.

• Testes de escrita/leitura no app (ex.: upload temporário).
• Procure world-writable e SUID inesperados.
• Compare ACLs antes/depois para encerrar o incidente.
• Considere um reload de serviços que leem configs sob demanda.

# World-writable e SUID/SGID suspeitos no escopo tratado
find /srv/app -xdev \( -perm -0002 -o -perm -2000 -o -perm -4000 \) -ls

# Diff de ACLs
getfacl -R -p /srv/app > /root/acl.after
diff -u /root/acl.before /root/acl.after | sed -n '1,200p'

# Reload (se necessário)
systemctl daemon-reload || true
# Ex.: nginx, php-fpm, etc. (apenas reload se alterou configs)
# systemctl reload nginx || true

Recursos correlatos e quando usar PITR

Quando a perda afetar apenas dados de um banco, considere uma restauração no nível do próprio banco (PITR) em vez de manipular arquivos do data directory. Para backups de sistema de arquivos, snapshots reduzem risco e preservam metadados.

Veja materiais práticos para implementar snapshots e rotinas de backup verificáveis em servidores Linux. Para bancos PostgreSQL, o guia de PITR sem downtime aprofunda a estratégia.

Perguntas frequentes

Preciso parar os serviços para restaurar permissões e ACLs?

Na maioria dos casos, não. chmod, chown e setfacl são operações atômicas e não exigem reinício. Se você não alterou o conteúdo, um reload de serviços pode bastar quando há leitura dinâmica de configs.

Posso recuperar ACLs de um backup feito com tar ou rsync comum?

Sim, se o backup armazenou ACLs e xattrs. Com tar, use as opções --acls e --xattrs. Com rsync, preserve -A e -X. Sem esses metadados, use uma referência (snapshot/host gêmeo) para reconstituir ACLs.

E se o filesystem estiver montado com noacl?

Reative o suporte a ACLs remontando com a opção acl ou habilitando-a por padrão no /etc/fstab. Sem suporte a ACLs, setfacl não terá efeito e permissões finas ficarão indisponíveis.

Como tratar volumes Docker ou bind mounts durante a correção?

Ajuste donos/permissões/ACLs no host nos diretórios de volumes. Mapeie UIDs/GIDs usados pelos containers e aplique chown/chmod/setfacl no caminho real do volume, evitando alterar camadas de imagem.

Reinstalar pacotes corrige permissões de sistema?

Em distribuições RPM, rpm --setperms/--setugids corrige para padrões do pacote. Em Debian/Ubuntu, reinstalar pode repor defaults, mas pode sobrescrever configs. Planeje em janela de manutenção e faça backup prévio.

Veja também

• 502 Bad Gateway intermitente em Docker Compose com Nginx e PHP‑FPM: como diagnosticar e corrigir timeouts e excesso de conexões
• Como diagnosticar e capturar pacotes para intermitência de rede entre containers Docker no Debian
• Como reduzir tempo de recuperação após crash de servidor Linux com playbook Ansible e runbook de recuperação
• Como reduzir tempo de build e evitar artefatos duplicados em CI para monólitos PHP grandes