This article highlights the most common “gotchas,” especially when restoring only part of a website.
Important concept (in one sentence):
Restore = rollback (your live data changes). Download = copy (your live data does not change).
Symptom → safest restore scope (mini selector)
Use this as a quick “pick the smallest hammer” guide:
Only a plugin/theme/file change broke the site → Home Directory Files
Posts/pages/users/orders/content are missing or wrong → Databases (often with Database Users)
“Database connection” or “access denied” errors → Database Users (and sometimes Databases)
Mailboxes or email messages disappeared → Email Accounts
FTP login stopped working → FTP Accounts
Scheduled tasks stopped running / changed → Cron Jobs (restore only if you’re sure)
Domain records were edited and mail/site routing broke → DNS Zones (restore only if you’re sure)
SSL padlock/warnings started after a certificate change → SSL Certificates (restore only if you’re sure)
Backup items, explained (what it contains → what changes → when to use)
Below, each item has three tight blocks:
1) Full Account
What it contains
A combined snapshot of everything you’re allowed to restore (files + databases + email + DNS/SSL + etc.).
What will change if restored
Potentially a lot. Restoring a Full Account can roll back multiple parts of your hosting account to the backup date, not just your website.
When to use / when not to use
Use when: you need a big rollback (major break, widespread unwanted changes, serious cleanup).
Avoid when: only one piece is broken (a single plugin, a single database, a mailbox, etc.). Full Account restores are the easiest way to “fix one thing and accidentally roll back five others.”
2) Home Directory Files
What it contains
Your account’s files and folders (the “stuff on disk”): website code, themes/plugins, uploads/media files, configuration files, scripts, etc.
What will change if restored
Your current files can be replaced by older versions from the backup date. Anything created or edited after that backup may be lost for the restored paths.
When to use / when not to use
Use when: a file was deleted, your site files were changed, a plugin/theme update broke the frontend, or you need to roll back code/config.
Avoid when: the problem is clearly content/data (missing posts/users/orders) — that’s usually database, not files.
3) Databases
What it contains
Your database contents: tables and records (site content, user accounts inside the app, settings saved in the DB, ecommerce orders, etc.).
What will change if restored
Your live database can be rolled back to the backup date. Newer content (posts/users/orders/settings added after that date) may be lost.
When to use / when not to use
Use when: content/users/settings went missing, a data import went wrong, a site update changed data in a bad way, or you need to undo database changes.
Avoid when: the issue is clearly a file-only change (broken theme files, missing images, changed code).
4) Database Users
What it contains
Database users and privileges (who can log in to which database, and what permissions they have).
What will change if restored
Database usernames/passwords/privileges may be reset back to the backup date. This can immediately change whether your site can connect to its database.
When to use / when not to use
Use when: you see database permission/authentication failures (for example, “access denied”), or you restored a database and the related DB user/privileges must match.
Avoid when: everything is working and you only need to roll back content. Restoring DB users can overwrite working credentials and create new connection problems if your application config is expecting a newer password.
5) Email Accounts
What it contains
Your email mailboxes and email account structure (mailbox accounts, folders, and mailbox data).
What will change if restored
Mailbox data may be rolled back to the backup date. Messages created/received after that date may not be present in the restored mailbox state.
When to use / when not to use
Use when: a mailbox was deleted, messages disappeared, or email account structure needs to be restored.
Avoid when: your issue is only routing (DNS/MX) or only a client-side mail app issue — restoring mailboxes can create unwanted rollbacks of mailbox contents.
6) FTP Accounts
What it contains
FTP users/logins and their access settings.
What will change if restored
FTP accounts may be re-created/rolled back, including passwords and access paths.
When to use / when not to use
Use when: an FTP account was deleted or changed and you need to restore access.
Avoid when: you’re trying to restore website content — FTP Accounts doesn’t roll back your site files themselves.
7) Cron Jobs ⚠️ Restore only if you’re sure
What it contains
Your scheduled tasks (cron job commands and schedules).
What will change if restored
Old schedules/commands can come back. Cron can start running tasks you forgot existed — immediately and repeatedly.
When to use / when not to use
Use when: a known important cron task was deleted or changed and you need to roll it back.
Avoid when: you’re “just restoring the site.” Cron restores can have side effects.
Most common unintended outcomes
Duplicate cron jobs running (double emails, double imports, double invoices)
Unexpected load spikes from jobs you didn’t mean to re-enable
Jobs calling scripts that no longer exist (noise/errors)
8) DNS Zones ⚠️ Restore only if you’re sure
What it contains
Your domain’s DNS records (A/AAAA, CNAME, MX, TXT, etc.) managed in the hosting zone.
What will change if restored
DNS records can be overwritten back to the backup date. That can change where your website points and where your email is delivered.
When to use / when not to use
Use when: DNS records were accidentally edited/deleted and you need to revert the zone.
Avoid when: you’ve made intentional DNS changes since the backup date (new email provider records, verification TXT records, new subdomains, etc.).
Most common unintended outcomes
Website points to the wrong server/IP
Email delivery breaks because MX/TXT records revert
Domain verification records disappear (TXT changes)
9) SSL Certificates ⚠️ Restore only if you’re sure
What it contains
SSL certificate material for your domain (certificate + related components used for HTTPS).
What will change if restored
Your currently installed SSL certificate can be replaced by an older one from the backup date.
When to use / when not to use
Use when: you know the certificate on the account was replaced/removed incorrectly and you need to revert it.
Avoid when: you recently renewed/changed SSL intentionally. Restoring SSL can roll back to an expired or mismatched certificate.
Most common unintended outcomes
Browser security warnings due to mismatch/expiry
HTTPS “padlock” changes unexpectedly
A working, newer certificate gets overwritten
Dependencies & coupling (why “partial restores” surprise people)
JetBackup items are separate — but websites are often tightly connected. Here are the most important couplings:
Files ↔ Database (the classic website dependency)
Most modern sites store:
Code + uploads in files
Content + settings + users in the database
If you restore only files but your issue is in the DB (or vice versa), you can end up with a site that’s “half old / half new,” which can cause odd behavior.
Databases ↔ Database Users/Privileges
A database restore may bring back the data, but your site still needs working database credentials + permissions. If those don’t match, the site can’t connect.
Email accounts ↔ forwarding/rules (high-level)
Mailbox data is one piece. Email routing/rules (forwarding behavior, filters, and DNS/MX records) are other pieces. Restoring only one piece may not fully recreate the behavior you remember.
DNS ↔ SSL
DNS decides where your domain points. SSL certs are tied to domain names and where they’re served. Restoring DNS or SSL independently can create mismatches (the domain points one place, but the certificate restored is for a different setup).
Cron ↔ files/scripts
Cron jobs run commands that usually point to scripts in your file system. If you restore files without cron (or cron without files), jobs might run scripts that aren’t there anymore — or old jobs might run against a newly-restored site.
Common gotchas (read this before you restore)
Restoring is a rollback, not a merge. If you restore an item to last week, you’re effectively saying “make this item look like last week,” which can remove newer changes in that item.
Database-only restores can break a site that recently updated. Some updates change both files and database structure/data. Rolling back only one side can cause mismatches.
Database user restores can overwrite working passwords. If your application config file expects a newer password, restoring DB users may reintroduce an older password and break connectivity.
DNS/SSL/Cron restores are “high blast radius.” They can affect traffic routing, HTTPS security, and background automation — even if your website files/db are fine.
Internal verification notes (HostBible team)
These are the JetBackup 5 reference points used to ensure the item list and the database-user warning match JetBackup’s own docs:
JetBackup 5 user panel lists backup items like Full Account, Home Directory Files, Databases, Database Users, Email Accounts, FTP Accounts, Cron Jobs, DNS Zones, SSL Certificates. (docs.jetbackup.com)
JetBackup warns that restoring/downloading Databases without also selecting the related Database Users can result in only the database being included, and you should ensure the proper DB users are selected/assigned. (docs.jetbackup.com)
JetBackup notes the visible sections/items can differ depending on permissions granted by the service provider. (docs.jetbackup.com)
JetBackup’s item naming also describes “email - Email Accounts and Structure” (useful context for what the Email item represents). (docs.jetbackup.com)