Stratis: Gestão de Armazenamento Local com Camadas Thin-Pool
O Stratis é uma camada de gestão de armazenamento local para Linux que simplifica a criação de pools, snapshots e provisionamento fino, oferecendo uma alternativa menos complexa ao ZFS e ao Btrfs — sem sacrificar as funcionalidades essenciais que uma PME precisa num servidor físico.
Neste artigo
- Introdução — Armazenamento local em Linux sem complexidade
- O que é o Stratis
- Instalação e Criação de Pools
- Snapshots e Provisionamento Fino
- Comparação com ZFS e Btrfs
- Boas Práticas para PME
- Conclusão
Introdução — Armazenamento local em Linux sem complexidade
Gerir armazenamento local num servidor Linux tradicionalmente significa escolher entre duas abordagens: a simplicidade do LVM + XFS, que oferece gestão de volumes básico mas pouca automação, ou sistemas avançados como OpenZFS e Btrfs, que trazem integridade de dados, compressão e snapshots ao custo de uma curva de aprendizagem significativa.
Para uma PME com alguns servidores físicos, esta escolha raramente é simples. O ZFS exige configuração cuidada de ZIL/SLOG, ARC, datasets e propriedades. O Btrfs, embora mais integrado no kernel, tem histórico de instabilidade em configurações RAID complexas. Entretanto, o LVM manual — com dezenas de comandos lvcreate, lvresize e mkfs — é propenso a erros quando não há equipa dedicada de administrador de sistemas.
O Stratis surge exactamente neste espaço: oferece as capacidades avançadas — snapshots, provisionamento fino, encriptação e níveis de desempenho — através de uma CLI simples (stratis), mantendo a robustez do device-mapper e do XFS por baixo. É um projecto activamente desenvolvido e suportado pela Red Hat, incluído no RHEL e Fedora.
O que é o Stratis
O Stratis é um serviço de gestão de armazenamento local para Linux que funciona como uma camada de abstracção sobre tecnologias maduras do kernel: device-mapper (para provisionamento fino e snapshots) e XFS (como filesystem). O componente principal é o stratisd, um daemon em Rust que corre em segundo plano e gere os pools, filesystems e snapshots.
A arquitectura tem três camadas principais:
- Block devices — discos físicos, partições ou LUKS que o administrador adiciona ao pool.
- Pool — agrupa os dispositivos de bloco num pool fino de device-mapper, com provisionamento dinâmico.
- Filesystems — volumes XFS criados dentro do pool, com tamanho inicial reduzido e crescimento automático.
O stratisd comunica com o kernel via D-Bus e expõe uma API que a CLI stratis utiliza. Toda a complexidade do device-mapper — criar pool fino, mapear volumes, redimensionar — fica escondida. O administrador interage apenas com conceitos simples: pool, filesystem, snapshot.
| Componente | Tecnologia base | Função |
|---|---|---|
| stratisd | Rust daemon | Gestão de pools, filesystems e snapshots via D-Bus |
| stratis CLI | Python | Interface de linha de comando para o administrador |
| Thin pool | device-mapper | Provisionamento dinâmico e snapshots |
| Filesystem | XFS | Formatação e escrita de dados |
O código-fonte está disponível publicamente no repositório oficial do stratisd no GitHub, com documentação técnica completa e registo de problemas activo.
Instalação e Criação de Pools
No RHEL 9, CentOS Stream e Fedora, o Stratis vem nos repositórios oficiais. A instalação resume-se a dois pacotes:
dnf install stratisd stratis-cli
systemctl enable --now stratisd
A criação de um pool é um único comando. Neste exemplo, adicionamos um disco inteiro (/dev/sdb) a um novo pool chamado dados:
stratis pool create dados /dev/sdb
Para verificar o estado do pool:
stratis pool list
Name Total Physical Properties UUID
dados 1 TiB Ca,Cr 3f9a...
A coluna Properties mostra Ca (Cache) e Cr (Encrypted) quando activas — um tilde antes do código (~Ca) indica que a propriedade está desactivada. O Stratis suporta encriptação via LUKS de forma transparente.
A criação de filesystems dentro do pool é igualmente directa:
stratis filesystem create dados partilhados
stratis filesystem create dados vm-backups
Os filesystems ficam disponíveis em /stratis/dados/partilhados e /stratis/dados/vm-backups — o Stratis cria estes pontos de montagem automaticamente:
stratis filesystem list
Pool Name Created Device
dados partilhados 2026-08-21 10:30 /stratis/dados/partilhados
dados vm-backups 2026-08-21 10:31 /stratis/dados/vm-backups
Para montar persistentemente, adicionar ao /etc/fstab usando o identificador estável:
/stratis/dados/partilhados /mnt/partilhados xfs defaults,x-systemd.requires=stratisd 0 0
/stratis/pool/fs com x-systemd.requires=stratisd para garantir que o daemon arranca antes da montagem.Snapshots e Provisionamento Fino
Os snapshots são uma das funcionalidades mais úteis do Stratis para PME. São instantâneos Copy-on-Write (CoW) criados sobre o pool fino de device-mapper — consomem espaço apenas à medida que os blocos divergem do original. Isto permite criar cópias point-in-time antes de actualizações ou configurações arriscadas, sem duplicar o armazenamento completo.
stratis filesystem snapshot dados partilhados partilhados-pre-update
O snapshot fica disponível como um filesystem normal em /stratis/dados/partilhados-pre-update e pode ser montado, navegado ou restaurado. Para reverter, basta substituir o filesystem original pelo snapshot com um rename:
stratis filesystem destroy dados partilhados
stratis filesystem rename dados partilhados-pre-update partilhados
O provisionamento fino é activo por predefinição em todos os filesystems Stratis. Cada filesystem começa com um tamanho pequeno (tipicamente ~1 GiB) e cresce automaticamente até ao limite do pool. Isto significa que se pode criar 10 filesystems num pool de 500 GiB e cada um “verá” espaço disponível sem estar pré-alocado:
stratis filesystem list
Pool Name Used Created
dados partilhados 45 GiB 2026-08-21 10:30
dados vm-backups 120 GiB 2026-08-21 10:31
dados partilhados-snap 2 GiB 2026-08-21 14:00
A coluna Used mostra o consumo real. O snapshot partilhados-snap ocupa apenas 2 GiB — os blocos que divergiram do original desde a criação do snapshot.
Nota importante: o Stratis não tem compressão nem deduplicação nativas — ao contrário do ZFS (LZ4/Zstd) e do Btrfs (Zstd). A compressão por VDO integra-se com LVM (lvmvdo), não com o Stratis; a integração de VDO no Stratis foi discutida no passado mas nunca implementada, e as notas de lançamento mais recentes (séries 3.8 e 3.9, 2026) continuam sem a listar. Os filesystems Stratis são sempre XFS — não há opção para ext4. Se a compressão for requisito, as alternativas são VDO/lvmvdo por baixo de um volume LVM clássico, ou escolher ZFS/Btrfs para esse volume.
stratis pool list regularmente é essencial para evitar encher o pool — o que faria com que todos os filesystems dentro dele ficassem só de leitura.Comparação com ZFS e Btrfs
O Stratis não compete directamente com o ZFS em integridade de dados nem com o Btrfs em flexibilidade de subvolumes. O seu nicho é a simplicidade operacional. A tabela seguinte resume as diferenças principais:
| Funcionalidade | Stratis | ZFS | Btrfs |
|---|---|---|---|
| Filesystem base | XFS | Próprio (ZFS) | Próprio (Btrfs) |
| Somas de Verificação por bloco | Não | Sim | Sim |
| Snapshots CoW | Sim | Sim | Sim |
| Thin provisioning | Sim (automático) | Sim (refreservation) | Sim |
| RAID nativo | Não (usa mdadm) | Sim (RAID-Z) | Sim (Btrfs RAID) |
| Compressão | Não (VDO é LVM, não Stratis) | Sim (LZ4/Zstd) | Sim (Zstd) |
| Complexidade CLI | Baixa | Elevada | Média |
| Encriptação | LUKS integrado | Nativa (ZFS 2.x) | LUKS externo |
| Suporte Red Hat | Oficial (RHEL) | Comunitário | Limitado |
A ausência de somas de verificação por bloco é a principal limitação do Stratis face ao ZFS. Isto significa que o Stratis não detecta silenciosamente corrupção de dados em repouso (bit-rot). No entanto, para cargas onde a cópia de segurança externa é garantida — o que deve ser sempre o caso numa PME — esta limitação é mitigada pela simplicidade operacional.
Já escrevemos em detalhe sobre o OpenZFS no Linux para PME — essa abordagem faz sentido quando a integridade de dados é o requisito principal. O Stratis complementa essa solução para servidores onde o objectivo é gestão simples com snapshots.
Boas Práticas para PME
A adopção do Stratis num ambiente de PME beneficia de algumas recomendações práticas, baseadas na experiência de configuração e manutenção:
1. Usar discos inteiros, não partições
O Stratis foi desenhado para gerir dispositivos de bloco inteiros. Adicionar /dev/sdb em vez de /dev/sdb1 permite ao stratisd gerir o dispositivo correctamente, incluindo identificação por UUID e adição de cache.
2. Adicionar discos de cache para desempenho
O Stratis suporta a adição de dispositivos de bloco como cache (tipicamente SSDs de baixa latência) a um pool existente. Isto acelera leituras aleatórias sem reconfigurar os filesystems:
stratis pool add-cache dados /dev/nvme0n1
3. Snapshot antes de cada actualização
Criar um snapshot antes de dnf update ou alterações de configuração permite reverter em segundos. Automatizar com um script simples em cron:
#!/bin/bash
# Snapshot diário antes do cron de actualização
DATA=$(date +%Y%m%d-%H%M)
stratis filesystem snapshot dados partilhados "snap-partilhados-$DATA"
# Limpar snapshots com mais de 7 dias
stratis filesystem list --name dados | grep "snap-partilhados-" | \
awk -v d="$DATA" '{print $2}' | while read fs; do
# Remover snapshots antigos
stratis filesystem destroy dados "$fs"
done
4. Monitorizar a ocupação do pool
Como o provisionamento fino permite sobre-subscrição, é fundamental alertar quando o pool atinge 80% de capacidade. Um script simples integrado com o sistema de monitorização existente:
stratis pool list | \\\n awk \'NR > 1 { gsub(/[^0-9.]/, "", $3); if ($3+0 > 80) print "ALERTA: Pool acima de 80%: " $1 }\'
5. Não confiar em Stratis como única cópia de segurança
Snapshots não são cópias de segurança — residem no mesmo pool. Se o pool falhar, os snapshots também se perdem. Manter sempre uma cópia de segurança externa (disco removível, NAS remoto ou serviço de nuvem) é imprescindível.
Conclusão
O Stratis ocupa um espaço útil no ecossistema de armazenamento Linux: oferece gestão de pools, snapshots CoW, provisionamento fino e encriptação através de uma CLI que qualquer administrador aprende em minutos. Para PME que precisam de capacidades avançadas de armazenamento em servidores físicos — sem a complexidade do ZFS nem a imprevisibilidade histórica do Btrfs — é uma opção sólida, activamente mantida e suportada comercialmente pela Red Hat.
A decisão entre Stratis, ZFS e Btrfs depende do cenário concreto. Se a prioridade for integridade de dados com somas de verificação e RAID nativo, o OpenZFS continua a ser a escolha correcta. Se o objectivo for simplicidade operacional com snapshots fiáveis e gestão delegada ao daemon, o Stratis reduz a carga administrativa de forma significativa.
O projecto está em desenvolvimento activo no GitHub (stratis-storage/stratisd), com plano de desenvolvimento que inclui níveis de desempenho automáticos, expansão de pools online e melhorias na integração com systemd. Para quem já usa RHEL ou Fedora, vale a pena avaliar em ambiente de testes antes de adoptar em produção.