How to Recover a Deleted Joomla Site from a 2022 Backup (Beginner's Guide)

Overview: What to do first when a Joomla site is deleted

When you discover the site is gone, take a few measured actions that preserve your chances of a full recovery.

Quick checklist before you start

• Document what you have: backup filenames, sizes, timestamps, and any host account emails.
• Confirm backup formats (e.g., .zip, .jpa, .sql, .sql.gz).
• Do not change live DNS or overwrite any existing production files.
• Gather access credentials you will need: cPanel/hosting login, FTP/SFTP, and database access.
• Make a duplicate copy of the backup files and work from the copy.

Choose your recovery target (local, staging, or new host)

Decide where to restore first: a local machine, a staging subdomain with a host, or a temporary new hosting account.

• Local — safest for private testing and experimentation (use XAMPP, WAMP, MAMP, or Docker).
• Staging — replicates server environment closer to production; useful if you plan to go live on the same host later.
• New host — fastest route to get public site back online but can involve DNS work and costs.

Technical warnings: Do not overwrite an active production site without a successful staging test. Keep the original backup untouched.

Step 1 — Identify and inspect your backup file

Before restoring, identify whether your archive is a packaged Akeeba backup, a manual file archive, or a database-only export. That determines the restore steps.

How to tell if the backup is an Akeeba JPA/ZIP or a manual archive

• Akeeba packages commonly use .jpa, .jps, or packaged .zip files and may include a manifest when extracted.
• Manual site archives typically show Joomla folders at the top level: configuration.php, administrator/, templates/, etc.
• Database-only backups will be .sql or compressed .sql.gz and will not include Joomla folders.

What files and DB tables to look for inside the archive

• Look for configuration.php (do not share this file — it contains credentials).
• Confirm presence of key folders: administrator/, components/, templates/, and media/.
• Open SQL files and check for CREATE TABLE statements and a table prefix such as jos_ or similar.

Practical example

Using cPanel File Manager, you can view an uploaded .zip without extracting by using the built-in listing feature. On a desktop, use a tool to list archive contents (for advanced users: unzip -l site-2022.zip) — but avoid extracting on a live site root.

Warning: configuration.php and SQL files contain sensitive credentials. Never publish or send them in an unsecured channel.

Step 2 — Ask the hosting provider for help and additional files

If the original host still has account records or snapshots, request specific exports. Hosts often retain backups for a time even after account closure.

What to request from the old host

• Ask for a compressed archive of the site's public folder (public_html or www) from the date you need.
• Request a mysqldump (database export) in gzip format from the relevant date.
• If the host offers snapshots, ask about snapshot timestamps, retention windows, and possible costs for retrieval.

How to communicate with support for best results

• Provide account identifiers, approximate deletion date, and the filenames you already have.
• Request files in standard downloadable formats (ZIP, GZIP) and ask if they can temporarily enable access to Softaculous or provide a cPanel backup.

Warning: Share credentials only via the host's secure support channels. Hosts have different retention policies — act quickly.

Step 3 — Choose a safe restore target (staging, local, or new host)

Restoring to a non-production environment reduces risk and allows you to troubleshoot without affecting visitors.

Set up a local environment: XAMPP, Local, or Docker basics

• Install a local stack such as XAMPP (Windows/Mac/Linux) or Local for beginners; ensure Apache/Nginx, PHP and MySQL/MariaDB are available.
• For experienced users, Docker can replicate server components more precisely (use official images and a docker-compose stack).
• Match PHP version and required extensions as closely as possible to avoid compatibility issues (verify exact versions with Joomla documentation).

When to prefer staging or a new host

• Use staging to validate the site under similar server software before switching DNS.
• Choose a new host when the old provider cannot help or if you need to go live quickly.

Warning: Local environments can behave differently from production. Avoid sending live emails from local or staging without configuring SMTP safely.

Step 4 — Manual restore with cPanel and phpMyAdmin (file + DB)

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

Upload and extract files

1. Upload the backup archive to the target folder (public_html, subdomain folder, or local web root).
2. Use cPanel File Manager to extract into an empty folder. If file size exceeds limits, upload via FTP and extract locally, or ask host for assistance.

Create a database and user in cPanel

In cPanel: MySQL Databases > create a new database > create a user > assign the user to the database with ALL PRIVILEGES. Note exact names (often user_dbname) for configuration.php.

Import the SQL

• Use phpMyAdmin > Import to upload an .sql or .sql.gz file. For large files, compress to .gz if supported.
• If phpMyAdmin times out, ask the host to import the SQL via command-line or use SSH and the mysql CLI: mysql -u user -p database < file.sql (advanced).

Edit configuration.php

Open configuration.php and update database settings: public $user, public $password, public $db, public $host, and public $dbprefix. Make a backup of configuration.php before editing.

Fix file and folder permissions

Set folders to appropriate permissions and ensure configuration.php is not world-writable. Verify logs and tmp folders are writable by the web server user.

Practical example

Restoring a 400MB zip via cPanel: if File Manager cannot upload a single 400MB file due to limits, split the archive or upload via FTP and extract. Import the matching SQL then update configuration.php to point to the new DB.

Warnings: Double-check the database name before importing to avoid overwriting an existing DB. When changing table prefixes, be careful: mismatches can cause broken admin login or missing content.

Step 5 — Restoring with Akeeba backups (if applicable)

If your archive is an Akeeba package, the Kickstart method automates extraction and DB import; it can be faster than manual methods.

Using Akeeba Kickstart (high-level)

1. Download the small kickstart.php helper from Akeeba (verify the official source).
2. Upload kickstart.php and the Akeeba archive (.jpa, .zip) to the restore folder.
3. Run kickstart.php in a browser and follow the extraction and installer steps to restore files and import the DB.

Common Akeeba pitfalls and fixes

• Large archives can exceed PHP memory or execution time; upload via FTP and run Kickstart or use chunked extraction.
• .htaccess rules may block Kickstart; check server error logs and temporarily adjust .htaccess if safe.

Security warning: Remove Kickstart and the archive from the webroot immediately after restoration to prevent unauthorized access.

Step 6 — Fix configuration and environment issues (PHP, DB, permissions)

After the restore, environment mismatches are a common source of errors. Use server logs and Joomla error reporting to diagnose issues.

Troubleshooting common errors

• DB connection errors: Re-check credentials in configuration.php and confirm the database user has privileges.
• 500 server error / blank page: Temporarily enable error reporting or review server error logs to view the underlying PHP error.
• Missing PHP extensions: Some Joomla features require specific PHP extensions; enable them in cPanel or ask the host.

Checking and updating PHP versions

In cPanel use the PHP selector to change versions. Match the PHP version to your Joomla version requirements as closely as practical, then test the site. Verify exact minimum/maximum PHP versions from official Joomla documentation before changing.

Warning: Do not leave error reporting enabled on a public site — disable it after debugging. Record current settings before making PHP changes so you can revert if needed.

Step 7 — Test the restored site and resolve extension/template issues

Thorough testing helps you find broken functionality caused by outdated extensions or an incompatible template.

Functional test checklist

• Frontend pages load and images/media appear.
• Administrator login works; you can access Extensions > Manage.
• Menus, modules, and forms operate as expected; sample content edits save correctly.
• Emails and contact forms function (use test SMTP credentials and avoid sending to live users from staging).

Handling third-party extensions and templates

• If the admin panel is accessible, disable suspicious extensions via Extensions > Manage.
• If admin access is unavailable, you can disable extensions directly in the database (advanced): take a DB backup first, then set enabled to 0 in the #__extensions or #__modules table as appropriate.
• Switch to a default Joomla template (Protostar/Beez) to check whether the custom template causes frontend issues.

Warning: When disabling extensions in the database, always make a database backup and document the change. Do not delete extension files until you have a tested replacement or update.

Step 8 — Plan the upgrade path (Joomla 3.10 → Joomla 4) and timeline

Once restored, you should plan an upgrade for security and compatibility. Upgrading can be straightforward for some sites but may require rebuilding for others.

Recommended workflow

1. Restore and test on staging.
2. Inventory all extensions and templates and check their Joomla 4 compatibility.
3. Update all extensions to their latest Joomla 3.10-compatible releases.
4. Run the core upgrade on staging and perform full tests.
5. Create final backups and prepare a rollback plan.

When to delay upgrading or consider a rebuild

If key extensions are not updated to support Joomla 4, or if the template is heavily customized and lacks an upgrade path, consider rebuilding parts of the site on a fresh Joomla 4 installation and migrating content selectively.

Warning: Never attempt a core upgrade on a live production site without staging validation and complete backups.

Step 9 — Go live checklist and security hardening

Before switching DNS or pointing the domain to the recovered site, perform a final security and functionality sweep.

Checklist before switching DNS

• Take a final staging backup or snapshot.
• Disable debugging and remove temporary error displays.
• Confirm SMTP/contact forms, payment gateways (if any), and email deliverability.
• Lower TTL in DNS records 24–48 hours before the switch to speed propagation (optional).

Security steps after restore

• Remove any installer scripts or backup archives from the webroot.
• Set secure file permissions and protect configuration.php from web access.
• Enable HTTPS with a valid certificate and consider security headers and a security extension if helpful.
• Set strong administrator passwords and consider two-factor authentication.

Warning: Do not leave backup files or restoration tools in a publicly accessible location after launch.

Preventing this in future: backups, hosting choices and documentation

Learn from the recovery process and put measures in place to reduce future risk.

Backup strategy recommendations

• Use automated off-site backups (cloud storage or remote FTP). Keep multiple retention points (daily, weekly, monthly).
• Test restores periodically to verify backup integrity.
• Store credentials securely in a password manager, not in plaintext files.

Choosing Joomla-friendly hosting

• Prefer hosts with flexible PHP version selection, reasonable backup retention, SSH access for advanced restores, and responsive support.
• Consider managed Joomla hosts if you prefer hands-on assistance with restores and migrations.

Maintain a minimal site documentation file listing installed extensions, template names and versions, license keys (stored securely), and staging credentials.

FAQ

Conclusion

Recovering a deleted Joomla site from a 2022 backup is usually possible with careful, staged steps: identify the backup type, request any additional files from the host, restore into a safe environment, troubleshoot environment or extension mismatches, and plan a cautious upgrade path. Takeaways: always keep multiple off-site backups, document your site details, and test restores periodically so a single mistake or hosting issue does not cause long-term loss.

If you follow the steps above and verify server and extension compatibility with official documentation before touching a production site, you will minimize risk and have a clear path to recovery.

Quick practical checklists

Immediate actions

• Duplicate backup files and store a safe copy offsite.
• Collect host account emails, deletion date, and account identifiers.
• Decide: local, staging, or new host for the first restore.

Pre-launch checklist

• Final backup of staging site.
• Disable debugging, clear caches, verify forms and email.
• Remove installers and archives from webroot; secure configuration.php.