Onde ficam armazenados os dados de backup da empresa?

Quando um decisor de TI precisa responder onde ficam armazenados os dados de backup da empresa, a pergunta costuma chegar em um momento incômodo: durante uma auditoria, uma due diligence de segurança ou, pior, depois de um incidente. A resposta raramente é um endereço único. Envolve infraestrutura física, estrutura lógica e políticas de acesso que, quando desalinhadas, transformam uma cópia aparentemente protegida em um arquivo inútil na hora da restauração.

Este texto organiza essa resposta em camadas e ajuda a identificar os pontos que realmente importam para ambientes corporativos com dados sensíveis, incluindo operações financeiras e transações via Pix. O objetivo não é indicar um único formato ideal, mas dar critérios para avaliar local, nuvem e arranjos híbridos à luz de conformidade com a LGPD, exigências regulatórias do setor e metas de recuperação definidas pela própria empresa.

Ao final, você terá um roteiro para auditar fornecedores, reconhecer erros comuns — como confundir backup com sincronização — e entender por que imutabilidade e isolamento de rede pesam mais do que o volume de terabytes contratado.

O que significa "onde ficam armazenados" os dados de backup

Quando um gestor de TI pergunta onde ficam os dados de backup da empresa, a resposta nunca cabe em uma única frase. O "onde" envolve pelo menos três camadas sobrepostas: a infraestrutura física que guarda os bits, a estrutura lógica que organiza os arquivos e a camada de controle que define quem pode ler, copiar ou destruir essas informações. Ignorar qualquer uma dessas camadas leva a decisões de armazenamento que parecem seguras no papel, mas falham exatamente no momento da restauração ou de uma auditoria.

Em ambientes corporativos com dados sensíveis — como registros de transações Pix, informações cadastrais e documentos contratuais —, o local de armazenamento também é uma decisão jurídica. A LGPD não exige que o backup fique em território brasileiro, mas impõe obrigações específicas quando há transferência internacional, e o setor financeiro ainda soma regulações do Banco Central que tratam de resiliência operacional e continuidade. Entender as três camadas é o primeiro passo para auditar se a cópia de segurança realmente atende ao nível de risco assumido pela organização.

Camada física: servidor, NAS, fita, disco e data center

A camada física responde a uma pergunta concreta: em qual equipamento, dentro de qual edificação, os dados estão gravados. As opções vão de um servidor dedicado com discos locais, passando por appliances NAS (network-attached storage) e redes SAN (storage area network), até bibliotecas de fita LTO e, no caso da nuvem, data centers operados por terceiros. Cada mídia tem características distintas de durabilidade, custo por terabyte e velocidade de leitura — um disco NVMe restaura em minutos o que uma fita LTO-9 pode levar horas para localizar e montar.

O data center é o elo físico mais negligenciado. Um servidor de backup instalado no mesmo rack do servidor de produção está fisicamente exposto aos mesmos eventos: incêndio, queda de energia prolongada, falha no nobreak, acesso indevido de terceirizados. Por isso, a localização geográfica do prédio — e não apenas o tipo de equipamento — é um critério de decisão. Data centers comerciais no Brasil costumam publicar certificações como Tier III ou Tier IV do Uptime Institute, que indicam níveis de redundância de energia e refrigeração.

Camada lógica: buckets, volumes, repositórios e cofres imutáveis

Acima do hardware, a camada lógica define como os dados são organizados e endereçados dentro do sistema de armazenamento. Em nuvem, isso aparece como buckets no Amazon S3, containers no Azure Blob Storage, vaults no AWS Backup ou repositórios em soluções como Acronis e Veeam. Em ambientes locais, a camada lógica é formada por volumes, LUNs, sistemas de arquivos e diretórios de repositório. A escolha da estrutura lógica afeta diretamente a granularidade da restauração — recuperar um único e-mail de um bucket de objetos é tecnicamente diferente de restaurar um volume inteiro.

Um conceito que ganhou relevância a partir de 2023 é o cofre imutável. Trata-se de um repositório lógico configurado com object lock ou WORM (write once, read many), que impede que qualquer processo — inclusive credenciais de administrador comprometidas — altere ou apague os dados antes de um prazo definido. A imutabilidade é uma propriedade da camada lógica, mas depende de suporte na camada física e de políticas na camada de controle. Sem as três alinhadas, o cofre existe apenas como configuração nominal.

Camada de controle: quem gerencia as chaves e os acessos

A camada de controle determina quem possui as credenciais, as chaves de criptografia e os privilégios administrativos sobre o repositório. Um backup criptografado não protege contra um invasor que detém a chave; por isso, a separação de funções entre quem opera o backup e quem guarda a chave é uma prática recomendada. Em ambientes Azure, isso se materializa com Azure Key Vault e RBAC (role-based access control); em infraestrutura local, com contas de serviço segregadas e cofres de senha.

O risco mais comum nessa camada é o acúmulo de privilégios. Quando a mesma conta de administrador de domínio consegue apagar os backups, alterar a política de retenção e acessar a produção, o ransomware encontra um caminho único para destruir todas as cópias. A auditoria da camada de controle deve verificar se há autenticação multifator obrigatória, registro de eventos de deleção e um processo formal de recuperação de acesso de emergência — o chamado break glass — que não dependa de uma única pessoa.

Backup local (on-premises): onde os dados realmente ficam

Backup local significa que as cópias residem em infraestrutura própria ou alugada pela empresa, dentro de instalações sob sua responsabilidade direta ou de um data center contratado. A vantagem central é a previsibilidade: a equipe de TI sabe exatamente em qual prédio, sala e equipamento os dados estão, e não depende de conectividade com a internet para iniciar uma restauração. A desvantagem é que a empresa herda integralmente a responsabilidade por redundância, segurança física e manutenção do hardware.

Servidor de backup dedicado, NAS e SAN

O servidor de backup dedicado é a arquitetura mais simples: uma máquina com sistema operacional e software de backup, equipada com discos de alta capacidade. Ela recebe os dados dos servidores de produção pela rede local e os grava em volumes locais. O NAS cumpre função semelhante, mas é um appliance otimizado para servir arquivos via protocolos como SMB ou NFS, geralmente com menor custo de aquisição. A SAN, por sua vez, entrega blocos de armazenamento em rede de alta velocidade, como Fibre Channel ou iSCSI, e é mais comum em ambientes com bancos de dados de grande porte.

Cada opção impõe um perfil de recuperação distinto. Restaurar um servidor inteiro a partir de um NAS doméstico reconfigurado para uso corporativo pode levar dias, enquanto uma SAN com discos empresariais e rede de 10 GbE ou superior reduz esse tempo para horas. O dimensionamento correto considera não apenas a capacidade em terabytes, mas o RTO (recovery time objective) aceitável para cada sistema. Uma base de dados que processa Pix em tempo real tem RTO muito mais agressivo do que um file server de documentos antigos.

Fita LTO e cofre físico off-site

A fita LTO continua sendo a mídia mais barata por terabyte para retenção de longo prazo. A geração LTO-9, disponível desde 2021, grava até 18 TB nativos por cartucho (45 TB comprimidos). A fita tem uma propriedade que nenhum disco oferece: quando o cartucho é ejetado da biblioteca e guardado em um cofre físico fora do site principal, ele fica naturalmente desconectado da rede — um air gap físico que nenhum malware alcança.

O cofre off-site é o destino clássico dessas fitas. Empresas de médio porte costumam contratar empresas especializadas em guarda de mídias, que oferecem controle de temperatura, umidade e inventário rastreável. O ponto fraco é operacional: a rotação de fitas depende de pessoas, veículos e procedimentos manuais, e o teste de restauração a partir do cofre remoto é frequentemente adiado. Um cartucho ilegível descoberto apenas durante um desastre representa uma cópia que nunca existiu de fato.

Riscos de manter a cópia no mesmo ambiente de produção

O erro estrutural mais grave no backup local é armazenar a cópia no mesmo ambiente físico e lógico da produção. Um ataque de ransomware que compromete o domínio corporativo consegue, em minutos, localizar compartilhamentos de backup acessíveis pela rede e criptografá-los junto com os dados originais. A mesma falha vale para desastres físicos: um incêndio na sala de servidores destrói produção e backup simultaneamente.

• Credenciais de domínio com acesso simultâneo à produção e ao repositório
• Backup em disco externo conectado permanentemente via USB
• Compartilhamento de rede sem isolamento de VLAN ou firewall
• Repositório de backup no mesmo storage da produção, apenas em volume diferente

Para mitigar esse risco, a arquitetura local deve prever isolamento de rede, contas de serviço exclusivas e, idealmente, uma cópia adicional em mídia removível ou em outro prédio. A proteção contra ransomware começa exatamente por essa separação: sem isolamento, nenhuma estratégia de retenção sobrevive a um ataque direcionado.

Backup em nuvem: onde os dados ficam dentro do provedor

No backup em nuvem, a empresa contrata capacidade de armazenamento de um provedor como Microsoft Azure, AWS ou Google Cloud, e o software de backup envia as cópias pela internet ou por conexão dedicada. O "onde" deixa de ser um prédio conhecido pela equipe de TI e passa a ser uma abstração geográfica definida pelo provedor: região, zona de disponibilidade e classe de armazenamento. Essa mudança transfere a responsabilidade física para o provedor, mas não elimina a necessidade de auditoria — ela apenas muda de natureza.

Regiões, zonas de disponibilidade e replicação geográfica

Uma região de nuvem é uma área geográfica que contém pelo menos um data center físico. O Azure, por exemplo, opera a região Brazil South no estado de São Paulo e anunciou a Brazil Southeast no Rio de Janeiro; a AWS mantém a sa-east-1 em São Paulo. Dentro de uma região, as zonas de disponibilidade são data centers fisicamente separados, conectados por rede de baixa latência, projetados para que a falha de um não derrube o outro. A replicação geográfica, por sua vez, copia dados entre regiões distintas — no Azure, o GRS (geo-redundant storage) replica da região primária para uma secundária pareada, que no caso do Brazil South fica fora do Brasil.

Esse detalhe tem implicação direta para a LGPD. Um backup configurado com replicação geográfica em um provedor global pode, sem que o contratante perceba, manter cópias em data centers nos Estados Unidos ou na Europa. A escolha da redundância geográfica precisa ser consciente: dados armazenados apenas em região brasileira atendem a requisitos de soberania de forma mais simples, enquanto a replicação para fora do país exige base legal e cláusulas contratuais específicas, tema detalhado mais adiante.

Object storage, cold storage e classes de arquivamento

Dentro do provedor, os dados de backup raramente ficam em discos virtuais comuns. O padrão é o object storage — Azure Blob, Amazon S3, Google Cloud Storage —, que guarda cada arquivo como um objeto com metadados e identificador único, distribuído em múltiplos discos e servidores. Sobre essa base, os provedores oferecem classes de armazenamento com custos decrescentes conforme a frequência de acesso esperada diminui: hot, cool, cold e archive.

• Hot: acesso imediato, custo alto por GB, para backups recentes e restaurações frequentes
• Cool/Cold: acesso em minutos a horas, custo intermediário, para retenção de médio prazo
• Archive: acesso em horas, custo baixíssimo por GB, para retenção de longo prazo e conformidade
• Deep Archive (AWS) / Archive (Azure): menor custo, latência de recuperação de até 12 a 48 horas

A classe de armazenamento define não apenas o preço, mas o tempo de restauração. Um backup de compliance guardado em archive pode levar horas para ficar disponível, o que é aceitável para auditoria, mas inviável para recuperar um sistema de pagamento em produção. A escolha da classe precisa estar alinhada ao RTO de cada carga de trabalho, não apenas à planilha de custos.

Onde ficam os dados no Microsoft 365, Google Workspace e AWS Backup

Há um equívoco recorrente em achar que o Microsoft 365 "faz backup" dos dados. O Microsoft 365 replica dados entre data centers para alta disponibilidade, mas a replicação não é backup: se um usuário excluir um e-mail ou um ransomware criptografar arquivos do SharePoint, a replicação propaga a alteração para todas as cópias. Os dados do Exchange Online, OneDrive, SharePoint e Teams ficam em regiões definidas pelo locatário — para clientes brasileiros, tipicamente na região Brazil South —, mas a retenção nativa é limitada e não substitui uma solução dedicada. O tema é aprofundado em por que o Microsoft 365 não dispensa backup.

No Google Workspace, os dados de Gmail, Drive e demais serviços ficam em data centers do Google. O Google replica entre regiões para durabilidade, mas, assim como no Microsoft 365, a exclusão definitiva de um usuário remove os dados após o período de retenção padrão. Já o AWS Backup é um serviço de orquestração que centraliza backups de EC2, RDS, EBS e outros serviços, armazenando as cópias em cofres dentro da região escolhida — com opção de cofre imutável e replicação entre regiões. A localização exata dos dados em cada provedor deve constar no contrato e no painel de configuração, e não pode ser presumida.

Backup híbrido e a regra 3-2-1-1-0 na prática

A estratégia híbrida combina uma cópia local para restauração rápida com uma cópia em nuvem para sobrevivência a desastres locais. É o modelo que melhor equilibra RTO, custo e resiliência para a maioria das empresas de médio porte. A regra 3-2-1-1-0 é a evolução mais recente da clássica 3-2-1, adicionando dois requisitos que respondem diretamente ao cenário de ransomware: uma cópia imutável e zero erros de restauração verificados.

Como distribuir as cópias entre local, nuvem e off-site

A regra 3-2-1 estabelece três cópias dos dados, em dois tipos de mídia diferentes, com uma cópia fora do site. Na prática, uma configuração híbrida típica mantém a cópia primária em disco local de alto desempenho, uma segunda cópia em appliance ou NAS em outro prédio da empresa, e uma terceira em nuvem ou em fita guardada em cofre externo. A diversidade de mídias importa porque falhas de firmware, erros de configuração e ataques tendem a se propagar entre dispositivos idênticos.

A distribuição geográfica deve considerar o cenário de desastre regional. Uma enchente que atinge um data center em São Paulo pode também afetar o escritório da empresa na mesma cidade, tornando inútil uma cópia off-site a poucos quilômetros. Para dados de missão crítica, a cópia remota precisa estar em outra região metropolitana ou em outra região de nuvem, distante o suficiente para não compartilhar os mesmos riscos de infraestrutura elétrica, telecomunicações e clima.

Cópia imutável e air gap contra ransomware

A cópia imutável é o componente "1" adicional da regra 3-2-1-1-0: pelo menos uma das cópias deve ser incapaz de sofrer alteração ou exclusão durante o período de retenção definido. Em nuvem, isso se implementa com object lock no S3, immutable storage no Azure Blob ou recursos equivalentes no Google Cloud. A imutabilidade não é uma promessa de invulnerabilidade — é uma barreira técnica que impede que credenciais comprometidas destruam o backup, reduzindo de forma mensurável o impacto de um ataque.

O air gap é o conceito complementar: uma separação física ou lógica total entre a cópia e a rede de produção. A fita ejetada é o air gap físico clássico; em nuvem, um cofre imutável em conta isolada, com credenciais separadas e sem API de deleção acessível, funciona como air gap lógico. O "0" final da regra representa zero erros de restauração — ou seja, a exigência de testar periodicamente se as cópias realmente podem ser recuperadas a partir do local onde estão armazenadas. Uma solução de backup em nuvem para médias empresas só se sustenta se o teste de restore fizer parte da rotina, não do improviso.

Onde ficam os dados de backup no Brasil e por que isso importa para a LGPD

A LGPD não proíbe armazenar backup fora do Brasil, mas trata a transferência internacional como um fluxo que exige fundamento legal e salvaguardas contratuais. A localização dos dados deixou de ser detalhe técnico e virou item de auditoria.

Data centers no Brasil versus provedores internacionais

Armazenar backups em data centers no Brasil reduz a latência de restauração para equipes locais e simplifica a demonstração de conformidade com a LGPD, pois os dados permanecem sob jurisdição brasileira. Os principais provedores de nuvem mantêm regiões no país — Azure Brazil South, AWS sa-east-1 e Google Cloud São Paulo —, e há também data centers nacionais de colocation e provedores de nuvem soberana. A desvantagem histórica era o custo por gigabyte, historicamente mais alto no Brasil do que em regiões norte-americanas, embora a diferença tenha diminuído com a expansão da oferta local.

Provedores internacionais sem presença no Brasil oferecem preços agressivos, mas impõem transferência internacional automática dos dados. Nesse cenário, a empresa precisa mapear todos os países por onde o provedor replica as informações, verificar se há acordo de cooperação jurídica com o Brasil e formalizar cláusulas contratuais que garantam os direitos dos titulares. Para dados de transações Pix e informações bancárias, a avaliação de risco tende a favorecer a permanência em território nacional ou em provedores com garantias contratuais robustas.

Transferência internacional de dados e cláusulas contratuais

Quando o backup é replicado para fora do Brasil, a LGPD exige que a transferência se apoie em uma das bases legais do artigo 33 — como cláusulas contratuais específicas, normas corporativas globais ou certificações reconhecidas. Na prática, isso significa revisar o contrato do provedor de nuvem para identificar onde os dados podem ser processados e exigir aditivos que limitem a transferência às regiões autorizadas. O contrato padrão de grandes provedores costuma listar todas as regiões globais como possíveis destinos, o que exige negociação ou configuração técnica para restringir.

Além do contrato, é necessário documentar a base legal da transferência no registro de operações de tratamento de dados, item cobrado em auditorias e em incidentes de segurança. Empresas que atuam com dados financeiros devem avaliar ainda se a transferência internacional conflita com exigências do Banco Central ou de reguladores setoriais, que podem impor residência de dados para categorias específicas de informação. A orientação de uma consultoria de cibersegurança para o setor financeiro costuma incluir esse mapeamento jurídico-técnico como etapa obrigatória.

Retenção, eliminação e auditoria das cópias

A localização dos backups também afeta a capacidade de atender a pedidos de eliminação de dados. A LGPD garante ao titular o direito de solicitar a exclusão de seus dados pessoais, e esse direito se estende às cópias de segurança. Um backup em fita guardado em cofre externo não pode ser alterado seletivamente com facilidade; por isso, políticas de retenção precisam prever como os dados serão eliminados ao fim do prazo — seja pela destruição física da mídia, seja pela expiração automática de objetos em nuvem.

• Prazo de retenção definido por classe de dado e por obrigação legal
• Processo documentado de eliminação ao fim do prazo, com evidência auditável
• Registro de todas as restaurações realizadas, com data, responsável e finalidade
• Revisão periódica de acessos ao repositório de backup, incluindo contas de serviço

A auditoria das cópias fecha o ciclo: não basta saber onde os dados estão, é preciso provar quem os acessou, quando e por quê. Logs de acesso ao repositório, trilhas de auditoria do cofre imutável e relatórios de teste de restauração formam o conjunto de evidências que sustenta a conformidade diante de uma fiscalização ou de um incidente.

Como descobrir onde os backups da sua empresa estão agora

Muitas empresas descobrem a localização real dos backups apenas durante um incidente. O inventário de cópias costuma estar fragmentado entre planilhas, configurações de software legado e contratos antigos com provedores que já trocaram de nome. Um diagnóstico estruturado começa com perguntas diretas à equipe de TI e ao fornecedor, seguidas de verificação em ambiente real — não apenas em documentação.

Perguntas para fazer ao fornecedor ou à equipe de TI

1. Em quais data centers físicos e regiões de nuvem as cópias estão armazenadas hoje?
2. Existe alguma replicação automática para fora do Brasil? Para quais países?
3. Quem possui as credenciais de administrador do repositório e como elas são protegidas?
4. As chaves de criptografia ficam com a empresa ou com o provedor?
5. Qual é o prazo de retenção de cada classe de backup e o que acontece ao fim dele?
6. Quando foi o último teste de restauração completo, a partir do local real de armazenamento?
7. Qual é o custo estimado para restaurar 1 TB em um cenário de desastre?

As respostas devem ser verificadas em tela, não apenas aceitas verbalmente. Um fornecedor que afirma manter os dados no Brasil precisa demonstrar isso na configuração da conta de nuvem, no contrato e no relatório de localização de dados. Divergências entre o que foi prometido e o que está configurado são o principal sinal de alerta nesse diagnóstico.

Checklist de verificação: região, criptografia, retenção e restore

• Região de armazenamento confirmada no painel do provedor, sem replicação não documentada
• Criptografia em repouso com chave gerenciada pela empresa ou com política de acesso segregada
• Criptografia em trânsito (TLS 1.2 ou superior) em todos os caminhos de envio e restauração
• Política de retenção aplicada por classe de dado, com retenção mínima e máxima definidas
• Pelo menos uma cópia imutável ou com air gap para dados críticos
• Teste de restauração documentado nos últimos 90 dias, com tempo medido e aprovado
• Relatório de acessos administrativos ao repositório disponível para auditoria

O checklist funciona como linha de base para comparar fornecedores e para cobrar correções. Uma consultoria de segurança da informação pode executar essa verificação de forma independente, evitando que a própria equipe que configurou o backup seja a única responsável por validá-lo. A independência da auditoria importa porque erros de configuração tendem a se repetir quando verificados pelos mesmos olhos que os criaram.

Erros comuns ao escolher onde armazenar o backup

Os erros de armazenamento de backup raramente aparecem no momento da implantação. Eles se revelam meses ou anos depois, quando uma restauração falha, um custo inesperado explode o orçamento ou uma auditoria encontra cópias em locais não autorizados. Conhecer os três erros mais frequentes ajuda a evitá-los antes que se tornem incidentes.

Confundir backup com sincronização ou replicação

Sincronização e replicação copiam alterações em tempo real ou quase real, propagando também exclusões e criptografia maliciosa. O OneDrive sincronizando pastas locais, a replicação de banco de dados entre sites ou o espelhamento de volumes em storage não são backup: se um arquivo for apagado ou sequestrado, a "cópia" sincronizada reflete a perda imediatamente. Esse erro é especialmente comum em empresas que migraram para o Microsoft 365 e assumiram que a plataforma já protege os dados — um equívoco detalhado em como fazer backup de e-mails e arquivos do Microsoft 365.

O backup verdadeiro mantém versões históricas independentes do estado atual da produção. Ele permite voltar a um ponto no tempo anterior ao incidente, o que sincronização e replicação não conseguem fazer. A distinção precisa estar refletida na arquitetura: o repositório de backup não pode ser um destino de sincronização contínua, mas sim um local que recebe cópias versionadas em intervalos definidos e as preserva por um período de retenção.

Nunca testar a restauração a partir do local real de armazenamento

Um backup que nunca foi restaurado é uma hipótese, não uma proteção. O teste precisa partir do local real onde a cópia está armazenada — o cofre em nuvem, a fita no cofre externo, o appliance remoto — e não de uma cópia local de conveniência. Restaurar a partir da cópia local e assumir que a cópia remota funciona é o mesmo erro lógico de testar o freio de um carro em descida e concluir que ele funciona em subida.

Testes periódicos revelam falhas silenciosas: fitas ilegíveis, objetos de nuvem com permissão incorreta, chaves de criptografia perdidas, repositórios corrompidos. O "0" da regra 3-2-1-1-0 existe justamente para institucionalizar essa verificação.

Ignorar custo de saída (egress) e tempo de recuperação

O custo de armazenamento em nuvem é apenas uma fração do custo total de um backup. A restauração em cenário de desastre gera tráfego de saída — egress — cobrado por gigabyte pelos provedores. Restaurar 10 TB de dados da nuvem pode custar centenas ou milhares de reais apenas em egress, valor que surpreende quem nunca simulou o cenário. Provedores como AWS e Azure cobram egress para a internet pública, e os preços variam por região e por volume mensal.

O tempo de recuperação é o segundo custo oculto. Baixar grandes volumes pela internet pode levar dias, dependendo da largura de banda disponível, enquanto uma fita LTO no cofre local de outra cidade pode ser transportada em horas. A escolha do local de armazenamento precisa considerar o pior cenário: quanto tempo a empresa pode ficar sem determinado sistema e quanto custa, em egress e em horas paradas, trazer os dados de volta. Para cargas críticas, a resposta costuma ser uma combinação de cópia local para restauração rápida e nuvem para sobrevivência a desastres — exatamente a lógica do backup em nuvem para empresas bem dimensionado.