How to recover a Joomla 3.10 backup after your host deleted the site (recovery & migration guide)

Quick overview: what this guide covers and immediate first steps

This section sets expectations and lists the immediate small actions you should take before attempting any restore.

First triage checklist (do these now)

• Copy the backup files you already have to a safe local folder on your computer. Work only with copies; do not overwrite the originals.
• Do not attempt an immediate live restore unless you have no choice. Prefer a local or staging test first.
• Collect account details: cPanel/FTP/SSH access, database names (if known), domain registrar credentials and any emails about account suspension or deletion.

What to expect from this guide

• Multiple recovery options: manual file+DB restore, restore to a local/staging server, and Akeeba/installer-based recovery.
• Common blockers covered: host installer policies, PHP compatibility, missing database, and DB prefix mismatches.
• Actionable next steps to test and upgrade a restored Joomla 3.10 site.

Practical example: if you have a ZIP file and a site.sql.gz file, copy both to a folder named "site-restore-2022" and keep the originals untouched.

Warning: attempting to restore into an existing live Joomla installation without testing can overwrite a working site; always work on copies or staging first.

Step 1 — Assess the backup you have (files, SQL, archive type)

Before any restore, you must understand exactly what your backup contains. Different archive types require different restore methods.

Common backup types and why they matter

• File archive (zip/tar) + separate SQL dump (.sql or .sql.gz): requires manual file upload and database import.
• Akeeba backup (.jpa/.jps): typically contains both files and DB and is restored with Akeeba Kickstart/Installer.
• Full cPanel backup (.tar.gz): may include all account files and server-side DB dumps and can be restored by cPanel or manually unpacked.

How to open and inspect the backup archive

• Use desktop tools like 7-Zip, WinRAR, or macOS Archive Utility to list archive contents without extracting everything.
• Look for a configuration.php file at the archive root or inside the site folder — this file reveals DB names, prefixes and some path settings.
• Check for an SQL file (site.sql, database.sql, or .sql.gz). If you have a .jpa, plan on using Akeeba Kickstart or extracting it with the proper tool.

Finding the SQL dump and verifying charset

• Open the SQL file in a text editor (or inspect the first few lines) to ensure it includes CREATE TABLE and INSERT statements.
• If the SQL is compressed (.gz), decompress locally first. Check for charset declarations such as utf8mb4 or utf8 to avoid import charset problems later.

Checking configuration.php values you will need

• Important fields: public $host, public $user, public $password, public $db, public $dbprefix, $log_path, $tmp_path. Record these values for the restore.
• Note the DB table prefix (for example, jos_ or abc_) — this often prevents table name mismatches on import.
• Do not share configuration.php contents publicly. Redact passwords before sending anything to support.

Practical example: your archive contains configuration.php and site.sql.gz. After decompression, you find DB name cp_user_mysite and prefix jos_abc. Create a database and set configuration.php accordingly during restore.

Warning: corrupt or partial archives can fail during extraction. Test extracting once on a local machine with sufficient disk space before attempting a server restore.

Step 2 — Contact the host and domain/registrar (what to ask and expect)

Even if the host deleted the account, they may still have server-side backups with short retention windows. Contacting them early increases your chance of full recovery.

Exact information and files to request from support

• Request a full cPanel account backup (.tar.gz) and a separate MySQL dump exported from the server for the date before deletion.
• Ask for file-level backups of public_html or equivalent and any mailbox or logs you might need (FTP/SSH logs, access logs) to document the timeline.
• If they offer temporary re-enabling of the account to let you download files, ask if that is possible.

How to communicate: sample support message

Keep your support request short and factual: include account email/username, domain, approximate deletion date, and a request for a full cPanel backup and MySQL dumps. Only provide sensitive file contents (like configuration.php) if requested and via secure channels.

When to involve the domain registrar

• Confirm the domain is still under your control and that DNS records were not changed. If the domain expired or was transferred, contact the registrar immediately.
• Keep evidence of domain renewal notices and registrar emails—these help in disputes and recovery requests.

Warning: never paste database passwords into public support forums. Use the host's secure ticketing system or an agreed secure channel.

Option A — Manual restore on your current hosting (step-by-step)

This is the most universal method: upload files, create a database, import SQL, and update configuration.php.

Create a database and user in cPanel — required settings

1. Open cPanel > MySQL Databases and create a new database.
2. Create a database user and set a strong password.
3. Assign the user to the database with ALL PRIVILEGES and note the full DB name and username (hosts often prepend an account prefix).

Upload files (FTP/File Manager) and set file permissions

• Recommended approach: upload the archive and extract using File Manager if available. For large backups, extract locally and upload via SFTP.
• Default permissions: folders 755 and files 644. Consider 640 or 600 for configuration.php if supported by the host.
• Ensure the paths for $log_path and $tmp_path in configuration.php point to directories that exist and are writable.

Importing the SQL dump with phpMyAdmin or CLI

• Use phpMyAdmin import for small-to-medium SQL files. For large files, ask the host to import via mysql CLI to avoid upload and timeout limits.
• If the DB prefix in your SQL is different than configuration.php, either change configuration.php to match the imported tables or perform a careful SQL search-and-replace. Always keep a copy of the original SQL before changing it.
• Watch for errors about character sets; import using the correct charset (see SQL header comments for hints).

Editing configuration.php after restore (host, DB name, user, prefix)

• Update public $host, public $user, public $password and public $db to match the database you created.
• Set the public $dbprefix to the prefix used in the imported tables.
• Confirm $log_path and $tmp_path point to valid server paths. Some hosts use custom paths under the home directory.

Run the site and fix fatal errors (PHP version mismatch)

• If you encounter a white screen or fatal error, check server error logs and the PHP version. Many errors arise from PHP version incompatibility with older extensions.
• If your host allows changing PHP versions per-site, try switching to a version close to what the site previously used (verify supported versions before changing).

Manual restore example: extract the backup locally; upload files to public_html via SFTP; in cPanel create DB cp_user_mydb and user cp_user_dbuser; import site.sql via phpMyAdmin (or request host CLI import); edit configuration.php to use cp_user_* credentials; set permissions; visit the site.

Warning: changing DB prefixes by search-and-replace can break third-party extensions that hardcode table names. Always keep original SQL backups.

Option B — Restore to a local or staging environment (safe testing)

Testing locally or on a staging subdomain reduces risk. You can diagnose PHP issues, extension conflicts, and template problems safely.

Create a local server (XAMPP/MAMP/Docker) and required PHP settings

• Install XAMPP, MAMP or a Docker stack. Choose a PHP version compatible with Joomla 3.10 for initial testing (verify exact supported versions before production changes).
• Enable required PHP extensions such as mysqli, mbstring, json and xml (check Joomla docs for the full list).
• Adjust php.ini settings temporarily for large imports: upload_max_filesize, post_max_size, memory_limit, and max_execution_time.

Upload files and import DB locally

• Place the site files into your local web root and import the SQL into a local database using phpMyAdmin or mysql CLI.
• Update configuration.php with your local DB credentials (commonly localhost).
• If testing domain-specific paths, update your hosts file to map the domain to 127.0.0.1 for testing.

Testing and common fixes in local environment

• Enable Joomla error reporting in configuration.php to help spot problems. Use error reporting only in local or staging environments.
• Install the same extensions locally or disable problematic extensions to see if the site loads without them.
• Try a test Joomla core update locally first. If the upgrade fails locally, it will likely fail on a live site too.

Local restore example: install XAMPP with PHP 7.4, create database joomla_local, import SQL, update configuration.php and, if needed, modify /etc/hosts to test the original domain locally.

Warning: performing search-and-replace on the DB for URLs can corrupt serialized data stored by extensions if you don't use a tool that handles PHP serialization correctly.

Option C — Use backup tools or installers (Akeeba, Softaculous restore workflows)

When your backup is an Akeeba .jpa or you prefer installer tools, specialized workflows can simplify the process — but hosts sometimes block older core installers.

Restoring an Akeeba .jpa backup using Kickstart

• Upload Akeeba Kickstart (kickstart.php) and the .jpa file into a web-accessible folder and run the kickstart script in your browser.
• Kickstart extracts files and starts the Akeeba Installer that will prompt for DB credentials and perform the install steps.
• After a successful restore, delete kickstart.php and any installer files immediately and verify configuration.php settings.

Using Softaculous or host 'restore' tools and dealing with blocked installers

• Many hosts prevent installing older core software via Softaculous for security reasons. If Softaculous blocks the Joomla 3.x installer, ask the host if they can restore your files and DB directly to the account rather than re-running an installer.
• Workarounds include restoring into a staging subdomain running a compatible PHP version or performing a manual file and DB restore.
• Ask support whether they can temporarily enable the required installer or PHP version for the restore.

When to use professional migration services

• If backups are partial, damaged, or the site contains many outdated extensions, a paid migration specialist can handle complex serialized data replacements and extension replacements safely.

Practical example: you find a file site_backup.jpa. Upload kickstart.php and the .jpa into public_html/restore and run your production domain/restore/kickstart.php. Follow the prompts and remove installer files afterward.

Warning: leaving Kickstart or installer files on a live site is a security risk — remove them immediately after use.

Common problems and troubleshooting (PHP errors, DB prefix, permissions)

These are the typical issues you will encounter during a restore and practical ways to diagnose and fix them.

Database connection errors

• Verify configuration.php DB credentials exactly match the database name and user on the server. Some hosts prefix DB names with an account slug.
• Confirm the DB user has the required privileges. If in doubt, reassign ALL PRIVILEGES temporarily for the restore step and tighten later.
• Check that public $dbprefix matches the actual table prefixes in the imported database. A mismatch will cause missing table errors.

PHP fatal errors and version mismatches

• Inspect server error logs via cPanel or ask the host for the most recent PHP error log entries.
• If extensions or templates use deprecated PHP functions, try changing the PHP version to one close to the site's original environment.
• Record error messages and search extension/template vendor documentation for compatibility notes before making core changes.

Permissions and missing files

• Set directories to 755 and files to 644 by default. Ensure tmp and logs are writable by the webserver (often 755 plus ownership by the webserver user).
• If media or uploaded files are missing, check if those folders were omitted from the backup and request them from the host if possible.

Troubleshooting example: the site shows "Could not connect to database". Open configuration.php and verify host, DB name and user; then log in to phpMyAdmin to confirm the DB exists and the user can access it.

Warnings: enabling full error reporting on a live site exposes server paths and sensitive information. Use error reporting only on local/staging environments or briefly with the site offline.

Next steps: testing, upgrade path and compatibility checks

Once a restored site is running, plan an upgrade and harden the site. Joomla 3.10 was provided as a bridge to Joomla 4, so upgrades need careful testing.

Inventory extensions and templates

• In the Joomla administrator, list installed extensions and note their versions. Identify extensions and templates that are no longer maintained.
• Check vendors for Joomla 4 compatibility or updated releases. If an extension is abandoned, find replacements before upgrading core.

Performing test upgrades and rollback plans

• Take a complete snapshot (files + DB) of the restored site before any upgrade.
• Perform staged updates: update extensions that offer Joomla 4 compatibility first where available, then attempt a core upgrade on staging/local test sites.
• Keep a rollback plan: retain the original snapshot so you can revert quickly if the upgrade introduces errors.

Security checks and cleanup

• Reset all passwords (Joomla admin users, DB users, FTP/SFTP). Remove any unused admin accounts.
• Install a security extension or enable security hardening features and configure scheduled automated backups.

Upgrade example: in staging, update extensions to their latest Joomla 4-ready releases, switch the Joomla Update component to a testing channel and run the 3.10 → 4.x upgrade. Test thoroughly before applying changes on production.

Warning: some templates or extensions lack upgrade paths; replacing them may require layout adjustments and manual content migration. Always test first.

Preventive checklist: backups, hosting and policies to avoid repeat loss

After recovery, improve your hosting and backup strategy to prevent future incidents.

Automated backup recommendations

• Keep at least two backup copies: one offsite (cloud storage) and one local. Retain weekly and monthly snapshots for longer-term recovery.
• Use a reliable backup tool such as Akeeba Backup or host-managed snapshots. Configure automated uploads to S3, Google Drive or another offsite service.
• Test a full restore on staging or local every few months to ensure backups are usable.

Hosting selection and account management

• Choose hosts that provide clearly documented backup retention and easy staging options. Prefer hosts that allow account snapshots or full cPanel backups.
• Keep billing and contact information current and set calendar reminders for domain and hosting renewals.
• Consider managed Joomla hosting for automatic updates, backups and security monitoring.

Policy and documentation checklist

• Maintain a recovery playbook that includes backup locations, DB credentials, restore steps and vendor contacts.
• Document extension licenses and how to re-download any commercial extensions after a restore.

Practical example: schedule daily site archives with Akeeba and configure automatic upload of weekly archives to Amazon S3. Keep monthly DB-only exports for long-term retention.

Warning: do not rely on a single backup location. Hosts can lose backups too.

Summary checklist and recommended resources

Use this compact checklist to guide immediate recovery and longer-term improvements.

One-page recovery checklist

1. Save original backups to a local disk (copy only).
2. Contact the host immediately and request full cPanel backup and MySQL dumps.
3. Restore to local or staging first whenever possible.
4. Import DB and upload files; update configuration.php with correct DB credentials and prefix.
5. Test site, fix errors (permissions, PHP version, missing extensions).
6. Plan and test an upgrade; implement a robust automated backup strategy after going live.

Tools and resources (recommended)

• Akeeba Backup + Kickstart — for full-site backups and easier restores.
• phpMyAdmin or mysql CLI — for database import/export.
• XAMPP, MAMP or Docker — for local testing.
• SFTP client (FileZilla) or cPanel File Manager — for file uploads and extraction.

Next reading: follow official Joomla upgrade and backup documentation and the Akeeba docs before performing production upgrades. Verify host-specific recovery options with your provider.

FAQ

Can I restore a Joomla 3.10 backup if my host blocks installing older Joomla versions?

Yes. If you have the raw files and the database dump you can perform a manual file+DB restore or restore to a staging/local environment. Akeeba Kickstart can also restore .jpa backups. If Softaculous blocks older installers, ask the host to restore files and DB directly or to provide a temporary environment with a compatible PHP version. Verify options with your host.

How do I know whether my backup contains the database?

Open the archive and look for files ending in .sql or .sql.gz, or for an Akeeba .jpa which usually contains the DB. If you only have site files and no SQL file, the database may be missing — contact the host immediately to request a server-side DB export.

What PHP version do I need to run Joomla 3.10?

Joomla 3.10 was intended as a bridge release and supports a range of PHP versions, but exact supported versions and recommendations change over time. Verify the current supported PHP versions in the official Joomla documentation before changing server PHP settings or making production changes.

Is it safer to restore locally or to the live site?

Restoring to a local or staging environment is safer. It allows you to find and fix compatibility issues and test an upgrade without risking live traffic. Only push to production once tests pass and you have a tested rollback snapshot.

What should I ask my host to retrieve after my account was deleted?

Ask for a full cPanel backup, raw MySQL dump(s) for the site databases, public_html or site file backups, and any relevant logs. Confirm their backup retention policy and whether they can temporarily re-enable the account to let you download files.

How can I prevent this from happening again?

Implement automated offsite backups, choose a host with clear backup and retention policies, keep billing and contact info current, and test restores periodically. Consider managed Joomla hosting if you want the host to handle backups and updates.

Conclusion

Recovering a Joomla 3.10 backup after a host deletes the site is usually possible if you have the file archive and database dump. Prioritize copying backups locally, contact your host quickly for any server-side backups, and restore into a staging or local environment to debug safely. Use Akeeba where available to simplify restores, and plan an upgrade path and improved backup strategy once the site is running. Before making production changes, verify technical details such as supported PHP versions and upgrade steps against the official Joomla documentation.

If you'd like, follow the suggested next steps in this guide and consult JoomlaForever tutorials on Akeeba backups and local staging to proceed methodically.