How to Restore a Website with JetBackup

Something’s gone wrong with your website and you need to roll it back. Before you restore everything, it’s worth taking a moment to work out what actually broke — restoring only what’s needed is faster, less disruptive, and means you don’t lose changes that weren’t part of the problem.

This guide helps you figure out what to restore and how to find the right files and databases. For the step-by-step restoration process itself, see the individual guides for restoring files from a home directory backup, restoring a database, or restoring a full account.

What Do You Need to Restore?

Most website issues fall into one of three categories. Identifying which one applies will save you from restoring more than necessary.

Files Only

Restore just files if the problem was caused by a file change — typically a plugin update, theme update, or a file you edited or deleted manually.

Common signs:

• The site broke immediately after updating a plugin or theme
• You see a white screen or a PHP fatal error
• You accidentally deleted or overwrote a file via File Manager, FTP, or SSH
• The site worked fine until you edited a template, .htaccess, or configuration file

In these cases the database is usually untouched, so there’s no need to restore it. A file-only restore gets the site back without losing any content, orders, form submissions, or other data that lives in the database.

Database Only

Restore just the database if the problem is with your site’s content or data rather than its code.

Common signs:

• Posts, pages, or products are missing or showing incorrect content
• A plugin migration or import corrupted data
• You’re seeing database errors like “Error establishing a database connection” (though this can also be a config file issue — check wp-config.php first)
• You accidentally deleted content through the CMS admin panel

A database-only restore leaves your files untouched, so any plugin or theme updates you’ve applied since the backup date will still be in place.

Both Files and Database

Restore both if:

• A major CMS core update failed (e.g. a WordPress core upgrade that broke mid-way)
• The site has been compromised or hacked
• You’re not sure what changed and the site is completely broken
• You need to revert the site to an exact previous state

If restoring both, restore the database first, then the files. This ensures that when the restored files (including configuration like wp-config.php) come back, they’re pointing at the correct restored database. Doing it the other way round can cause a brief window where your config references a database that hasn’t been rolled back yet.

Finding the Document Root

To restore the right files, you need to know where your website’s files live. This is the document root — the directory on the server that maps to your domain.

cPanel

Step 1. In cPanel, go to the Domains section (or search for “Domains” in the cPanel search bar).

Step 2. Find your domain in the list. The Document Root column shows the path to the site’s files — for example, /home/username/public_html for your primary domain.

Common document root patterns on cPanel:

• Primary domain: public_html
• Addon domain: public_html/example.com (or a custom path set when the domain was added)
• Subdomain: public_html/subdomain (or a custom path)

Plesk

Step 1. In Plesk, go to Websites & Domains.

Step 2. Click on the domain you need. The document root path is shown beneath the domain name — typically something like httpdocs for the primary domain.

Common document root patterns on Plesk:

• Primary domain: httpdocs
• Subdomain: custom path set when the domain was added
• Additional domain custom path set when the domain was added

Selecting the Right Folder in JetBackup

When you go to restore files in JetBackup via the Home Directory option, use the Change File Selection file browser to navigate to the document root path you identified above. You don’t need to restore your entire home directory — just the folder that contains the affected website.

If you only need to restore a specific plugin or theme, you can drill further into the file tree and select just that folder. For example, for a broken WordPress plugin, you’d navigate to wp-content/plugins/plugin-name within the document root and select only that directory.

Identifying Which Database to Restore

If your account hosts more than one website, you may have multiple databases. You need to restore the right one.

For WordPress Sites

Step 1. Open your site’s wp-config.php file. You’ll find it in the document root of the website (the same path you identified above). You can open it via cPanel’s File Manager or over FTP/SSH.

Step 2. Look for the DB_NAME line:

define( 'DB_NAME', 'username_wp123' );

The value in quotes is the database name — in this example, username_wp123. This is the database you need to select in JetBackup’s Databases restore screen.

For Other CMS Platforms

Most CMS platforms store the database name in a configuration file in the document root:

• Joomla: configuration.php — look for public $db = 'database_name';
• Drupal: sites/default/settings.php — look for the database value in the $databases array
• PrestaShop: app/config/parameters.php — look for database_name

If You’re Not Sure

Go to MySQL Databases in cPanel. You’ll see a list of all databases on the account. If there are only one or two, it’s usually obvious which one belongs to which site. If there are several, check the config file as described above — it’s the only reliable way to match a database to a specific website.

After Restoring

Once the restore job has completed in JetBackup’s Queue, run through these checks:

• Load the site in a browser and confirm it’s working. Check a few different pages, not just the homepage.
• Log in to the admin panel to make sure your admin access still works. If you restored the database, your login credentials will be whatever they were at the time of the backup.
• Clear all caches — if you use a caching plugin (WP Super Cache, W3 Total Cache, LiteSpeed Cache, etc.), clear it. Also clear any server-side or CDN caches. A restored database won’t be reflected through stale cached pages.
• Check for security updates — if you rolled back files to fix a broken update, you may now be running older versions of plugins or themes. Check for available updates and apply them carefully once the site is stable.
• Test core functionality — if the site handles orders, bookings, forms, or user registrations, do a quick test to make sure those flows still work.

If the site is still broken after restoring, it’s possible the issue predates the backup you selected. Try restoring from an earlier backup date, or consider whether the problem might be server-side (DNS, SSL, server configuration) rather than something within the account itself.