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.
When you discover the live site is gone, act carefully to preserve data and recovery options.
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).
Before restoring anything, confirm the backup is complete and safe to import.
Hosts often retain snapshots or backups for a window after account deletion. Ask specifically and politely for what you need.
/home/username/public_html (or the path they used) for a specific date."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."
Restoring the backup to a local environment helps you test and fix issues without affecting production systems.
C:/xampp/htdocs/site).mysql -u user -p dbname < backup.sql).configuration.php to use the local DB credentials and local paths.http://localhost/site to check for errors and missing assets.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.
This section shows a safe manual restore workflow using cPanel and phpMyAdmin for hosts that block older installer versions.
site_db).jos_ or custom prefixes).public_html) using cPanel File Manager or FTP and extract it there.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.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./logs and /tmp are writable by the web server; if you see permission errors, contact the host for correct ownership settings./install directories and check your .htaccess file.Try the frontend and the admin login. If you encounter errors, proceed to the troubleshooting section below.
These are frequent problems after a restore and practical ways to address them.
configuration.php and verify $host, $user, $password, and $db match the database you created.configuration.php ($dbprefix) and ensure it matches the imported tables in phpMyAdmin./plugins or /modules to force Joomla to ignore it./images and /media folders exist and contain files. Check permissions if images do not appear.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.
/administrator by IP (use host IP restrictions or careful .htaccess rules). Be cautious: IP restrictions can lock you out if your IP changes.After your site is restored and stabilized, plan a careful migration to Joomla 4. Do not perform a production upgrade without testing in staging.
After you restore the site, run these checks and start planning longer-term work.
Use official documentation and trusted providers for technical procedures you are unsure about.
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.
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.
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).
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.
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.
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.
The Joomla message “Update not possible because the offered update has expired” can be alarming, but in many cases it is temporary and harmless. This guide explains what the message usually means, safe immediate checks you can perform, how to prepare backups and staging tests, and how to proceed if you need to update manually. Follow the step-by-step advice below and verify any technical commands or UI paths against official Joomla documentation for your Joomla version before making changes to production sites.
This is a short, practical summary so you know whether to act immediately or simply wait.
The update system on your Joomla site received an "offer" from an update server that included an expiry indicator or validity window; when your site checks later that offer may no longer appear valid, so Joomla reports the offer as expired. Often this is a timing or caching issue rather than a local site failure.
Take a backup, then either wait a short while for the offer to refresh or perform the low-risk checks below.
If your site is non-critical (a personal blog), wait 1–2 hours and check the Update page again. If your site is business-critical (an online shop) take a full backup immediately and follow the low-risk checks; consider cloning to staging for any manual updates.
Understanding the typical causes helps you decide whether to wait or act.
An "offer" is metadata sent by an update server describing an available update: version number, package URL, and sometimes timestamps or digital signatures. If that metadata includes a limited validity window or if the metadata on the server is updated/rotated, a site may see the offer as expired until the update servers refresh or caches are cleared.
Host or CDN caching layers can serve stale update metadata to your site. Clearing the Joomla update cache may help, but host-level caches or firewalls might still block a fresh request — in that case contact your hosting provider.
Joomla.org publishes update metadata; if the metadata is reissued or has a short validity timestamp, some sites might briefly report the offer as expired until servers and caches propagate the new metadata.
Details about update metadata, timestamps, and signatures can differ by Joomla version and update server configuration. Verify specifics against official Joomla documentation before assuming the exact mechanism for your version.
These non-destructive checks give you information without risking the site.
Clearing the update cache is a low-risk action that often refreshes available update offers. The Extension Manager or Update component in Joomla has a cache-clearing option; the exact menu labels may vary by Joomla version—verify the path on your site before proceeding.
Check official Joomla release pages and announcements to confirm whether an update was withdrawn or reissued. For critical sites, subscribe to official channels and release notes so you can act promptly when a security update is published.
Steps prioritized by risk so you can choose what to do next.
If your site is business-critical or the update is a security patch, clone the site to staging, perform the manual update there, and test thoroughly. Only apply the same process on production after successful staging tests.
Decision example: For a hobby site, waiting is fine. For an ecommerce site with a security patch, take a backup immediately and perform an update on staging first, then schedule production downtime for the update.
If waiting and low-risk checks don't resolve the issue and the update is urgent, the manual methods below are options. Always test on staging first.
Some Joomla deployments support command-line tools for maintenance, which can be useful for large sites or scripted workflows. CLI update commands and availability depend on your Joomla version and server setup. Verify exact command syntax and support in official Joomla documentation before using CLI on production.
Avoid copying core files manually unless directed by official guidance. Replacing files manually risks missing database updates or leaving mixed file sets that break the site.
A simple monitoring plan helps you avoid unnecessary or risky repeated actions.
Retry cache clearing and 'Find Updates' once after 15–30 minutes and again after an hour. If, after repeated tries over 24–48 hours, the update still does not appear and the update is important, perform a manual update on a staging clone.
Sample log entry: 10:05 — saw expired offer message; 10:10 — created backup; 10:15 — cleared update cache; 10:45 — rechecked (no change); 12:30 — rechecked (no change); 24-hour check — no official notices; plan: clone to staging and test manual update.
If waiting and simple checks don't fix the problem, the following diagnostics can identify the cause.
Third-party extensions that alter the Extension Manager or update flow can interfere. Test by disabling non-essential extensions on a staging clone to see if update discovery behaves differently.
If logs show repeated HTTP 403 when contacting updates.joomla.org, contact your host with the exact timestamps and log lines so they can identify and resolve an outbound block.
Use this copyable checklist before any update activity to ensure you can recover if things go wrong.
Decision guidance to choose the appropriate path based on site risk and urgency.
For a security patch affecting an online store: backup, clone to staging, apply and test the update on staging (including transactions), then schedule a short maintenance window to update production.
Copyable checklist you can use immediately or paste into a support ticket.
1) Record the exact error message and timestamp.
2) Create a full backup (files + database) and store it off-server.
3) Clear Joomla update cache in the admin.
4) Re-run 'Find Updates' or the equivalent.
5) Check Joomla.org release notes/announcements.
6) If the update is urgent, clone the site to staging and perform a manual update there first.
7) If blocked by host-level issues (HTTP errors, firewall), contact your host with logs and timestamps; if the issue is beyond your comfort, contact a Joomla professional.
Always ensure backups are verified before attempting manual installs or file-level changes.
Typically, it is a temporary timing or cache issue with the update server and not an immediate emergency. Back up the site, check official Joomla announcements, and try the low-risk checks such as clearing the update cache and re-running update discovery.
For most situations wait a few hours. Recheck hourly for the first 1–2 hours, then every few hours or daily depending on urgency. For critical security updates, escalate to staging/manual update after a short wait and a backup.
You can manually install an official update package via the Extension Installer after taking a full backup and testing on staging. Avoid file-level manual replacements unless you have experience and a tested rollback plan.
Clearing the update cache often helps by removing stale offers, but it depends on the root cause. Host or CDN caches and server-side issues can still prevent the update from appearing.
Contact your host if logs show blocked requests or host-level caching/firewalls may be interfering. Contact Joomla community channels after you have checked official announcements and collected logs and timestamps for troubleshooting.
Include Joomla version, PHP and database versions, the exact error message and timestamp, steps already taken (backups, cache cleared), and relevant log snippets to help support diagnose the problem quickly.
The "offered update has expired" message is commonly temporary and resolved by servers and caches refreshing. Start with non-destructive checks: back up your site, clear the update cache, and monitor the Update screen. For urgent or security-related updates, clone to staging and perform manual updates after testing. If you see host-level errors or repeated failures, provide clear logs and timestamps to your hosting provider or a Joomla professional. Verify any Joomla-specific instructions against the official Joomla documentation before applying them to production systems.
Discovering a long-running Joomla site has been deleted by a host is stressful, but recovery is often possible. This guide gives a clear, step-by-step workflow for beginners: gather what you have, ask the host for server backups, inspect your archive, restore into a safe environment (local or staging), perform a manual or Akeeba-based restore, troubleshoot common issues, and plan an upgrade to Joomla 4. Read the warnings and checklists carefully — making changes without preparation can make recovery harder.
This section explains why hosts and auto-installers sometimes block older Joomla versions and summarizes your main recovery paths so you can choose the right approach.
Many hosts limit automated installation of end-of-life (EOL) CMS versions to reduce security exposure on their shared platforms. This is a policy decision by the host and not an absolute technical block to manual restoration.
Choose based on what you actually have:
Before attempting any restore, collect every piece of data and every credential you can. Work from a checklist so you do not miss anything important.
Common items inside a full Joomla backup:
Example file list for a full backup: configuration.php, index.php, administrator/index.php, components/com_content, templates/your-template, dump.sql.
Contact your hosting provider promptly and politely. The faster you ask, the better the chance a recent snapshot still exists.
"My site [your production domain] was removed on [date]. Please check for backups from [date range] and provide a copy of site files and the MySQL dump. Could you also confirm which PHP and MySQL/MariaDB versions are available and whether you can restore to a staging area?"
Before you restore anything, inspect the archive on your computer to understand what type of backup you have and whether it is complete.
Akeeba archives typically use .jpa/.jps or may be ZIP files with Akeeba metadata. A plain backup shows the Joomla folder structure and a SQL dump file.
Always restore first to a safe environment: a local machine (XAMPP/MAMP/Docker), a staging subdomain at your host, or a new temporary hosting account. This prevents accidental downtime for any existing production site.
Install XAMPP or MAMP and create a folder for the restored site. Alternatively use Docker to replicate the PHP and MySQL versions of the original server.
If your backup includes both files and an SQL dump, you can restore manually. Follow the ordered steps below and test each step before moving on.
Open configuration.php and update database host, database name, username and password to match the new DB. Also check $log_path and $tmp_path if the server path differs from the original environment.
If restoring to a different domain or test URL, update absolute URLs in the database. Use a tool that understands serialized PHP data if your site stores serialized arrays in the DB.
After restoring files and database, you may encounter errors. This section lists typical problems and practical fixes.
If the front-end fails due to a template or extension, switch to a core template (like Protostar for Joomla 3) to regain access, then re-install or update the broken extension.
You may need to increase memory_limit, max_execution_time or upload_max_filesize during import and extraction. Also ensure required PHP extensions such as mbstring, json and xml are enabled (verify the exact list against Joomla documentation).
Joomla 3.10 is commonly used as a transition to Joomla 4. After restoring, plan an upgrade rather than staying long on an older release.
When manual restore is difficult, consider alternative approaches that may save time and reduce risk.
If your backup is an Akeeba archive (.jpa/.jps/.zip) and Kickstart is available, upload the archive and kickstart.php to the target folder and run kickstart.php in a browser to extract and run the Akeeba installer. Akeeba automates much of the file and DB restoration process.
Specialized migration services can move a site between hosts, handle serialized data issues, and address compatibility problems. This is often the most reliable option for critical or complex sites.
Before switching DNS or replacing a live site, run through this pre-launch checklist on your staging copy.
This concise troubleshooting section helps you diagnose typical restore failures.
After recovery, prioritize securing the site and setting up a maintenance routine to prevent future loss.
Yes — if your backup contains both site files and a database dump you can restore manually or with Akeeba on a new host. Ensure the new server supports compatible PHP and DB versions and test the restore on staging first.
Ask the host for server backup snapshots or a temporary staging restore. Alternatively perform a manual restore from files + SQL or restore locally and then migrate the working copy to the new host.
Open the archive with 7-Zip or use tar -tf to list contents. Look for Joomla folders such as /administrator and a SQL dump file. Akeeba archives use .jpa/.jps extensions and include metadata identifying them.
Create a database and user, upload/extract files into webroot, import the SQL dump into the database (via phpMyAdmin or mysql CLI), edit configuration.php to match the new DB credentials and paths, set correct permissions, and test.
Joomla 3.10 supports a range of PHP versions, but exact supported and recommended versions should be verified against the official Joomla system requirements before proceeding.
Use a local server (XAMPP/MAMP/Docker), create a staging subdomain, or modify your hosts file to point a test domain to the staging IP so that public DNS is unaffected.
Disable or update problematic extensions, switch to a default Joomla template if needed, enable error reporting in staging to identify issues, and plan replacements for extensions that are not supported.
Only after the restored site is stable and backed up. Update all extensions to their latest 3.x versions, run the Pre-Update Check on a staging copy, and perform the upgrade in staging before upgrading live.
Hire a Joomla specialist if the site has custom code, complex integrations, or if you are uncomfortable performing manual restores and upgrades yourself.
Restoring a Joomla 3.10 site from a 2022 backup is usually achievable even if automated installers are blocked. The safest path is to gather all available data, ask the host for backups and environment details, restore into a local or staging environment, and follow a careful manual or Akeeba-based restore workflow. After restoring, secure the site, schedule reliable offsite backups, and plan a tested upgrade to Joomla 4. If the site is business-critical or complex, engaging a Joomla professional is a sound investment.
Note: Verify PHP and database version requirements, configuration.php variable names, and any host-specific policies against the official Joomla documentation and your host’s support documentation before making production changes.
A recently reported vulnerability affecting SP Page Builder has been linked in some reports to attackers creating hidden Super Administrator accounts and planting PHP backdoors. This article gives Joomla site owners a practical, time‑prioritised checklist to assess risk, contain an incident, detect and remove rogue Super Users and backdoors, and harden sites afterward. Technical details that depend on vendor advisories are flagged for verification — always confirm version and patch information with JoomShaper or official security notices before acting in production.
This is a concise action list for site owners who need to act fast.
Switch the site to maintenance mode → take a full backup snapshot → change admin passwords from a clean machine → inspect Users and recent file changes → update extensions and Joomla core.
WarningsUnderstanding the attack pattern helps prioritise checks and cleanup steps.
Practical analogy: attackers often leave a spare key (hidden Super Admin) and a toolset (PHP backdoor) to get back in later.
WarningsA prioritized, time‑boxed list to limit damage while preserving evidence.
Concrete checks you can do in Joomla admin, the database, and the server filesystem. Where commands or SQL are shown, they are examples and must be verified for your environment.
Follow a safe sequence: isolate → backup → identify → quarantine/remove → patch → rotate → monitor.
If you are unsure about any step, consider restoring a verified clean backup into a staging environment and performing updates and tests there before returning to production.
Use this decision guide to decide whether to clean the live site or restore from a verified clean backup.
Longer‑term steps to reduce exposure and detect intrusions early.
Know when to escalate to hosting, a security specialist, or law enforcement.
Always verify technical claims with authoritative sources before making production changes.
Practical verification flow: check the vendor advisory → confirm the fixed version → test update in a staging environment → update production and monitor.
WarningThird‑party blog posts and forum reports are useful for indicators but should always be confirmed by vendor advisories or CVE entries before concluding specifics.
No. Having the extension installed does not guarantee compromise. Check your extension version against the vendor advisory, take immediate containment steps (backup, maintenance mode, rotate credentials), and scan for indicators like unexpected Super Administrator accounts and unknown PHP files. Verify version and patch details with the vendor before concluding.
Take a full backup first. Then disable or lower the privileges of suspicious accounts via Users → Manage rather than deleting immediately. Record account details and quarantine any related files. Apply vendor patches, rotate credentials, and monitor logs for reappearance before permanent deletion.
Unpublishing may help as temporary containment, but it does not remove existing backdoors or accounts. Treat it as one short‑term measure while you back up, scan, and patch. Verify the effect of unpublishing with vendor guidance.
Restore when you have a verified clean backup from before the compromise, when many files or components are affected, or when you cannot identify persistence mechanisms. After restore, update the site and extensions before putting it back online.
Collect web server access logs (Apache/Nginx), PHP error logs, Joomla logs (if enabled), and hosting or control panel logs. Preserve these logs offserver for forensic review and provide them to your host or a security responder upon request.
Start with your hosting provider for snapshots and raw logs. If the issue is complex or persists, engage a Joomla‑experienced security firm. Consider notifying authorities if sensitive personal data was exposed, according to local regulations.
Act quickly but carefully: preserve evidence with a backup snapshot, contain access (maintenance mode and host‑level blocks if possible), rotate credentials from a trusted device, and scan for suspicious Super Administrator accounts and PHP files. Verify vendor advisories for SP Page Builder and apply patches promptly. If the compromise appears wide or persistent, prefer restoring a verified clean backup or engaging a Joomla security specialist. Always verify technical details against official advisories before making production changes.
Joomla module versioning: learn what Joomla 6.1 adds, how to upgrade safely, developer notes, system checks and roadmap guidance for site owners.
Proof-of-work CAPTCHA Joomla 6: learn what Joomla 6 adds, how to upgrade safely, developer notes, system checks and roadmap guidance for site owners.
Joomla 6 server requirements: learn what Joomla 6 adds, how to upgrade safely, developer notes, system checks and roadmap guidance for site owners.
Joomla 6.1 update checklist: learn what Joomla 6.1 adds, how to upgrade safely, developer notes, system checks and roadmap guidance for site owners.
Joomla 6.1 module language associations: learn what Joomla 6.1 adds, how to upgrade safely, developer notes, system checks and roadmap guidance for site owners.
Swetrix self-hosted analytics for Joomla: learn what the latest Joomla release adds, how to upgrade safely, developer notes, system checks and roadmap guidance
N8n Joomla integration: learn what the latest Joomla release adds, how to upgrade safely, developer notes, system checks and roadmap guidance for site owners.
Joomla in 2026: learn what Joomla 6.1 adds, how to upgrade safely, developer notes, system checks and roadmap guidance for site owners.
Comprehensive guide to Joomla 6.0.4 and 5.4.4: learn what's new, security and performance fixes, compatibility notes, and a step-by-step safe upgrade checklist with staging, backups, troubleshooting and rollback instructions.
Ultimate Joomla migration guide: step‑by‑step planning, backups, core/template and extension migration, database transfer, SEO-preserving 301 redirects, staging tests, performance and security checks, plus recommended tools and best practices.
The Joomla Content Editor (JCE) is a powerful extension designed to simplify and enhance content creation within the Joomla content management system. Joomla’s default editor options can be limiting, especially for users who need more control over formatting, multimedia management, and layout...
Automation tools streamline repetitive tasks, allowing users to save time and reduce manual errors. Popular no-code automation platforms include Zapier, Make.com (formerly Integromat), and IFTTT.
Joomla is a widely-used, open-source content management system (CMS) recognized globally for its flexibility, scalability, and ease of use. It powers millions of websites ranging from personal blogs to large-scale corporate portals and government websites. Joomla provides a robust framework that...
Admin Tools by Akeeba Ltd is one of the most respected and powerful administrative extensions available for Joomla. It serves as an all-in-one toolkit aimed at improving your site's security, performance, and day-to-day management.
one name consistently stands out when discussing Joomla website backups: Akeeba Backup. Developed by Akeeba Ltd.. Whether you are managing a personal blog or a commercial enterprise website, safeguarding your data is paramount, and Akeeba Backup rises to this challenge with robust features,...
Joomla continues to be a leading content management system (CMS), celebrated for its flexibility, scalability, and robust community support.
Discover the truth behind Joomla!, the renowned content management system empowering countless websites globally. Unraveling prevalent misconceptions, this article delves into Joomla! 's functionality and user-friendliness to offer valuable insights. By debunking the top ten myths surrounding...
MigrateMe 4 is a commercial extension that can migrate Joomla websites from Joomla 3 to Joomla 4. It is a relatively easy-to-use extension that can migrate all files and data from a Joomla website, including the content, the modules, the plugins, and the settings.
Regular Labs - Advanced Module Manager is an extension designed to enhance the administration of Joomla modules. With its powerful features and user-friendly interface, it aims to give users more control over their modules and provide them with a better overall experience.
Articles Anywhere is a powerful Joomla plugin that allows you to insert articles anywhere on your site, including within modules, 3rd party components, and even inside other articles. You can place complete articles and only specific data (like Title, Readmore Link, Text, Images, Custom Fields,...
Regular Labs' DB Replacer is a Joomla extension that allows you to search and replace text in any table in your Joomla database. It even supports searching with case sensitivity and using regular expressions. DB Replacer is a great way to save time and effort when you need to change a large amount of...
Regular Labs' ReReplacer is a powerful tool that allows users to search and replace text in various contexts. With its advanced features, ReReplacer will enable users to efficiently manipulate content using regular expressions (regex).
Content will be of significant importance in 2024. Sometimes we often write the same code repeatedly, but with the Content templater Extension from Regular Labs, you can import a template just by clicking a button.
Icons have a significant visual effect to have on your website. Did you know that using an icon as a Custom Field is possible? - Creating an override for the Field layout is done in minutes.
Since Font Awesome is included in Joomla's Cassiopeia template, we will use a template override for the...
