Summary
JetBackup showing Completed is only step one. Use this post-restore checklist to confirm your website (WordPress or other app) is healthy, the database connects and contains the expected data, file permissions look correct, email can send and receive, and cron jobs still run as expected. If anything still looks wrong, you’ll know what to check next—and what to send to HostBible Support.
Before you start
You’ve already run a JetBackup restore in HostBible cPanel (using the restore point you already chose).
You know what you restored (for example: files, database, email, and/or cron jobs).
If you use caching (browser, plugin, application cache), be prepared to clear/purge it so you’re not viewing an old cached version.
1) Confirm the restore finished and what it restored
Even when the queue says Completed, you want to confirm there were no hidden misses and that you restored the components you actually need.
Checklist
The JetBackup job shows Completed (not “Completed with warnings”).
You can identify which components were restored (example: Home Directory/files, MySQL database(s), Email, Cron jobs).
You’ve captured basic restore details for reference:
restore date/time
what was restored
any job ID/details shown in JetBackup
Why this matters: A website can still break if only files were restored but the database wasn’t (or vice versa). Email can “look fine” but be missing filters/forwarders if only some email items were restored.
2) Website validation checklist
A. Basic “does the site load?” test
Open your site in a private/incognito window.
Check the homepage and at least 2–3 internal pages.
Confirm you’re ending up on the expected protocol (usually https).
If you use any caching layer (plugin/app cache), purge it and refresh.
Healthy signs: Pages render normally, menus work, images load, no repeated redirect loop, no “Forbidden” pages everywhere.
B. WordPress post-restore checks (recommended)
1) Log in and check core functionality
Log in to /wp-admin
Confirm the Dashboard loads without fatal errors
Go to Tools → Site Health and note any critical items
Create a draft post/page and preview it
Upload a small image in Media → Add New (tests write access/permissions)
2) Fix common 404 issues
Go to Settings → Permalinks
Click Save Changes (no need to change anything)
This often resolves “homepage works but every other page is 404” after restores.
3) Confirm key WordPress files exist
In HostBible cPanel → File Manager (typically under public_html/):
wp-config.phpexistswp-content/exists (themes/plugins/uploads).htaccessexists (enable “Show Hidden Files” if needed)
If something looks off
A missing/empty
wp-config.php, missingwp-content/uploads, or a blank.htaccessusually points to a partial restore or the wrong component being restored.
C. Other apps (Laravel, Joomla, custom PHP, etc.)
Confirm the app loads the login page and one database-driven page (dashboard, list view, etc.)
Confirm the app’s config file exists and looks correct (commonly
.envor a config file in your app directory)Test one “write” action (save a setting, create a record, submit a form) if your app supports it
D. Check error logs (fastest way to find the real issue)
In HostBible cPanel:
Metrics → Errors: look for new entries that appear right after you load the site
If you find errors, capture:
exact error text
timestamp
URL you tried to load
That information is extremely helpful if you escalate to HostBible Support.
3) Database validation checklist
A. Confirm the database and user exist (cPanel)
In HostBible cPanel:
Go to Databases → MySQL® Databases
Confirm the expected database name(s) exist
Confirm the expected database user(s) exist
Confirm the user is assigned to the database with the required privileges (commonly ALL PRIVILEGES)
B. Confirm tables and data exist (phpMyAdmin)
Open Databases → phpMyAdmin
Select your database
Confirm you see tables (not an empty database)
Spot-check a few tables for reasonable row counts (especially for WordPress: options, posts, users)
C. If the site shows a database connection error
Use the message you see to narrow the cause:
WordPress: “Error establishing a database connection”
In
wp-config.php, verify:DB_NAMEDB_USERDB_PASSWORDDB_HOST
In MySQL Databases, confirm that DB user exists and is assigned to the DB with privileges
“Access denied for user …”
Usually indicates a password mismatch or missing privileges
Confirm DB user privileges
If you change/reset the DB user password in cPanel, you must update the app config to match
“Unknown database …”
DB name in your app config doesn’t exist in cPanel
Confirm the database name is correct and present
“Table … doesn’t exist”
Often indicates the wrong database was restored, only part of the database was restored, or a prefix mismatch
WordPress-specific: confirm
$table_prefixinwp-config.phpmatches your table names in phpMyAdmin
4) File permissions and critical file checks
Restores can bring back unexpected permissions, which can cause 403 errors, failed uploads, or scripts not executing.
A. Quick permission spot-check (safe defaults)
In HostBible cPanel → File Manager:
Folders are typically
755Files are typically
644Sensitive config files (like
wp-config.php) are often more restrictive (640or600)
Avoid
777(insecure; can trigger blocks)000(nothing will work; often causes widespread 403/permission errors)
B. Confirm key files weren’t replaced with the wrong version
In your site’s document root (often public_html/ or a domain subfolder):
.htaccessexists (common for WordPress and many PHP apps)index.phpexistsYour app config exists (
wp-config.php,.env, etc.)
If something is missing or looks clearly wrong after the restore, it may indicate:
the wrong component was restored (files vs DB)
a partial restore
the restore point doesn’t contain the expected data
5) Email validation checklist (accounts + send/receive)
A. Confirm mailboxes exist and have space
In HostBible cPanel:
Email → Email Accounts: confirm expected mailboxes exist
Confirm the mailbox is not at/over quota
A full mailbox can prevent new mail from arriving.
B. Webmail access test
Click Check Email next to a mailbox and log in to webmail
Confirm you can see historical messages (if mailbox data was restored)
C. Two-way mail flow test (inbound + outbound)
Use an external mailbox you control to run a reliable test.
Inbound test
Send from external → your domain mailbox
Confirm it arrives (check Inbox and Spam/Junk)
Outbound test
Reply from webmail → external mailbox
Confirm it arrives (check Spam/Junk)
D. Verify forwarders and filters are still present
In HostBible cPanel:
Email → Forwarders: confirm important forwarders exist
Email → Email Filters: confirm filters/rules exist
E. If sending/receiving still fails
In cPanel, a useful first check is:
Email → Track Delivery (especially for outbound mail)
If the issue looks like routing, server-level mail handling, or DNS-related behavior, move to the Contact HostBible Support section below (this article intentionally avoids advanced server-side fixes).
6) Cron job validation checklist (scheduled tasks)
If your site relies on scheduled tasks (backups, reports, subscriptions, publishing scheduled posts), validate cron behavior immediately.
A. Confirm cron jobs exist
In HostBible cPanel:
Go to Advanced → Cron Jobs
Confirm expected cron entries exist
Confirm they don’t appear duplicated (which can cause jobs to run twice)
B. Confirm cron output goes somewhere
If you use Cron Email, confirm it’s set to an address you can access
If your cron writes to a log file, confirm the log file exists and updates when jobs run
C. WordPress scheduled behavior quick test (optional but useful)
Schedule a WordPress post a short time in the future and confirm it publishes as expected
If you use plugins with scheduled tasks, confirm their “last run” timestamps update
If scheduling does not work, it may point to a cron/WP-Cron issue, a permissions issue, or an app error—check logs and then escalate if needed.
7) If something still looks wrong: triage and next steps
A. Quick triage by symptom
Site won’t load / 500 error / white screen → check Metrics → Errors, plugin/theme/app errors, PHP setting mismatch
Database connection errors → check DB credentials + privileges
All pages 404 → WordPress permalinks save + confirm
.htaccess403 Forbidden → permissions issue (spot-check folder/file permissions)
Uploads fail → permissions, disk quota, or missing uploads directory
Email missing or can’t log in → Email Accounts + mailbox quota
Email won’t send/receive → Track Delivery + forwarders/filters
Scheduled tasks not running → Cron Jobs + cron output/logging
B. Consider a targeted re-restore (high level)
If you identify that only one component is wrong (for example: files look correct but the database is missing tables), you may need to restore that specific component again using the restore point you already chose.
C. Contact HostBible Support (recommended if checklist fails)
If you’ve completed this checklist and something is still broken, HostBible Support can help—especially for server-side issues outside cPanel.
Include the following to speed things up:
Domain name + cPanel username
What you restored (files, database(s), email, cron jobs)
Restore point date/time you used
Exact error message(s) + the URL/action that triggered it
Screenshots of:
Metrics → Errors (website issues)
Email → Track Delivery (mail issues)
For email issues: affected mailbox(es) and the timestamp of your test messages