JoomlaForever.com! - How to Restore a Joomla 3.x Backup After Your Host Deleted the Site

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

If your hosting provider deleted a long-running Joomla site after an account lapse, a recent full backup can usually be used to restore the site. This guide walks beginners through the immediate steps to preserve recovery options, how to inspect a backup safely, how to test a restore locally, how to perform a manual restore on a new host (using cPanel/phpMyAdmin), how to fix common errors, temporary hardening for Joomla 3.x, and planning the move to Joomla 4.

Before making production changes, verify the platform and version details against the official Joomla documentation and your host's support resources.

Immediate steps to take right now (before attempting restore)

When you discover the live site is gone, act carefully to preserve data and recovery options.

Quick instant checklist

Do not panic and do not overwrite or upload anything to the original live server.
Download the backup archive to at least two safe locations (local disk + cloud storage).
Record backup details: filename, size, date stamp, and any visible version hints (for example, a file named with “joomla3” or date).
Take screenshots of any control-panel messages or account deletion notices from the host.
Contact the old host immediately and ask whether they can provide server snapshots, file archives and a database dump for the account (be specific about dates and filenames).
Change passwords for any control-panel or FTP accounts you still control and document what you have before opening archives.

Practical examples

Example: Save a copy of the backup to your desktop and to Google Drive before extracting. Then, email the host a short, specific request for server backups (see the sample request later in this article).

Warnings

Do not upload the backup archive to the live host before verifying its contents — doing so could overwrite data or trigger security filters.
Avoid running installers on a live server until you confirm compatibility with the backup contents.

How to inspect the backup file — what to look for

Before restoring anything, confirm the backup is complete and safe to import.

What files should be inside a typical Joomla full backup

configuration.php — critical (contains DB connection info and site settings).
SQL dump — file with .sql or .sql.gz extension (your database export).
Site folders: administrator, components, modules, plugins, templates, images, media, tmp, etc.
Optional: a README, list of installed extensions, or separate third-party installers.

How to list and inspect archive contents safely

On a computer you control, list the archive without extracting it: for example, unzip -l backup.zip or tar -tf backup.tar.gz will show contents.
On Windows, use 7-Zip or WinRAR to view contents before extraction.
Open the SQL dump in a text editor to check the header for table prefixes, database names, and any comments indicating Joomla version — but do not execute it yet.

Technical warnings

Do not import an SQL file into a live database until you have inspected it for DROP/DELETE commands or other suspicious content.
Backups from unknown sources can contain malicious code. Scan files locally with antivirus or malware scanners before uploading to any server.

Option A: Ask the old host for backups and recovery options

Hosts often retain snapshots or backups for a window after account deletion. Ask specifically and politely for what you need.

What to ask the host (sample requests)

Request a full file archive of /home/username/public_html (or the path they used) for a specific date.
Request a MySQL dump for the site database, compressed as a .gz file if possible.
Ask whether they can restore the site to a temporary location so you can copy files, or provide FTP/HTTP download links for provided snapshots.

Sample short request (use your own words):

"Hello—my account for example@your production domain was recently deleted. Could you provide any available server snapshots or backups for the domain your production domain dated around YYYY-MM-DD? Specifically, we need the public_html files and a MySQL database export. Please let me know what you can provide and how to download it. Thank you."

Warnings and notes

Hosts may charge for out-of-policy restores or may refuse; treat this as one recovery avenue and pursue local/manual restore options in parallel.
Don't rely solely on the host — keep your own off-site backups in the future.

Option B: Restore locally for testing (recommended first step)

Restoring the backup to a local environment helps you test and fix issues without affecting production systems.

Setting up a local server and restoring the backup

Install a local stack such as XAMPP (Windows/Mac), MAMP (Mac), Local by Flywheel, or use Docker with PHP and MariaDB containers.
Choose a PHP version close to the original environment (Joomla 3.10 commonly ran on PHP 7.x — verify this against official Joomla docs for exact compatibility before making production decisions).
Create a local database and user (via phpMyAdmin or CLI).
Extract the backup into your local webroot (for example, C:/xampp/htdocs/site).
Import the SQL dump into the local database (phpMyAdmin 'Import' or mysql -u user -p dbname < backup.sql).
Edit configuration.php to use the local DB credentials and local paths.
Visit the site at http://localhost/site to check for errors and missing assets.

Practical examples

XAMPP example: install XAMPP, start Apache and MySQL, open phpMyAdmin, create a database named 'site_db', import the SQL file, copy files to C:/xampp/htdocs/site, update configuration.php with local DB details, then open http://localhost/site.

Warnings

PHP extensions required by some third-party extensions might not be enabled locally — enable them before testing.
A local environment may not match production path, mail, or cron behavior; use it primarily for functional debugging.

Manual restore on a new hosting account (step-by-step)

This section shows a safe manual restore workflow using cPanel and phpMyAdmin for hosts that block older installer versions.

Create database and import SQL

In cPanel, open MySQL Databases and create a database (for example, site_db).
Create a database user and assign it to the database with All Privileges.
Open phpMyAdmin and import the SQL dump. For large files, use the host's large import tool, upload by SSH and import with the CLI, or split the file into smaller chunks.
Confirm the tables were imported and note the table prefix (for example, jos_ or custom prefixes).

Upload files and edit configuration.php

Upload the backup archive to the site's document root (often public_html) using cPanel File Manager or FTP and extract it there.
Open configuration.php and update the database fields (user, password, db, host) and any path variables such as $log_path and $tmp_path. Also check $live_site if present.
If configuration.php is missing, do not attempt to recreate it by guesswork — consider doing a clean Joomla install in a separate folder and carefully migrating settings, or ask a specialist.

Permissions, ownership and security settings

Start with directories set to 755 and files to 644. Do not set directories to 777 — this is insecure.
Ensure /logs and /tmp are writable by the web server; if you see permission errors, contact the host for correct ownership settings.
Remove any leftover /install directories and check your .htaccess file.

Test the site

Try the frontend and the admin login. If you encounter errors, proceed to the troubleshooting section below.

Warnings

Do not set permissions to 777. Incorrect permissions can expose your site to attacks.
Hosts use different ownership models (suPHP, FPM); if you experience permission problems, ask the host for their recommended ownership and permissions.

Common restore problems and how to fix them

These are frequent problems after a restore and practical ways to address them.

Database connection errors

Open configuration.php and verify $host, $user, $password, and $db match the database you created.
Check the table prefix in configuration.php ($dbprefix) and ensure it matches the imported tables in phpMyAdmin.
If the import failed, re-import and note errors in phpMyAdmin to guide fixes.

White Screen of Death (WSOD) or fatal PHP errors

Enable temporary error reporting for debugging (on a non-production environment) and check server error logs for PHP fatal errors.
Verify the PHP version and required extensions. Some old extensions may not work on newer PHP releases; if possible, switch to a compatible PHP version in cPanel temporarily.
If a third-party extension causes a fatal error, disable it by renaming its folder under /plugins or /modules to force Joomla to ignore it.

Missing media or broken links

Confirm /images and /media folders exist and contain files. Check permissions if images do not appear.
Search templates and extensions for hard-coded paths if links are broken and adjust paths or update configuration.

Admin login issues

Clear browser cookies and try logging in again.
If you must reset an admin password in the database, do not run SQL snippets copied from random sources — have a verified SQL snippet or use a tested recovery procedure. The exact SQL for resetting an admin password should be verified against Joomla 3.10 documentation and is listed in the article's verification checklist.

Technical warnings

Only enable verbose error reporting in a safe environment and revert it on a live site after debugging.
Always back up the database before running direct SQL statements. Editing the DB directly can break the site if done incorrectly.

Running an end-of-life Joomla 3.x site — risks and temporary mitigations

Joomla 3.10 and other 3.x releases may be at or near end-of-life. Running them carries increased security risk. Use these short-term mitigations while you plan an upgrade.

Short-term hardening checklist

Restrict access to /administrator by IP (use host IP restrictions or careful .htaccess rules). Be cautious: IP restrictions can lock you out if your IP changes.
Use strong, unique passwords for admin users and enable two-factor authentication (2FA) if available and compatible.
Install a Web Application Firewall (WAF) or enable host-provided WAF rules.
Remove unused extensions and templates, and update extensions that still receive updates.
Ensure HTTPS is enabled and force redirect to HTTPS site-wide.
Schedule frequent backups and monitor logs for suspicious activity.

Warnings

IP restriction rules in .htaccess can lock you out; always have an alternate access method or host console before enabling them.
Some hardening steps can interfere with necessary integrations (APIs, payment gateways). Test in staging if possible.

Upgrading strategy: move from Joomla 3.10 to Joomla 4 (high-level plan)

After your site is restored and stabilized, plan a careful migration to Joomla 4. Do not perform a production upgrade without testing in staging.

Compatibility checklist before upgrading

Create an inventory of installed extensions, plugins and templates and mark each as "compatible", "update available", or "no upgrade path".
Restore the Joomla 3.10 site to a staging environment and update all extensions to their latest 3.10-compatible versions before attempting the migration.
Check templates and custom code; many templates and custom overrides will require updates for Joomla 4.
Follow the official Joomla upgrade/migration guide and test the full site functionality in staging (forms, logins, payment flows, email, APIs).

Practical migration example (high level)

Restore backup to staging and verify the site works on a supported PHP version for Joomla 3.10.
Update extensions and fix issues discovered in staging.
Follow Joomla's documented upgrade path to move staging from 3.10 to 4.x and test carefully.
When staging is stable, schedule a production migration with full backups and a rollback plan.

Warnings

Upgrading major versions can break templates and custom code; ensure you have backups and a rollback plan.
Some third-party extensions may not have Joomla 4 versions; plan replacements where needed.

Checklist and next steps after a successful restore

After you restore the site, run these checks and start planning longer-term work.

30-minute, 24-hour, 7-day post-restore checklist

30 minutes: Verify homepage loads, login to admin, check server error logs for immediate fatal errors.
24 hours: Test forms, email delivery, payment flows (if applicable), and set up uptime monitoring.
7 days: Run security scans, review search indexing and analytics, and begin planning the Joomla 4 migration.

Key tasks

Install an SSL certificate and force HTTPS site-wide.
Set up automated backups (files + DB) with off-site storage and test restoring those backups periodically.
Enable logging and monitor logs for unusual activity for at least 72 hours after the restore.

Warnings

Don't declare the site fully restored until critical functionality (forms, payments, logins) is tested.
Monitor for performance regressions after a restore — caching and environment differences can affect speed.

Resources and where to get help

Use official documentation and trusted providers for technical procedures you are unsure about.

Recommended resources

Official Joomla documentation for system requirements, configuration.php reference, and migration guides — verify specific steps there before production changes.
cPanel and phpMyAdmin documentation for file and database operations on your host.
Reputable Joomla service providers or developers for complex recoveries, database corruption, or migrations.

When to hire a Joomla specialist

Hire a specialist if the database is corrupted, tables are missing, or the site shows signs of compromise.
If multiple extensions and the template require significant updates or rewrites for Joomla 4, a developer experienced in migrations can save time and reduce risk.

Safety tips when hiring

Vet contractors by asking for references and examples of prior Joomla restore/migration work.
Avoid giving full admin credentials to unvetted parties — use temporary accounts or supervise access where possible.

FAQ

Can I restore a Joomla 3.10 backup onto a site running Joomla 4?

No. Directly restoring a Joomla 3.10 backup into a Joomla 4 install is not advisable. Instead, restore the 3.10 backup into a separate Joomla 3 environment, test and update extensions and templates, and then follow the official Joomla 3.10 → 4 upgrade path on a staging copy before migrating production.

My host won't let me install older Joomla versions with Softaculous — what can I do?

Perform a manual restore: upload files, create a new database, import the SQL dump, and edit configuration.php. Alternatively, restore locally with XAMPP/Docker and then migrate to a new host. If the host refuses to cooperate, consider moving to a hosting provider that allows manual installs or ask the host to restore their snapshot for you.

How do I know if my backup is complete or missing important files?

Inspect the archive without extracting: look for configuration.php, an SQL dump, and Joomla folders such as /administrator, /components, and /templates. If critical items are missing, contact the host for a snapshot or search other backups (developer machines, older exports).

What should I do if the SQL import is too large for phpMyAdmin?

Split the SQL file or use the host's large-file import tool, import via SSH with the mysql CLI, or import locally using a higher-limit environment and then export a smaller, workable dump.

Is it safe to run Joomla 3.10 temporarily after restoring?

Running Joomla 3.10 temporarily can be acceptable with strict mitigations: restrict administrator access, apply all possible extension updates, install a WAF, use HTTPS, and monitor closely. Plan an upgrade to Joomla 4 as a longer-term solution.

Conclusion

A working Joomla 3.10 backup can usually be restored if you follow a cautious, step-by-step approach: preserve copies, inspect the archive, test locally, perform a manual restore on a new host (files + DB + configuration.php), resolve common errors, harden the site temporarily, and then plan the migration to Joomla 4. When in doubt, request snapshots from your host and consider engaging an experienced Joomla professional for complex or security-sensitive recoveries.

Always verify version and configuration details against official Joomla 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