Criar um bucket compatível com S3

Object Storage é um lugar para guardar arquivos que não fica preso a um servidor. O disco da sua VPS existe enquanto a VPS existe; um bucket é independente dela. Você grava e lê pela rede, com a API S3, de qualquer máquina que tenha credencial.

Isso muda o tipo de problema que ele resolve bem. Imagens de um sistema, uploads de usuário, artefatos de build, dumps de banco, arquivos estáticos de um site: tudo isso cresce sem previsão e não precisa da latência de um disco local. Já o sistema de arquivos de um banco de dados em produção não é caso de bucket — banco quer disco de bloco, com latência baixa e escrita aleatória.

O que é um bucket, na prática

Um bucket é o contêiner de nível mais alto do Object Storage. Dentro dele você tem objetos, e cada objeto tem uma chave (o nome completo, como backups/2026-08/pgdump.sql.gz), o conteúdo e metadados.

O detalhe que confunde quem vem do sistema de arquivos: não existem diretórios. O keyspace é plano. A barra em backups/2026-08/pgdump.sql.gz é só um caractere na chave. As ferramentas mostram isso como se fosse pasta porque filtram por prefixo (--prefix backups/2026-08/), mas não há nada para criar ou remover antes de gravar. Escrever uma chave com barras já basta.

Consequência prática: prefixo é a sua principal ferramenta de organização e de custo de listagem. Se você jogar 400 mil objetos na raiz, qualquer ls vai ser lento e caro. Se separar por prefixo previsível — por aplicação, por data, por cliente — você lista só o pedaço que interessa.

As decisões que você toma na criação

Criar o bucket em si é rápido. O que vale pensar antes são quatro escolhas, porque duas delas são difíceis de desfazer.

1. O nome

O nome do bucket normalmente entra na URL, então trate-o como nome DNS:

Nomes também não são reaproveitáveis livremente: dentro do namespace da região, o nome é único. backups provavelmente já existe. Use algo com contexto: acme-prod-uploads, acme-prod-dbdump.

Renomear bucket não existe na API S3. Para "renomear" você copia tudo para um bucket novo e apaga o antigo. Escolha o nome pensando em conviver com ele.

2. Um bucket ou vários

A tentação é criar um bucket só e separar por prefixo. Funciona, mas junta coisas com necessidades diferentes de acesso e de retenção.

Separe em buckets diferentes quando:

• o conteúdo tem público diferente — estáticos que qualquer um lê versus dumps de banco que ninguém deve ler;
• a retenção é diferente — uploads permanentes versus backups que expiram em 30 dias;
• a credencial deve ser diferente — a aplicação web não precisa de acesso ao bucket de backup.

O último item é o mais importante. Se a aplicação for comprometida e a credencial dela alcançar o bucket de backup, você perde os dois de uma vez.

3. A região

O Object Storage da EasyOps fica no Brasil. Coloque o bucket na mesma região da VPS que mais escreve nele: latência menor e caminho de rede mais curto. Mover objetos entre regiões depois é uma cópia completa — trabalhosa e demorada em volumes grandes. Decida antes.

4. Público ou privado

O padrão certo é privado. Um bucket privado só responde a requisições assinadas com sua credencial. Se você precisar servir arquivos para o navegador de qualquer pessoa, há duas rotas:

• deixar o objeto legível publicamente — válido para CSS, JS, imagens de um site;
• manter tudo privado e gerar URLs pré-assinadas com validade curta — o certo para arquivo de cliente, nota fiscal, relatório.

O erro clássico é tornar público o bucket inteiro para resolver um caso, e junto disso expor dumps e logs. Se um bucket guarda qualquer dado de cliente, ele não fica público.

Credenciais

O acesso é por par de chaves: um access key ID e uma secret access key. O ID é identificador; a secret é senha e normalmente é exibida uma única vez, no momento em que é gerada. Guarde-a antes de fechar a aba: se você perdê-la, o caminho é gerar um novo par e descartar o antigo, porque o valor original não é recuperável.

Trate a secret como qualquer segredo de produção: fora do Git, em variável de ambiente ou gerenciador de segredos. Se o painel permitir mais de um par de chaves, use um par por aplicação. Assim você revoga um sem derrubar os outros.

Confirmar que funciona

Depois de criar o bucket e a credencial, valide pela linha de comando antes de apontar qualquer aplicação para lá. Com a AWS CLI configurada — o passo a passo está em Configurar a AWS CLI e o rclone no seu bucket — o endpoint do Object Storage entra explicitamente, porque a CLI assume a AWS por padrão:

# listar os buckets da credencial
aws s3 ls --endpoint-url "$EASYOPS_S3_ENDPOINT"

# gravar um objeto de teste
echo "ok" > /tmp/teste.txt
aws s3 cp /tmp/teste.txt s3://acme-prod-uploads/diagnostico/teste.txt \
  --endpoint-url "$EASYOPS_S3_ENDPOINT"

# ler de volta
aws s3 cp s3://acme-prod-uploads/diagnostico/teste.txt - \
  --endpoint-url "$EASYOPS_S3_ENDPOINT"

# apagar
aws s3 rm s3://acme-prod-uploads/diagnostico/teste.txt \
  --endpoint-url "$EASYOPS_S3_ENDPOINT"

Use o endpoint da sua região, informado pelo painel ao criar o bucket. Os quatro comandos exercitam listar, gravar, ler e apagar — as quatro permissões que a maioria das integrações precisa. Se ls funciona e cp retorna AccessDenied, o problema é permissão da credencial, não configuração da CLI.

Um sinal de erro comum: SignatureDoesNotMatch quase sempre é secret copiada com espaço no fim ou relógio da máquina fora de hora. Cheque date antes de procurar em outro lugar.

Onde isso encaixa

Um bucket não é backup do servidor. Ele guarda o que você mandar para ele; não captura estado de disco nem sistema. Para voltar uma VPS inteira ao ar você continua precisando de backup ou snapshot. O bucket é o destino natural de backups lógicos — dumps de banco, arquivos de aplicação — que você quer fora da máquina que os gerou.

Esse é o próximo passo prático: enviar backup de banco para um bucket, com dump comprimido e retenção. Se ainda não tem servidor gerando dados, comece por criar sua primeira VPS. Valores e franquias ficam em preços.