Si no archivas hoy…

🌐 También en 19 idiomas

English · 日本語 · 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)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés Esta sección cambió en inglés y aún no se ha vuelto a traducir. (11)

Módulo 4 de 4 del capítulo Diseñar para la escala, capítulo 7 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: El volumen se encuentra con el modelo de uso compartido · Siguiente: el próximo capítulo, Arquitectura de consultas y recuperación

La pregunta que responde este módulo: ¿cómo se planifican el archivado y la purga?

Cuando alguien me dice “ya archivaremos los registros antiguos más adelante”, hago una sola pregunta: si no archivas hoy, ¿vas a archivar alguna vez? “Más adelante” suele convertirse en después de la próxima versión, después de la migración, después de la reorganización, después de arreglar el rendimiento, después de quedarnos sin almacenamiento. Y cinco años después, alguien por fin pregunta por qué hay 80 millones de registros en este objeto. No quiero descubrir el archivado cuando el gran volumen de datos ya se ha convertido en el problema. Si sé que los datos van a crecer, decido su ciclo de vida cuando los diseño. La propia guía de Salesforce dice lo mismo: “si tu volumen de datos aumenta, el rendimiento puede degradarse con el tiempo. Una política de archivar o descartar datos al mismo ritmo al que entran en el sistema puede evitar este efecto” (Best Practices for Deployments with Large Data Volumes (se abre en una pestaña nueva), Winter ‘27).

Cada registro tiene un ciclo de vida

Ya nos hemos preguntado cómo se crea un registro, quién es su propietario, quién puede cambiarlo, qué tiene la autoridad. Ahora, una más: ¿cómo sale? Un registro puede pasar de activo a inactivo, a archivado y a purgado. No todos los registros necesitan todas las etapas, pero cada objeto de gran volumen necesita un ciclo de vida. Una entrega de Steve Trucking se necesita constantemente mientras está en curso: el equipo, el coordinador, atención al cliente, el socio, la automatización. Una semana después de completarse, sigue siendo útil. A los seis meses, es sobre todo historial de servicio. A los tres años, sobre todo analítica, auditoría o alguna disputa ocasional. A los diez años, quizá nadie tenga ya un motivo legítimo para conservarla. El valor de los datos cambia con el tiempo; la arquitectura debería cambiar con él.

La eliminación es inevitable, así que decídela el primer día

Algún día sí tendrás que borrar datos. Así que quiero las políticas de retención y purga definidas al principio del proyecto, no cuando el almacenamiento se encarezca. La retención la marcan los requisitos de negocio y regulatorios: ¿cuánto tiempo debe seguir operativo?, ¿cuánto tiempo debemos conservarlo, y por qué?, ¿quién podría necesitarlo?, ¿con qué rapidez debe obtenerlo?, ¿puede desaparecer algún día?, ¿y dice la privacidad que debería desaparecer antes? El capítulo 5 mostró que conservarlo todo para siempre no es automáticamente más seguro; a veces conservar los datos más tiempo es el riesgo.

Mantén separadas tres decisiones. Retención: ¿cuánto tiempo lo conservamos? Archivado: ¿dónde, y cómo, conservamos lo que ya no pertenece a la carga de trabajo activa? Purga: ¿cuándo y cómo se elimina de forma permanente? Necesitar siete años de datos no significa siete años activos. Quizá sean dieciocho meses activos, luego archivados durante el resto del periodo y después purgados. Ahora el ciclo de vida es explícito.

Purgar con volumen tiene su propia mecánica, y Salesforce la detalla. Borrar un registro no lo elimina de inmediato: va a la Papelera de reciclaje durante 15 días, y mientras está ahí “sigue afectando al rendimiento de la base de datos porque los datos siguen residentes, y los registros eliminados tienen que excluirse de todas las consultas”. Para una purga de un millón de registros o más, el consejo de Salesforce es la opción de borrado definitivo (hard delete) de Bulk API 2.0, que se salta la Papelera de reciclaje, y, cuando los registros tienen muchos hijos, borrar primero los hijos (Deleting Data (se abre en una pestaña nueva); Best Practices: Deleting Data (se abre en una pestaña nueva)). Una purga es una operación de datos como cualquier otra a escala: planifícala, ejecútala por lotes y compruébala.

Conocimiento para el examen. Conoce cómo purgar con volumen: los registros eliminados de forma lógica permanecen 15 días en la Papelera de reciclaje y siguen ralentizando las consultas; para un millón de registros o más, usa el borrado definitivo (hard delete) de Bulk API 2.0; borra los hijos antes que los padres.

Clic para ampliar

Conservar durante siete años no significa mantener activo durante siete años.

Haz una copia de seguridad antes de borrar

Archivar acaba significando quitar registros del sistema activo, así que antes de diseñar la eliminación quiero la historia de recuperación: ¿podemos recuperar?, ¿con qué rapidez?, ¿sabemos exactamente qué se fue?, ¿podemos restaurar las relaciones?, ¿lo hemos probado? Las copias de seguridad van antes de borrar nada. La copia de seguridad y el archivo son capacidades distintas: una copia de seguridad protege contra la pérdida; un archivo saca deliberadamente los datos de la población activa y mantiene el acceso que el negocio todavía necesita. Borrar diez registros por error es molesto. Borrar diez millones es un incidente. El Número de Ceros también se aplica a los errores.

Ambas vienen ahora de la propia Salesforce. Own, la empresa detrás de OwnBackup, forma parte de Salesforce Platform: Own Recover es ahora Salesforce Backup & Recover (copias de seguridad diarias y a demanda de datos y metadatos, restauración a nivel de campo, registro u objeto, recuperación a un momento dado), y Archive mueve los datos que se usan poco a un almacenamiento de bajo coste y los mantiene accesibles desde Salesforce, según políticas de archivado y retención (Own From Salesforce Product Suite FAQ (se abre en una pestaña nueva); Own’s tools, now part of Salesforce (se abre en una pestaña nueva)).

Un archivo que nadie puede encontrar es casi una eliminación

Un equipo mueve los datos antiguos a un sitio más barato. Archivado completo. Luego llama un cliente: “Tuve una entrega hace cuatro años y necesito la prueba de entrega”. El agente busca en Salesforce: nada. Ahora necesita otro sistema, la tabla correcta, un identificador, un administrador, una solicitud, dos días. Eso no es gran cosa como archivo. Los datos archivados no tienen que comportarse como los datos activos. Pueden ser más lentos, de solo lectura, mostrarse en otro componente. Pero los datos archivados tienen que seguir siendo localizables, según lo requiera el negocio.

He visto esto bien hecho en una cadena de servicios. Al principio del proyecto me dijeron: “Solo hacemos cien citas al día en una tienda”. Cien, nada del otro mundo. Pero tenían mil tiendas, abiertas seis días a la semana. Haz la cuenta rápida: son unos 31 millones de citas al año. Después creaban dos registros de cita por cada visita, uno en la recepción y otro en la trastienda, así que 62 millones. Y necesitaban cinco años: más de 300 millones de registros. Pude ver venir el gran volumen de datos antes incluso de salir a producción. Así que desde el principio dijimos: tiene que haber archivado antes de recoger una sola cita. Pusimos el archivo en objetos grandes (big objects) y lo integramos desde la base. Cuando un usuario buscaba a un cliente, primero aparecían las citas vivas y, debajo, las archivadas. El archivo no fingía ser datos activos, y nadie tuvo que convertirse en administrador de bases de datos para encontrar el historial. Los datos activos donde el sistema operativo los necesita; los datos archivados en algún lugar adecuado a su volumen; un camino desde el contexto de negocio hasta ambos. Mucho mejor que cualquiera de los dos extremos: todo activo para siempre, o movido a algún sitio donde nadie lo encuentra.

¿Dónde debería vivir el archivo?

Mantener los datos en el núcleo es como tenerlos en la parte delantera de la oficina, donde estorban al trabajo de hoy. En algún momento del futuro de cualquier objeto con decenas de millones de registros hay un traslado a la parte de atrás: una caja en un archivo, el cobertizo (objetos grandes) o un holograma (virtualización, los datos que se muestran en Salesforce pero viven en otro lugar). No hay una única respuesta; elijo el destino según la restricción. Cuando el cliente no quiere un almacén externo, he usado objetos grandes: en la plataforma, hechos para volúmenes muy grandes, pero sin interfaz de usuario ni informes estándar, con acceso solo mediante Apex y consultas a través del índice, así que planifica la vía de acceso antes de elegirlos (el “cobertizo del fondo” del capítulo 3). Planifica también el almacenamiento: la mayoría de las ediciones tienen asignado almacenamiento para 1 millón de registros de objetos grandes por organización, y más hay que acordarlo con Salesforce (Data and File Storage Allocations (se abre en una pestaña nueva)). Otros dos hechos importan para un archivo. Los objetos grandes solo admiten permisos de objeto y de campo, no reglas de uso compartido, y los desencadenadores y los flujos no se ejecutan sobre ellos. Y insertar dos veces un registro idéntico crea solo uno, así que las escrituras pueden ser idempotentes, lo que ayuda cuando una ejecución de archivado tiene que reanudarse (Big Objects (se abre en una pestaña nueva)).

Clic para ampliar

Un objeto grande: el archivo se queda dentro de Salesforce, y tú construyes la ventana a través de la que lo ven los usuarios.

Cuando un almacén externo está bien, he usado una base de datos fuera de la plataforma mostrada mediante Salesforce Connect, para que los registros archivados aparezcan en Salesforce sin copiarlos de vuelta. Con precisión: Salesforce Connect llega a los datos externos mediante servicios OData, otras organizaciones de Salesforce, un adaptador personalizado creado con Apex Connector Framework, o adaptadores específicos para Amazon DynamoDB, GraphQL y SQL (el adaptador SQL admite Snowflake y Amazon Athena), así que una base de datos general suele necesitar delante una capa OData o un adaptador personalizado (Choose Which Salesforce Connect Adapter to Use (se abre en una pestaña nueva)).

Clic para ampliar

Un almacén externo: el archivo sale de Salesforce, y Salesforce Connect lo vuelve a poner a la vista.

El archivo no tiene por qué ser una base de datos. Pueden ser archivos en un almacenamiento de archivos de bajo coste, como Amazon S3, y el adaptador SQL de Salesforce Connect para Amazon Athena permite a los usuarios “analizar datos directamente en Amazon Simple Storage Service (Amazon S3)” desde Salesforce. Un inconveniente para un archivo: ese adaptador está disponible “no para objetos externos de gran volumen de datos”, así que comprueba lo que necesita tu volumen antes de elegirlo (Salesforce Connect SQL Adapter for Amazon Athena (se abre en una pestaña nueva)).

Clic para ampliar

Almacenamiento de archivos: el mismo traslado, con archivos en lugar de una base de datos.

Y ahora Archive de Salesforce es la opción integrada, que mantiene los registros archivados accesibles desde Salesforce. También hay herramientas de terceros en el mercado, como GRAX.

Conocimiento para el examen. Conoce los destinos de archivo y qué son los objetos grandes (big objects): hechos para volúmenes muy grandes (rendimiento constante desde un millón de registros hasta mil millones); accesibles mediante Apex, las API y su índice, no mediante la interfaz estándar; solo permisos de objeto y de campo, sin reglas de uso compartido; sin desencadenadores ni flujos. Conoce las alternativas: un almacén externo mediante Salesforce Connect y Archive de Salesforce.

El producto no es la lección. Las características sí: cuántos datos, con qué frecuencia se recuperan, con qué rapidez deben aparecer, si necesitan acceso relacional, si los usuarios deben encontrarlos desde Salesforce, si pueden ser de solo lectura, quién puede verlos, cuánto tiempo se conservan, cuánto cuestan y cómo se purgarán al final. Esas respuestas eligen la tecnología. Y recuerda: dónde viven físicamente los datos y dónde puede descubrirlos un usuario son preguntas distintas. La entrega de hace cinco años no pertenece al objeto activo. Eso no significa que el agente de atención no deba poder encontrarla.

El archivado en tres pasos

Cuando saco grandes volúmenes de un sistema operativo, no me gusta copiar y luego borrar en un solo paso. Exige demasiada confianza. Y antes de la primera ejecución real, la ensayo: una ejecución de prueba que muestra qué registros se moverían, idealmente en un sandbox de copia completa, sin borrar nada. La aplicación Archive de Salesforce permite previsualizar una política de archivado antes de publicarla (Archive App (se abre en una pestaña nueva)), y otras herramientas de archivado ofrecen un modo de prueba por la misma razón. Después uso tres pasos:

1. Copiar y marcar. Copia los registros al archivo y márcalos en el origen como pendientes de archivar. No borres nada todavía. Ahora existen las dos copias. En la cadena de servicios, esto era un lote que se ejecutaba el fin de semana.
2. Verificar. Vuelve a consultar el origen y el archivo y demuestra que el archivo es correcto: recuentos, identificadores, relaciones, totales u otra conciliación; ¿podemos recuperarlos? Para más garantía, añade sumas de comprobación, o restaura una muestra y compárala. Luego márcalos como validados. Confía, pero verifica. Los usuarios siguen encontrando los registros en el origen, porque todavía no están archivados.
3. Borrar y cambiar. Solo después de la verificación, y solo para los registros que no estén bajo una retención legal, borra los registros activos y marca el archivo como completo, para que las pantallas de búsqueda los traigan ahora del archivo. El borrado no tiene por qué ser inmediato; podría hacerse una semana después.

¿Qué podría salir mal con una sola pasada, copiar y borrar? Que no se haya copiado y hayas borrado los registros. La cuestión es que no cruzas la frontera destructiva hasta haber demostrado la copia. Y con los estados, puedes informar de cada ejecución de archivado.

No es solo una costumbre mía; así funcionan las herramientas de archivado serias. El archivado y purga de Oracle, por ejemplo, valida los registros, los copia a tablas de archivo y luego purga a partir de lo que archivó, con un programa de reinicio para cuando una ejecución falla a medias (Archive and Purge (se abre en una pestaña nueva)). Las herramientas que copian y borran en una sola pasada vienen con la advertencia de probar antes con una ejecución de prueba (AWS Prescriptive Guidance: Archiving data from unpartitioned tables (se abre en una pestaña nueva)). La aplicación Archive de Salesforce respeta las retenciones legales: los registros bajo una retención legal no se pueden borrar ni eliminar (Archive App).

Clic para ampliar

No cruces la frontera destructiva hasta haber demostrado la copia.

Y diséñalo para que pueda reanudarse. Archivando 20 millones de registros, el trabajo falla en el registro 14.382.711. Si la respuesta es “empezar de nuevo”, no me gusta el diseño. Las operaciones grandes fallan: se caen conexiones, los trabajos agotan el tiempo, un registro raro lanza un error. El proceso tiene que saber qué ha tenido éxito ya, que es para lo que sirven los estados del archivo (pendiente, verificado, archivado, fallido), para poder reanudar sin duplicar datos, perder datos ni borrar algo que no se archivó de forma segura. A escala, poder reanudar forma parte de la fiabilidad.

Una cosa más que conviene saber antes de dar por terminada una purga: borrar los registros activos no es lo mismo que eliminar los datos. Las copias de seguridad, las cachés, las réplicas y las copias analíticas pueden seguir conservándolos. Eso está bien para un archivo, y es justo lo que el capítulo 5 te pide tener en cuenta cuando la legislación de privacidad dice que los datos deben desaparecer.

No archives todo para siempre

Archivar puede convertirse en una excusa para no decidir borrar. “Puede que lo necesitemos algún día”. Quizá no. El capítulo 5 pregunta ¿se nos permite conservarlo? Este capítulo añade ¿tiene valor mantenerlo activo? Algunos registros pasan a un archivo; otros se resumen, otros se anonimizan, otros se borran. El objetivo no es preservar cada byte. Es conservar lo que el negocio necesita legítimamente durante el tiempo que lo necesita legítimamente.

Los archivos cambian el Número de Ceros

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

El archivo sigue teniendo que ser seguro

Que los datos salgan del objeto activo no significa que dejen atrás sus requisitos de seguridad. Redrock solo veía las entregas de Redrock mientras estaban activas; archívalas y Redrock sigue sin obtener el historial de Keystone. El archivo también necesita un modelo de autorización, para los datos personales de los destinatarios, las fotos, los datos financieros, el historial de servicio y el acceso de los agentes. Un archivo en objetos grandes no ayuda por sí solo aquí: los objetos grandes no admiten reglas de uso compartido, así que la vía de acceso que construyas tiene que llevar consigo la frontera entre socios. Una pregunta de diseño para cada archivo: ¿cómo sobreviven al traslado los requisitos de seguridad originales? La implementación puede cambiar; el requisito no.

Los agentes y los datos archivados

Un destinatario le pregunta a un agente: “¿dónde se entregó mi nevera hace cuatro años?”. La respuesta existe, pero está archivada. ¿Debería poder llegar a ella el agente? Mi posición: es una decisión importante, y le corresponde al negocio. El arquitecto expone las opciones y lo que cuesta cada una: qué archivo, cómo llega a él un agente, la latencia, el consumo, qué puede decir un agente sobre datos antiguos, y los límites de retención y privacidad. Luego decide el negocio. Si los datos archivados deben seguir al alcance, construye un camino de recuperación autorizado. Si no, deja que el límite del archivo lo imponga. Lo que no quiero es que la tecnología tome la decisión por accidente.

Más allá del examen: lo que cambia la IA. Archivar incluye ahora una decisión de contexto: si el historial sigue al alcance de los agentes. Un archivo no forma parte automáticamente del contexto de un agente solo porque los datos sigan existiendo. Plantea la decisión al negocio y luego aplica las mismas reglas de autorización y retención que para el acceso de las personas.

Steve Trucking: decide el ciclo de vida antes de necesitarlo

A cinco años: unos 9 millones de órdenes de trabajo, 14,5 millones de partidas, millones de fotos, y el historial de estados y el GPS que mantuvimos deliberadamente fuera del núcleo. No quiero que Steve Trucking espere al quinto año para decidir qué significa “antiguo”. Puede que los periodos exactos aún no estén fijados; no pasa nada. Pero la arquitectura ya debería estar preguntando: ¿cuánto tiempo sigue operativa una entrega completada? ¿Qué detalles deben ver de inmediato los agentes de atención? ¿Cuándo pasan al archivo las órdenes de trabajo y sus partidas, y adónde? ¿Qué historial pertenece a Snowflake? ¿Dónde viven las fotos antiguas, y cuándo se borran? ¿Qué registros archivados siguen viendo los socios minoristas? ¿Puede un agente llegar a las entregas archivadas? No son preguntas de limpieza. Son preguntas de arquitectura.

Para cada objeto de gran volumen, quiero cinco respuestas. ¿Cuándo deja de estar activo? ¿Adónde va? ¿Cómo demostramos que llegó? ¿Cómo lo encuentra alguien después? ¿Cuándo se borra definitivamente? Si no puedes responderlas, no tienes una estrategia de archivado. Tienes una esperanza.

Clic para ampliar

Cinco respuestas, o solo tienes una esperanza.

Lo que decide aquí un arquitecto

• El ciclo de vida activo, archivado, retenido y purgado de cada objeto de gran volumen, decidido antes de que el almacenamiento o el rendimiento lo impongan.
• Qué copia de seguridad y recuperación deben estar listas antes de cualquier archivado o purga destructivos.
• Dónde viven los datos archivados (big objects, un almacén externo mediante Salesforce Connect, Archive de Salesforce), según el volumen, la recuperación, la latencia, la seguridad, el coste y la eliminación.
• Cómo se verifican los procesos de archivado y cómo se hacen reanudables antes de que los registros crucen la frontera de la eliminación.
• Qué contenido no estructurado vive fuera del núcleo mientras su registro de negocio se queda en Salesforce, y si los datos archivados siguen al alcance de los agentes.

Dedicamos mucho tiempo a cómo entran los datos en un sistema: API, importaciones, integraciones, migraciones, usuarios, agentes. Dedica lo mismo a cómo salen, porque los datos que creamos hoy son el problema de gran volumen de mañana. Puede que el archivado no empiece hasta dentro de tres años. El ciclo de vida debería existir ya. Diseña la salida cuando diseñas la entrada.

Explora

• Trailhead, Explore Archival Versus Purge in Data Cleanup (se abre en una pestaña nueva): back up before cleaning or moving data; archive versus purge, checked 2026-11-01. ⟲
• Salesforce Help, Archive App (se abre en una pestaña nueva): 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 (se abre en una pestaña nueva) (current; confirmed 2021), checked 2026-11-01. ⟲
• Industry examples of the same pattern: Oracle, Archive and Purge (se abre en una pestaña nueva) (Oracle Receivables: validate, archive, then purge from the archive tables, with a restart program), and AWS Prescriptive Guidance, Archiving data from unpartitioned tables (se abre en una pestaña nueva) (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 (se abre en una pestaña nueva), Deleting Data (se abre en una pestaña nueva) and Best Practices: Deleting Data (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• Salesforce Help, Data and File Storage Allocations (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• Salesforce Help, Own From Salesforce Product Suite FAQ (se abre en una pestaña nueva), and Salesforce, Own’s tools, now part of Salesforce (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• Salesforce Help, Salesforce Connect SQL Adapter for Amazon Athena (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• Salesforce Help, Choose Which Salesforce Connect Adapter to Use (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• Salesforce Developers, Big Objects Implementation Guide (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• SteveTechArc, Documentos de Salesforce por versión: estas guías, una por año desde Winter ‘16, cada una con una copia archivada.