Se não arquiva hoje…

🌐 Também em 19 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

Imagem gerada com IA

Traduzido com IA. Ainda não revisto pela comunidade. Ler em inglês Esta secção mudou em inglês e ainda não foi traduzida de novo. (42)

Módulo 4 de 4 do capítulo Projetar para a escala, capítulo 7 do curso Data Architect. Cada módulo sustenta-se sozinho. Anterior: O volume encontra o modelo de partilha · Próximo: o próximo capítulo, Arquitetura de consulta e recuperação

A pergunta que este módulo responde: Como planeia o arquivamento e o expurgo?

When somebody tells me “we’ll archive the old records later,” I ask one question: if you’re not archiving today, are you ever going to archive? “Later” often becomes after the next release, after the migration, after the reorganization, after we fix performance, after we run out of storage. Then five years on, someone finally asks why there are 80 million records in this object. I don’t want to discover archiving after large data volume has become the problem. If I know the data will grow, I decide its lifecycle when I design it. Salesforce’s own guide says the same: “if your volume of data is increasing, performance can degrade as time goes by. A policy of archiving or discarding data at the same rate at which it comes into the system can prevent this effect” (Best Practices for Deployments with Large Data Volumes (abre num novo separador), Winter ‘27). ⟲

Cada registo tem um ciclo de vida

Já perguntamos como um registo é criado, quem é o dono, quem pode alterá-lo, o que tem a autoridade. Agora, mais uma: como ele sai? Um registo pode passar de ativo a inativo, a arquivado e a expurgado. Nem todo o registo precisa de todas as etapas, mas cada objeto de alto volume precisa de um ciclo de vida. Uma entrega da Steve Trucking é necessária o tempo cada enquanto está em andamento: pela equipa, pelo coordenador, pelo atendimento ao cliente, pelo parceiro, pela automação. Uma semana depois de concluída, ainda é útil. Seis meses depois, é sobretudo histórico de serviço. Três anos depois, sobretudo análise, auditoria ou uma eventual disputa. Dez anos depois, talvez ninguém tenha mais um motivo legítimo para guardá-la. O valor dos dados muda com o tempo; a arquitetura deveria mudar junto.

A eliminação é inevitável, então decida-a no primeiro dia

Algum dia vai precisar de eliminar dados. Por isso quero as políticas de retenção e expurgo definidas no início do projeto, não quando o armazenamento ficar caro. A retenção é ditada pelos requisitos de negócio e regulatórios: por quanto tempo precisa de continuar operacional, por quanto tempo precisamos guardá-la e porquê, quem pode precisar dela, com que rapidez precisa obtê-la, ela pode sair algum dia, e a privacidade diz que deveria sair antes? O capítulo 5 mostrou que guardar tudo para sempre não é automaticamente mais seguro; às vezes guardar os dados por mais tempo é o próprio risco.

Mantenha três decisões separadas. Retenção: por quanto tempo guardamos? Arquivamento: onde, e como, guardamos o que não pertence mais à carga de trabalho ativa? Expurgo: quando e como é removido para sempre? Precisar de sete anos de dados não significa sete anos ativos. Talvez sejam dezoito meses ativos, depois arquivados pelo resto do período, depois expurgados. Agora o ciclo de vida é explícito.

Purging at volume has its own mechanics, and Salesforce spells them out. Deleting a record doesn’t remove it at once: it goes to the Recycle Bin for 15 days, and while it’s there it “still affects database performance because the data is still resident, and deleted records have to be excluded from any queries.” For a purge of a million records or more, Salesforce’s advice is the hard delete option of Bulk API 2.0, which skips the Recycle Bin, and when records have many children, to delete the children first (Deleting Data (abre num novo separador); Best Practices: Deleting Data (abre num novo separador)). A purge is a data operation like any other at scale: plan it, run it in batches, and check it. ⟲

Test knowledge. Know how to purge at volume: soft-deleted records stay in the Recycle Bin for 15 days and still slow queries; for a million records or more, use Bulk API 2.0 hard delete; delete children before parents. ⟲

Clique para ampliar

Retain for seven years doesn’t mean keep active for seven years. ⟲

Faça backup antes de eliminar

Arquivar acaba a significar remover registos do sistema ativo, então, antes de projetar a eliminação, quero a história da recuperação: conseguimos recuperar, com que rapidez, sabemos exatamente o que saiu, conseguimos restaurar as relações, já testamos? Os backups vêm antes de qualquer eliminação. Backup e arquivo são capacidades diferentes: um backup protege contra perdas; um arquivo tira deliberadamente os dados da população ativa, a manter o acesso de que o negócio ainda precisa. Eliminar dez registos por engano é aborrecido. Eliminar dez milhões é um incidente. O Número de Zeros vale para os erros também.

Os dois agora vêm do próprio Salesforce. A Own, empresa por trás do OwnBackup, faz parte da Salesforce Platform: o Own Recover agora é o Salesforce Backup & Recover (backups diários e sob demanda de dados e metadados, restauração em nível de campo, registo ou objeto, recuperação para um ponto no tempo), e o Archive move dados pouco usados para um armazenamento de baixo custo, mantendo-os acessíveis de dentro do Salesforce, segundo políticas de arquivamento e retenção (Own From Salesforce Product Suite FAQ (abre num novo separador); Own’s tools, now part of Salesforce (abre num novo separador)).

Um arquivo que ninguém encontra é quase uma eliminação

Uma equipa move os dados antigos para um lugar mais barato. Arquivamento concluído. Aí um cliente liga: “Recebi uma entrega há quatro anos e preciso do comprovante de entrega”. O agente pesquisa no Salesforce: nada. Agora precisa de outro sistema, da tabela certa, de um identificador, de um administrador, de uma solicitação, de dois dias. Isso não é grande coisa como arquivo. Os dados arquivados não precisam de se comportar como os dados ativos. Podem ser mais lentos, somente leitura, exibidos num componente diferente. Mas os dados arquivados precisam de continuar encontráveis, como o negócio exige.

I’ve seen this done well at a service chain. At the very beginning of the project they told me, “We only do a hundred appointments a day at a store.” A hundred, no big deal. But they had a thousand stores, open six days a week. Do the quick math: that’s about 31 million appointments a year. Then they created two appointment records for every visit, one at the front office and one at the back, so 62 million. And they needed five years: over 300 million records. I could see large data volume coming before we’d even gone live. So right from the beginning we said: there has to be archiving before we collect a single appointment. We put the archive in big objects and built it in from the ground up. When a user searched a customer, the live appointments came first, and below them, the archived ones. The archive didn’t pretend to be active data, and nobody had to become a database administrator to find history. Active data where the operational system needs it; archived data somewhere suited to its volume; a path from the business context to both. Much better than either extreme: everything active forever, or moved somewhere nobody can find. ⟲

Onde o arquivo deve ficar?

Keeping data in core is like keeping it at the front of the office, where it’s in the way of today’s work. Somewhere in the future of any object with tens of millions of records there’s a move to the back: a box in an archive, the shed (big objects), or a hologram (virtualization, the data shown in Salesforce but living elsewhere). There’s no single answer; I choose the destination by constraint. When the customer doesn’t want an external store, I’ve used big objects: on-platform, built for very large volumes, but with no standard UI or reporting, Apex-only access and querying through the index, so plan the access path before you choose them (chapter 3’s “shed out back”). Plan the storage too: most editions are allocated storage for 1 million big object records per org, and more has to be arranged with Salesforce (Data and File Storage Allocations (abre num novo separador)). Two more facts matter for an archive. Big objects support only object and field permissions, not sharing rules, and triggers and flows don’t run on them. And inserting an identical record twice creates only one, so writes can be idempotent, which helps when an archive run has to restart (Big Objects (abre num novo separador)). ⟲

Clique para ampliar

A big object: the archive stays inside Salesforce, and you build the window users see it through. ⟲

When an external store is fine, I’ve used an off-platform database surfaced through Salesforce Connect, so archived records appear in Salesforce without being copied back. Precisely: Salesforce Connect reaches external data through OData services, other Salesforce orgs, a custom adapter built with the Apex Connector Framework, or specific adapters for Amazon DynamoDB, GraphQL and SQL (the SQL adapter supports Snowflake and Amazon Athena), so a general database usually needs an OData layer or a custom adapter in front of it (Choose Which Salesforce Connect Adapter to Use (abre num novo separador)). ⟲

Clique para ampliar

An external store: the archive leaves Salesforce, and Salesforce Connect brings it back into view. ⟲

The archive doesn’t have to be a database. It can be files in low-cost file storage, such as Amazon S3, and Salesforce Connect’s SQL adapter for Amazon Athena lets users “analyze data directly in Amazon Simple Storage Service (Amazon S3)” from Salesforce. One catch for an archive: that adapter is available “not for high-data-volume external objects,” so check what your volume needs before you choose it (Salesforce Connect SQL Adapter for Amazon Athena (abre num novo separador)). ⟲

Clique para ampliar

File storage: the same move, with files in place of a database. ⟲

And now Salesforce’s Archive is the built-in option, keeping archived records reachable from Salesforce. Third-party tools such as GRAX are in the market too. ⟲

Test knowledge. Know the archive destinations and what big objects are: built for very large volumes (consistent performance from a million records to a billion); reached through Apex, APIs and their index, not the standard UI; object and field permissions only, no sharing rules; no triggers or flows. Know the alternatives: an external store through Salesforce Connect, and Salesforce’s Archive. ⟲

O produto não é a lição. As características são: quantos dados, com que frequência são recuperados, com que rapidez precisam de aparecer, se precisam de acesso relacional, se os utilizadores precisam encontrá-los a partir do Salesforce, se podem ser somente leitura, quem pode vê-los, por quanto tempo são guardados, quanto custam e como serão expurgados no fim. Essas respostas escolhem a tecnologia. E lembre: onde os dados ficam fisicamente e onde um utilizador consegue descobri-los são perguntas diferentes. A entrega de cinco anos atrás não pertence ao objeto ativo. Isso não significa que o agente de atendimento não deva conseguir encontrá-la.

O arquivamento em três etapas

When I’m moving large volumes out of an operational system, I don’t like copy, then delete in one step. There’s too much trust in it. And before the first real run, I rehearse it: a dry run that shows which records would move, ideally in a full copy sandbox, deleting nothing. Salesforce’s Archive app lets you preview an archive policy before you publish it (Archive App (abre num novo separador)), and other archiving tools offer a dry-run mode for the same reason. Then I use three steps: ⟲

1. Copy and flag. Copy the records to the archive and mark them in the source as pending archive. Don’t delete anything yet. Now both copies exist. On the service chain, this was a batch that ran on the weekend. ⟲
2. Verify. Re-query the source and the archive and prove the archive is right: counts, identifiers, relationships, totals or other reconciliation; can we retrieve them? For extra assurance, add checksums, or restore a sample back and compare it. Then flag them as validated. Trust but verify. Users still find the records in the source, because they aren’t archived yet. ⟲
3. Delete and flip. Only after verification, and only for records that aren’t under a legal hold, delete the active records and mark the archive complete, so the search screens now pull them from the archive. The deletion doesn’t have to follow at once; it could happen a week later. ⟲

What could go wrong with one pass, copy and delete? It didn’t copy, and you’ve deleted the records. The point is that you don’t cross the destructive boundary until you’ve proved the copy. And with the states, you can report on every archive run. ⟲

This isn’t just my habit; it’s how the serious archiving tools work. Oracle’s archive and purge, for example, validates the records, copies them to archive tables, and then purges from what it archived, with a restart program for when a run fails partway (Archive and Purge (abre num novo separador)). Tools that copy and delete in a single pass come with a warning to test with a dry run first (AWS Prescriptive Guidance: Archiving data from unpartitioned tables (abre num novo separador)). Salesforce’s Archive app respects legal holds: records under a legal hold can’t be deleted or removed (Archive App). ⟲

Clique para ampliar

Don’t cross the destructive boundary until you’ve proved the copy. ⟲

E projete para poder retomar. Ao arquivar 20 milhões de registos, o job falha no registo 14.382.711. Se a resposta for “começar de novo”, não gosto do design. Operações grandes falham: conexões caem, jobs estouram o tempo, um registo esquisito gera um erro. O processo precisa de saber o que já correu bem, que é para isso que servem os estados do arquivo (pendente, verificado, arquivado, com falha), para poder retomar sem duplicar dados, perder dados ou eliminar algo que não foi arquivado com segurança. À escala, poder retomar faz parte da confiabilidade.

One more thing to know before you call a purge done: deleting the active records isn’t the same as erasing the data. Backups, caches, replicas and analytics copies may still hold it. That’s fine for an archive, and it’s exactly what chapter 5 asks you to account for when privacy law says the data must go. ⟲

Don’t Archive Everything Forever

Arquivar pode tornar-se uma desculpa para não decidir eliminar. “Pode ser que nós precise algum dia.” Talvez não. O capítulo 5 pergunta temos permissão para guardar isso? Este capítulo acrescenta há valor em mantê-lo ativo? Alguns registos vão para um arquivo; alguns são resumidos, alguns anonimizados, alguns eliminados. O objetivo não é preservar cada byte. É guardar o que o negócio precisa legitimamente, pelo tempo que precisar legitimamente.

Os arquivos mudam o Número de Zeros

Unstructured data is a different scale problem. Steve Trucking expects four to five million photos a year. Purely for magnitude, at about 4 MB a photo, five million is about 20 TB in one year, before growth. The real size will vary; the zeros tell you the binary content needs its own architecture. That’s why Checkpoint 1 separated the business record about a photo from the photo itself. Salesforce may need the photo’s type, its delivery, when and by whom it was taken, where it’s stored and its retention state, or even just a count and a “required photos complete” flag. The image belongs in storage built for millions of large objects. It’s the same principle as FleetLink’s GPS: keep in core what the operational process needs, and don’t copy every high-volume artifact into core because Salesforce takes part in the process. ⟲

O arquivo continua a precisar de ser seguro

Data leaving the active object doesn’t leave its security requirements behind. Redrock saw only Redrock’s deliveries while they were active; archive them, and Redrock still doesn’t get Keystone’s history. The archive needs an authorization model too, for Recipient personal data, photos, financial data, service history and agent access. A big-object archive doesn’t help on its own here: big objects don’t support sharing rules, so the access path you build has to carry the partner boundary. One design question for every archive: how do the original security requirements survive the move? The implementation may change; the requirement doesn’t. ⟲

Os agentes e os dados arquivados

Um destinatário pergunta a um agente: “onde a minha frigorífico foi entregue há quatro anos?”. A resposta existe, mas está arquivada. O agente deve conseguir alcançá-la? A minha posição: é uma decisão importante, e cabe ao negócio. O arquiteto apresenta as opções e o que cada uma custa: qual arquivo, como um agente chega até ele, a latência, o consumo, o que um agente pode dizer sobre dados antigos, e os limites de retenção e privacidade. Depois, o negócio decide. Se os dados arquivados devem continuar ao alcance, construa um caminho de recuperação autorizado. Se não devem, deixe que o limite do arquivo garanta isso. O que não quero é que a tecnologia tome a decisão por acidente.

Além do exame: o que a IA muda. Arquivar agora inclui uma decisão de contexto: se o histórico continua ao alcance dos agentes. Um arquivo não faz parte automaticamente do contexto de um agente só porque os dados ainda existem. Leve a decisão ao negócio e depois aplique as mesmas regras de autorização e retenção que para o acesso das pessoas.

Steve Trucking: decida o ciclo de vida antes de precisar dele

Em cinco anos: cerca de 9 milhões de ordens de trabalho, 14,5 milhões de itens de linha, milhões de fotos, e o histórico de estado e o GPS que mantivemos deliberadamente fora do núcleo. Não quero que a Steve Trucking espere o quinto ano para decidir o que “antigo” significa. Os períodos exatos podem ainda não estar definidos; tudo bem. Mas a arquitetura já deveria estar a perguntar: por quanto tempo uma entrega concluída continua operacional? Quais detalhes os agentes de atendimento precisam de ver de imediato? Quando as ordens de trabalho e os seus itens de linha vão para o arquivo, e para onde? Qual histórico pertence ao Snowflake? Onde ficam as fotos antigas, e quando são eliminadas? Quais registos arquivados os parceiros retalhistas ainda veem? Um agente pode alcançar entregas arquivadas? Não são perguntas de faxina. São perguntas de arquitetura.

Para cada objeto de alto volume, quero cinco respostas. Quando ele deixa de ser ativo? Para onde vai? Como provamos que chegou lá? Como alguém o encontra depois? Quando é eliminado de vez? Se não consegue responder, não tem uma estratégia de arquivamento. Tem uma esperança.

Clique para ampliar

Five answers, or you have a hope. ⟲

O que um arquiteto decide aqui

• O ciclo de vida ativo, arquivado, retido e expurgado de cada objeto de alto volume, decidido antes que o armazenamento ou o desempenho o imponham.
• Que backup e recuperação precisam de estar prontos antes de qualquer arquivamento ou expurgo destrutivo.
• Onde ficam os dados arquivados (big objects, um armazenamento externo pelo Salesforce Connect, o Archive do Salesforce), com base em volume, recuperação, latência, segurança, custo e eliminação.
• Como as execuções de arquivamento são verificadas e tornadas retomáveis antes que os registos cruzem a fronteira da eliminação.
• Qual conteúdo não estruturado fica fora do núcleo enquanto o seu registo de negócio fica no Salesforce, e se os dados arquivados continuam ao alcance dos agentes.

Passamos muito tempo a pensar em como os dados entram num sistema: APIs, importações, integrações, migrações, utilizadores, agentes. Passe o mesmo tempo a pensar em como eles saem, porque os dados que criamos hoje são o problema de grande volume de amanhã. O arquivamento pode só começar daqui a três anos. O ciclo de vida deveria existir agora. Projete a saída quando projetar a entrada.

Para saber mais

• Trailhead, Explore Archival Versus Purge in Data Cleanup (abre num novo separador): back up before cleaning or moving data; archive versus purge, checked 2026-11-01. ⟲
• Salesforce Help, Archive App (abre num novo separador): archive policies and preview, job sessions, Log Failures and Continue, purge policies, legal holds, Archive Search and the Archive component, checked 2026-11-01. ⟲
• ISO, ISO 15489-1:2016, Records management: Concepts and principles (abre num novo separador) (current; confirmed 2021), checked 2026-11-01. ⟲
• Industry examples of the same pattern: Oracle, Archive and Purge (abre num novo separador) (Oracle Receivables: validate, archive, then purge from the archive tables, with a restart program), and AWS Prescriptive Guidance, Archiving data from unpartitioned tables (abre num novo separador) (a one-pass archiver; test with a dry run first), checked 2026-11-01. ⟲
• Salesforce Developers, Best Practices for Deployments with Large Data Volumes (Winter ‘27): Best Practices (abre num novo separador), Deleting Data (abre num novo separador) and Best Practices: Deleting Data (abre num novo separador), checked 2026-11-01. ⟲
• Salesforce Help, Data and File Storage Allocations (abre num novo separador), checked 2026-11-01. ⟲
• Salesforce Help, Own From Salesforce Product Suite FAQ (abre num novo separador), and Salesforce, Own’s tools, now part of Salesforce (abre num novo separador), checked 2026-11-01. ⟲
• Salesforce Help, Salesforce Connect SQL Adapter for Amazon Athena (abre num novo separador), checked 2026-11-01. ⟲
• Salesforce Help, Choose Which Salesforce Connect Adapter to Use (abre num novo separador), checked 2026-11-01. ⟲
• Salesforce Developers, Big Objects Implementation Guide (abre num novo separador), checked 2026-11-01. ⟲
• SteveTechArc, Salesforce Documents by Release: these guides, once a year from Winter ‘16, each with an archived copy. ⟲