Akeeba Kickstart Pro - Joomla Extension

A Guide to Restoring a Site with Akeeba Kickstart Pro

Akeeba Kickstart Pro is not meant for a routine Joomla extension install. It is designed for a more sensitive job - extracting a site archive on the server, launching the built-in restoration script, and safely removing temporary files when the work is done. In this guide, we will walk through how to use Akeeba Kickstart Pro without unnecessary risk: what to prepare before you begin, which modes to choose, how to work with JPA, JPS, and ZIP archives, what the Pro features add, and how to confirm that the restoration completed properly.

This article is written as a practical guide for a site owner, Joomla administrator, or webmaster who already has a backup and wants to restore the site on a new hosting account, in a subdomain, locally, or in an empty directory. It is not a rewritten product listing. The focus here is on workflow, settings, checks, common mistakes, and fixes that help you avoid losing files, leaving the restoration script exposed, or confusing archive extraction with database restoration.

It is also important to understand where the product's responsibility ends. Kickstart extracts the files from the archive and hands the user off to the restoration script that is already stored inside the backup. That means the correct workflow has two parts: first, carefully unpack the archive with Kickstart, then complete the site restoration in the installer window and return to Kickstart for cleanup. If you skip the last step, sensitive temporary files may remain on the server.

When Kickstart Is Actually Needed and When It Is Not

The most common mistake happens before any files are even uploaded: the user treats Kickstart like a Joomla extension and tries to install it through the Extension Manager. That is the wrong approach. Akeeba Kickstart Pro is a standalone PHP file that runs directly in a browser or from the command line. It is useful specifically when the full Joomla admin panel is unavailable, when a site is being moved to another server, or when you need to extract a backup archive directly on the hosting account without uploading thousands of files over FTP.

A typical workflow looks like this: you have a backup created with Akeeba Backup or Akeeba Solo, and you have a server directory where the restored site should live. You upload the Kickstart file and all archive parts there, open the file URL in your browser, choose the archive and extraction mode, and start the process. Once the files are unpacked, Kickstart offers a link to the restoration script. That script restores the database and part of the site's configuration. Then you close the script window, return to Kickstart, and run cleanup.

The product is especially useful in four situations. First, moving a site to a new host while the original site is still live and you need to bring up a copy quickly. Second, restoring after a failure when the Joomla admin panel no longer opens but you still have access to the server files. Third, creating a local copy to test updates, switch templates, or troubleshoot conflicts. Fourth, extracting individual files from an archive, such as an accidentally deleted image folder or a modified template file.

Kickstart may be unnecessary if all you have is a standard ZIP archive with a small set of files and your hosting account can already unpack it quickly and correctly through its file manager. It is also not a substitute for checking Joomla, PHP, database, and extension compatibility. If a backup was created with one database technology and the target server uses another incompatible one, Kickstart will not magically turn that copy into a working site. It only extracts the files and helps launch the restoration script.

The key point: Kickstart does not fix a bad backup, and it does not restore Joomla by itself. It gives you a fast, controlled way to extract the archive on the server, while the script inside the backup completes the actual site restoration.

What to Check Before You Start the Restoration

Preparation takes far less time than fixing a half-restored site. For Akeeba Kickstart Pro, three things matter most: the correct launch location, archive integrity, and temporary process security. If even one of these is off, the result can look strange: Kickstart runs but cannot see the archive; the restoration script opens but the site does not work afterward; cleanup leaves files behind; or visitors see an in-progress restoration page.

The restoration directory

The Kickstart file should go in the location that is meant to become the site root. On typical hosting, that is the directory where the Joomla index.php file lives or is supposed to live - often something like public_html, httpdocs, htdocs, www, or a folder named after the domain itself. If you are restoring into a subdirectory, both Kickstart and the archive need to be placed in that exact subdirectory, not one level above it.

Before restoring on a live domain, decide what should happen to any existing files. By default, Kickstart creates new files and replaces existing ones, but it does not necessarily delete everything that is not present in the archive. The Pro option to delete content before extraction can produce a cleaner restore, but it is a dangerous mode intended for experienced users. If you choose the wrong directory, it can remove files from a neighboring site, system folders, a separate script, or someone else's data. In everyday work, it is safer to prepare a separate empty directory or subdomain.

Archive integrity and all parts of the backup set

For JPA, JPS, and multi-part ZIP archives, every part must be uploaded. In Akeeba archives, that may include the main file plus sequential parts with extensions like .j01, .j02 or .z01, .z02. If even one part is missing, extraction may stop with an error or, worse, appear to continue far enough to launch restoration while still leaving you with an incomplete site.

If the archive is transferred over FTP, use binary transfer mode. Automatic or text mode can corrupt both the archive and the Kickstart PHP file. SFTP and hosting file managers usually handle the equivalent binary transfer correctly, but it is still worth comparing file sizes between your local computer and the server after upload. For large archives, that simple check can save hours of troubleshooting.

PHP, the database, and file permissions

Kickstart runs as a PHP script, so the server must be able to execute PHP, and the restoration directory must be writable using the method you choose. But restoring the site depends on more than Kickstart alone. The internal restoration script must be able to connect to the database, write the tables, and update the configuration. Before you begin, have the database name, username, password, and database server address ready. Do not send those details to article generators, chat threads, or third-party tools; they are only needed by you during the restoration itself.

If you are moving the site to a different hosting account, verify the database type as well. A backup created on a MySQL-compatible system should not be restored as a PostgreSQL site, and vice versa. Also confirm in advance which PHP branch your Joomla version and critical extensions require. Kickstart may successfully extract the files even in an environment where Joomla itself cannot start because of incompatibility.

Temporary process security

Site restoration is a moment when the archive, the installer script, and the extraction file all exist side by side on the server. That means you cannot treat the Kickstart URL as a harmless technical link. Use a Kickstart password through the configuration file, or rename the PHP file to a random name without obvious words. This matters even more in Pro workflows, because importing an archive by URL or from S3 increases the potential impact of an access mistake.

If the restoration is happening on a public domain, enable the mode that hides the process from regular visitors whenever it is supported by your server. On Apache and LiteSpeed, Stealth Mode can redirect visitors to a static page while you work. If the site sits behind a CDN, load balancer, or proxy, do not rely only on IP detection. In that case, a restoration password inside the archive and restricted directory access matter more.

How to Prepare Kickstart Files Without Installing Anything in Joomla

After downloading the Akeeba Kickstart Pro ZIP package, unpack it locally. Inside, you will find kickstart.php and language INI files. For a minimal setup, the PHP file alone is enough; the translated interface can be added only if needed. Do not upload the Kickstart ZIP package as a Joomla extension. The Extension Manager should not be part of this workflow.

For safer use, it is best to rename the file before uploading it to the server. The name should be random, keep the .php extension, and avoid easy-to-guess words. If you are using password protection, you can place a configuration file next to the PHP file. Its name depends on the PHP filename: if the file is called restore-panel.php, the configuration may be named restore-panel.json.php. A generic kickstart.json.php file is also possible, but a configuration file matching the PHP filename takes priority.

The example below shows only the file format. Do not use the weak example password, and do not store real secrets in a public location. It is better to generate a long random password in a password manager and, after the restoration is complete, remove both the PHP file and the configuration file.

<?php die(); ?>{
  "password": "replace-with-long-random-password"
}

The first line with die() is required. It protects the configuration content from being accidentally served as plain text. If the line is different, Kickstart will refuse to use the file. For stronger protection, the documentation recommends storing the password as a bcrypt hash, but for most administrators the main thing to understand is the principle: the configuration file must not expose the secret, and it must be deleted after the restoration is finished.

How to upload the files

Upload the renamed Kickstart PHP file to the restoration root. Then upload all parts of the backup archive to the same directory. If the archive is already stored in the standard Akeeba Backup output folder on the original site and you are restoring in that same location, Kickstart can work with it there. But when moving to a new server, it is simpler to keep all required files together. That lowers the risk of choosing the wrong archive.

For FTP, enable binary transfer mode. In FileZilla, that is done through the Transfer menu, then Transfer Type, then Binary. If you are using SFTP, you usually do not need to choose a separate mode. After upload, make sure the PHP file has normal read and execution permissions for the server, and that the directory is writable. Do not make kickstart.php executable as a system program, and do not give every file maximum permissions without a reason.

How to open the interface

Open the URL of the renamed PHP file in your browser. If the file is named restore-panel.php and is placed in the domain root, the URL will look something like https://example.com/restore-panel.php. If you see a page warning about an insecure setup, Kickstart is expecting either a password file or a renamed script. If you get a 403 response, check .htaccess, web.config, Admin Tools settings, or any other rules that block PHP files from running outside the normal Joomla entry points.

Once the interface opens, do not rush to click Start. First, confirm which archive is selected, which write mode is set, and whether any warnings are displayed. If multiple archives are sitting in the directory, choose the right one manually. A good habit is to keep only one current archive set there, so you do not accidentally restore an outdated copy.

Extraction Settings: Direct, FTP, Hybrid, and Risky Options

The main Kickstart setting is the file write method. It determines whether the script can replace files in the restoration directory and how much manual work will be left if you hit a permission error. In most cases, you start with direct write or Hybrid mode, and use FTP only when the server's permission model does not allow PHP to overwrite files directly.

Direct Write

Direct write means Kickstart saves files to disk as the PHP process user. It is the simplest option for an empty directory, a local server, or hosting where the file owner and the PHP user already align. If the directory already contains files owned by someone else, direct write may stop with an "unwritable file" error. If that happens, do not blindly rerun the process. It is better to understand why PHP cannot write the file: the owner is different, the permissions are too strict, the folder is protected by the host, or the file is locked.

FTP mode

FTP mode makes Kickstart extract files into a temporary directory first, then upload them into the final location through FTP or FTPS. This helps when PHP does not own the files in the target directory. But it requires correct FTP credentials, a writable temporary folder, and a server network setup that supports it. Kickstart does not support SFTP in this mode, because SFTP is a different protocol, not a variation of FTP.

If your host tells you to use port 22, that usually means SFTP, not FTP. In the Kickstart web interface, you need standard FTP or FTPS. The FTP Directory path is also often misunderstood. It should be the path inside the FTP connection that points to the root of the site being restored, not something like /home/account/public_html if your FTP client shows a different internal path. The most reliable way to confirm it is to connect with an FTP client, open the correct folder, and copy the path shown there.

Hybrid for shared hosting

Hybrid mode tries direct writing first, and if a file cannot be replaced because of ownership or permissions, it switches to FTP mode. On shared hosting, that is often the most practical choice. It reduces the number of stops caused by mixed file ownership, but it still requires valid FTP settings. If the site is large and the server is slow, do not mistake pauses for a freeze: Kickstart works in chunks to stay within PHP execution time limits.

Settings you should not enable without a reason

Some options look convenient but come with real consequences. Ignore most errors can help with a problematic archive or a move between different file systems, but it also hides write failures. Use it only when you already know which files might fail to extract and how you will verify the result afterward. For a production restore, it is a poor default choice.

Restore permissions only makes sense for archives where permissions were actually stored, and it does not transfer file ownership. In a normal restore, it is safer to end up with standard permissions: files readable by the server, directories accessible, and writable only where Joomla needs it. Restoring old permissions can bring back ownership conflicts and break writing to cache, logs, or images.

Delete everything before extraction is a Pro feature for wiping a directory before a clean overwrite. It should never be turned on as a cosmetic preference. Before using it, make sure the directory contains only the site you are restoring and that there are no files from another domain, email data, user uploads, temporary exports, or utility scripts sitting nearby. If you are unsure, create a new empty directory and restore there instead.

Configuration check: before clicking Start, you should know exactly which archive is selected, where it will be extracted, how files will be written, and what will happen to the existing contents of the directory.

Pro Features: Importing an Archive by URL, Amazon S3, and Installing ZIP Packages

With Akeeba Kickstart Pro, the value goes beyond basic extraction of a local archive. Pro mode adds workflows where the archive does not have to be downloaded to your computer first and then uploaded back to the server. That is especially useful for large backups, slow home internet connections, or workflows where backups already live in external storage.

Import by URL

The import by URL feature works when the archive is available through a direct HTTP or HTTPS link. That link must point to the file itself, not to a page where the user still has to click another download button. If the service returns an HTML page instead of the archive, Kickstart will download HTML rather than the backup. In Dropbox-like scenarios, you need a direct-download link, and if the service requires it, you may need to change a URL parameter so the file downloads immediately.

For a multi-part archive, import every part. There is no way around that rule with a Pro feature. If you have .j01, .j02, and the main .jpa, every part has to end up on the server. After the import, return to the main Kickstart page and choose the archive for extraction. If the archive list is empty, check the directory permissions and filenames.

Amazon S3 and compatible storage

Amazon S3 import is designed for cases where backups are stored in a bucket and you do not want to route a large file through your local computer. In the interface, you enter the access credentials, choose the bucket, and select the object. For S3-compatible services, you may need a custom endpoint, region, and the appropriate signing method. The credentials must have sufficient permission to list buckets, list objects, and retrieve the required object.

This mode is convenient, but it requires discipline. Do not use long-lived keys with unnecessary privileges, do not leave Kickstart exposed after the import, and do not store access credentials in notes next to the site. If the server reports SSL certificate problems while connecting to S3, the documentation points to an up-to-date certificate authority bundle as the fix. That is a server configuration issue, not a backup failure.

Installing a CMS or another ZIP package

The Kickstart Pro product page also describes the ability to download and install ZIP packages for CMS platforms or other PHP applications. For a Joomla administrator, that can be useful in a technical scenario, but it should not be mixed up with restoring an Akeeba Backup archive. If you already have a full site backup archive, do not install a fresh Joomla copy first, and do not try to restore on top of a clean installation unless you fully understand why. A full site backup already contains the site's files and its built-in restoration installer.

The practical rule is simple: to restore a site from Akeeba Backup, work with the backup archive and the built-in restoration script. For a standalone CMS ZIP package, use Kickstart as a server-side extractor only when you understand that this is not a restoration of an existing site, but a separate installation or technical unpacking task.

Practical Scenario: Moving a Joomla Site to New Hosting

Below is a concrete scenario that people most often look for when they search for "Akeeba Kickstart Pro instructions" or "how to restore Joomla from Akeeba Backup." It works for moving a site to a new hosting account, a staging subdomain, or a local server. Hosting control panels may differ, but the logic stays the same.

Goal

The goal is to get a working copy of a Joomla site on a new environment. When the process is complete, the user should be able to open the public site, log in to the admin panel, check a few articles, menus, images, and forms, and confirm that links no longer point to the old domain.

Preparation

On the original site, create a full backup with Akeeba Backup, or use an existing archive only if you are sure it is current. Download all archive parts. On the target hosting account, create an empty database and database user. Prepare the site root: an empty directory, a subdomain, or a separate domain. If you are restoring over an existing site, make an additional backup of the current state and make sure you understand the consequences of overwriting it.

Restoration steps

1. Unpack the Akeeba Kickstart Pro ZIP package on your local computer and rename the PHP file to a random name with a .php extension.
2. Upload the renamed PHP file and all parts of the backup archive to the root of the target site.
3. Create a password configuration file or make sure the PHP filename does not contain easy-to-guess words.
4. Open the PHP file URL in your browser and confirm that the correct archive is selected.
5. Choose Hybrid for shared hosting or Direct Write for an empty directory with normal permissions.
6. Enable Stealth Mode if the restoration is happening on a public domain and the server configuration can restrict visitors correctly.
7. Click Start and wait for the archive extraction to finish.
8. Open the restoration script from the Kickstart button and complete the database restoration steps.
9. When the script finishes, close its tab, return to Kickstart, and click Clean Up.
10. Open the public site and the admin panel, then check the configuration and links.

Checkpoint before extraction

Before you click Start, take a brief pause and treat the directory as a restoration checkpoint. It should contain the renamed Kickstart PHP file, the protection configuration file if you are using one, and all parts of a single backup set. Do not keep old archives, "just in case" database exports, or folders from another site in the same location. If the restore is happening in a subdomain, open the hosting file manager and make sure that subdomain actually points to the directory where you uploaded the files. A wrong document root is more common than it seems: Kickstart runs, the archive extracts, but later the user checks a different domain or a different folder.

Checkpoint after the installer script

When the restoration script reports success, do not switch straight into normal site work. First close the script window, return to Kickstart, and run cleanup. Then open the site root in the file manager and confirm that the temporary files are gone. This is not distrust of the product - it is a normal administrative habit. If cleanup failed to remove even one file because of permissions, you will see it immediately while the steps and chosen settings are still fresh in your mind.

Expected result

After cleanup, the site root should no longer contain the Kickstart PHP file, the backup archive, or the installation folder. The public site should open without an intermediate restoration page, and the admin panel should accept the credentials of the restored site. If the move was to another domain or into a subdirectory, check the URL configuration, .htaccess rules, and the paths for the temporary folder, logs, and cache.

A detail that often gets in the way

Users sometimes close the Kickstart tab after jumping into the installer because they assume Kickstart has already done its job. Do not close that tab. After the restoration script finishes, you need to return to Kickstart specifically to run cleanup. If the tab has already been closed, you will have to clean up manually through the file manager or FTP: remove the Kickstart PHP file, the archive, and the installation folder, and also make sure any temporarily renamed server configuration files were restored to their original names.

Partial File Extraction Instead of a Full Restore

One of Kickstart's underrated features is the Files to extract field. It allows you to extract not the entire site, but only selected paths or file patterns from the archive. This is not a replacement for a full restore after a serious failure, but it is a very useful tool for a targeted emergency: a deleted image folder, an overwritten template file, or a missing document that existed in the backup.

Paths in this field are written relative to the archive, not relative to the server file system. If the archive contains images/cat.png, that is exactly how the path should be written. A full server path like /home/account/public_html/images/cat.png would be incorrect. The separator is a forward slash, even if the restore is happening on a Windows server or in a local Windows environment.

Patterns let you extract groups of files. For example, images/*.jpg will find JPG files in the images folder, but not necessarily throughout all subfolders. For more complex patterns, you need to understand shell pattern syntax. If the goal is to restore a specific folder with nested files, it is often easier to specify the directory with a clear pattern and then verify the result manually.

When partial extraction makes sense

Use this mode when the problem is limited to files and does not affect the database. Good examples include restoring a deleted image, bringing back a template file, recovering a PDF document, or reverting an accidentally changed CSS file. A bad example would be trying to restore a site after a hack or a failed update when you do not know which files and tables were changed. In that case, partial extraction can leave the system in an inconsistent state.

How to verify the result

After partial extraction, open the file manager and make sure the required files really appeared. Then check the public page where those files are used. If you restored a template file or CSS file, clear the Joomla cache and, if the site uses external caching or a CDN, bypass it temporarily. If nothing changes, you may have restored the file from the wrong archive, or the template being edited may live in a different template style, override, or child structure.

Restoration Security and Cleanup Afterward

With Kickstart, the security section is not a formality. During restoration, the server may temporarily hold files that expose the archive contents, the site configuration, and the installer workflow. That is why a good Akeeba Kickstart Pro guide never ends with launching the site - it ends with removing temporary files and verifying access.

Password or random filename

If Kickstart is exposed under an obvious URL, anyone who guesses the address can try to interfere with the process. Current documentation describes two main protection methods: a password configuration file and renaming the PHP file to a random name without obvious words. The best option is to use both, especially on a public domain. But even that is not a reason to leave the file on the server after the কাজ is done.

For the Pro version, caution matters even more because importing an archive by URL or from S3 makes it possible to pull an external file onto the server. If an attacker can control that process, the consequences may be more serious than with a normal local extraction of an archive that was already uploaded. So do not share the Kickstart link in chats, do not send it to a client unless absolutely necessary, and do not leave it available for days.

Stealth Mode and the restoration password

Stealth Mode helps hide the restoration script from regular visitors, but it should not be your only protection. How well it works depends on the server configuration. If the server sits behind a CDN or a load balancer, IP checks may not behave the way you expect. In those conditions, it is more reliable to use the Restoration Script Password in the backup and restrict directory access through hosting controls.

If the site is being restored in a subdomain or a local environment, Stealth Mode may not be necessary. But the principle stays the same: only the administrator should have access to the process, and all temporary files should be removed as soon as the job is complete. Do not leave the backup archive next to the site "just in case." Store backups in secured external storage, not in the public web root.

Cleanup through Clean Up

After the installer script is finished, return to the Kickstart tab and click Clean Up. This removes the installation folder, the archive and its parts, the Kickstart file itself, and the translation INI files if they were placed alongside it. It also restores any temporarily renamed server configuration files. If automatic cleanup fails, Kickstart will show you what still has to be removed manually.

The final manual check is simple: the site root should no longer contain the renamed Kickstart file, kickstart.json.php or a same-name configuration file, backup archives, archive parts, or the installation folder. If you enabled temporary access rules, restore them to their normal state. If you removed or renamed .htaccess to get around a block, put the correct version back and verify the site URLs.

Checking the Result After Restoration

Your post-restore check should not stop at seeing the home page load. A restored Joomla site can look normal while still having incorrect paths, old URLs, broken write permissions, damaged cache behavior, or conflicting server rules. That is why, after using Akeeba Kickstart Pro, it is worth doing a short but systematic verification.

The public site

Open the home page, a few internal articles, a category page, the contact form, a page with images, and any custom components that are critical to the project. If the site was moved to a different domain, confirm that links do not still point to the old address. If some pages return 404 errors, inspect .htaccess, SEF URL settings, and the site's base path.

For a better check, open those pages both in a private browser window and in your normal logged-in administrator session. That lets you see two different states: what an anonymous visitor gets and what a privileged user sees. If the problem appears only in the normal session, clear the browser cache and the Joomla cache. If it also appears in the private window, move on to server rules, paths, and extensions. That simple separation helps you avoid wasting time on cache when the real cause is in .htaccess, and vice versa.

The Joomla admin panel

Log in to the admin panel and make sure you can open articles, menus, modules, templates, Global Configuration, and the extension list. If the admin area loads but specific sections fail, the issue may not be Kickstart at all. It may be a PHP compatibility problem, an outdated extension, or incorrect paths for temporary folders. Check Joomla system messages and the hosting error log.

Right after login, do not start updating extensions. First confirm that the restored copy is stable: save a test article without publishing it, open the module list, check the default template, and make sure Global Configuration saves successfully. If saving the configuration fails, updating extensions will only add more variables. A restoration is not truly complete the moment you log in to the admin panel - it is complete when basic write operations succeed without errors.

Write permissions and service folders

Joomla must be able to write to cache, logs, and the temporary folder. After moving to another server, absolute paths may change. If image uploads do not work, cache cannot be cleared, or extension updates fail, check the paths in Global Configuration and the file ownership. Do not try to fix this by giving everything maximum permissions. It is better to correct the owner, group, or specific folders according to your host's recommendations.

You can test write permissions without using dangerous commands. Upload a small test image through the Joomla Media Manager, then delete it through the standard interface. After that, clear the cache and confirm that no new warnings appear in the admin panel. If the upload works but deletion fails, the issue may be ownership of existing files. If even the upload fails, check the temporary folder path and the permissions on the images directory.

Cache, CDN, and external services

After restoration, clear the Joomla cache, the template or optimizer cache if one exists, and temporarily test the site without the CDN. Many post-migration symptoms look like restoration problems when the browser or CDN is simply serving old files. If the site uses external integrations, check the domain, callback URL, and API settings inside the extensions themselves. Some components store absolute URLs or file paths separately from Joomla's main configuration.

For a site with forms, payments, subscriptions, or third-party authentication, create a separate verification path. Submit a test form, check the email, open the login page, verify the post-login redirect, and make sure system emails are sent from the new domain. Kickstart does not change how those extensions work, so after a migration they may still require manual updates to the domain, secret keys, or allowed callback URLs in the service dashboards. Those secrets should not be written into an article, ticket, or public note; verify them only inside the site panel and the service itself.

Quick takeaway: a successful restoration is not confirmed by the Clean Up button alone. You also need to open the public pages and admin panel, and verify file writes, links, cache behavior, and critical extensions.

Akeeba Kickstart Pro Errors and Symptom-Based Troubleshooting

Restoration errors almost always come from one of four layers: access to Kickstart itself, archive visibility, file writing, or launching the restoration script after extraction. Below is a practical troubleshooting path worth following before contacting support. It does not replace the official documentation, but it helps you narrow down the cause faster.

"Insecure setup detected" appears

Symptom: Kickstart opens, but instead of the interface it shows a warning about an insecure setup. Cause: the file was launched without a password configuration and with a predictable name. What to check: whether a valid .json.php file is present next to it with the required first line, and whether the PHP filename contains obvious words. How to fix it: create a password configuration file or rename the PHP file to a random name, then open the new URL. If renaming leads to a 403 error, move on to checking the server's security rules.

403 Forbidden when opening the renamed file

Symptom: the browser shows a 403 error even though the file is in the correct directory. Possible cause: rules in .htaccess, web.config, Admin Tools, or another protection layer are blocking PHP files from running outside Joomla's standard entry points. What to check: temporary access rules, PHP execution blocks in the directory, and host security configurations. How to fix it: temporarily rename the conflicting server configuration file or add an exception for the restoration process. When you are finished, make sure you restore the protection.

Kickstart cannot see the archive

Symptom: the interface opens, but the archive dropdown list is empty. Cause: the archive is not next to the PHP file, the directory permissions do not allow file listing, the extension is not recognized, or not all archive parts were uploaded. What to check: the directory, filenames, site root permissions, and archive permissions. How to fix it: place the archive next to Kickstart, apply correct permissions based on the hosting provider's guidance, and make sure all parts of the backup set are present.

AJAX Error, Invalid Archive Header, or extraction stops partway through

Symptom: the process starts, but then stops with an AJAX error, an invalid archive header error, or a corruption message. Cause: a corrupted upload, a missing part of a multi-part archive, FTP text mode, a server timeout, a security module block, or a bad archive. What to check: file sizes, binary transfer mode, the presence of .j01/.z01 parts, and the hosting error logs. How to fix it: re-upload all parts in binary mode, try extracting the archive locally with a compatible tool, and on the server switch to Hybrid or FTP if the problem is related to file writing.

Unwritable file during extraction

Symptom: Kickstart cannot overwrite a specific file or folder. Cause: the existing file belongs to another user, or the folder is not accessible to the PHP process. What to check: file ownership, directory permissions, and the selected write mode. How to fix it: switch to Hybrid or FTP, ask the host to correct ownership, or restore the site into an empty directory. Do not make Ignore most errors your first response, because you may end up with an incomplete copy of the site.

After restoration, the old domain opens or HTTPS points to the wrong place

Symptom: the site is restored, but links still point to the old address, the local copy tries to open the old domain over HTTPS, or the admin panel redirects incorrectly. Cause: old .htaccess rules, template settings, extensions with absolute URLs, cache, or configuration values. What to check: SEF settings, .htaccess, Global Configuration, security extensions, and cache. How to fix it: temporarily disable redirects, review the site configuration, and clear the cache. If the move is local, make sure the domain, protocol, and path match the new environment.

The site works, but files cannot be uploaded and cache cannot be cleared

Symptom: the public site opens, but the admin area reports file write errors, image uploads fail, or updates cannot be installed. Cause: incorrect file ownership or outdated absolute paths for tmp and logs. What to check: Joomla Global Configuration, folder permissions, file ownership, and system messages. How to fix it: correct the paths, ask the host to align file ownership, and set normal permissions for files and folders. Use maximum-permission mode only as a short diagnostic step in a closed environment, not as the final fix.

CLI Mode for Experienced Administrators

Kickstart can be run not only from a browser, but also from the command line. This mode is useful on a server where the administrator has SSH access and understands the permission model. It can extract a JPA, JPS, or ZIP archive into the current or a specified directory, validate the archive with a dry run, extract only selected paths, or restore saved file permissions when that is truly necessary.

CLI mode is not a direct replacement for the web interface. It does not support FTP or Hybrid, it does not include Stealth Mode, and it does not restore the site end to end. Like the web interface, it only extracts the archive. If you are dealing with a full Akeeba Backup site, you still need to run the restoration script afterward. So CLI should be treated as part of a technical workflow, not as a one-button recovery method.

A typical command looks like this:

php kickstart.php archive.jpa /path/to/extract

For a JPS archive, you may need to provide the archive password through the --password option, and for a validation run without writing files, use --dry-run. Do not run deletion commands before extraction unless you are absolutely sure about the target directory. The deletion option in CLI carries the same risk as the Pro mode in the web interface: it can remove not only the site files, but everything else that happens to be in the selected path.

Who Akeeba Kickstart Pro Is For and When Another Approach Is Better

Akeeba Kickstart Pro is a strong fit for people who regularly move Joomla sites, work with large archives, keep backups in external storage, or need to restore a site without access to a working admin panel. It is especially useful for web studios and administrators who are already in the habit of keeping clean backup sets and documenting their restoration process.

For an individual site owner, the product can also be convenient, but only if that person is willing to read the on-screen warnings carefully and avoid turning on risky options without understanding them. If you have never worked with a site root, FTP, databases, and file permissions, it is safer to do a test restoration in a subdomain first or ask your host to help with the initial setup.

The product may not be the right fit if your host blocks arbitrary PHP files from running in the site root and does not give you a way to create a temporary exception. It also does not solve the problem if the backup is damaged, incompatible with the current server environment, or missing the required database. In those cases, it is more useful to start by checking the archive and Joomla requirements than by repeating extraction attempts.

If you are planning a restore after a suspected compromise, do not use Kickstart as your only tool. First preserve the evidence, isolate the site, change passwords, and verify that the backup was created before the incident. Restoring an infected archive will simply bring the problem back onto the new server. Kickstart speeds up the technical side, but it does not replace security analysis.

When Akeeba Kickstart Pro Is the Right Choice

Akeeba Kickstart Pro is worth using when you already have a Joomla site backup and need a controlled server-side extraction workflow: moving to new hosting, recovering after a failure, creating a test copy, or selectively pulling files from the archive. The product's strength is not that it "does everything by itself," but that it handles the heaviest part of restoration well: it quickly extracts a large archive in the target environment and passes you to the correct restoration script.

For a good outcome, the order of operations matters most. Prepare an empty or clearly defined directory, upload every part of the archive, protect access to the PHP file, choose the write mode based on the server situation, do not enable destructive deletion unless you are certain, complete the installer script, and make sure to click Clean Up. After that, check the public site, the admin panel, cache, write permissions, links, and critical extensions.

If you are ready to go through those checks, you can download the ZIP package and test the restoration on a copy of the site first. That kind of test gives you more value than any amount of theory: you will see whether the server is suitable, whether the archive is valid, and which settings belong in your own internal restoration checklist.