Wenn Sie heute nicht archivieren …

🌐 Auch in 19 Sprachen

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

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen Dieser Abschnitt hat sich im Englischen geändert und wurde noch nicht neu übersetzt. (42)

Modul 4 von 4 im Kapitel Für Skalierung entwerfen, Kapitel 7 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Wenn Volumen auf das Freigabemodell trifft · Weiter: das nächste Kapitel, Architektur für Abfragen und Abruf

Die Frage, die dieses Modul beantwortet: Wie planen Sie Archivierung und Bereinigung?

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 (öffnet in einem neuen Tab), Winter ‘27). ⟲

Jeder Datensatz hat einen Lebenszyklus

Wir haben gefragt, wie ein Datensatz entsteht, wem er gehört, wer ihn ändern darf, was maßgeblich ist. Jetzt noch eine Frage: Wie verlässt er das System? Ein Datensatz kann von aktiv zu inaktiv zu archiviert zu bereinigt wandern. Nicht jeder Datensatz braucht jede Stufe, aber jedes Objekt mit hohem Volumen braucht einen Lebenszyklus. Eine Lieferung von Steve Trucking wird ständig gebraucht, solange sie läuft: von der Crew, der Koordination, dem Kundenservice, dem Partner, der Automatisierung. Eine Woche nach dem Abschluss ist sie noch nützlich. Sechs Monate später ist sie vor allem Servicehistorie. Drei Jahre später vor allem Analytik, Audit oder der gelegentliche Streitfall. Zehn Jahre später hat vielleicht niemand mehr einen legitimen Grund, sie überhaupt zu behalten. Der Wert von Daten ändert sich mit der Zeit; die Architektur sollte sich mit ihm ändern.

Löschen ist unvermeidlich, also entscheiden Sie es am ersten Tag

Irgendwann müssen Sie Daten löschen. Deshalb will ich Aufbewahrungs- und Bereinigungsrichtlinien, die zu Beginn des Projekts festgelegt werden, nicht erst, wenn Speicher teuer wird. Aufbewahrung wird von geschäftlichen und regulatorischen Anforderungen bestimmt: Wie lange muss es operativ bleiben, wie lange müssen wir es behalten, warum, wer könnte es brauchen, wie schnell muss er es bekommen, darf es irgendwann weg, und sagt der Datenschutz, dass es früher weg sollte? Kapitel 5 hat gezeigt, dass alles für immer zu behalten nicht automatisch sicherer ist; manchmal ist das längere Behalten von Daten das Risiko.

Halten Sie drei Entscheidungen auseinander. Aufbewahrung: Wie lange behalten wir es? Archivierung: Wo und wie behalten wir, was nicht mehr in die aktive Arbeitslast gehört? Bereinigung: Wann und wie wird es endgültig entfernt? Sieben Jahre Daten zu brauchen heißt nicht, sieben Jahre aktiv. Vielleicht achtzehn Monate aktiv, dann für den Rest der Frist archiviert, dann bereinigt. Jetzt ist der Lebenszyklus ausdrücklich.

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 (öffnet in einem neuen Tab); Best Practices: Deleting Data (öffnet in einem neuen Tab)). 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. ⟲

Zum Vergrößern klicken

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

Sichern Sie, bevor Sie löschen

Archivieren heißt irgendwann, Datensätze aus dem aktiven System zu entfernen. Bevor ich das Löschen entwerfe, will ich also die Geschichte der Wiederherstellung kennen: Können wir wiederherstellen, wie schnell, wissen wir genau, was weg ist, können wir die Beziehungen wiederherstellen, haben wir es getestet? Sicherungen stehen, bevor irgendetwas gelöscht wird. Sicherung und Archiv sind unterschiedliche Fähigkeiten: Eine Sicherung schützt vor Verlust; ein Archiv verschiebt Daten bewusst aus dem aktiven Bestand und erhält den Zugriff, den das Geschäft noch braucht. Zehn Datensätze versehentlich zu löschen ist ärgerlich. Zehn Millionen zu löschen ist ein Vorfall. Die Anzahl der Nullen gilt auch für Fehler.

Beides kommt inzwischen von Salesforce selbst. Own, das Unternehmen hinter OwnBackup, ist Teil der Salesforce Platform: Own Recover heißt jetzt Salesforce Backup & Recover (tägliche und bedarfsweise Sicherungen von Daten und Metadaten, Wiederherstellung auf Feld-, Datensatz- oder Objektebene, Wiederherstellung zu einem Zeitpunkt), und Archive verschiebt selten genutzte Daten in günstigen Speicher und hält sie innerhalb von Salesforce zugänglich, nach Archivierungs- und Aufbewahrungsrichtlinien (Own From Salesforce Product Suite FAQ (öffnet in einem neuen Tab); Own’s tools, now part of Salesforce (öffnet in einem neuen Tab)).

Ein Archiv, das niemand findet, ist fast eine Löschung

Ein Team verschiebt alte Daten an einen günstigeren Ort. Archivierung abgeschlossen. Dann ruft eine Kundin an: „Ich hatte vor vier Jahren eine Lieferung und brauche den Liefernachweis.“ Der Service sucht in Salesforce: nichts. Jetzt braucht er ein anderes System, die richtige Tabelle, eine Kennung, eine Administratorin, einen Antrag, zwei Tage. Das ist kaum ein Archiv. Archivierte Daten müssen sich nicht wie aktive Daten verhalten. Sie dürfen langsamer sein, schreibgeschützt, in einer anderen Komponente angezeigt. Aber archivierte Daten müssen auffindbar bleiben, wie das Geschäft es verlangt.

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. ⟲

Wo soll das Archiv liegen?

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 (öffnet in einem neuen Tab)). 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 (öffnet in einem neuen Tab)). ⟲

Zum Vergrößern klicken

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 (öffnet in einem neuen Tab)). ⟲

Zum Vergrößern klicken

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 (öffnet in einem neuen Tab)). ⟲

Zum Vergrößern klicken

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. ⟲

Das Produkt ist nicht die Lektion. Die Eigenschaften sind es: wie viele Daten, wie oft sie abgerufen werden, wie schnell sie erscheinen müssen, ob sie relationalen Zugriff brauchen, ob Benutzer sie aus Salesforce heraus finden müssen, ob sie schreibgeschützt sein können, wer sie sehen darf, wie lange sie aufbewahrt werden, was sie kosten und wie sie schließlich bereinigt werden. Diese Antworten wählen die Technologie. Und denken Sie daran: Wo Daten physisch liegen und wo ein Benutzer sie entdecken kann, sind verschiedene Fragen. Die fünf Jahre alte Lieferung gehört nicht in das aktive Objekt. Das heißt nicht, dass der Kundenservice sie nicht finden können sollte.

Die Archivierung in drei Schritten

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 (öffnet in einem neuen Tab)), 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 (öffnet in einem neuen Tab)). 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 (öffnet in einem neuen Tab)). Salesforce’s Archive app respects legal holds: records under a legal hold can’t be deleted or removed (Archive App). ⟲

Zum Vergrößern klicken

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

Und entwerfen Sie es so, dass es neu starten kann. Sie archivieren 20 Millionen Datensätze, und der Job schlägt bei Datensatz 14.382.711 fehl. Wenn die Antwort „von vorn anfangen“ lautet, gefällt mir der Entwurf nicht. Große Operationen scheitern: Verbindungen brechen ab, Jobs laufen in Zeitüberschreitungen, ein seltsamer Datensatz wirft einen Fehler. Der Prozess muss wissen, was bereits gelungen ist, und genau dafür sind die Archivzustände da (ausstehend, überprüft, archiviert, fehlgeschlagen), damit er neu starten kann, ohne Daten zu duplizieren, Daten zu verlieren oder etwas zu löschen, das nicht sicher archiviert wurde. Im großen Maßstab ist Neustartfähigkeit Teil der Zuverlässigkeit.

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

Archivierung kann zur Ausrede werden, die Entscheidung zum Löschen zu vermeiden. „Vielleicht brauchen wir es eines Tages.“ Vielleicht nicht. Kapitel 5 fragt: Dürfen wir es behalten? Dieses Kapitel ergänzt: Hat es einen Wert, es aktiv zu halten? Manche Datensätze wandern in ein Archiv; manche werden zusammengefasst, manche anonymisiert, manche gelöscht. Das Ziel ist nicht, jedes Byte zu bewahren. Es ist, zu behalten, was das Geschäft legitimerweise braucht, so lange es das legitimerweise braucht.

Dateien verändern die Anzahl der Nullen

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. ⟲

Das Archiv muss trotzdem sicher sein

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. ⟲

Agenten und archivierte Daten

Ein Empfänger fragt einen Agenten: „Wohin wurde mein Kühlschrank vor vier Jahren geliefert?“ Die Antwort existiert, aber sie ist archiviert. Soll der Agent sie erreichen können? Meine Position: Das ist eine bedeutende Entscheidung, und sie liegt beim Geschäft. Die Architektur legt die Optionen dar und was jede kostet: welches Archiv, wie ein Agent es erreicht, die Latenz, der Verbrauch, was ein Agent über alte Daten sagen darf, und die Grenzen von Aufbewahrung und Datenschutz. Dann entscheidet das Geschäft. Wenn archivierte Daten erreichbar bleiben sollen, bauen Sie einen autorisierten Abrufweg. Wenn nicht, lassen Sie die Archivgrenze das durchsetzen. Was ich nicht will, ist, dass die Technologie die Entscheidung aus Versehen trifft.

Über die Prüfung hinaus: Was KI ändert. Archivierung umfasst jetzt eine Kontextentscheidung: ob die Historie für Agenten erreichbar bleibt. Ein Archiv ist nicht automatisch Teil des Kontexts eines Agenten, nur weil die Daten noch existieren. Legen Sie die Entscheidung dem Geschäft vor und wenden Sie dann dieselben Autorisierungs- und Aufbewahrungsregeln an wie beim Zugriff durch Menschen.

Steve Trucking: Den Lebenszyklus festlegen, bevor wir ihn brauchen

Nach fünf Jahren: rund 9 Millionen Arbeitsaufträge, 14,5 Millionen Positionen, Millionen Fotos, dazu die Statushistorie und die GPS-Daten, die wir bewusst außerhalb des Core gehalten haben. Ich will nicht, dass Steve Trucking bis zum fünften Jahr wartet, um festzulegen, was „alt“ bedeutet. Die genauen Fristen stehen vielleicht noch nicht fest; das ist in Ordnung. Aber die Architektur sollte schon fragen: Wie lange bleibt eine abgeschlossene Lieferung operativ? Welche Details muss der Kundenservice sofort sehen? Wann wandern Arbeitsaufträge und ihre Positionen ins Archiv, und wohin? Welche Historie gehört nach Snowflake? Wo liegen alte Fotos, und wann werden sie gelöscht? Welche archivierten Datensätze sehen Handelspartner noch? Kann ein Agent archivierte Lieferungen erreichen? Das sind keine Aufräumfragen. Das sind Architekturfragen.

Für jedes Objekt mit hohem Volumen will ich fünf Antworten. Wann hört es auf, aktiv zu sein? Wohin geht es? Wie beweisen wir, dass es dort angekommen ist? Wie findet es jemand danach? Wann wird es endgültig gelöscht? Wenn Sie diese nicht beantworten können, haben Sie keine Archivierungsstrategie. Sie haben eine Hoffnung.

Zum Vergrößern klicken

Five answers, or you have a hope. ⟲

Was Architekt:innen hier entscheiden

• Der aktive, archivierte, aufbewahrte und bereinigte Lebenszyklus jedes Objekts mit hohem Volumen, festgelegt, bevor Speicher oder Leistung ihn erzwingen.
• Welche Sicherung und Wiederherstellung vor jeder zerstörerischen Archivierung oder Bereinigung stehen müssen.
• Wo archivierte Daten liegen (Big Objects, ein externer Speicher über Salesforce Connect, das Archive von Salesforce), nach Volumen, Abruf, Latenz, Sicherheit, Kosten und Löschung.
• Wie Archivierungsläufe überprüft und neustartfähig gemacht werden, bevor Datensätze die Löschgrenze überschreiten.
• Welche unstrukturierten Inhalte außerhalb des Core liegen, während ihr geschäftlicher Datensatz in Salesforce bleibt, und ob archivierte Daten für Agenten erreichbar bleiben.

Wir verbringen viel Zeit damit, wie Daten in ein System gelangen: APIs, Importe, Integrationen, Migrationen, Benutzer, Agenten. Verbringen Sie genauso viel Zeit damit, wie sie wieder hinausgelangen, denn die Daten, die wir heute erzeugen, sind das Problem mit großen Datenvolumen von morgen. Die Archivierung beginnt vielleicht erst in drei Jahren. Der Lebenszyklus sollte jetzt existieren. Entwerfen Sie den Ausgang, wenn Sie den Eingang entwerfen.

Weiterlesen

• Trailhead, Explore Archival Versus Purge in Data Cleanup (öffnet in einem neuen Tab): back up before cleaning or moving data; archive versus purge, checked 2026-11-01. ⟲
• Salesforce Help, Archive App (öffnet in einem neuen Tab): 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 (öffnet in einem neuen Tab) (current; confirmed 2021), checked 2026-11-01. ⟲
• Industry examples of the same pattern: Oracle, Archive and Purge (öffnet in einem neuen Tab) (Oracle Receivables: validate, archive, then purge from the archive tables, with a restart program), and AWS Prescriptive Guidance, Archiving data from unpartitioned tables (öffnet in einem neuen Tab) (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 (öffnet in einem neuen Tab), Deleting Data (öffnet in einem neuen Tab) and Best Practices: Deleting Data (öffnet in einem neuen Tab), checked 2026-11-01. ⟲
• Salesforce Help, Data and File Storage Allocations (öffnet in einem neuen Tab), checked 2026-11-01. ⟲
• Salesforce Help, Own From Salesforce Product Suite FAQ (öffnet in einem neuen Tab), and Salesforce, Own’s tools, now part of Salesforce (öffnet in einem neuen Tab), checked 2026-11-01. ⟲
• Salesforce Help, Salesforce Connect SQL Adapter for Amazon Athena (öffnet in einem neuen Tab), checked 2026-11-01. ⟲
• Salesforce Help, Choose Which Salesforce Connect Adapter to Use (öffnet in einem neuen Tab), checked 2026-11-01. ⟲
• Salesforce Developers, Big Objects Implementation Guide (öffnet in einem neuen Tab), checked 2026-11-01. ⟲
• SteveTechArc, Salesforce Documents by Release: these guides, once a year from Winter ‘16, each with an archived copy. ⟲