Preço lido hoje na página oficial dos dois. O estado do nosso backup foi medido pela API da Backblaze, não estimado. Latência e velocidade de restauração foram cronometradas do nosso servidor em São Paulo.
Backup e imagens do CRM têm perfil de acesso oposto. O backup grava muito e quase nunca lê. As imagens do CRM gravam pouco e são lidas o dia inteiro. Somar os dois numa conta só é o jeito mais rápido de escolher errado.
Se você parar de ler aqui, já dá pra decidir. O resto é a conta e a prova.
Fica na Backblaze B2, do jeito que está.
Custa R$ 0,15 por mês hoje e não passa de R$ 6,60 nem no cenário mais pessimista de doze meses. O R2 faria a mesma coisa por mais que o dobro do preço por giga e, o que pesa muito mais, não tem chave só de escrita. Trocar seria pagar mais caro pra perder a única coisa que fez a gente escolher a B2 lá atrás.
Só que a proteção que a gente acha que tem não está ligada. Três coisas pra arrumar, todas dentro da B2, todas de graça. Estão na seção dos achados.
Vai pro Cloudflare R2, e a razão não é preço.
Nesse volume os dois custam zero, e vão continuar custando zero por bastante tempo. O que separa é medida de rede: do nosso servidor em São Paulo, o primeiro byte da Cloudflare chega em 48 ms e o da B2 em 425 ms. Isso é sentido em cada foto que abre. Some a isso egress sem franquia e sem teto, cache no Brasil com uma caixinha marcada e o AdvisorZ já ter a camada de storage pronta pra receber outro provedor.
Um detalhe pesa mais que tudo isso junto e você precisa saber: hoje os arquivos do advisorx estão abertos na internet. Testei. Está na seção do CRM.
Não vale. O ganho de unificar seria uma fatura a menos e um painel a menos, e isso custa quase nada. O preço de unificar é alto dos dois lados: jogar o backup no R2 entrega a chave de leitura de tudo que a gente tem pra qualquer um que roube a credencial do servidor, e jogar as imagens na B2 põe cada leitura de ficha atravessando o continente e amarra a operação numa franquia que é uma razão, não um número fixo.
Cada carga fica onde é melhor. Duas credenciais, duas faturas que somadas não chegam a R$ 20 por mês.
Mesmo tipo de produto, uso invertido. Isso é o eixo de tudo que vem depois.
Laranja é Backblaze B2, azul é Cloudflare R2. Onde uma seção inteira vem de uma cor só, é porque aquela demanda tem um vencedor claro. Não é decoração, é a resposta.
Lido hoje, 06/09/2026, na página de preço da própria empresa. Link e horário no fim da página. Preço muda, então trate esta tabela como uma foto de hoje.
A B2 está anunciando $6,95 por TB hoje. O número que a casa vinha usando, $6,00 por TB, é de uma tabela antiga. A diferença é pequena aqui porque o volume é pequeno, mas quem for calcular terabyte precisa usar o valor de hoje.
R$ 5,13 por dólar. É a PTAX de venda do Banco Central de 04/09/2026, o último fechamento disponível. Câmbio mexe todo dia, então trate todo valor em real como aproximado. Se o dólar for pra R$ 6,00, some 17% em cima de tudo, e nenhuma decisão desta página muda por causa disso.
Tudo desta seção saiu da API nativa da Backblaze e do cronômetro, hoje. Nada aqui é estimativa.
| Primeiro arquivo do bucket | 04/06/2026, 20h00 |
| Versão corrente | 11,449 GB · 60.711 objetos |
| Todas as versões, que é o que a B2 cobra | 14,097 GB · 68.891 entradas |
| Peso morto de versões antigas | 2,648 GB · 3.209 marcadores |
| Última rodada do cron | 06/09, 03h08 · 492 s · sem falha |
| Frequência real do backup | 1x por dia, 03h00 BRT |
Ajuste no que a gente vinha repetindo: o cron roda uma vez por dia, não de 3 em 3 horas. Está no crontab como 0 6 * * *, que é 03h00 no nosso fuso. E cada rodada não são 112 MB, são cerca de 145 MB só nos dumps de banco, mais a sincronia dos diretórios.
Em gigabytes gravados. Julho é o mês em que a sincronia dos diretórios entrou e subiu 56 mil objetos de uma vez. Agosto fechou em 4,13 GB. Setembro está em 2,98 GB com 6 dias, o que projeta perto de 15 GB no mês se o ritmo continuar. É a faixa que uso nos cenários abaixo: de 4 a 15 GB por mês.
| Momento | No bucket | B2 | R2 |
|---|---|---|---|
| Hoje, medido | 14,1 GB | R$ 0,15 | R$ 0,32 |
| 6 meses no ritmo de agosto | 38,7 GB | R$ 1,02 | R$ 2,21 |
| 6 meses no ritmo de setembro | 104,1 GB | R$ 3,36 | R$ 7,24 |
| 12 meses no ritmo de agosto | 63,3 GB | R$ 1,90 | R$ 4,10 |
| 12 meses no ritmo de setembro | 194,1 GB | R$ 6,56 | R$ 14,17 |
Operação não entra na conta em nenhum dos dois. Na B2 gravar, ler e listar são grátis por política. No R2, a sincronia diária faz algo perto de 26 mil operações de classe A por mês, e a franquia é de 1 milhão. Nenhum dos dois cobra por isso no nosso volume.
Se o backup crescer, quanto fica. Preço de tabela dos dois, câmbio de R$ 5,13.
Backup só tem um dia importante, que é o dia em que você precisa dele. Tudo que interessa é: alguém consegue destruir, e quanto tempo leva pra voltar.
| Proteção | Backblaze B2 | Cloudflare R2 |
|---|---|---|
| Chave só de escrita | Tem | Não tem |
A B2 monta a chave escolhendo capacidade por capacidade: dá pra pedir writeFiles sem readFiles e sem deleteFiles. O R2 só oferece quatro níveis prontos, e o menos poderoso que grava é "Objeto: ler e gravar", que também apaga e lê tudo. | ||
| Chave amarrada a um pedaço do bucket | Por prefixo de nome | Só por bucket inteiro |
| Chave com prazo de validade | Até 1.000 dias | Tem |
| Imutabilidade contra ransomware | Object Lock, modo governança ou conformidade | Bucket lock, até mil regras |
| Os dois travam apagar e sobrescrever por um prazo. A B2 separa governança, que um administrador consegue derrubar, de conformidade, que ninguém derruba. A documentação do R2 não faz essa separação. | ||
| Versionamento | Ligado por padrão, sempre | Ligado por padrão |
| Poda automática de versão velha | Regra de ciclo de vida | Regra de ciclo de vida |
| Custo de restaurar tudo | R$ 0 | R$ 0 |
| Aqui a franquia da B2 é generosa justamente pra backup: ela dá 3x o que você guarda, e uma restauração completa consome no máximo 1x. Só passaria da franquia quem baixasse o acervo inteiro três vezes no mesmo mês. | ||
Baixei do bucket, do nosso servidor, com a rede de hoje:
No ritmo medido, puxar os 11,4 GB inteiros do bucket levaria perto de 20 minutos. Restaurar só os bancos, que é o cenário real de emergência, leva 15 segundos de download. Isso responde a pergunta que só importa no pior dia: a B2 não é o gargalo.
Não estava no pedido, mas apareceu enquanto eu media o bucket pra fazer a conta. Nenhum deles é motivo pra trocar de provedor. Todos são de graça pra arrumar e valem mais que a diferença de preço da página inteira.
A gente vem repetindo que "o servidor escreve mas não apaga". Hoje isso não é verdade. Perguntei pra própria API da Backblaze o que a chave que está no servidor pode fazer, e ela respondeu com a lista completa:
writeFiles, readFiles e deleteFiles: grava, lê e apaga qualquer arquivo do bucket.writeBuckets e writeBucketLifecycleRules: muda a configuração do bucket.shareFiles: gera link de download pra fora.Quem entrar no servidor lê o backup inteiro e depois apaga. E não é descuido de quem criou a chave: o próprio backup.sh precisa de deleteFiles, porque a etapa 5 aplica a retenção com rclone delete. A regra de retenção do jeito que está escrita obriga a chave a ser poderosa.
E é aqui que o R2 perde a discussão de segurança sem apelação: no R2 não existe chave só de escrita. A menos poderosa que grava também lê e apaga. O que a gente tem hoje na B2 por acidente, no R2 seria o teto do que dá pra fazer.
O bucket está com a lista de regras de ciclo de vida vazia. Como a B2 guarda toda versão de todo arquivo, e o rclone sync apenas esconde o que sumiu do servidor em vez de apagar, o lixo fica lá pra sempre.
O tamanho disso agora: 2,648 GB de versões escondidas e 3.209 marcadores. É 19% do bucket, e a fração cresce todo mês. A retenção de 30 dias que a gente acha que tem está apagando o que o rclone enxerga, e o rclone não enxerga versão antiga.
A API devolveu isClientAuthorizedToRead: false pra configuração de trava do bucket, ou seja a chave não tem permissão de ler esse campo. O valor voltou nulo, o que sugere que está desligado, mas sugerir não é saber. Precisa abrir o painel da Backblaze e olhar.
Na mesma leitura veio que a criptografia padrão do bucket está sem algoritmo definido, ou seja o SSE do lado da B2 não está configurado.
daysFromUploadingToHiding: 30 e daysFromHidingToDeleting: 1 no prefixo db/daily/, e só daysFromHidingToDeleting: 7 no resto. A B2 poda sozinha, do lado dela, e os 2,6 GB de lixo somem.rclone delete do scriptbackup.sh perde a razão de existir. E é ela que obriga a chave a ter poder de apagar.writeFiles e listFiles apenas: grava, não lê, não apaga. Outra completa, guardada fora do servidor, usada só na restauração. Quem invadir o servidor consegue no máximo sujar o bucket com arquivo novo, e nunca ler nem destruir o que já está lá.Custo disso: zero em dinheiro. Umas duas horas de trabalho, quase tudo em configuração de bucket. Me dá o play e eu faço.
Fui atrás do que existe de verdade hoje, nos três lugares onde a casa guarda arquivo de cliente, antes de projetar qualquer coisa.
| Onde | Tamanho | Arquivos | Média |
|---|---|---|---|
| advisorx legado, no compartilhado imagens, planilhas, documentos de aprovação | 720 MB | 2.955 | 250 KB |
| crm-summit, na VPS mídia que o cliente manda no WhatsApp | 167,6 MB | 595 | 288 KB |
| bancada-30, na VPS antecessor do crm-summit, congelado em 19/08 | 337,1 MB | 378 | 913 KB |
| AdvisorZ, na VPS a camada de storage existe, o balde está vazio | 0 | 0 | nenhum |
Percentis do que está ativo: o menor arquivo tem 164 bytes, a mediana é 383 KB, 90% cabem em 568 KB e o maior tem 3,22 MB. Arquivo pequeno em quantidade grande, que é o perfil em que operação pesa mais que armazenamento.
Somando os dois lugares onde entra arquivo de cliente de verdade, bancada-30 com 337,1 MB e crm-summit com 167,6 MB, dá 504,7 MB. Um é a continuação do outro, os dois juntos cobrem o período que você descreveu. O número que você deu de cabeça estava certo.
Detalhe que muda a projeção: os 720 MB do advisorx legado não são desses dois meses. São de três anos, e estão praticamente parados: 125 arquivos em novembro de 2025, 19 em agosto de 2026. O legado morreu. Quem cresce é a mídia de WhatsApp.
Você projeta crescimento com 20 usuários. Eu não sei quantas pessoas operam o CRM hoje, então não invento o multiplicador: deixo ele à vista e você ajusta.
| Arquivos novos no crm-summit | 141 em 6 dias |
| Tamanho médio medido | 288,5 KB |
| Entrada hoje | ~204 MB por mês |
| Mais o legado, que quase não anda | ~5 MB por mês |
| Total de hoje | ~210 MB por mês |
A conta pra frente é 210 MB x (20 ÷ N), onde N é quantas pessoas usam o CRM hoje. Se hoje são 2 pessoas, 20 usuários multiplicam por 10 e dão 2,1 GB por mês. Se são 4, multiplicam por 5 e dão 1,05 GB. Se são 8, multiplicam por 2,5 e dão 525 MB. Nas tabelas abaixo trabalho com 4 pessoas hoje, ou seja 5 vezes mais. Suposição Me diga o número e eu refaço em dois minutos.
| Momento | Acervo | B2 | R2 |
|---|---|---|---|
| Hoje | 0,89 GB | R$ 0 | R$ 0 |
| 6 meses com 20 usuários | 7,2 GB | R$ 0 | R$ 0 |
| 12 meses com 20 usuários | 13,5 GB | R$ 0,13 | R$ 0,27 |
Nos dois primeiros momentos o acervo inteiro cabe nos 10 GB de franquia grátis que os dois dão. Não é desconto de novato, é franquia permanente. Leitura, gravação e saída também ficam dentro das franquias em todos os três cenários, nos dois provedores. Preço não decide esta demanda. Não é que decide pouco: não decide nada.
Mexa nos três controles e veja a conta se refazer. Se estourar a franquia de saída da B2, eu aviso aqui embaixo.
A Backblaze não tem data center na América do Sul. Os deles ficam na Califórnia, no Arizona, na Virgínia, em Amsterdã e em Toronto. Não é escolha nossa, é o mapa deles. A Cloudflare termina a conexão na borda de São Paulo e o pedido segue pela rede interna dela.
Dá pra pôr a B2 atrás da Cloudflare, e existe um acordo entre as duas empresas que zera o custo de saída nesse caminho. Com o arquivo já em cache na borda de São Paulo, a segunda leitura em diante fica igual: perto de 50 ms nos dois.
A diferença sobra em três lugares que não somem: a primeira leitura de cada arquivo, que atravessa o continente de qualquer jeito, toda gravação, porque upload nunca é servido de cache, e o trabalho de montar isso. No R2 é uma caixinha de domínio próprio no painel. Na B2, como o bucket é privado, é preciso um Worker assinando cada pedido, e isso vira código nosso pra manter.
Preço empatou em zero e latência já foi. Sobram estes.
| O que precisamos | Backblaze B2 | Cloudflare R2 |
|---|---|---|
| Egress | Grátis até 3x o guardado, depois $0,01/GB. Ilimitado se passar pela Cloudflare. | Zero, sem franquia e sem teto. |
| Link temporário assinado | Sim. Autorização de download com validade de até 7 dias, e dá pra amarrar num prefixo de nome. Também aceita link assinado no padrão S3. | Sim, link assinado no padrão S3. E dá pra proteger o domínio próprio com WAF e com o Access. |
| CORS | Regra por bucket. | Regra por bucket. |
| Upload direto do navegador | Sim, com link assinado. | Sim, com link assinado, e dá pra pôr um Worker no caminho pra validar antes de aceitar. |
| Servir por domínio nosso com cache no Brasil | Só com um Worker nosso assinando cada pedido, porque o bucket é privado. | Uma caixinha no painel. O cache da Cloudflare entra junto. |
| Tamanho máximo de arquivo | Não apurei o teto exato. Não apurei | 5 TiB por objeto, 5 GiB por envio de uma vez, uma escrita por segundo no mesmo nome. |
| Encaixe no que já temos | Já está montado e provado no backup, com o único remote do rclone configurado. | O AdvisorZ já tem a camada pronta pra receber outro provedor, e o próprio .env.example dele cita o R2. |
O teto de tamanho não muda nada na prática: o maior arquivo que temos hoje tem 3,22 MB e o AdvisorZ já corta em 10 MB por arquivo, com lista fechada de tipos aceitos. Nenhum dos dois provedores chega perto de ser o limite.
São três caminhos diferentes e eles não têm o mesmo custo de mudar:
open(), sem camada nenhuma no meio. Mover ele pra armazenamento de objeto é reforma de verdade, não é trocar uma variável.move_uploaded_file na pasta pública. Não vale reformar um sistema que está sendo substituído.Os arquivos que os clientes mandaram pro advisorx são servidos direto da pasta pública do site, sem nenhuma autenticação. Peguei o nome de um arquivo real e baixei ele com um comando simples, sem sessão e sem login: voltou 200 e a imagem inteira. Listar a pasta dá erro, então a única coisa protegendo é o nome do arquivo ser um md5 difícil de adivinhar.
Isso é o mesmo padrão das 980 fotos expostas que a gente já tinha registrado. E é exatamente o problema que armazenamento de objeto com bucket privado e link assinado com validade resolve de nascença, nos dois provedores. Ou seja: a mudança que você está avaliando por causa de custo tem um benefício maior do lado da segurança, e ele vale mais que a conta inteira desta página.
Perguntei se os arquivos precisam abrir direto pro cliente ou se só a equipe vê por dentro do sistema. Não travei esperando, então tratei os dois casos. Ela muda o peso, não a escolha.
A leitura fica amarrada em 20 pessoas trabalhando em horário comercial. Nesse mundo, a franquia de saída da B2 nunca aperta: pra estourar, cada uma das 20 pessoas teria que abrir mais de 300 arquivos por dia, todo dia útil. Não acontece.
Aí o R2 ganha por conforto, não por necessidade: o domínio próprio com cache é uma caixinha marcada em vez de um Worker escrito à mão, e a tela pinta mais rápido pra quem está atendendo. A diferença é de qualidade de trabalho, e a decisão continua sendo a mesma.
Muda de figura. Um link mandado no WhatsApp é buscado por todo mundo que abre a conversa, e ainda pelo robô que gera a pré-visualização. A leitura para de acompanhar o tamanho do acervo, e é exatamente aí que a franquia da B2 aperta, porque ela é uma razão sobre o que você guarda: acervo pequeno com muita leitura é o pior caso dela.
Some a isso o cliente sendo quem espera a página abrir, com 425 ms de rede antes de qualquer byte. E que link pra cliente precisa de validade curta, de bucket privado e de poder cortar acesso depois. Nesse mundo o R2 deixa de ser conforto e vira o certo.
Em nenhum dos dois casos eu mudaria a resposta. Se for só interno, o R2 ganha por margem confortável. Se o cliente abre direto, ganha sem discussão. Por isso mandei a análise em vez de segurar esperando você responder.
A resposta ainda importa, mas pra outra decisão: quanto tempo o link fica válido e se o arquivo passa por uma checagem de permissão antes de ser entregue. Isso é desenho de sistema, não escolha de provedor.
Você pediu o limiar. Aqui está, com a conta aberta.
Recomendo trocar em uma das duas demandas. Aqui está o que cada mudança custa de trabalho e de risco.
backup.sh, mais uma restauração de teste pra provar que voltou inteiro. Chuto 4 horas de trabalho.O que a página de preço não conta na primeira leitura.
rclone sync não apaga, esconde. A versão continua ocupando espaço e sendo cobrada. Quem olha a listagem normal não vê e acha que a retenção funcionou.r2.dev tem limite de taxa e a própria documentação diz que não serve pra produção. Domínio próprio não é opcional.Buracos honestos. Nenhum deles muda a recomendação, mas você precisa saber que existem.
Tudo lido em 06/09/2026. Câmbio de 04/09/2026, que é o último fechamento do Banco Central.
curl do nosso servidor, três tentativas por endereço.du e contagem por extensão nos três lugares.