--- title: Export your catalog data description: Download artifact metadata, original asset files, a full restorable backup, or a people/CRM contact list — as JSON, JSONL, CSV, XML, XLSX, or ZIP. section: guides order: 18 updated: 2026-07-06 verified: 2026-07-06 related: [ guides/metadata-harvesting, guides/custom-fields, guides/collections-and-permissions, guides/importing-photos, ] features: [bulk-export, custom-fields] --- # Export your catalog data Get data out of Preservated in a form another system — or a rebuilt Preservated institution — can use. Go to **Admin → Operations → Export** and choose one of three tracks: **Content**, **Backup**, or **People (CRM)**. Every export runs as a background job and produces downloadable files that stay available for 30 days. You need the **admin** role in your institution to create any export. Anyone with **editor** access or above can download finished Content or Backup files; the **People (CRM)** track is restricted to admins because it contains personal information. ## Content track — metadata and asset files for another system Use this when you want artifact records (and optionally the original files) for a spreadsheet, a research dataset, or a different collections product. ### Create a Content export 1. **Records** — choose what to export: - **All artifacts** — everything in the institution. - **One collection** — a single collection. - **Filtered (browse query)** — paste the URL of a filtered Browse page. The export uses exactly the same filters (search, types, creators, subjects, places, dates, containment) that page shows, and the panel displays the filters it detected so you can confirm. 2. **Format** — see [Choose a format](#choose-a-format). 3. **Public records only** — off by default. An admin export includes everything you can see, including members-only and private records; the export's manifest labels it that way so a file with non-public data is never mistaken for a publishable one. Turn this on for an export you intend to share. 4. **Fields** — toggle the columns/keys to include. The defaults cover standard archival description (identifier, title, type, date, description, creators, subjects, places, rights, collection, asset filenames). Your institution's custom fields appear here too; fields marked *(private)* are staff-only metadata and are off by default. 5. **Include original asset files** (optional) — see [Including the original files](#including-the-original-files). 6. Review the **preview**, then select **Start export**. The list below the form shows progress. Completed exports offer the data file(s) plus a `MANIFEST.json` describing what was exported (institution, scope, field list, record count, and the visibility labeling). ### Choose a format - **JSON** — one file containing a `meta` header and a `records` array. Best when the consumer is a script or another system that wants the full structure: multi-value fields stay arrays, and controlled terms keep their vocabulary (`scheme`) and authority link (`uri`). - **JSONL** — the same records, one per line, with no wrapper. Best for streaming pipelines and bulk loaders. - **CSV** — one row per artifact, for spreadsheets and flat-file imports. Nested data is flattened; see the rules below. ### How CSV flattening works CSV cannot hold nested values, so multi-value fields are joined into one cell with a **semicolon + space** (`; `) separator — for example `Fishing; Boats`. Cells that contain commas, quotes, or line breaks are quoted per the CSV standard, so the `; ` separator inside a cell is unambiguous. Two options add vocabulary detail: - **Annotate controlled terms with scheme** appends the vocabulary in brackets: `Fishing [LCSH]; Boats [AAT]`. - **Include authority URI columns** adds a paired `_uri` column with the terms' authority links, in the same order as the values, so machine consumers get URIs without parsing brackets. Exported terms carry the scheme and URI stored on your records — the export never guesses or re-derives an authority link. ### Including the original files Turn on **Include original asset files** to stream the original master files (the images and documents you uploaded, not thumbnails or IIIF tiles) into the export alongside the metadata: - Each artifact record gains an `asset_files` list of in-archive paths and the underlying asset IDs, so you can match files back to records. - **Include preview images** additionally adds a web-ready 1600px preview for each asset, in a separate `previews/` folder — useful if you want lightweight images rather than full-resolution masters. - **Archive part size** (1, 2, 4, or 10 GB) caps how large each ZIP file gets. Large institutions produce many gigabytes of masters, so the files are split into numbered parts (`assets-part-0001.zip`, `assets-part-0002.zip`, …) rather than one unbounded archive; a `MANIFEST.json` records which asset lives in which part. Each part downloads independently and can be retried on its own if a download fails. - A live estimate shows the matching artifact count, the total size of masters (and previews, if included), and the resulting part count, updating as you change options. On very large result sets the estimate is sampled and labeled as such — actual size may be a bit higher. ### Preview before you run The preview panel renders the first 20 matching records through the same serializer the export job uses, so what you see is exactly what the file will contain. For CSV it shows the actual header row and flattened cells, updating live as you toggle fields and options; for JSON and JSONL you can page record by record. ### Downloads and retention Finished files download from the export list; links are private and each download re-checks your institution permission. Files are kept for **30 days**, then removed automatically — the export entry stays in the list marked **Expired**, and you can run a fresh export with the same settings at any time. ### Re-importing a Content export A CSV or JSONL export round-trips through the [import wizard](/docs/en-US/guides/importing-photos): map columns back to fields, and values that carry authority URIs rebind to the same vocabulary records rather than creating duplicates. The Content track is interchange-shaped, not a backup — collection descriptions and other collection-level settings are not included, so treat it as a best-effort round trip, not a full restore. ## Backup track — a restorable copy of your whole institution Use this for disaster recovery: a complete, self-describing dump intended to rebuild your institution inside Preservated if it were ever lost. Unlike the Content track, Backup always covers **the whole institution** — there is no scope picker — and keeps every table in its original, normalized shape rather than flattening it for portability. It includes collections, artifacts, assets, people, identifiers, locations, events, CMS pages, tours, and current AI-generated content (superseded or failed AI results are not carried). ### Create a Backup export 1. Go to the **Backup** tab. 2. **Include original asset files** (optional) — off by default (metadata only). When on, every master file streams into ZIP64 archive parts, exactly as in the Content track. 3. **Include preview images** and **Archive part size** appear once assets are included, with the same meaning as the Content track. 4. Use the **table preview** to sanity-check any table's data before running — pick a table from the dropdown and page through a sample of its rows. 5. Select **Start backup**. Depending on size, a Backup export produces either one combined ZIP (small institutions) or a metadata archive plus one or more asset-part ZIPs (larger ones), always alongside a standalone `MANIFEST.json` that describes every table, row count, and asset location. :::note Restoring a Backup file back into Preservated is not yet available — the format is designed for it, and a restore/import path is planned. Today the Backup track is for safekeeping a copy of your data, not for self-service recovery. ::: ## People (CRM) track — a contact list of your members Use this to build a mailing list or load your institution's people into a CRM or CMS. This track exports **members, affiliations, and pending invites** — not catalog data — and is separate from Backup because people are shared accounts, not institution-owned records. ### Create a People (CRM) export 1. Go to the **People (CRM)** tab. 2. Choose which **datasets** to include: **members** (on by default), **affiliations**, **pending invites**. 3. **Include email addresses** — on by default, since a contact list without emails is rarely useful; turn it off to export names, roles, and status only. 4. Choose a **format**: **CSV** (default), **XLSX**, or **JSON**. 5. Check **I understand this export contains personal information** — this confirmation is required and the export will not start without it. 6. Select **Start export**. :::warning This export contains personal information — names and, when enabled, email addresses of people affiliated with your institution. Handle the downloaded file according to your privacy policy and applicable data-protection law, and don't redistribute it beyond its intended use. ::: The People (CRM) track produces flat rows (`name, email, role, status, joinedAt, lastActiveAt, affiliation`) shaped for common mailing-list and CRM imports, plus a manifest. Files follow the same 30-day retention and download path as the other tracks. ## Related - To let aggregators harvest your **public** records continuously instead of as a one-time file, use [OAI-PMH](/docs/en-US/guides/metadata-harvesting). - Field-level privacy and crosswalk behavior come from your [custom field library](/docs/en-US/guides/custom-fields).