Jika Anda Tidak Mengarsipkan Hari Ini…

🌐 Juga tersedia dalam 19 bahasa

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

Gambar dibuat dengan AI

Diterjemahkan dengan AI. Belum ditinjau oleh komunitas. Baca dalam bahasa Inggris Bagian ini telah berubah dalam bahasa Inggris dan belum diterjemahkan ulang. (42)

Modul 4 dari 4 dalam bab Merancang untuk Skala, bab 7 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Ketika Volume Bertemu Model Berbagi · Berikutnya: bab berikutnya, Arsitektur Kueri dan Pengambilan Data

Pertanyaan yang dijawab modul ini: Bagaimana Anda merencanakan pengarsipan dan pembersihan data?

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 (terbuka di tab baru), Winter ‘27). ⟲

Setiap Rekaman Punya Siklus Hidup

Kita sudah bertanya bagaimana sebuah rekaman dibuat, siapa pemiliknya, siapa yang boleh mengubahnya, apa yang otoritatif. Sekarang satu lagi: bagaimana ia keluar? Sebuah rekaman bisa bergerak dari aktif ke tidak aktif, ke diarsipkan, ke dibersihkan. Tidak setiap rekaman butuh setiap tahap, tetapi setiap objek bervolume tinggi butuh siklus hidup. Sebuah pengiriman Steve Trucking terus dibutuhkan selama berlangsung: oleh kru, koordinator, layanan pelanggan, mitra, otomasi. Seminggu setelah selesai, ia masih berguna. Enam bulan kemudian, sebagian besar ia riwayat layanan. Tiga tahun kemudian, sebagian besar untuk analitik, audit, atau sesekali sengketa. Sepuluh tahun kemudian, mungkin tidak ada lagi alasan sah untuk menyimpannya. Nilai data berubah seiring waktu; arsitekturnya harus ikut berubah.

Penghapusan Tak Terhindarkan, Jadi Putuskan Sejak Hari Pertama

Suatu hari Anda memang perlu menghapus data. Jadi saya ingin kebijakan retensi dan pembersihan ditetapkan di awal proyek, bukan ketika penyimpanan menjadi mahal. Retensi digerakkan oleh kebutuhan bisnis dan regulasi: berapa lama ia harus tetap operasional, berapa lama kita wajib menyimpannya, mengapa, siapa yang mungkin membutuhkannya, seberapa cepat mereka harus mendapatkannya, bisakah ia akhirnya dihapus, dan apakah privasi menuntut ia dihapus lebih cepat? Bab 5 menunjukkan bahwa menyimpan segalanya selamanya tidak otomatis lebih aman; kadang menyimpan data lebih lama justru risikonya.

Pisahkan tiga keputusan. Retensi: berapa lama kita menyimpannya? Pengarsipan: di mana, dan bagaimana, kita menyimpan yang tidak lagi termasuk beban kerja aktif? Pembersihan: kapan dan bagaimana ia dihapus permanen? Membutuhkan tujuh tahun data tidak berarti tujuh tahun aktif. Mungkin delapan belas bulan aktif, lalu diarsipkan sepanjang sisa periode, lalu dibersihkan. Sekarang siklus hidupnya eksplisit.

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 (terbuka di tab baru); Best Practices: Deleting Data (terbuka di tab baru)). 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. ⟲

Klik untuk memperbesar

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

Cadangkan Sebelum Menghapus

Pengarsipan pada akhirnya berarti menghapus rekaman dari sistem aktif, jadi sebelum merancang penghapusan saya ingin cerita pemulihannya: bisakah kita memulihkan, seberapa cepat, apakah kita tahu persis apa yang hilang, bisakah kita memulihkan hubungannya, sudahkah kita mengujinya? Cadangan dipasang sebelum apa pun dihapus. Cadangan dan arsip adalah kemampuan yang berbeda: cadangan melindungi dari kehilangan; arsip sengaja memindahkan data keluar dari populasi aktif sambil mempertahankan akses yang masih dibutuhkan bisnis. Salah menghapus sepuluh rekaman itu menjengkelkan. Salah menghapus sepuluh juta adalah insiden. Jumlah Nol juga berlaku untuk kesalahan.

Keduanya kini datang dari Salesforce sendiri. Own, perusahaan di balik OwnBackup, adalah bagian dari Salesforce Platform: Own Recover kini menjadi Salesforce Backup & Recover (pencadangan harian dan sesuai permintaan untuk data dan metadata, pemulihan di tingkat bidang, rekaman, atau objek, pemulihan ke titik waktu tertentu), dan Archive memindahkan data yang jarang dipakai ke penyimpanan berbiaya rendah sambil tetap bisa diakses dari dalam Salesforce, di bawah kebijakan pengarsipan dan retensi (Own From Salesforce Product Suite FAQ (terbuka di tab baru); Own’s tools, now part of Salesforce (terbuka di tab baru)).

Arsip yang Tidak Bisa Ditemukan Siapa Pun Hampir Sama dengan Penghapusan

Sebuah tim memindahkan data lama ke tempat yang lebih murah. Pengarsipan selesai. Lalu seorang pelanggan menelepon: “Saya punya pengiriman empat tahun lalu dan butuh bukti pengirimannya.” Agen layanan mencari di Salesforce: tidak ada apa-apa. Sekarang mereka butuh sistem lain, tabel yang tepat, sebuah pengenal, seorang administrator, sebuah permintaan, dua hari. Itu bukan arsip yang berarti. Data arsip tidak harus berperilaku seperti data aktif. Ia boleh lebih lambat, hanya-baca, ditampilkan di komponen yang berbeda. Tetapi data arsip harus tetap bisa ditemukan, sesuai kebutuhan bisnis.

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

Di Mana Arsip Sebaiknya Tinggal?

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 (terbuka di tab baru)). 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 (terbuka di tab baru)). ⟲

Klik untuk memperbesar

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 (terbuka di tab baru)). ⟲

Klik untuk memperbesar

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 (terbuka di tab baru)). ⟲

Klik untuk memperbesar

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

Produknya bukan pelajarannya. Karakteristiknyalah: berapa banyak data, seberapa sering diambil, seberapa cepat harus muncul, apakah butuh akses relasional, apakah pengguna harus menemukannya dari Salesforce, apakah boleh hanya-baca, siapa yang boleh melihatnya, berapa lama disimpan, berapa biayanya, dan bagaimana ia akhirnya dibersihkan. Jawaban-jawaban itu yang memilih teknologinya. Dan ingat: di mana data tinggal secara fisik dan di mana pengguna bisa menemukannya adalah pertanyaan yang berbeda. Pengiriman lima tahun lalu tidak termasuk di objek aktif. Itu tidak berarti agen layanan tidak boleh bisa menemukannya.

Arsip Tiga Langkah

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 (terbuka di tab baru)), 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 (terbuka di tab baru)). 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 (terbuka di tab baru)). Salesforce’s Archive app respects legal holds: records under a legal hold can’t be deleted or removed (Archive App). ⟲

Klik untuk memperbesar

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

Dan rancang agar bisa dimulai ulang. Saat mengarsipkan 20 juta rekaman, job-nya gagal di rekaman 14.382.711. Jika jawabannya “mulai dari awal”, saya tidak suka desainnya. Operasi besar bisa gagal: koneksi putus, job kehabisan waktu, satu rekaman aneh memunculkan error. Prosesnya harus tahu apa yang sudah berhasil, dan untuk itulah status arsip (menunggu, terverifikasi, diarsipkan, gagal), agar ia bisa dimulai ulang tanpa menggandakan data, kehilangan data, atau menghapus sesuatu yang belum diarsipkan dengan aman. Dalam skala besar, kemampuan dimulai ulang adalah bagian dari keandalan.

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

Pengarsipan bisa menjadi alasan untuk menghindari keputusan menghapus. “Siapa tahu suatu hari kita butuh.” Mungkin tidak. Bab 5 bertanya apakah kita boleh menyimpannya? Bab ini menambahkan apakah ada nilainya membuatnya tetap aktif? Sebagian rekaman pindah ke arsip; sebagian diringkas, sebagian dianonimkan, sebagian dihapus. Tujuannya bukan menyimpan setiap byte. Tujuannya menyimpan apa yang secara sah dibutuhkan bisnis selama ia secara sah membutuhkannya.

File Mengubah Jumlah Nol

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

Arsip Tetap Harus Aman

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

Agen dan Data Arsip

Seorang Penerima bertanya kepada agen, “ke mana kulkas saya dikirim empat tahun lalu?” Jawabannya ada, tetapi sudah diarsipkan. Haruskah agen bisa menjangkaunya? Posisi saya: itu keputusan penting, dan itu keputusan bisnis. Arsitek memaparkan opsi-opsinya dan biaya masing-masing: arsip yang mana, bagaimana agen menjangkaunya, latensinya, konsumsinya, apa yang boleh dikatakan agen tentang data lama, serta batasan retensi dan privasi. Lalu bisnis yang memutuskan. Jika data arsip harus tetap terjangkau, bangun jalur pengambilan yang terotorisasi. Jika tidak, biarkan batas arsip yang menegakkannya. Yang tidak saya inginkan adalah teknologi yang membuat keputusan itu secara kebetulan.

Di luar ujian: apa yang diubah AI. Pengarsipan kini mencakup keputusan konteks: apakah riwayat tetap terjangkau oleh agen. Arsip tidak otomatis menjadi bagian dari konteks agen hanya karena datanya masih ada. Serahkan keputusannya kepada bisnis, lalu terapkan aturan otorisasi dan retensi yang sama seperti untuk akses manusia.

Steve Trucking: Tetapkan Siklus Hidup Sebelum Kita Membutuhkannya

Dalam lima tahun: sekitar 9 juta perintah kerja, 14,5 juta item baris, jutaan foto, serta riwayat status dan GPS yang sengaja kita jauhkan dari core. Saya tidak ingin Steve Trucking menunggu sampai tahun kelima untuk memutuskan apa arti “lama”. Periode pastinya mungkin belum ditetapkan; tidak apa-apa. Tetapi arsitekturnya seharusnya sudah bertanya: berapa lama pengiriman yang selesai tetap operasional? Detail mana yang harus langsung dilihat agen layanan? Kapan perintah kerja dan item barisnya pindah ke arsip, dan ke mana? Riwayat mana yang tempatnya di Snowflake? Di mana foto lama tinggal, dan kapan dihapus? Rekaman arsip mana yang masih dilihat Mitra Ritel? Bisakah agen menjangkau pengiriman yang diarsipkan? Itu bukan pertanyaan bersih-bersih. Itu pertanyaan arsitektur.

Untuk setiap objek bervolume tinggi, saya ingin lima jawaban. Kapan ia berhenti aktif? Ke mana ia pergi? Bagaimana kita membuktikan ia sampai di sana? Bagaimana seseorang menemukannya sesudahnya? Kapan ia akhirnya dihapus? Jika Anda tidak bisa menjawabnya, Anda tidak punya strategi arsip. Anda punya harapan.

Klik untuk memperbesar

Five answers, or you have a hope. ⟲

Yang Diputuskan Arsitek di Sini

• Siklus hidup aktif, diarsipkan, disimpan, dan dibersihkan untuk setiap objek bervolume tinggi, diputuskan sebelum penyimpanan atau kinerja memaksanya.
• Cadangan dan pemulihan apa yang harus ada sebelum pengarsipan atau pembersihan yang merusak.
• Di mana data arsip tinggal (big object, penyimpanan eksternal lewat Salesforce Connect, Archive dari Salesforce), berdasarkan volume, pengambilan, latensi, keamanan, biaya, dan penghapusan.
• Bagaimana proses pengarsipan diverifikasi dan dibuat bisa dimulai ulang sebelum rekaman melewati batas penghapusan.
• Konten tidak terstruktur mana yang tinggal di luar core sementara rekaman bisnisnya tetap di Salesforce, dan apakah data arsip tetap terjangkau oleh agen.

Kita menghabiskan banyak waktu untuk bagaimana data masuk ke sistem: API, impor, integrasi, migrasi, pengguna, agen. Habiskan waktu yang sama untuk bagaimana ia keluar, karena data yang kita buat hari ini adalah masalah volume data besar esok hari. Pengarsipan mungkin baru dimulai tiga tahun lagi. Siklus hidupnya harus ada sekarang. Rancang pintu keluar ketika Anda merancang pintu masuk.

Jelajahi

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