如果你今天不歸檔……
另有 19 種語言版本
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
第 4 個模組，共 4 個，屬於 Data Architect 課程第 7 章為規模而設計。每個模組都可以單獨閱讀。 上一篇：當資料量遇上共用模型 · 下一篇：下一章查詢與檢索架構
**本模組回答的問題：**如何規劃歸檔和清除？
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 （在新標籤頁中開啟）, Winter ‘27). ⟲
每條記錄都有生命週期
Section titled “每條記錄都有生命週期 ”我們已經問過一條記錄是怎麼建立的、歸誰所有、誰能改它、什麼是權威的。現在再加一個：**它怎麼離開？一條記錄可能從活動到非活動，到歸檔，再到清除。**並不是每條記錄都需要經歷每個階段，但每個大數據量物件都需要一個生命週期。Steve Trucking 的一次配送在進行中時一直被需要：配送小組、排程員、客服、合作夥伴、自動化都要用它。完成一週後，它仍然有用。六個月後，它主要是服務歷史。三年後，主要用於分析、稽核或偶爾的爭議。十年後，也許已經沒人有正當理由保留它了。資料的價值隨時間變化；架構也應該隨之變化。
刪除不可避免，所以在第一天就決定
Section titled “刪除不可避免，所以在第一天就決定 ”總有一天你確實需要刪除資料。所以我要求保留和清除策略在專案一開始就定下來，而不是等儲存變貴的時候。保留由業務和監管要求驅動：它要保持運營狀態多久，我們必須保留它多久，為什麼，誰可能需要它，他們需要多快拿到，它最終能不能走，隱私是否要求它更早走？第 5 章說明了永遠保留一切並不自動更安全；有時保留資料更久本身就是風險。
把三個決定分開。**保留：**我們保留它多久？**歸檔：**那些已經不屬於活動工作負載的資料，我們放在哪裡、怎麼保留？**清除：**什麼時候、怎麼永久刪除？需要七年的資料，不意味著七年都保持活動。也許是十八個月活動，然後在剩餘期間歸檔，然後清除。這樣生命週期就明確了。
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 （在新標籤頁中開啟）; Best Practices: Deleting Data （在新標籤頁中開啟）). 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. ⟲
Retain for seven years doesn’t mean keep active for seven years. ⟲
刪除之前先備份
Section titled “刪除之前先備份 ”歸檔最終意味著把記錄從活動系統中刪除，所以在設計刪除之前，我要先有恢復方案：我們能恢復嗎，多快，我們確切知道刪了什麼嗎，能恢復關係嗎，測試過嗎？**在刪除任何東西之前，先把備份做好。**備份和歸檔是不同的能力：備份防止丟失；歸檔有意把資料移出活動資料集，同時保留業務仍然需要的存取。誤刪十條記錄很煩人。誤刪一千萬條就是一次事故。「零的個數」也適用於錯誤。
現在兩者都由 Salesforce 自己提供。OwnBackup 背後的公司 Own 已經成為 Salesforce Platform 的一部分：Own Recover 現在是 Salesforce Backup & Recover（每日和按需備份資料和後設資料，在欄位、記錄或物件級別恢復，按時間點恢復），而 Archive 按照歸檔和保留策略，把很少使用的資料移到低成本儲存，同時仍可在 Salesforce 內部存取（Own From Salesforce Product Suite FAQ （在新標籤頁中開啟）；Own’s tools, now part of Salesforce （在新標籤頁中開啟））。
沒人找得到的歸檔，幾乎就是刪除
Section titled “沒人找得到的歸檔，幾乎就是刪除 ”一個團隊把舊資料移到了更便宜的地方。歸檔完成。然後一位客戶打來電話：「我四年前有一次配送，現在需要送達證明。」客服在 Salesforce 裡搜尋：什麼也沒有。現在他們需要另一個系統、正確的表、一個識別符號、一位管理員、一個申請，外加兩天時間。這算不上什麼歸檔。歸檔資料不必表現得像活動資料。它可以更慢、只讀、顯示在不同的元件裡。但歸檔資料必須按業務的要求保持可查閱。
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. ⟲
歸檔應該放在哪裡？
Section titled “歸檔應該放在哪裡？ ”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 （在新標籤頁中開啟）). 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 （在新標籤頁中開啟）). ⟲
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 （在新標籤頁中開啟）). ⟲
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 （在新標籤頁中開啟）). ⟲
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. ⟲
產品不是重點。特徵才是：資料有多少，多久被檢索一次，需要多快呈現，是否需要關係型存取，使用者是否必須從 Salesforce 裡找到它，能否只讀，誰可以看，保留多久，成本多少，以及最終怎麼清除。這些答案決定技術。還要記住：**資料物理上放在哪裡，和使用者在哪裡能發現它，是兩個不同的問題。**五年前的配送不屬於活動物件。這不意味著客服不應該能找到它。
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 （在新標籤頁中開啟）), and other archiving tools offer a dry-run mode for the same reason. Then I use three steps: ⟲
- 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. ⟲
- 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. ⟲
- 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 （在新標籤頁中開啟）). 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 （在新標籤頁中開啟）). Salesforce’s Archive app respects legal holds: records under a legal hold can’t be deleted or removed (Archive App). ⟲
Don’t cross the destructive boundary until you’ve proved the copy. ⟲
還要把它設計成可以重啟。歸檔 2,000 萬條記錄，作業在第 14,382,711 條記錄處失敗。如果答案是「從頭再來」，我就不喜歡這個設計。大型操作會失敗：連線中斷、作業超時、一條古怪的記錄丟擲錯誤。流程必須知道哪些已經成功，這正是歸檔狀態（待處理、已驗證、已歸檔、失敗）的用途，這樣它才能重啟，而不會重複資料、丟失資料，或刪除尚未安全歸檔的東西。在規模上，可重啟性是可靠性的一部分。
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
Section titled “Don’t Archive Everything Forever”歸檔可能成為逃避刪除決定的藉口。「說不定哪天會用到。」也許不會。第 5 章問的是**我們被允許保留它嗎？**這一章加上一句：**讓它保持活動有價值嗎？**有些記錄移到歸檔；有些被彙總，有些被匿名化，有些被刪除。目標不是儲存每一個位元組。而是在業務正當需要的期間，保留業務正當需要的東西。
檔案改變「零的個數」
Section titled “檔案改變「零的個數」 ”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. ⟲
歸檔仍然必須安全
Section titled “歸檔仍然必須安全 ”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. ⟲
代理程式與歸檔資料
Section titled “代理程式與歸檔資料 ”一位收貨人問代理程式：「四年前我的冰箱送到哪裡了？」答案存在，但已經歸檔了。代理程式應該能觸及它嗎？我的立場：**這是一個重大決定，而且應該由業務來做。**架構師列出選項以及每個選項的代價：哪個歸檔，代理程式如何觸及，延遲，消耗，代理程式可以就舊資料說些什麼，以及保留和隱私方面的限制。然後由業務決定。如果歸檔資料應該保持可觸及，就建一條經過授權的檢索路徑。如果不應該，就讓歸檔邊界來強制執行。我不希望的，是技術在無意中替你做了這個決定。
**考試之外：AI 改變了什麼。**歸檔現在包括一個上下文決定：歷史是否對代理程式保持可觸及。歸檔不會僅僅因為資料仍然存在，就自動成為代理程式上下文的一部分。把這個決定交給業務，然後應用與人工存取相同的授權和保留規則。
Steve Trucking：在需要之前決定生命週期
Section titled “Steve Trucking：在需要之前決定生命週期 ”按五年算：大約 **900 萬個工作訂單、1,450 萬個明細項目，**幾百萬張照片，還有我們有意放在核心之外的狀態歷史和 GPS。我不希望 Steve Trucking 等到第五年才決定「舊」是什麼意思。具體的期限現在可能還沒定；沒關係。但架構應該已經在問：一次已完成的配送保持運營狀態多久？客服必須馬上看到哪些細節？工作訂單和它們的明細項目什麼時候移到歸檔，移到哪裡？哪些歷史屬於 Snowflake？舊照片放在哪裡，什麼時候刪除？零售合作夥伴還能看到哪些歸檔記錄？代理程式能觸及已歸檔的配送嗎？這些不是清理問題。它們是架構問題。
對每一個大數據量物件，我要五個答案。**它什麼時候不再活動？它去哪裡？我們如何證明它到了那裡？之後別人怎麼找到它？它最終什麼時候被刪除？**如果你回答不了這些，你就沒有歸檔策略。你只有一個希望。
Five answers, or you have a hope. ⟲
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- 每個大數據量物件的活動、歸檔、保留和清除生命週期，在儲存或效能逼你之前就決定好。
- 在任何破壞性的歸檔或清除之前，必須先有哪些備份和恢復能力。
- 歸檔資料放在哪裡（big object、通過 Salesforce Connect 存取的外部儲存、Salesforce 的 Archive），依據是資料量、檢索、延遲、安全、成本和刪除。
- 在記錄跨越刪除邊界之前，如何驗證歸檔執行，並讓它可以重啟。
- 哪些非結構化內容放在核心之外、而它的業務記錄留在 Salesforce 中，以及歸檔資料是否對代理程式保持可觸及。
我們花了很多時間研究資料如何進入一個系統：API、匯入、整合、遷移、使用者、代理程式。也要花同樣多的時間研究它如何出去，因為我們今天建立的資料，就是明天的大數據量問題。歸檔也許三年後才開始。生命週期現在就應該存在。設計入口的時候，就設計出口。
- Trailhead, Explore Archival Versus Purge in Data Cleanup （在新標籤頁中開啟）: back up before cleaning or moving data; archive versus purge, checked 2026-11-01. ⟲
- Salesforce Help, Archive App （在新標籤頁中開啟）: 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 （在新標籤頁中開啟） (current; confirmed 2021), checked 2026-11-01. ⟲
- Industry examples of the same pattern: Oracle, Archive and Purge （在新標籤頁中開啟） (Oracle Receivables: validate, archive, then purge from the archive tables, with a restart program), and AWS Prescriptive Guidance, Archiving data from unpartitioned tables （在新標籤頁中開啟） (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 （在新標籤頁中開啟）, Deleting Data （在新標籤頁中開啟） and Best Practices: Deleting Data （在新標籤頁中開啟）, checked 2026-11-01. ⟲
- Salesforce Help, Data and File Storage Allocations （在新標籤頁中開啟）, checked 2026-11-01. ⟲
- Salesforce Help, Own From Salesforce Product Suite FAQ （在新標籤頁中開啟）, and Salesforce, Own’s tools, now part of Salesforce （在新標籤頁中開啟）, checked 2026-11-01. ⟲
- Salesforce Help, Salesforce Connect SQL Adapter for Amazon Athena （在新標籤頁中開啟）, checked 2026-11-01. ⟲
- Salesforce Help, Choose Which Salesforce Connect Adapter to Use （在新標籤頁中開啟）, checked 2026-11-01. ⟲
- Salesforce Developers, Big Objects Implementation Guide （在新標籤頁中開啟）, checked 2026-11-01. ⟲
- SteveTechArc, Salesforce Documents by Release: these guides, once a year from Winter ‘16, each with an archived copy. ⟲