Caderno de Dúvidas

S3 (Simple Storage Service) é o serviço de object storage da AWS — e "object storage" é o conceito em si: guardar dados como objetos (blob + metadados + chave) num namespace de buckets, acessíveis via HTTP/REST, em vez de um filesystem com inodes e diretórios reais.

O modelo mental

• Bucket = container de topo, nome globalmente único (vira subdomínio: bucket.s3.amazonaws.com)
• Objeto = key (string, tipo fotos/2024/img.jpg) + value (bytes) + metadados. As barras na key são só convenção — não existe árvore de diretórios de verdade
• Objetos são imutáveis: você não faz append nem edita parte; sobrescreve o objeto inteiro (PUT atômico)
• API mínima: PUT, GET, DELETE, LIST (por prefixo), multipart upload, presigned URLs, versionamento, lifecycle

O que faz "ser S3" e não um mkdir num servidor

• Escala horizontal: dados fatiados em muitos nós, sem ponto único
• Durabilidade: replicação e/ou erasure coding — os "11 noves" de durabilidade são a medida de quão raro é perder um objeto
• Consistência: read-after-write forte hoje
• API estável: é a interface que todo mundo implementa

S3 caseiro na prática

Normalmente significa subir algo que fala a API do S3 — MinIO, Ceph RGW, SeaweedFS, Garage. Você ganha compatibilidade com SDKs, CLI (aws s3 cp), Terraform etc. Se for construir do zero, o esqueleto é: servidor HTTP com roteamento por bucket/key, metadados num DB (Postgres/SQLite), blobs no disco com sharding por hash, e replicação/erasure coding por cima pra durabilidade.

Depende do papel do dado — primário ou cópia. Como cópia única de tudo, nunca: seu disco é um ponto só. Como armazenamento principal da aplicação, o disco do server ganha em custo e latência na maioria dos casos. O que decide são quatro eixos: custo, latência, durabilidade e acesso.

Onde o disco do server ganha

• Custo bruto por TB: é o armazenamento mais barato que existe na prática. Disco de dedicado sai por poucos euros por TB (ou já vem incluso); a Storage Box da Hetzner custa €10,90 por 5 TB (~€2,2/TB) com tráfego ilimitado. Bucket: B2 $6,95/TB, Hetzner S3 ~$7,30/TB, R2 ~$15/TB, S3 Standard ~$23/TB.
• Egress: o maior custo escondido da cloud. S3 cobra $0,09/GB de saída (~$90 por TB servido) — servir arquivos pros usuários pode custar mais caro que armazená-los. No local, tráfego já incluso (dedicado e Storage Box: ilimitado).
• Latência: NVMe local responde em menos de 1 ms; bucket é um round-trip HTTP por objeto. Para muitos arquivos pequenos, thumbnails ou range requests, a diferença é brutal.
• Sem custo por operação nem rate limit: em object storage, cada PUT/GET/LIST é medido (barato, mas medido) e há throttle. No disco local não existe essa contabilidade.
• Controle: nenhuma credencial, SDK ou rede externa no caminho crítico; acesso direto ao filesystem pra debug, rsync e grep.

Onde o bucket ganha (o que o disco local não te dá)

• Durabilidade de verdade: bucket replica em ≥ 3 zonas automaticamente. Seu disco é 1 cópia em 1 prédio. RAID protege de disco morto — não de incêndio, roubo, ransomware, rm -rf ou erro humano.
• Disponibilidade gerenciada: server em manutenção, reboot ou reinstalação = arquivos fora do ar. Bucket tem SLA, versionamento e object lock (anti-ransomware) prontos.
• Escala elástica: disco enche → migração dolorosa. Bucket é efetivamente infinito.
• Acesso multi-consumidor: vários servers, apps, workers ou CDN lendo o mesmo dado é trivial via presigned URLs. No disco local, isso vira NFS/Samba ou API própria.
• Features prontas: versionamento, lifecycle, replicação cross-region, URL assinada com TTL — no local você constrói tudo na mão (ou roda MinIO).

Preços de referência (21/09/2026, sem VAT)

O padrão que resolve

Não é ou-ou — é camada:

• Disco local = primário / working set. A app roda no mesmo server: latência mínima, custo marginal zero. Quer API S3 local? Roda MinIO ali mesmo.
• Segunda cópia fora do host = obrigatória. Storage Box (barata, rsync/Borg) ou bucket S3-compatible, sincronizado com restic/rclone. Regra 3-2-1: 3 cópias, 2 mídias, 1 fora do site.
• Servir arquivo pro usuário: direto do disco local (ou CDN na frente) evita o egress caro; bucket só se precisar de escala geográfica.
• Híbrido: MinIO local + replicação assíncrona pro bucket = API S3, dados quentes no disco e uma cópia sobrevivendo fora do server.

MinIO é um servidor de object storage self-hosted que fala a API do S3 — o "S3 caseiro" mais popular que existe. Um único binário em Go; você aponta pra discos e ganha um endpoint S3 (http://seu-server:9000) com console web, versionamento e presigned URLs. Os apps continuam falando S3 com SDK/CLI — só trocam o endpoint e as credenciais.

O que ele é (e o que não é)

• É o servidor, não o cliente — implementa o protocolo S3 dentro do seu hardware
• Não é filesystem: não monta como drive, não tem lock POSIX nem append. Quem consome precisa falar S3 (SDK, aws s3, rclone)
• Roda em bare metal, Docker ou Kubernetes (tem Operator), com console web de administração

Como funciona por baixo

• Objetos são gravados em drives (diretórios). Com múltiplos discos, usa erasure coding (Reed-Solomon) + checksums anti-bitrot: os dados viram k+m blocos e sobrevivem à perda de m discos
• Modos: 1 nó/1 disco (sandbox), 1 nó/N discos, N nós/N discos (cluster distribuído com quórum)
• Metadados ficam junto dos objetos no próprio backend — sem banco externo. Simplicidade é a proposta

O que ele te dá

• API S3 de verdade: multipart upload, versionamento, object lock (WORM anti-ransomware), lifecycle, policies/IAM, presigned URLs, notificações (webhook/Kafka)
• Presigned URL: a app gera um link com validade pro cliente baixar direto do seu storage, sem expor credenciais
• Replicação entre clusters (site replication) e criptografia em repouso (SSE)

Onde encaixa no trade-off do Q2

• Ganha: API S3 (compatibilidade de SDK) + custo e latência do disco local + egress zero
• Assume: a durabilidade. Erasure coding protege de disco morto — não de incêndio, roubo ou ransomware. A cópia offsite (Storage Box/bucket) continua sendo sua responsabilidade

Pegadinhas (21/09/2026)

• Licença AGPLv3: uso interno tranquilo; oferecer como serviço derivado traz obrigações fortes
• Em junho/2025 a MinIO enxugou drasticamente o console da edição community (~110 mil linhas removidas), empurrando gestão e features pro produto comercial (AIStor). O servidor S3 segue aberto, mas confira o que está incluído antes de contar com alguma feature
• Cluster multi-nó tem regras de quórum e expansão — não é plug-and-play pra durabilidade real
• Alternativas no mesmo espaço: SeaweedFS, Garage e RustFS (Apache 2.0, drop-in) — e Ceph RGW se for parque corporativo

Na prática

docker run -d --name minio \
  -p 9000:9000 -p 9001:9001 \
  -v /srv/minio:/data \
  -e MINIO_ROOT_USER=admin \
  -e MINIO_ROOT_PASSWORD='senha-forte' \
  minio/minio server /data --console-address ":9001"

API em http://seu-server:9000 (endpoint que o SDK usa), console em http://seu-server:9001. Pra produção: rodar como serviço (systemd), TLS na frente e um cron de cópia offsite.

São duas famílias diferentes que apareceram na tabela do Q2: egress é um conceito de rede/custo, enquanto rsync, SFTP, WebDAV e Borg são formas de acessar e escrever num armazenamento remoto — por isso a Storage Box lista os quatro como "protocolos suportados".

Egress

• Em rede: é o tráfego que sai da rede de um provedor rumo à internet. O oposto é o ingress — o que entra
• Em cloud storage, virou sinônimo do custo de baixar seus próprios dados. Quase todo provedor cobra só a saída (subir é grátis), porque saída custa banda de verdade e é o que te deixa preso (lock-in)
• Números: S3 cobra $0,09/GB (~$90/TB) de saída — baixar 1 TB custa ~4× mais que armazenar 1 TB por um mês. É por isso que "egress grátis" (R2, B2 até 3× o armazenado, Storage Box ilimitado) é diferencial de peso
• Regra prática: se o dado é muito servido (fotos, vídeos, downloads), o egress domina a conta — aí é bucket com egress grátis ou servir direto do disco local

rsync — espelho incremental

• Ferramenta (e protocolo) clássica de sincronização de arquivos, roda por cima do SSH
• O pulo do gato é o delta: só as diferenças trafegam — mudou 1 MB num arquivo de 10 GB, envia ~1 MB
• Serve pra espelhar pastas inteiras, com --delete pra cópia idêntica: rsync -av --delete /var/lib/app/ box:/app/

SFTP — transferência por SSH

• SSH File Transfer Protocol: transferir arquivos pela mesma sessão segura do SSH (porta 22, mesmas chaves)
• Não confundir com FTPS (FTP + TLS) nem FTP puro — SFTP é o primo moderno e criptografado
• Uso típico: subir/baixar arquivos pontuais, com clientes gráficos (FileZilla, Cyberduck) ou scripts

WebDAV — pasta via HTTP

• Extensão do HTTP que faz um storage remoto parecer pasta de verdade (GET, PUT, DELETE, MOVE, locking)
• Uso típico: montar a Storage Box como drive de rede no Finder/Explorer — conveniência de arrastar e soltar
• Mais lento que SFTP para volume grande; brilha pra acesso casual e edição de documentos

Borg — backup versionado e cifrado

• Não é protocolo: é uma ferramenta de backup (BorgBackup) com deduplicação, compressão e criptografia no cliente
• Cada backup vira um "archive" que só guarda blocos novos — 30 dias de snapshots ocupam pouco; retenção se define com borg prune (ex: 7 diários, 4 semanais)
• Diferença chave vs rsync: rsync espelha o estado atual (cópia viva); Borg guarda histórico imutável — ransomware sobrescreveu tudo? Restaura a versão de ontem

Dois tools que vivem no fluxo de cópia/backup do server: rclone é a ponte — copia, sincroniza e monta arquivos entre storages (local, S3, Storage Box, Drive...). restic é a máquina do tempo — faz backup versionado, cifrado e deduplicado. Um move; o outro preserva.

rclone — o canivete suíço de transferência

• CLI em Go, apelidada de "rsync para cloud storage": fala 70+ backends — S3-compatible, B2, R2, Storage Box via SFTP/WebDAV, Google Drive etc.
• Você configura "remotes" com nome (rclone config) e opera tipo rclone sync /var/lib/app/ box:/app — com copy, move, check e --progress
• Extras: rclone mount (monta o remote como pasta via FUSE) e rclone serve (expõe um remote como S3/WebDAV)
• Diferença do rsync: copia o arquivo inteiro quando mudou (sem delta por blocos), mas em troca fala API de nuvem nativamente — rsync não fala S3

restic — backup com histórico, dedup e cripto

• Cada execução vira um snapshot num repositório (local, SFTP, S3, B2, R2...). Os dados são quebrados em chunks com deduplicação: só blocos novos ocupam espaço
• Sempre criptografado no cliente (a senha nunca vai pro storage) e verificável com restic check
• Restaura um arquivo, uma pasta ou o snapshot inteiro; restic mount monta os snapshots como pastas pra navegar
• Retenção declarativa: restic forget --keep-daily 7 --keep-weekly 4 --prune define o histórico e libera espaço
• É primo do Borg (Q4): os dois fazem backup dedup+cifrado com snapshots. O restic se destaca por ser binário único em Go e falar muitos backends nativamente

Quem faz o quê (pra não confundir)

• rsync: espelho incremental (delta por bloco) via SSH — cópia viva, sem histórico
• rclone: cópia/sync entre nuvens e storages variados — cópia viva, sem histórico
• restic / Borg: backup versionado com dedup e cifra — histórico imutável, restaura a versão de qualquer data

Na prática (combo no cron)

rclone sync /var/lib/app/ box:/app --progress

restic init -r sftp:box:/app-backups
restic backup -r sftp:box:/app-backups /var/lib/app
restic forget -r sftp:box:/app-backups --keep-daily 7 --keep-weekly 4 --prune

A frase não é sobre onde os bytes moram — é sobre contrato de programação. Um filesystem (ext4, APFS, NTFS) implementa a API POSIX, que os programas usam há décadas. Object storage (S3/MinIO) implementa HTTP: PUT/GET/DELETE. São modelos de I/O diferentes — e cada termo da frase vem daí.

Filesystem (POSIX): arquivo é fluxo mutável

• Edita no lugar: open, read, write em qualquer offset, seek, truncate — o arquivo é um fluxo de bytes que você altera aos pedaços
• Árvore real de diretórios, rename atômico (é o que faz o padrão "grava temp + renomeia" ser seguro), links e permissões
• Locks (flock/fcntl): dois processos coordenam "estou escrevendo, não mexe"
• mmap: mapeia o arquivo na memória; e o kernel mantém cache de página por conta própria

Object storage (S3/MinIO): objeto é blob imutável via HTTP

• Operações: PUT (grava o objeto inteiro), GET, DELETE, LIST (por prefixo de nome)
• Sem escrita parcial e sem append: não existe pwrite nem O_APPEND. Mudou 1 byte num objeto de 10 GB? Reenvia o objeto inteiro (multipart monta um objeto novo em pedaços — não anexa a um existente)
• Namespace plano: "pastas" são só prefixo da chave; renomear uma pasta = copiar cada objeto e apagar o original. Sem links
• Sem lock POSIX, sem mmap, sem page cache: cada leitura é uma requisição HTTP. O mais próximo de coordenação é escrita condicional (If-Match/ETag) e object lock — que é retenção/WORM, não lock de concorrência

Traduzindo a frase, palavra por palavra

• "Não monta como drive": não existe mount nativo. Existem pontes FUSE (s3fs, rclone mount, JuiceFS) que fingem um filesystem — mas cada operação vira request(s) HTTP, e as semânticas são aproximadas: lock vira local ao mount, rename vira copy+delete, e o "grava temp + renomeia" deixa de ser atômico. Banco de dados e apps que dependem disso corrompem
• "Sem lock POSIX": flock/fcntl não existem — dois processos (ou duas máquinas montando o mesmo bucket) não negociam acesso. A coordenação vira responsabilidade da aplicação
• "Sem append": não tem O_APPEND — log append-only vira re-upload do arquivo inteiro. Na prática, apps gravam log local ou repensam o formato

Por que isso importa na prática

• App escrito pra POSIX (editor, SQLite/Postgres, Git, qualquer legado) não "só aponta" pro bucket: ou é reescrito pro SDK S3, ou fica atrás de uma camada FUSE com ressalvas, ou continua em disco local com sync
• É por isso que o MinIO te dá endpoint HTTP, não um drive: a aplicação precisa falar S3
• Contraste: a Storage Box (Q2/Q4) é armazenamento de arquivos — por isso lista WebDAV/Samba e "usable as network drive". Object storage não tem isso nativamente
• Do outro lado: pro que object storage faz bem (backup imutável, servir arquivos via URL assinada, escalar leitura em muitos nós), o contrato POSIX nem é necessário

Sim. Licença open source é uma concessão irrevogável para as versões já publicadas: arquivar o repositório (deixar read-only) ou abandonar o projeto não retira os direitos que a licença te deu. Copyright também não expira com abandono — e "abandonware" não é um status jurídico que libera o software.

O dono não pode "des-licenciar" o passado

• Publicar sob MIT/GPL/Apache é conceder direitos de forma definitiva. O detentor pode parar de publicar e até relicenciar versões futuras — mas o que já saiu sob a licença antiga permanece sob ela
• Exemplos de relicenciamento que geraram forks: Terraform → OpenTofu, Redis → Valkey, Elasticsearch → OpenSearch — as versões antigas seguem na licença original
• Arquivar no GitHub não muda o LICENSE do repo: ele continua aplicável àquele código. Repositório read-only não revoga nada

O que você continua podendo fazer

• Usar, modificar, forkar e redistribuir aquela versão conforme a licença — MIT/Apache com atribuição; GPL/AGPL mantendo o copyleft e oferecendo a fonte
• Guardar suas cópias e disponibilizá-las sob a mesma licença — é o que a comunidade faz quando um projeto morre: OpenOffice → LibreOffice, Hudson → Jenkins

Pegadinhas

• Projeto sem LICENSE ≠ domínio público: repo abandonado sem licença é "todos os direitos reservados" — arquivado não te dá direito nenhum novo. Sem arquivo de licença, não há fork legítimo
• Marca não vai junto: licenças OSS concedem código, não trademark (a Apache 2.0 diz isso explicitamente). O fork usa o código, não necessariamente o nome
• Copyleft continua te obrigando: quem redistribui GPL/AGPL precisa manter a fonte das modificações acessível a quem recebe — e precisa ter guardado essa fonte, porque o site original pode sair do ar
• Você pode perder a licença por violá-la: a GPLv3, por exemplo, termina os direitos automaticamente ao descumprir os termos (com reintegração se corrigir). A irrevogabilidade protege quem cumpre
• O risco real é operacional, não jurídico: sem patches de segurança, cada CVE vira sua dívida; dependências apodrecem; o ecossistema migra

Na prática, com um projeto arquivado que você usa

• Confira a licença e procure fork ativo (continuação pela comunidade) — ou assuma o fork você mesmo
• Se continuar na versão original: congele a versão, guarde a fonte (mirror/vendoring — o Software Heritage também arquiva código e licenças) e planeje fazer seus próprios patches
• Se redistribuir: cumpra atribuição/copyleft à risca