How to check a Ghost export before relying on it for recovery

A Ghost export can move useful content without being a complete disaster-recovery backup. Decide which problem you are solving before downloading anything: moving articles, leaving a provider, preparing a redesign or restoring an exact site after a failure. The right collection of files depends on that answer.

Ghost's current export options are broader than older instructions suggest, especially on Ghost(Pro). That makes checking the actual export more important, not less. A ZIP labelled as containing all data still needs an inventory and a restoration test before it becomes part of your recovery plan.

Inspect the export your installation offers

The current Ghost export guide directs owners and administrators to the Import/Export area and its All data option. It lists content and settings, members, post analytics, themes, routes and redirects. On Ghost(Pro), media files can also be included; self-hosted installations require a separate media copy.

Choose the components you need and record that choice beside the resulting archive. Do not infer completeness from the filename. Open the ZIP and confirm that the expected content, theme archives and routing files are actually present. Keep the original export unchanged and work from a copy when inspecting it.

For Ghost(Pro), the guide says the archive is prepared asynchronously and delivered through a link valid for seven days. Download and store the actual file rather than retaining only the message. An expired link is not an off-site copy of your publication.

For a self-hosted site, identify where images and other uploaded files live. Confirm that whoever manages the server can export them. An article that still loads its images from the old host may look correctly restored until the old service is closed, which is exactly the dependency this check should expose.

Match the backup to the recovery promise

Ghost's self-hosted backup documentation distinguishes content export from backing up the database and content folder. It says the administrative export does not include comments or member activity history. For exact recovery, the database and stored files matter, not just the posts visible in the editor.

Describe the recovery target in ordinary language: which site state must return, and how much recent work can be lost? A publication updated every hour has a different tolerance from an archive changed monthly. Set the backup frequency from that tolerance instead of copying somebody else's schedule.

Record the Ghost version, relevant runtime requirements and the location of configuration separately. Keep secrets in an access-controlled store rather than in a broadly shared editorial ZIP. Whoever restores the site needs the configuration, but not every person reviewing articles needs the credentials.

On Ghost(Pro), the backup policy distinguishes managed backups from requested full-site archives. Requested archives are not supplied as a service-continuity backup, and they cannot be provided after an account has already been cancelled. Arrange any needed export or archive before ending the service.

Restore somewhere that cannot surprise readers

Create a private test environment rather than restoring over the live publication. Prevent indexing and block outbound mail and live payment actions. A restoration exercise should not send old messages, create duplicate transactions or expose a copied member list to the public.

Use the official import workflow for a content move, or the appropriate database restoration procedure for a full recovery. These are different operations. Importing posts successfully does not establish that comments, member history, settings and integrations have returned to their previous state.

Choose representative checks: an old post, a recent post, a page with several images, a custom route and a redirect. Compare their visible content and destination URLs with the original. If the publication uses member access, test that boundary with authorized test accounts rather than real customers' passwords.

A hypothetical test might recover every article but leave uploaded audio on the old server. That is a partial restoration, not a harmless cosmetic issue. Record the missing dependency, correct the backup scope and repeat the test before describing the recovery process as usable.

Keep a recovery note someone else can follow

Store the archive away from the production server and limit who can retrieve it. Member exports are personal data, not sample content for an unrestricted design preview. Document retention and deletion for old copies so that a backup habit does not quietly become an unmanaged data collection.

Write a short recovery note with the archive date, included components, version information, storage location and the last successful test. Identify the person who can authorize restoration and the person who has access to the necessary hosting and domain controls. Those roles may not be the same.

Before a migration, define when editorial changes stop and how later changes will be carried across. Otherwise, a technically correct export can become outdated while writers continue publishing. Keep the old service available until the new site and its independent asset copies have passed the agreed checks.

Use the hosting migration checklist for the wider move and add restoration testing to your maintenance routine. The useful outcome is not an impressive stack of ZIP files. It is a documented route from a known copy to a functioning, private-tested publication.