RustFS no Linux: instalação por binário e Docker

Precisar de uma API compatível com S3 não significa precisar hospedar os dados na AWS. O RustFS é um servidor de armazenamento de objetos escrito em Rust: recebe requisições de aplicações e clientes S3, guarda objetos em discos sob seu controle e oferece console de administração. Neste guia, vamos instalar por binário com systemd ou Docker com Compose, proteger as credenciais e validar o caminho completo: criar bucket, enviar, baixar e conferir um arquivo.

Referência da revisão: 7 de outubro de 2026. Os exemplos fixam RustFS 1.0.1, release estável publicada em 3 de outubro de 2026. Isso não é promessa de “última versão” permanente. Consulte as notas da release antes de instalar ou atualizar.

O que é o RustFS — e o que ele não é

Apesar do nome, não é um sistema de arquivos para formatar uma partição e montar no lugar do ext4 ou XFS. A interface principal deste artigo é uma API de objetos: cada objeto tem conteúdo, chave e metadados e pertence a um bucket. Um nome como backups/servidor1/arquivo.tar é uma chave com prefixos; não cria, por si só, as mesmas operações e garantias de um diretório POSIX.

É útil para aplicações que já falam S3, ambientes de desenvolvimento, repositórios de artefatos, armazenamento de dados analíticos e destinos de backup compatíveis. Não substitua uma pasta compartilhada ou o disco de um banco de dados por um bucket sem verificar o modelo de acesso exigido pela aplicação.

O código do servidor usa a licença Apache 2.0. Hospedagem própria significa que capacidade, atualização, acesso, monitoramento e recuperação ficam sob responsabilidade do operador. A linguagem Rust é uma característica da implementação, não uma garantia de invulnerabilidade ou de desempenho no seu hardware.

Compatibilidade S3: teste a aplicação, não apenas o logotipo

“S3-compatible” não equivale a reproduzir todos os serviços e comportamentos da AWS. Consulte a matriz de compatibilidade e valide as operações que sua aplicação realmente usa: multipart upload, URLs assinadas, metadados, checksums, versionamento, políticas e exclusão.

O repositório apresenta recursos como versionamento, Object Lock, lifecycle, replicação, IAM e criptografia. A disponibilidade de um recurso não configura automaticamente uma política segura: cada um precisa de escopo, credenciais e teste de falha. Funcionalidades marcadas como preview não devem ser tratadas como contrato de produção. Veja a tabela de recursos do projeto.

Atenção ao MinIO: compatibilidade de API e compatibilidade do formato em disco são assuntos diferentes. O README consultado ainda classifica a interoperabilidade on-disk como preview, condicionada à feature rio-v2, fora do build padrão, e informa limitações com objetos criptografados pelo MinIO. Não aponte RustFS para os únicos discos de produção do MinIO como se fosse apenas trocar o executável.

Arquitetura: API, console e persistência

Nos exemplos, a API S3 atende em 127.0.0.1:9000 e o console em 127.0.0.1:9001. Aplicações usam a API; administradores usam o console. O armazenamento precisa sobreviver à substituição do executável ou container. O backup deve estar em outro domínio de falha, não em outra pasta do mesmo disco.

Este tutorial fica em SNSD. Criar várias pastas no mesmo disco não cria redundância física. O projeto também alerta que SNSD não cresce diretamente para um pool multidisco: planeje outra implantação e migração pela API S3. Consulte a seleção de topologia e o aviso sobre expansão.

Antes de instalar

• Use um host de teste Ubuntu ou Debian com systemd, sudo, Bash e arquitetura x86_64 ou ARM64.
• Reserve armazenamento persistente e espaço para objetos, versões antigas, uploads incompletos e logs.
• Confira a sincronização do relógio: autenticação assinada depende de horário correto.
• Mantenha firewall ativo. Neste primeiro estágio, não abra 9000/9001 para a internet.
• Escolha um dos caminhos. Não rode binário e Docker nas mesmas portas nem com o mesmo diretório de dados.

O guia oficial recomenda XFS e discos apresentados individualmente ao sistema para suas implantações de armazenamento; NFS não é indicado como backend. A pasta local usada aqui simplifica o laboratório, não representa um layout de produção. Não há comando de formatação neste artigo: identificar o disco errado pode destruir dados. Para hardware e cluster, siga os pré-requisitos oficiais.

uname -m
timedatectl status
df -hT
sudo ss -lntp | grep -E ':(9000|9001)\b' || true
sudo apt update
sudo apt install -y ca-certificates curl unzip openssl

Opção A: instalar pelo binário oficial

1. Baixar uma versão fixa e validar o SHA-256

O bloco abaixo seleciona o pacote musl da release 1.0.1 para x86_64 ou ARM64. Os SHA-256 foram conferidos nos artefatos oficiais dessa release. Ao mudar a versão, atualize também nome, URL e hash; não remova a validação.

Execute o bloco inteiro em Bash. Ele trabalha em uma pasta temporária exclusiva e instala o binário versionado somente se o checksum corresponder.

(
set -euo pipefail
VERSION=1.0.1
case "$(uname -m)" in
  x86_64)
    ARCH=x86_64
    SHA256=a834096dafa1f1a55825a2cdaf49d006a193978d344f2d508c2be475133738a3
    ;;
  aarch64|arm64)
    ARCH=aarch64
    SHA256=d2533e293204597416cb8d30790ea35df14cb4521633fa3574c64333141bafdf
    ;;
  *) echo "Arquitetura não coberta por esta receita"; exit 1 ;;
esac
WORK=$(mktemp -d)
trap 'rm -rf -- "$WORK"' EXIT
cd "$WORK"
FILE="rustfs-linux-${ARCH}-musl-v${VERSION}.zip"
curl --fail --location --retry 3 --output "$FILE" \
  "https://github.com/rustfs/rustfs/releases/download/${VERSION}/${FILE}"
printf '%s  %s\n' "$SHA256" "$FILE" | sha256sum --check -
unzip -q "$FILE" -d unpack
BIN=$(find unpack -type f -name rustfs -print)
test -n "$BIN" && test -f "$BIN"
sudo install -d -m 0755 /usr/local/lib/rustfs
sudo install -o root -g root -m 0755 "$BIN" \
  "/usr/local/lib/rustfs/rustfs-${VERSION}"
sudo ln -sfn "/usr/local/lib/rustfs/rustfs-${VERSION}" /usr/local/bin/rustfs
/usr/local/bin/rustfs --version
)

Se o download, checksum ou localização do executável falhar, o bloco para. Não calcule um hash novo do arquivo baixado para “corrigir” a divergência. Confira arquitetura, release e origem. O executável permanece sob controle de root; quem grava objetos não precisa poder substituí-lo.

2. Criar usuário e diretórios

Em um host novo, crie uma conta dedicada. Se ela já existir, inspecione a instalação anterior em vez de repetir a receita às cegas.

sudo adduser --system --group --home /var/lib/rustfs \
  --shell /usr/sbin/nologin rustfs
sudo install -d -o rustfs -g rustfs -m 0750 /var/lib/rustfs
sudo install -d -o rustfs -g rustfs -m 0750 /var/lib/rustfs/data
sudo install -d -o rustfs -g rustfs -m 0750 /var/log/rustfs

Se os dados estiverem em um volume dedicado, monte-o antes de criar o diretório final, confira com findmnt e acrescente à unidade uma dependência do ponto de montagem. Caso contrário, o serviço pode gravar no disco raiz quando a montagem falhar. Não execute chown -R sobre uma árvore que contenha dados de outros serviços.

3. Gerar credenciais sem senha padrão

Os nomes documentados são RUSTFS_ACCESS_KEY e RUSTFS_SECRET_KEY. Não confunda com uma conta IAM da AWS: essas credenciais pertencem ao seu RustFS. O valor padrão público rustfsadmin não deve ser usado. A access key abaixo usa hexadecimal maiúsculo; não contém a barra que quebraria o escopo de assinatura SigV4. Referência de credenciais.

Este comando falha se o arquivo já existir, para não substituir silenciosamente as chaves de uma instalação anterior:

sudo bash -euo pipefail <<'ROOT'
test ! -e /etc/default/rustfs
umask 077
{
  printf 'RUSTFS_ACCESS_KEY=%s\n' "$(openssl rand -hex 10 | tr 'a-f' 'A-F')"
  printf 'RUSTFS_SECRET_KEY=%s\n' "$(openssl rand -hex 32)"
  cat <<'ENV'
RUSTFS_ADDRESS=127.0.0.1:9000
RUSTFS_CONSOLE_ADDRESS=127.0.0.1:9001
RUSTFS_CONSOLE_ENABLE=true
RUSTFS_OBS_LOGGER_LEVEL=info
RUSTFS_OBS_LOG_DIRECTORY=/var/log/rustfs
ENV
} > /etc/default/rustfs
chmod 600 /etc/default/rustfs
ROOT

Abra com sudoedit /etc/default/rustfs e guarde as credenciais no cofre da equipe. Não publique o arquivo nem copie sua saída para tickets. Nesta unidade, o systemd lê o arquivo protegido e entrega o ambiente ao processo; o usuário do serviço não precisa ler diretamente um arquivo root-only.

4. Criar o serviço systemd

A unidade abaixo é uma adaptação para nó único, usuário não root e diretórios explícitos. Type=simple indica início do processo, não prontidão da API; a prontidão será verificada separadamente. Para uma introdução às unidades e logs, veja nosso guia de systemd.

sudo tee /etc/systemd/system/rustfs.service > /dev/null <<'EOF'
[Unit]
Description=RustFS Object Storage
Documentation=https://docs.rustfs.com/en/
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=rustfs
Group=rustfs
WorkingDirectory=/var/lib/rustfs
EnvironmentFile=/etc/default/rustfs
ExecStart=/usr/local/bin/rustfs /var/lib/rustfs/data
Restart=on-failure
RestartSec=5
TimeoutStopSec=120
LimitNOFILE=1048576
UMask=0027
NoNewPrivileges=true
PrivateTmp=true
ProtectHome=true
ProtectSystem=full
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
EOF
sudo systemd-analyze verify /etc/systemd/system/rustfs.service
sudo systemctl daemon-reload
sudo systemctl enable --now rustfs
sudo systemctl status rustfs --no-pager
sudo journalctl -u rustfs -n 80 --no-pager

Além do journal, a configuração direciona logs do aplicativo a /var/log/rustfs; inclua esse caminho na política de retenção de logs. Se a unidade reiniciar repetidamente, pare-a e corrija o erro: reinício automático não resolve permissão negada, porta ocupada ou volume ausente.

Opção B: instalar com Docker e Compose

Este é um caminho alternativo, não uma continuação da opção A. Use Docker Engine atualizado e o plugin Compose. Confirme docker version e docker compose version; se faltarem, siga a instalação oficial. O usuário precisa de acesso ao daemon, privilégio que deve ser tratado como administrativo.

O exemplo fixa a tag rustfs/rustfs:1.0.1, persiste dados e logs em volumes nomeados e publica só em loopback. No container, o processo precisa escutar na interface interna, não em 127.0.0.1: quem restringe o acesso no host é o mapeamento das portas.

1. Criar o projeto e o arquivo de credenciais

umask 077
PROJECT=$(mktemp -d "$HOME/rustfs-lab.XXXXXX")
cd "$PROJECT"
printf '%s\n' "Projeto criado em: $PROJECT"
{
  printf 'RUSTFS_ACCESS_KEY=%s\n' "$(openssl rand -hex 10 | tr 'a-f' 'A-F')"
  printf 'RUSTFS_SECRET_KEY=%s\n' "$(openssl rand -hex 32)"
} > rustfs.env
chmod 600 rustfs.env
printf '%s\n' 'rustfs.env' '.env' > .gitignore

Guarde esse caminho: os comandos de Compose precisam ser executados nele. Abra rustfs.env localmente para cadastrar as credenciais no cofre. Arquivo de ambiente não é criptografia; usuários com acesso ao daemon podem inspecionar o ambiente do container. Em uma operação mais sensível, avalie a injeção por arquivos RUSTFS_ACCESS_KEY_FILE e RUSTFS_SECRET_KEY_FILE, com permissões adequadas.

2. Salvar o Compose

Crie o arquivo compose.yaml com este conteúdo:

name: linuxpro-rustfs-lab
services:
  rustfs:
    image: rustfs/rustfs:1.0.1
    restart: unless-stopped
    env_file:
      - ./rustfs.env
    environment:
      RUSTFS_ADDRESS: ":9000"
      RUSTFS_CONSOLE_ADDRESS: ":9001"
      RUSTFS_CONSOLE_ENABLE: "true"
      RUSTFS_OBS_LOGGER_LEVEL: "info"
      RUSTFS_OBS_LOG_DIRECTORY: "/logs"
    command: ["/data"]
    ports:
      - "127.0.0.1:9000:9000"
      - "127.0.0.1:9001:9001"
    volumes:
      - rustfs-data:/data
      - rustfs-logs:/logs
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    stop_grace_period: 2m
    healthcheck:
      test: ["CMD", "curl", "-fsS", "http://127.0.0.1:9000/health/ready"]
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 60s
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
volumes:
  rustfs-data:
  rustfs-logs:

Os intervalos, limite de logs do Docker e tempo de parada são escolhas deste laboratório, não garantias de dimensionamento. A rotação acima limita stdout/stderr do Docker; não limita automaticamente os arquivos gravados em /logs. Nomeie outro projeto se linuxpro-rustfs-lab já existir, para não reutilizar volumes por acidente.

3. Subir e conferir a imagem

docker compose config --quiet
docker compose pull
docker image inspect rustfs/rustfs:1.0.1 --format '{{index .RepoDigests 0}}'
docker compose up -d
docker compose ps
docker compose logs --tail=80 rustfs

Use config --quiet para validar sem imprimir credenciais resolvidas. Registre o digest e, se precisar reproduzir exatamente a implantação, substitua a referência de imagem pelo digest homologado. Um healthcheck unhealthy não faz o Docker reiniciar automaticamente um processo que continua rodando: precisa haver monitoramento e uma ação definida.

O Dockerfile da versão usa UID/GID 10001, cria os diretórios e inclui curl. Volumes nomeados novos herdam a preparação da imagem; se preferir bind mounts, prepare apenas os diretórios dedicados:

sudo install -d -o 10001 -g 10001 -m 0750 /srv/rustfs-lab/data
sudo install -d -o 10001 -g 10001 -m 0750 /srv/rustfs-lab/logs

Nesse caso, substitua as origens dos volumes no Compose por esses caminhos. Não misture os dois modelos numa instalação com dados sem plano de migração. Em Docker rootless, user namespaces ou SELinux, a correspondência de UID e rótulos exige adaptação; não resolva com chmod 777. Referência: RustFS com Docker.

Validar a API, o console e o acesso remoto

A partir do próprio host, use os endpoints documentados:

curl --fail --silent --show-error http://127.0.0.1:9000/health/live
curl --fail --silent --show-error http://127.0.0.1:9000/health/ready
curl --fail --silent --show-error http://127.0.0.1:9001/rustfs/console/health
sudo ss -lntp | grep -E ':(9000|9001)\b'

Liveness verifica o processo; readiness verifica dependências necessárias e pode retornar 503. Nenhum dos dois comprova que seu usuário consegue gravar um objeto. Abra http://127.0.0.1:9001/rustfs/console/ e entre com as credenciais geradas. A API S3 usa 9000; enviar um cliente S3 para 9001 é um erro de endpoint. Referência de portas e health checks.

Se o servidor for remoto, mantenha as portas fechadas e abra um túnel a partir do seu computador, substituindo usuário e host. As portas locais precisam estar livres:

ssh -N -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:9000:127.0.0.1:9000 \
  -L 127.0.0.1:9001:127.0.0.1:9001 usuario@servidor

Com o túnel aberto, navegador e cliente S3 no seu computador usam os mesmos endereços locais. Isso é adequado à administração e homologação, não substitui o endpoint HTTPS que aplicações remotas precisarão usar. Para Docker, também confira docker compose ps e os mapeamentos publicados: nem todo modo de rede aparece como um processo ouvinte em ss.

Teste S3: criar bucket, enviar e conferir o download

Instale a AWS CLI v2 pelo procedimento oficial e confira aws --version. Usá-la como cliente do RustFS não exige criar uma conta AWS. Para não misturar credenciais com perfis existentes, abra um terminal novo e use arquivos de configuração isolados:

umask 077
CLIENT_DIR=$(mktemp -d "$HOME/rustfs-client.XXXXXX")
export AWS_CONFIG_FILE="$CLIENT_DIR/config"
export AWS_SHARED_CREDENTIALS_FILE="$CLIENT_DIR/credentials"
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE
unset AWS_DEFAULT_PROFILE AWS_ENDPOINT_URL AWS_ENDPOINT_URL_S3
unset AWS_ROLE_ARN AWS_WEB_IDENTITY_TOKEN_FILE
aws configure --profile rustfs-lab
aws configure set s3.addressing_style path --profile rustfs-lab

Informe a access key e secret key do RustFS nos prompts, região us-east-1 e formato json. O endpoint explícito abaixo aponta ao RustFS local, não à AWS. Use a credencial administrativa apenas neste bootstrap controlado; para a aplicação real, crie uma identidade limitada conforme a próxima seção. Arquivos e perfis da AWS CLI.

cd "$CLIENT_DIR"
export AWS_PAGER=""
ENDPOINT=http://127.0.0.1:9000
BUCKET="linuxpro-lab-$(date +%s)"
printf 'Teste RustFS LinuxPro\n' > original.txt

aws --profile rustfs-lab --endpoint-url "$ENDPOINT" s3api create-bucket \
  --bucket "$BUCKET"
aws --profile rustfs-lab --endpoint-url "$ENDPOINT" s3api put-object \
  --bucket "$BUCKET" --key teste/original.txt --body original.txt
aws --profile rustfs-lab --endpoint-url "$ENDPOINT" s3api get-object \
  --bucket "$BUCKET" --key teste/original.txt recebido.txt
sha256sum original.txt recebido.txt
cmp original.txt recebido.txt && echo "Conteúdo idêntico"

O resultado esperado é a mensagem Conteúdo idêntico e hashes iguais. Isso comprova o conteúdo desse objeto no fluxo testado, não a compatibilidade completa do servidor. Não use ETag como sinônimo universal de MD5: multipart e criptografia podem mudar sua interpretação. Referências: create-bucket, put-object e get-object.

Reinicie apenas a instalação escolhida: sudo systemctl restart rustfs ou, na pasta do projeto, docker compose restart rustfs. Aguarde readiness e repita o GET e o cmp. Para validar persistência de container, execute depois uma recriação controlada com docker compose up -d --force-recreate, preservando os volumes, e repita a leitura.

Quando terminar, remova somente o objeto e bucket deste teste, que não habilitou versionamento:

aws --profile rustfs-lab --endpoint-url "$ENDPOINT" s3api delete-object \
  --bucket "$BUCKET" --key teste/original.txt
aws --profile rustfs-lab --endpoint-url "$ENDPOINT" s3api delete-bucket \
  --bucket "$BUCKET"

Feche o terminal de teste para descartar as variáveis. Os arquivos de credenciais permanecem no diretório impresso/criado; remova-os deliberadamente quando não forem mais necessários e revogue as credenciais de teste. Nunca faça uma limpeza recursiva de um bucket real para reproduzir o exemplo.

Não use a credencial root na aplicação

No console, crie um usuário dedicado, uma política e, quando adequado, uma service account. A política de exemplo abaixo permite listar e manipular objetos somente no bucket linuxpro-app. Crie esse bucket administrativamente antes. O nome do recurso é ilustrativo e precisa coincidir com o bucket real.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetBucketLocation"],
      "Resource": ["arn:aws:s3:::linuxpro-app"]
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": ["arn:aws:s3:::linuxpro-app/*"]
    }
  ]
}

É um ponto de partida para operações simples, não uma política universal: multipart, versionamento ou outras funcionalidades podem exigir ações adicionais. Retire exclusão se a aplicação não precisar dela. Anexe a política ao usuário apropriado e teste também uma operação proibida, como ler outro bucket. Policies de service accounts restringem a identidade pai; não concedem automaticamente privilégios que o pai não tem. IAM e políticas do RustFS.

TLS antes de abrir a API à rede

HTTP no loopback atende ao laboratório; aplicações remotas devem usar HTTPS. O RustFS documenta TLS nativo com RUSTFS_TLS_PATH e dois arquivos PEM chamados rustfs_cert.pem e rustfs_key.pem. O certificado precisa ser válido para o DNS usado pelos clientes, com cadeia confiável. Não use --no-verify-ssl como solução permanente. Configuração TLS oficial.

Para o binário, obtenha primeiro o certificado conforme a política da organização. Copie-o para um diretório dedicado, com a chave legível pelo serviço e não por todos os usuários:

sudo install -d -o root -g rustfs -m 0750 /etc/rustfs/tls
sudo install -o root -g rustfs -m 0640 /CAMINHO/fullchain.pem \
  /etc/rustfs/tls/rustfs_cert.pem
sudo install -o root -g rustfs -m 0640 /CAMINHO/privkey.pem \
  /etc/rustfs/tls/rustfs_key.pem
sudoedit /etc/default/rustfs

Substitua /CAMINHO pelos arquivos reais. Acrescente RUSTFS_TLS_PATH=/etc/rustfs/tls. Se clientes remotos forem necessários, altere o bind da API para o IP da interface privada escolhida e libere essa porta apenas para as redes autorizadas. O console pode permanecer no loopback. Reinicie e teste HTTPS com o hostname do certificado. A renovação precisa atualizar os arquivos copiados e incluir reinício controlado; renovar o certificado original não atualiza automaticamente essa cópia.

No Docker, monte o diretório de certificados como somente leitura e configure RUSTFS_TLS_PATH para o caminho interno. Garanta leitura ao UID/GID 10001 sem tornar a chave pública. O TLS nativo afeta ambos os listeners: altere também URLs de clientes e o healthcheck para HTTPS, usando hostname compatível com o certificado e a CA correta. Não mantenha o healthcheck HTTP mostrado no laboratório depois de habilitar TLS.

Se preferir proxy reverso, use um hostname dedicado à API e preserve Host, caminho e parâmetros assinados. Não acrescente um prefixo arbitrário como /s3/: isso pode invalidar assinaturas. Limites de upload, timeouts e streaming precisam ser homologados com objetos reais, inclusive multipart. Console e API têm políticas de exposição distintas.

Versionamento, retenção e backup são camadas diferentes

• Versionamento: ajuda a recuperar versões anteriores, mas aumenta consumo e exige política para versões antigas.
• Lifecycle: automatiza expiração ou transição; uma regra errada também automatiza exclusão indesejada.
• Object Lock: acrescenta restrições de retenção; planeje cuidadosamente antes de aplicar a dados que depois precisarão ser removidos.
• Replicação: pode copiar também erros lógicos, dependendo da configuração. Não a trate automaticamente como backup independente.
• Backup: precisa de destino separado, credenciais protegidas e restauração ensaiada, incluindo configurações e chaves necessárias à leitura.

Não copie apenas arquivos visíveis do diretório interno com o serviço escrevendo e suponha que isso forma um snapshot consistente. Para portabilidade, use ferramentas S3 e verifique o que elas preservam: versões, delete markers, políticas, retenção e metadados não acompanham necessariamente uma simples cópia de objetos.

O guia de rclone ajuda no planejamento. Faça primeiro inventário e cópia não destrutiva; sync pode apagar o que só existe no destino. Para migração, mantenha a origem intacta até validar a aplicação, a contagem, o conteúdo e o procedimento de retorno.

Operação: saúde, capacidade e atualização

Monitore o armazenamento como um serviço de dados: espaço livre, crescimento, erros de I/O, latência e erros da API, falhas de autenticação, uploads incompletos e validade do certificado. Em cluster, acrescente quorum, discos indisponíveis, healing e replicação. Saúde do processo não é sinônimo de capacidade de gravação. O cliente oficial rc complementa console e APIs para inspeção administrativa.

Para telemetria centralizada, veja OpenObserve: logs, métricas e traces. Se o objetivo for usar RustFS como armazenamento do OpenObserve, consulte o guia do servidor dedicado. São papéis diferentes: RustFS guarda objetos; OpenObserve interpreta e consulta telemetria.

Antes de atualizar, leia a release, registre versão e digest, faça backup e teste restauração. Na opção binário, instale o executável novo ao lado do anterior, pare o serviço, troque o link e valide readiness e um teste S3. Na opção Docker, altere a imagem no Compose, faça pull e recrie preservando volumes. Um nó único terá interrupção de serviço.

Rollback não é só guardar o executável anterior. Se a atualização mudar estado persistido, voltar o binário pode não ser suportado. Confirme compatibilidade nas notas e mantenha um caminho de restauração. Não improvise atualização rolling em cluster sem compreender quorum e esperar cada nó voltar pronto. Procedimentos oficiais de atualização.

Problemas comuns e como investigar

Se houver erro de integridade, pare de fazer mudanças exploratórias nos discos e preserve logs e cópias de recuperação. Apagar metadados internos para “forçar o start” pode piorar o problema.

Parar o laboratório sem destruir os objetos

Na opção binário, sudo systemctl stop rustfs para o processo e preserva dados e configuração. Na opção Docker, entre na pasta do projeto e execute:

docker compose down

Sem -v, os volumes nomeados permanecem. Não use docker compose down -v, docker volume prune ou exclusão do diretório como rotina de atualização. Essas operações podem destruir a persistência. O cleanup de dados só deve ocorrer após conferir o ambiente e decidir explicitamente que ele é descartável.

Checklist antes de pensar em produção

• Versão e checksum/digest registrados; processo sem root.
• Credenciais padrão removidas e identidade de aplicação restrita.
• API e console com exposição deliberada; TLS validado sem bypass.
• Discos e volumes persistentes identificados e monitorados.
• Upload, download, checksum e leitura após reinício aprovados.
• Backup independente e restauração ensaiada.
• Retenção, versões antigas, multipart e capacidade contabilizados.
• Limites de compatibilidade testados com a aplicação real.
• Topologia compatível com os requisitos de disponibilidade.

O melhor começo é pequeno, mas verificável: uma versão fixa, um bucket, um objeto conferido e uma recuperação que funciona. Depois amplie a carga e a arquitetura com evidências — não porque “S3-compatible” ou “escrito em Rust” substitui planejamento.

Fontes oficiais

• RustFS: projeto e proposta
• Código, recursos e limites conhecidos
• Documentação e instalação
• Release 1.0.1
• Instalação SNSD
• Docker
• Status e health checks
• TLS
• Atualizações