JoomlaForever.com! - How to Rescue and Restore a Joomla 3.10 Backup After Your Host Deleted the Site (Beginner's Guide)

Details: Written by: Bjørn Ove Bremnes; Parent Category: Community Questions; Category: Community Questions - News; Published: 07 June 2026

If your host removed a long-running Joomla site and all you have is a backup from 2022 (Joomla 3.10), don’t panic. This guide gives a practical, step-by-step rescue plan you can follow yourself or hand to a technician. You will learn how to preserve the backup, inspect its contents, choose an appropriate restore method, test safely in staging, and take immediate hardening and migration steps.

Quick checklist: what to do first (immediate actions)

Before attempting any restore, stop any action that might overwrite or destroy the backup. Follow this short checklist to preserve evidence and prepare for recovery.

Stop automated installers or processes that might modify files on the host.
Download the backup file(s) locally and save at least two copies (external drive and cloud storage).
Collect hosting account details, billing records, and any correspondence with the host about the deletion.
Contact the host immediately and ask about snapshots or retention — see the next section for exact questions to ask.
Create a simple plan: will you try a self-restore (manual/Akeeba) or hire a professional?

Immediate: preserve the backup, download multiple copies

How you download matters. Use cPanel File Manager or FTP to avoid corrupting the archive. Name and date-stamp local copies, for example: site-backup-2022-10-12.zip. Keep one copy offline (external drive) and one copy in cloud storage (e.g., Google Drive or Dropbox).

Practical example:

In cPanel File Manager: locate the archive, select it, click Download. Save one copy locally on your computer and upload a second copy to your cloud account.

Warning:

Do not re-run installers or let an automated installer rewrite files while preparing a manual restore.

Understand your backup: what to look for in a 2022 Joomla backup

Inspect the backup archive before attempting any restore. Knowing what you have will determine which restore method to use.

Common backup formats: ZIP/TAR of files + a separate .sql database dump; host-specific snapshots; or an Akeeba package (.jpa, .jps, or Akeeba .zip).
Essential Joomla 3.10 files and folders to expect: configuration.php, /administrator, /components, /templates, /images, /media and others. The database dump should contain CREATE TABLE statements and a table prefix.
Check archive size and timestamps to spot truncated or incomplete archives.

How to inspect the backup archive (what files / SQL to expect)

Browse the archive in cPanel File Manager or use a local unzip tool; do not extract the archive into a public webroot on a live site.
Look for configuration.php at the archive root — it contains database names, prefixes and paths (handle securely).
If there is an .sql or compressed SQL file, open the first lines to confirm it contains CREATE TABLE statements and a table prefix (for example jos_ or a custom prefix).
If you find an Akeeba archive (.jpa/.jps), it usually includes both files and the SQL needed for a full restore.

Practical example:

Open the ZIP in cPanel and confirm presence of configuration.php and backup.sql. Note the DB prefix from the SQL header for later use.

Warning:

configuration.php contains credentials — keep it secure and do not paste it into public forums or emails.

Ask your host: recovery, snapshots and what to request

Hosts have different backup and retention policies. Contact them quickly and request explicit items to improve recovery chances.

Ask: Do you have snapshots for my account and, if so, can you restore files or provide a download for a specific date?
Ask for a full database export (SQL) and a complete site archive if available.
Request a one-time restore to a temporary subdomain or staging account if they offer that — it speeds testing.

Questions to ask the hosting provider (snapshots, retention, backups)

Do you keep snapshots for this account? From which dates?
Can you provide downloadable links to a full site archive and a database dump (timestamped) for a specified date?
Can you perform a one-time restore to a temporary subdomain or staging account so I can test the site?
If Softaculous manages the install, can you export a complete archive or allow a manual install of the older files?

Practical example (email template):

Polite request: Please provide any available snapshots or backups for account X dated around YYYY-MM-DD. If possible, provide downloadable links for a full site archive and database export or restore the snapshot to a temporary subdomain for my testing. Thank you.

Warning:

Do not assume host staff will perform upgrades or migrate the site. Clarify that you only want a copy or a one-time restore unless you explicitly request a migration.

Three practical restore methods (ranked by simplicity)

Choose a method based on what the backup contains and what access you have. Below are three common approaches, from easiest to most manual.

Method A — Softaculous / host restore (when available)

When to use: your host offers snapshots or Softaculous can restore the specific backup.
Pros: fastest and easiest, minimal manual editing.
Cons: limited control; some hosts avoid installing legacy Joomla versions for security reasons.

Method B — Manual restore: extract files, create DB, import SQL, update configuration.php

When to use: you have a files archive and a .sql database dump and access to cPanel/FTP/phpMyAdmin.
Pros: full control; useful when only part of the site is recoverable.
Cons: requires careful edits (configuration.php), permission fixes and attention to PHP/MySQL compatibility.

Method C — Akeeba Restore: Kickstart and restoration steps

When to use: the backup is an Akeeba archive (.jpa/.jps or Akeeba zip).
Pros: Akeeba Kickstart automates extraction and DB import.
Cons: requires the Kickstart script and may need manual clean-up afterwards; some hosts block running such scripts.

Decision example:

If your backup file ends in .jpa, use Akeeba Kickstart. If you have a ZIP of site files plus a separate .sql, use the Manual method. If the host can restore a snapshot for your account, the Host/Softaculous restore is often the fastest.

Warning:

Before any restore, ensure the target environment supports the PHP and MySQL versions required by Joomla 3.10 — verify this against official Joomla documentation before making production changes.

Step-by-step manual restore using cPanel and phpMyAdmin

This procedure assumes you have a ZIP of site files and a database .sql file and access to cPanel and phpMyAdmin.

Method B — Manual restore: main steps

Create a safe target environment: use a subdomain or a separate folder that is not the active public root.
Upload and extract site files to the target folder via cPanel File Manager or FTP.
Create a new MySQL database and a user in cPanel; assign the user to the database with all privileges. Record DB name, user and password.
Import the .sql file via phpMyAdmin. For large SQL files, use chunked import tools or ask the host for help to avoid timeouts.
Edit configuration.php to update DB credentials: $host, $user, $password, $db and the $dbprefix if needed. Also check $log_path, $tmp_path and $live_site values.
Adjust file and folder permissions (commonly 644 for files and 755 for folders — verify with official Joomla hardening docs for your host). Test the site and admin login.

Practical example:

Create database restored_db and user restored_user, import backup.sql with phpMyAdmin, update configuration.php with the recorded DB credentials and then visit the staging URL to test /administrator login.

Warnings:

Large SQL imports can time out; consider server-side import tools or ask your host for assistance.
Make a backup copy of configuration.php before editing; incorrect edits can break the site.

Restore using an Akeeba backup (if file is Akeeba archive)

Akeeba backups are common in Joomla sites and include site files and the database in a single archive. If you have an Akeeba archive, Kickstart is typically the fastest option.

Method C — Akeeba Kickstart process overview

Upload the Akeeba archive (for example site-backup.jpa) and kickstart.php to the restoration folder on your server.
Run http://yourtempdomain/path/to/kickstart.php and follow the Kickstart extraction wizard.
After extraction, run the included Akeeba Installer to connect the database and finalize configuration.
Clean up: remove kickstart.php and any installer files after the restore is complete.

Practical example:

Upload site-backup.jpa and kickstart.php to /restoresite/, navigate to /restoresite/kickstart.php, extract and follow the prompts to import the DB and finish installation.

Warnings:

Some hosts block uploads or execution of such scripts. If blocked, restore locally or on a different host.
Always remove Kickstart and installer files after the restore — they are a security risk if left accessible.

Set up a local or staging environment for safe testing

Restoring to a local machine or a staging subdomain is strongly recommended. Test there before exposing the restored Joomla 3.10 site to the public.

Benefits: test administrator access, extensions, URLs and run upgrades in a safe place.
Options: XAMPP (Windows), MAMP (macOS), Local by Flywheel, or a staging subdomain provided by your host.
Checklist for staging: match PHP and MySQL versions as closely as possible, enable the same PHP extensions, and configure the hosts file if you want to use the original domain locally.

Setting up XAMPP/MAMP or a subdomain for staging

Install the local stack, create a database, import the SQL and copy files into the local web folder (htdocs or similar).
Edit configuration.php to use local DB credentials and either set $live_site or use the hosts file to map the live domain to your local host.
Test thoroughly: admin login, forms, extensions and front-end pages.

Warning:

Local environments can differ from production. Always test differences in PHP/MySQL versions and extensions.

After-restoration checklist: fix config, permissions, URLs and email

Once the site is restored and tested in staging, perform these immediate checks before going live.

Update configuration.php values: $host, $user, $password, $db, $dbprefix, plus $log_path, $tmp_path and $live_site if used.
Check file and folder permissions and ownership according to host recommendations.
Test admin and front-end functions, including forms and search; test email sending and update SMTP settings if needed.
Clear Joomla cache and temporary files, and run any database fixes prompted by Joomla admin.

Testing site functionality: forms, login, extensions, links

Confirm /administrator login works and that key pages render correctly.
Submit contact or checkout forms to verify email and payment integrations.
Run a small crawl to find broken links or missing images.

Warning:

Do not enable SEO-friendly URLs until you confirm that mod_rewrite and .htaccess are configured correctly on the new host.

Dealing with extensions, templates and missing files

After restore you may find disabled or missing extensions or templates. Here is how to identify and address those issues safely.

Check Extensions > Manage > Manage for missing or disabled entries and review error logs for missing files.
If an extension is missing, search your backup for the /components/com_xxx and /administrator/components/com_xxx folders and restore them, or download the original package from the vendor.
Templates must be present in /templates. If assets are missing, the layout can break — restore template files from backup or reinstall the template and reapply settings stored in the DB.

How to identify incompatible extensions and where to find replacements

Check developer sites and the Joomla Extensions Directory (JED) for compatibility notes. Some 3.x-only extensions do not have Joomla 4 equivalents.
If a vendor no longer provides legacy builds, consider secure, actively maintained alternatives from JED.

Warning:

Avoid installing legacy extension packages from unknown sources — this can introduce malware. Prefer official vendor downloads or JED-listed packages.

Security and support: risks of running Joomla 3.10 and migration options

Joomla 3.10 is near the end of its lifecycle; restored sites should not be left exposed without hardening and an upgrade plan.

Immediate hardening: change all passwords, update admin emails, remove unused admin users and extensions, enable two-factor authentication for administrator accounts if available.
Backup the restored site again before making any upgrades or changes.
Plan a staged migration to a supported Joomla version (Joomla 4 or later) after testing compatibility of templates and extensions.

Stepwise approach to upgrade from Joomla 3.10 to Joomla 4+ (testing first)

On a staging copy, update all extensions to the latest Joomla 3.10-compatible versions.
Test the site thoroughly on staging and resolve any extension/template incompatibilities.
Follow the official Joomla upgrade documentation to perform the migration on staging first. Once successful, schedule a maintenance window for the live migration and repeat the tested steps.

Warnings:

Do not perform an upgrade on your live site without a tested backup and a rollback plan.
Some extensions and templates used in Joomla 3.10 may not have Joomla 4 equivalents — verify compatibility before upgrading.

Troubleshooting common errors

Restores often encounter a few predictable errors. Keep error reporting on for staging and consult logs to find root causes.

500 Internal Server Error: Check web server error logs, temporarily rename .htaccess to rule out rewrite rules, verify PHP version and extensions, and confirm file permissions.
Database connection errors: Verify DB credentials in configuration.php, ensure the DB exists and that the DB user has correct privileges. Check whether the DB host should be localhost or a socket/hostname provided by the host.
Missing classes or fatal errors: Missing extension files or incompatible PHP versions can cause fatal errors. Enable error reporting on staging to get exact messages and restore missing files from the archive.
Large import timeouts: Use chunked import tools, server-side import, or ask the host to import the SQL file to avoid web-based timeouts.

Warning:

Enable error reporting only on staging — error output on a public site can reveal sensitive information to attackers.

When to call a pro and what information to prepare

Consider hiring a professional if backups are incomplete, databases appear corrupted, or the site uses heavily customized code. Preparing clear information will speed recovery and reduce cost.

Hire a pro if you lack access to cPanel/phpMyAdmin, the backup is partial, DB errors appear after import, or extensions are heavily customized.
Information to prepare for a developer: backup files or download links, cPanel screenshots or access details, the SQL dump, recent error logs, and a list of critical pages/features to prioritize.
Provide temporary credentials and revoke them after the work is complete.

Checklist to provide to a developer if you need paid help

Backup archive(s) and database SQL file (or links to download).
Host control panel URL and a screenshot of available snapshots if provided by the host.
List of critical pages and features (e.g., shop checkout, member login, contact forms) and the last known good date.
Error logs and any messages displayed during restore attempts.

Warning:

Do not share permanent root or long-term credentials. Use temporary accounts or change passwords after the job is done.

FAQ

Can I restore a Joomla 3.10 backup on a host that only allows installing newer Joomla versions?

Possibly. A manual restore (uploading files and importing the SQL) or using Akeeba Kickstart can recreate an older site without the host using an installer. If the host blocks required PHP versions or script execution, use a staging environment or a different host. Verify host restrictions and PHP/MySQL compatibility first.

How can I check whether the backup is complete and usable?

Open the archive and confirm presence of configuration.php, /administrator, key folders like /components and a database dump (.sql). Check that the SQL contains CREATE TABLE statements and a consistent table prefix. Keep sensitive files private while inspecting.

What's the easiest way to restore if I find an Akeeba .jpa file?

Use Akeeba Kickstart: upload the .jpa and kickstart.php to the restoration folder, run the script, follow the installer prompts, and complete post-restore cleanup. If the host blocks Kickstart, restore locally or on another host.

What immediate security steps should I take after restoring a Joomla 3.10 site?

Change all passwords, remove unused admin accounts, update or remove outdated extensions, enable two-factor authentication for admin accounts if available, and create a new full backup before attempting upgrades.

Can I upgrade directly from Joomla 3.10 to Joomla 4?

There is an official upgrade path, but compatibility checks for templates and extensions are required. Always test upgrades on a staging copy, back up before changes, and verify details against the official Joomla upgrade documentation before proceeding.

What should I provide to a developer to make the recovery fast?

Provide backup files or download links, cPanel access or screenshots, the SQL dump, recent error logs, a list of priority pages/features, and temporary credentials that can be revoked after work finishes.

Conclusion

Restoring a Joomla 3.10 backup after a host deletion is manageable with a careful, staged approach: preserve multiple copies of the backup, inspect its contents, choose the right restore method (host snapshot, manual or Akeeba), test in staging, harden the restored site, and plan a migration to a supported Joomla version. If the process feels risky or files are missing, collect the diagnostic information and hand it to a developer with the checklist provided. Verify compatibility and any version-specific details against official Joomla and vendor documentation before making production changes.

Add comment

Three ways optimize the use of CSS in content with Joomla

CSS has from the age of the Internet been a part of doing websites. It is an easy but useful way to design an article. There are several ways to write CSS in Joomla, you can use an external file to store all CSS codes in, you can use an extension to include the code, or you can write CSS directly in the content. In this article, I will give some look into how I do it.

In this article, I will show you three different ways to use CSS in an article. The easiest thing is to use an extension to add CSS to the article. There are several extensions in the JED (Joomla Extensions Directory) that gives this opportunity. One of the popular is Sourcerer from Regular Labs. But its also possible to do in-line CSS coding in every article, but this can be very ineffective in large articles, the third and maybe most used is to put the CSS codes into the template as eighter an external file or in the CSS capabilities of the template itself. In modern template-Framework is this common, the disadvantage of this is that you always need access to the backend to add extra CSS in your site.

W3C CSS verified: W3c.org is setting the standards for CSS

1 Code directly as you go (Hard coding the articles)

If you prefer to do the CSS coding inline as you write an article, you must bear in mind that you will NOT be able to reuse the CSS on any other articles and you must repeat the same thing for every content with the same code. This could look like this:

<a href="/home" style="background-color:#ff0000;color:#ffffff;">Home</a>

This will output: Home

2. Use an external file

If you use an external file as a CSS source, it is normally located under the css folder in your template directory. And its usually called custom.css or user.css, the downside with this is that you need access to either FTP or bee logged in to the backend as a Super Administrator.

3 Use an extension to add CSS code in the article

If you want to use an extension to insert CSS in an article, you can not reuse the CSS codes without having it in every article that contains the same style.

What do I recommend?

A combination of the option 2 and 3, will give the easiest result and you can standardize some of the CSS styles in a file and add styles in that applies to certain articles at one addon at the end of the written article.

Comments wanted