<p>A Strapi database backup does not contain uploaded files when the media provider stores them on disk or in object storage. I inventory both systems and write one recovery plan that reconnects database media records with the file objects they reference.</p><p>The <a href="https://docs.strapi.io/cms/features/media-library">Strapi Media Library documentation</a> describes the Media Library interface. Production durability depends on the configured upload provider, storage policy, and backup process outside that interface.</p>

<h2>Find where every upload lives</h2>

<p>I identify the active upload provider, bucket or filesystem path, region, public URL pattern, and credentials used by Strapi. Local container storage may disappear during redeployment, so I do not assume a mounted path is persistent.</p><p>I sample media records and confirm the referenced object exists. Orphaned database rows and unreferenced objects require different cleanup decisions.</p>

<h2>Back up data and media separately</h2>

<p>The database backup covers content records, relations, users, settings, and media metadata. The media backup covers uploaded objects and versions. I schedule both and record whether they share a recovery point.</p><p>If the backups run at different times, the restore may contain references to files that were not captured. I define the acceptable gap and use versioning or snapshots where the provider supports them.</p>

<h2>Protect backup credentials</h2>

<p>Backup jobs use a dedicated identity with read access to the source and write access to the backup destination. Restore access is more restricted because it can overwrite data. Credentials stay in the platform secret store and rotate on a schedule.</p><p>I encrypt backups and limit retention according to the data involved. Keeping every backup forever increases cost and privacy exposure.</p>

<h2>Document restore order</h2>

<p>I restore infrastructure configuration, database, media objects, and application version in a known order. Domain and CDN configuration may also need restoration if media URLs depend on them. The runbook names the owner for each system.</p><p>I verify object permissions after restore. Files can exist while public pages return 403 because the bucket policy, signed URL configuration, or CDN origin changed.</p>

<h2>Run a real restore test</h2>

<p>I restore into an isolated environment, start the matching Strapi version, and sample text, relations, users, and media. I request original and transformed media URLs and inspect logs for missing objects.</p><p>A successful backup job proves that files were written. Only a restore test proves the team can recover them within the expected time.</p>

<h2>Monitor drift and failed jobs</h2>

<p>I alert on backup failures, old recovery points, unusual size changes, and restore-test failures. I also track provider changes because moving from local uploads to object storage changes the recovery procedure.</p><ul><li>Database and media locations are inventoried.</li><li>Both receive backups.</li><li>Credentials are scoped and rotated.</li><li>Restore order is documented.</li><li>An isolated restore test passes.</li></ul>

<h2>Need help with Strapi?</h2>

<p>Terry Hunt Dev supports Strapi hosting, storage, and recovery through <a href="/services/strapi-development">Strapi development</a> and <a href="/services/website-maintenance">website maintenance</a>. Request a backup review through the <a href="/contact">contact page</a> without sharing credentials.</p>

Plan Strapi media storage and backups for production, including database and upload coverage, credentials, retention, restore order, and recovery testing.

Protecting Strapi Media Files and Backups in Production

Protect the Strapi database and uploaded media with separate backups, retention, restore order, and tested recovery steps.

Media Storage Resources & Benchmarks

Protecting Strapi Media Files and Backups in Production

Need hands-on help with Media Storage?