Keeping good backups of your Joomla! site is an important task for any site administrator; it will let you restore your site if it’s ever corrupted. One good option for managing your Joomla! site backups is Akeeba Backup. It creates a single zip file archive of all your database and site files.
How to install Akeeba Backup
- There are free (core) and commercial (professional) versions of the extension, see the Joomla! Extensions Directory (JED) for more details. Choose the version you need, then download and save it to your desktop
- Login to the backend of your site
- Go to Extensions > Manage > Install
- From the Upload Package File tab, locate and select the Akeeba zip file you saved to your desktop
- Click the ‘Upload and Install’ button
- After successfully installing the Akeeba Backup extension, go to Components > Akeeba Backup and click the green Configuration Wizard button. This automatic configuration runs a number of benchmark tests and configures some options of the extension based on the specifics of your server.
How to Back Up a Joomla! Site
Before moving on to the Backup Now page, you should make sure that the original site has a readable and valid configuration.php on its root for the overall backup and restoration process to work.
The ‘trick’ used by webmasters for providing configuration.php with an off-server root PHP file becomes incompatible with the restoration procedure.
Even if the ‘trick’ might be useful on the original site, the installer will have blanks in its options. If the user proceeds with the installation or restoration procedure, then the site will not work correctly. This will happen because crucial options will have the default value or no value at all.
Another important fact to remember is that restoring to a temporary URL will not work. Joomla!, Apache and PHP session management works that way, but Akeeba Backup does not work with the restoration of a temporary URL. If you install Joomla! on a temporary URL, you will still either have problems with logging in or with SEF URLs.
At the initial backup page, you will be able to add a short description (mandatory) and an optional lengthy comment for the backup. You will see this information in the backup administration page, and this will help you tell the difference between backups.
The backup’s time and date are contained in the default description. The comment, as well as the description, is stored in a README.html file in the installation directory of your archive. The backup mode should be the full backup for README.html to be stored.
Both the description and comment fields in Akeeba Backup 3.1.b1 support file naming “variables”, like [SITE], [DATE], and [TIME]. The variables that you can use are documented in the description of Output Directory configuration option. These variables can be used in case of automated backups too, like CRON-mode backups.
Two more fields may appear on this page:
- Encryption Key:
When using the JPS (encrypted archive) format, the content of the archive is encrypted using the AES-256 algorithm and the encryption key (password). To extract the archive, enter the password. If you previously entered a default password for JPS files in the Configuration Page, this field will be pre-filled with that password.
Note: The password here is case sensitive and non-recoverable. Hence, ABC, Abc, and abc are three different passwords here. If you forget your password, you cannot extract your JPS archive in any case.
- ANGIE Password
The ANGIE installer, which is embedded in the backup archive, lets you set a password to protect it (as of AKeeba Backup 3.7.5). This actually means that you need to enter this password to restore your site. This feature prevents unauthorized users to “stumble” upon your site when undergoing restoration, to copy your database passwords, or obtain other information about your site.
Hence, we STRONGLY recommended you to use an ANGIE password to restore your site on a live server. This is the only way to avoid accidental information leaks.
Note: This password is case-sensitive. Hence, ABC, Abc, and abc are three different passwords here. Contrary to the JPS password, setting the ANGIE password does not prevent anyone from extracting the archive or peeking at its contents. It prevents people from attempting to browse your site when you are in the process of restoring a backup, and from seeing any confidential information in the installer.
Click the Backup Now button whenever you want to start the backup. There might be some warnings in the above description field. They appear in the Control Panel’s right-hand panel as well and act as a reminder for you.
Note: The message “Default output directory is in use” is not an error message, but just a reminder that the default outputted directory is a well-known location of your site. A malicious user can figure out the name of your backup archive and download it directly over the web. To prevent that case, Akeeba Backup places a web.config file (compatible only with IIS 7) and a .htaccess file (compatible with all Apache installations).
If you have any doubts about the proper way to create a backup output directory above your original site’s root, or how it can be made writable by PHP, contact HostPapa support team. Then you will be able to use this backup output directory as the Output Directory in all of your backup profiles. This is the best method for backup protection.
Backup Progress Page
After clicking the Backup Now button, the backup progress page appears on the screen. Do not navigate away from this progress page or close your browser until the backup process is complete. If the backup process is interrupted, no backup file will be created, or your backup file will be incomplete. Akeeba Backup disables the menu in Joomla! during backup, this is to avoid accidental switching to a different page.
The backup progress page is a large panel, with the list of steps Akeeba Backup has to take to complete your backup. The steps with grey background have not been dealt with, and steps in the green background have been completed correctly. The steps with a blue background are in process.
Below the top section are two lines. The first one shows you the table or directory that was backed up previously. Hence, when the backup crashes, the table or directory that you see on the screen has not necessarily crashed. The table/directory shown on the screen has most likely been successfully backed up. However, the issue causing the crash appears in the log file, hence the backup log file is important when you create a support request.
The second line is used for less important messages. The messages can range from the percentage of a table already completed and the name of the part of the archive which was processed by the data processing engine.
The big bar that appears on the screen is the overall progress bar. It displays the approximation of the backup progress, and this bar can jump back and forth during the process. This is normal and not a bug. The reason for this is that Akeeba Backup does not know the number of files and directories that your site contains. Hence, it tries to make a guess and displays approximate backup progress. When the actual quantity of files and directories is known, some jumping back and forth occurs. This does not hamper your backup process in any way.
The next information that appears on the screen is the time elapsed since the last response from the server. This time elapsed is set to 0 when a new backup starts. If the last server response time reaches over 300 seconds (except when the application is uploading your backup archives), then your backup has crashed. In this case, you should navigate away from the backup page and look at the log file for error messages. Try different configuration options and change the minimum and maximum execution time before you fill a support request.
Akeeba Backup displays new Warnings panel with a yellow background in cases of a minor error. This box showcases the warnings that have occurred in the backup process in chronological order. These warnings are also logged in the Akeeba Backup Debug Log and they are marked with a warning.
Usual warnings can occur when files and directories become unreadable. Akeeba Backup treats them as minor errors because even though the backup process continues, the output you get might be an incomplete backup that cannot meet your requirements. Review and assess the importance of the warnings that appear on your screen.
Sometimes, an AJAX error can appear and stop your backup. If this happens, it means that a communication error has occurred between your server and the browser. This is a temporary server or network issue in some cases, and depending on the configuration preferences, Akeeba Backup may try to resume the backup. Akeeba Backup tries resuming the backup three consecutive times and 10 seconds after each error, this is by default. If the backup process does not resume, you will receive an error message. In this case, your backup has surely failed.
Backup Completion Page
After the backup process is complete, the Akeeba Backup cleans up all temporary files that it has created. It also cleans temporary files and deletes incomplete archive files if it detects a failure of the backup.
Akeeba Backup does not remove the log files by default. To delete them, navigate to the Manage Backups page and select the failed backup attempt(s). Click on Delete Files or Delete to remove the log files of failed backup processes.
After this, your site backup file is created successfully, and you can navigate out of the backup page to the backup administration page by clicking on the handy button below the backup completion message.
Akeeba Backup makes your life easier by streamlining the workflow of backing up, migrating, or restoring your site.
Even if you are restoring to the same host and location, transferring your site to a completely new host, or copying your site to a subdirectory/subdomain of the same host, the process is always the same for Akeeba Backup, and you only need to learn it once.
Note: Restoring to a different database technology won’t work, it shouldn’t work and you won’t be able to make it work. E.g. if you create a backup using MySQL database, you cannot restore the backup of this database on a Windows Azure SQL database, PostgreSQL, or Microsoft SQL server.
The structure of tables differs extremely between database server technologies. There is no way to have a one-to-one correspondence between two different database server technologies. The conversion process is a manual and laborious job involving a lot of trial and error.
This process also requires the knowledge of the code using this database.
For example, converting a tiny, simple database structure like Akeeba Backup to MS SQL Server and Postgre SQL can take about 20 hours. It requires a lot of changes to the existing code, in order to cater to the new databases. This is the time needed for the preparatory phase before the work on the actual database backup code can start. This kind of conversion is a manual process which cannot be automated.
The typical workflow of the backup and restoration process in Akeeba includes two utilities from the Akeeba Backup Suite. One is the Akeeba Backup component, and the other is the Akeeba Kickstart. The overview of the workflow is mentioned below:
- Install Akeeba Backup and configure it as needed. You can also use the automated Configuration Wizard to automatically configure the Akeeba Backup with the settings that match your server.
Click Backup Now and let your site back up.
Click Manage Backups.
Click on the download link situated to the right of the only backup entry from the list. You can also download the backup using FTP by saving all parts of the backup archive to your local PC.
- Extract the kickstart VERSION .zip file that you downloaded before from the Downloads repository. The zip file contains the kickstart.php and the translation INI files. Upload these files to the server where you need to restore your site.
- Upload all parts of the backup archive to the server (target server) where you want to restore your current site. Do not extract the archive yet, just upload it. The server’s directory should now comprise of the parts of the backup archive (.jpa, .j01, etc.) and the kickstart.php files.
- Open your browser and visit the Kickstart URL on the target server. E.g.: http://www.example.com/kickstart.php
- Change an option if required, before clicking on the Start button. Kickstart now extracts the backup archive to the server. This process is fast in comparison to FTP. If this process ends with an error, go back and select the Upload using FTP option. Then, you need to supply your FTP connection information and click on Start again.
- A new window (the Akeeba Backup Installer) appears on the screen. This is the site restoration script embedded inside your archive. Make sure that you do not close the Kickstart window.
- The Akeeba Backup Installer displays some prompts now. Fill in the details of the new server, the new database connection, and FTP connection information correctly.
- When the ABI (Akeeba Backup Installer) is ready, it will prompt you to delete the installation directory. Make sure that you ignore this prompt. Only close the ABI window.
- Navigate back to the Kickstart window and click the Clean Up button. Kickstart removes the installation directory and restores your .htaccess file in case there was one. Kickstart also removes the backup archive and itself.
- Click the View the front-end button to visit your new, working site.
If you are restoring the backup file to a different subdirectory on the same server as the original site, or if you are restoring the backup file to a different host altogether, you will need to edit your .htaccess file. Not doing this can cause your site to not work properly.
Some third-party extensions that store absolute filesystem paths, contain host or directory specific settings, or use absolute URLs might require manual reconfiguration after the completion of the restoration process.
For further questions, or if you need help, please open a support ticket from your HostPapa Dashboard. Click here to learn how to do it.