EmDash Backups and Website Recovery

What needs backing up on an EmDash site?

The database is the obvious starting point because it contains CMS records and structured site content. It is not necessarily the complete website state. Uploaded images and other media may live in a separate storage service, while the running application and its configuration determine how that content is rendered.

A recovery plan should therefore identify at least the content database, uploaded media, application configuration and the software/design version expected to read that data. The more tightly a site depends on a particular release, the more useful it is to know which release belonged with a recovery point.

This does not mean every backup product has to package the whole website into one archive. The important point is that all required components have a protection and restoration path.

Database backups are not media backups

On a typical Cloudflare EmDash deployment, CMS records and uploaded files are separate concerns. Restoring only database content can leave a site pointing at media that was deleted or changed after the database snapshot was taken.

The opposite is also possible: restoring an older media set without matching content records can produce files the current site no longer expects. Good recovery treats these stores as related parts of one website even when the underlying infrastructure protects them differently.

When evaluating a hosting service, ask what is protected rather than asking only whether “backups” are included.

Backup versus recovery

A backup is useful only if it can support a successful restore. Recovery therefore includes more than creating copies. The process needs to locate the intended protected state, restore the required components and verify that the resulting website actually works.

A useful verification step checks the public website and the editing path after restoration. A technically successful storage operation is not enough if visitors cannot load the site or an editor can no longer sign in and publish.

How often should an EmDash site be protected?

The useful interval depends on how frequently the website changes and how much recent work you can afford to lose. A mostly static brochure site and a publication adding several articles per day have different recovery requirements.

Also consider protection immediately before risky operations. An application update, significant migration or deliberate restore is a natural point to capture the current working state before making changes.

Retention matters too. Keeping only the newest recovery point can be insufficient when a problem is discovered after several days. A practical policy balances recent protection, older restore options and the cost of retaining them.

Should recovery depend on the EmDash admin?

Not necessarily. If the failure affects the application or editor itself, a recovery system that can only be operated from inside that broken application is less useful.

DashHarbor's managed recovery architecture is designed outside the EmDash administration interface. The hosting layer can work with protected database, media and deployment state even when the CMS interface is unavailable.

See DashHarbor website recovery for the product-specific approach, including verified recovery points and protection before restoring an older state.

What to ask an EmDash host about backups

• Does protection cover both CMS records and uploaded media?
• How is a recovery point verified?
• Can the site be recovered if the CMS admin itself is unavailable?
• What happens to the current state before an older backup is restored?
• How is the restored public site checked?
• Which software or design version belongs with the protected data?

Those questions reveal much more than a simple “backups included” label.