When backing up a WordPress site, most website administrators expect that services like Jetpack Backup will perform a comprehensive job—capturing every post, image, plugin, and configuration file. However, reality doesn’t always meet expectations. This article explores a real-world scenario where Jetpack Backup failed to restore certain critical files during a website recovery process, necessitating a deeper dive into the manual restoration workflow that ultimately salvaged essential components of the site.

TLDR: Jetpack Backup left out some essential files during an automatic restore, including crucial theme modifications and plugin configurations. The oversight became apparent only after restoring the site, leading to missing content and broken functionality. Fortunately, manual backups and diligent file comparison helped identify the gaps. A manual restore workflow was employed to recover these missing assets and fully restore the website to its intended state.

Understanding What Went Wrong

Jetpack Backup has built a reputation as a reliable, “set-it-and-forget-it” backup solution for WordPress websites. Typically, it handles full-site backups, capturing database content and files, including media uploads, themes, and plugins. However, in this particular case, a designer managing a content-rich site experienced unexpected behavior post-restore. Pages looked visually distorted, and certain backend settings were missing or malfunctioning.

Upon initial investigation, the restored files included the following:

• Database content (posts, pages, menus)
• Media uploads from the wp-content/uploads directory
• Theme files from the official theme folder
• Most plugin files

However, missing were the following:

• Custom theme modifications placed outside the main theme folder
• Configuration settings stored in separate JSON/XML files within wp-content
• Files located in wp-content/mu-plugins and caching object folders

Jetpack’s default backup configuration doesn’t cover every potential custom use case. Specifically, specialized setups—even something as common as Must-Use (MU) plugins—might not be tracked unless explicitly architected into the backup plan. This presented a clear challenge: to locate and manually restore the missing components.

The Symptoms After the Restore

Immediately after running the Jetpack-provided site restore, multiple issues emerged:

• The homepage design appeared broken, particularly in the header and footer areas.
• The Google Analytics integration was no longer functioning.
• Pre-configured shortcodes delivered “undefined function” errors upon usage.

In response, the developer began comparing the restored site with a local development version and uncovered several discrepancies. Most notable among them was the absence of four MU plugins housed within a directory not typically captured by Jetpack.

Initiating the Manual Restore Workflow

After reviewing logs and revisiting file records, a new approach was initiated. This manual restore process included:

1. Accessing a secondary backup source: The site manager had previously configured a local backup using BackWPup, which included a full file archive.
2. Mounting the archive locally: Files were examined digitally for discrepancies between the Jetpack-restored version and the archive.
3. File-by-file comparison: Using terminal commands and comparison tools such as Beyond Compare, the administrator pinpointed exactly which files had not been transferred.
4. Manual upload through SFTP: After isolating the missing files—which included template overrides in wp-content/uploads/theme-options and scripts in mu-plugins—the assets were uploaded back into their expected directories.
5. Database mapping where necessary: Some configuration files required re-import into the WordPress database, often handled through import tools within settings panels of specific plugins.

Rebuilding Confidence in the Restore

After the manual restore process was complete, the website functioned as expected. Pages loaded correctly, analytics tracking resumed, and all shortcodes executed without errors. However, the experience underscored a critical lesson: backup success isn’t guaranteed simply because a restore completes without error. Validation is often necessary to ensure depth and accuracy.

To avoid future surprises, the team implemented additional workflows:

• Creating a list of essential file directories typically missed by Jetpack Backup
• Scheduling regular cross-backups using a different plugin or cloud service
• Running monthly comparison scans between live and backup states

Why Jetpack Didn’t Catch Every File

Jetpack typically follows a plugin-configured schema for what to include in backups. By default, it tracks:

• Standard theme and plugin directories
• The database (including content posts, settings, and user accounts)
• Uploads within WordPress’s default media folder

However, files residing outside these predictable locations—or stored as non-WordPress-specific formats—may not be captured. Common causes for exclusion include:

• MU plugins in separate folders not within the Jetpack tracker’s path
• Script-based saved settings (like YAML or JSON for builders or theme frameworks)
• Third-party software integration folders within wp-content

This makes it essential for developers and site admins to evaluate whether they have any assets in atypical directories or formats.

Final Thoughts

Jetpack remains a reliable backup platform for many conventional WordPress sites. However, reliance solely on its automated restore system may leave websites incomplete after critical incidents. For any business relying heavily on custom development or extended WordPress implementations, it’s crucial to supplement Jetpack with redundant measures and understand what exactly is being backed up.

By identifying gaps early and maintaining a practical manual restore workflow, organizations can respond fast to partial recovery issues—and minimize website downtime.

FAQ: Jetpack Backup and Manual Restore

• Q: Why didn’t Jetpack Backup restore all of my files?
  A: Jetpack Backup follows specific file tracking protocols designed around standard WordPress installations. It may overlook non-standard files—such as MU plugins, custom scripts, and externally stored configuration files—unless explicitly managed.
• Q: How can I find out what Jetpack is actually backing up?
  A: Jetpack provides logs and backup activity within the site dashboard. However, for exhaustive verification, it’s best to cross-reference a downloaded snapshot with your known list of modified directories.
• Q: What tools can help with manual file comparison?
  A: Tools such as Beyond Compare, Meld, and even local terminal diff commands can assist in identifying files missing from a restore. Visual tools make it easier for developers to compare directory structures and file contents.
• Q: Should I stop using Jetpack because of this?
  A: No. Jetpack is still very effective for standard WordPress environments. Consider augmenting it with periodic manual backups and a list of non-standard paths for full protection.
• Q: What’s a good backup redundancy strategy?
  A: Use at least two independent backup systems: one automated (like Jetpack) and one manual or semi-maintained (like BackWPup or UpdraftPlus). Store these on different mediums or cloud platforms if possible.