Strapi content history and version restore

Start by deciding how far back you need to restore, and let that decision set the retention you buy or build. Map three inputs before you compare plans: business recovery requirements (how long a wrong edit, bad import or accidental deletion can go unnoticed before it matters), legal or audit holds (records that must keep their published state for a defined period), and editorial practice (how often editors revise high-risk pages such as pricing, policy or safety content). Then compare the result with the plan limits. Content History on the Growth plan keeps earlier versions for 14 days, and Enterprise extends that window up to 90 days. Confirm the exact window for your plan and version in Strapi's current documentation before you rely on it. Any requirement that exceeds the window needs a second mechanism, usually database backups or exported snapshots held under your own retention policy.

A restore of an earlier document version is a content operation. An editor opens the entry, chooses an earlier version, and brings it back as the working draft. Other documents, other editors' changes and the schema stay as they are, so the operation is narrow and reversible in the same workflow. A database restore is a different kind of action. It returns the whole database to the backup point and removes every write made after that point, including other editors' drafts, uploads metadata, localized variants, review or release changes, and admin or permission edits. Treat it as an incident response step with a named approver, a communication plan for editors and a clear statement of what content will be lost. Your backup frequency sets the maximum amount of work that can be lost, so match it to the recovery requirement you documented.

Database backups also have a fixed place in any Strapi 5 upgrade. Strapi's v4 to v5 migration guidance includes an upgrade tool with codemods, data migration scripts that run on the first start of Strapi 5, and a breaking changes list. The same guidance says to back up the database before you start, because downgrading is not supported. Once the migration scripts have run, the only rollback path for the data is the backup taken before them, so a backup that has never been restored is not a safety measure. Take the backup immediately before the migration window, record its time, and confirm that your database engine is on the supported list in the installation requirements. For Strapi 5, that list includes PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later and SQLite 3.

Turn these points into a short checklist before the first production restore question arrives. Confirm the Content History window for your plan and Strapi version. Write down the retention you need for each content type that carries legal, financial or safety weight, and decide whether database backups or an export process will cover the difference. Set the backup schedule from the maximum acceptable data loss, and keep a copy outside the primary database host. Run a restore into a separate staging instance at least once, time it, and check that media files, locales and permissions come back consistently with the database. Name who may approve a database restore and who tells editors when one happens. Ask your implementation partner or Strapi's sales team to confirm any retention figure that is not in the current pricing or documentation before you write it into policy.

A restore drill is the only reliable way to learn whether Content History and your database backups can bring back the content you need. Run it on a schedule, not only after something goes wrong. Start by choosing a small sample of documents across the content types that matter most, including at least one type with relations, components, and localized fields if you use them. Record the current field values and the published state of each document before you change anything. Next, edit each sample document in the admin panel and save the changes. Then restore an earlier version of each document through Content History and confirm that the restored draft matches the values you recorded. Content History restores one document's version. It does not roll back other documents, schema changes, or configuration, so the drill should check that those untouched items still look as expected afterward.

The second half of the drill tests the database backup. Restore the most recent backup into a separate environment, never the production database, and point a Strapi instance at it with the same major Strapi version and plugin configuration as production. Compare the restored data with production for the sample documents: field values, relations, publication status, and API responses for the same requests. Check that media references resolve, since uploaded files are often stored outside the database and need their own restore path. Confirm where your files live with your upload provider before the drill. Define success in writing before the drill starts. A typical pass means every sampled document matches its expected values, every API request returns the same structure, and the restore finishes within the recovery window your team has agreed. Record the date, the backup identifier, the people involved, and every difference found. Those records are also the evidence a compliance reviewer or auditor will ask to see.

Testing restores also verifies the backup itself, and this is the part teams most often skip. A backup job that reports success only proves that a file was written. It does not prove the file can be read, that it contains the expected tables, or that it restores on the same database engine and version that production uses. Strapi 5 supports PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later, and SQLite 3, so the drill should use the same engine and version as production, not a convenient substitute. The frequency of the drill belongs in your organization's backup and continuity policy, and that policy should set it. Ask the policy owner how often drills must run, who approves the results, and what happens when a drill fails. Also run an extra drill after major upgrades, schema changes, or changes to the database or storage setup, because those are the changes most likely to break a restore.

Before the first drill, decide several operational questions. Name one owner for the drill and one backup approver. Decide where the separate restore environment lives, and make sure it is isolated from production systems and their credentials. If the backup contains personal data, confirm with your privacy or legal team that copying it into a non-production environment is permitted and that the environment has matching access controls. Ask your implementation partner or internal team to document the exact steps so that someone else can repeat the drill during an incident when the usual owner is unavailable. When you request a quote for this work, ask what the drill includes: scripted restore steps, comparison checks, evidence records, and support for failed runs. Confirm whether the Content History retention on your plan covers the recovery window you need, and whether database backups must cover any longer period. Those answers determine how much of the drill depends on Content History and how much depends on backups.