Akeeba backup-guide

Akeeba Backup User's Guide

Nicholas K. Dionysopoulos

by Nicholas K. Dionysopoulos

Publication date January 2011

Abstract

This book covers the use of the Akeeba Backup site backup component for Joomla!™ -powered web sites. It does
not cover any other software of the Akeeba Backup suite, including Kickstart and the desktop applications which
have documentation of their own. Both the free Akeeba Backup Core and the subscription-based Akeeba Backup
Professional editions are completely covered.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any
later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of
the license is included in the appendix entitled "The GNU Free Documentation License".

Table of Contents
I. User's Guide to Akeeba Backup for Joomla!™ ..................................................................................... 1
1. Introduction ........................................................................................................................... 5
1. Introducing Akeeba Backup .............................................................................................. 5
2. Indicative uses ................................................................................................................ 5
3. A typical backup/restoration workflow ................................................................................ 6
4. Server environment requirements ....................................................................................... 7
2. Installation, updates and upgrades .............................................................................................. 9
1. Installing Akeeba Backup ................................................................................................. 9
1.1. Getting the installation packages ............................................................................. 9
1.2. Installing the backup component and language files .................................................... 9
1.2.1. Manual installation ..................................................................................... 9
1.3. Installing the administrator panel icon module and plugins ......................................... 10
2. Upgrading from Core to Professional ................................................................................ 10
3. Updating to the latest version .......................................................................................... 10
3. Using the Akeeba Backup component ....................................................................................... 11
1. Pages outside the Control Panel panes .............................................................................. 11
1.1. Common navigation elements ............................................................................... 11
1.2. The Control Panel ............................................................................................... 11
1.2.1. Editing the component's Parameters ............................................................. 15
1.2.2. I get a "JFTP::chmod: Bad response" error. What's wrong? ............................... 18
1.2.3. I get an error about something regarding T_OBJECT / I get a blank page when I
try to access Akeeba Backup .............................................................................. 18
2. Basic Operations ........................................................................................................... 19
2.1. Profiles Management ........................................................................................... 19
2.2. Configuration Wizard .......................................................................................... 20
2.3. Configuration ..................................................................................................... 21
2.3.1. The main settings ..................................................................................... 21
2.3.1.1. Basic Configuration ........................................................................ 21
2.3.1.2. Advanced configuration .................................................................. 25
2.3.1.3. Optional filters .............................................................................. 26
2.3.1.4. Quota management ......................................................................... 27
2.3.1.5. Fine tuning ................................................................................... 27
2.3.2. Database dump engines ............................................................................. 28
2.3.2.1. Native MySQL Backup Engine ........................................................ 28
2.3.3. File and directories scanner engines ............................................................. 30
2.3.3.1. Smart scanner ............................................................................... 30
2.3.4. Archiver engines ...................................................................................... 31
2.3.4.1. ZIP format .................................................................................... 31
2.3.4.2. JPA format ................................................................................... 32
2.3.4.3. Encrypted Archives (JPS format) ...................................................... 32
2.3.4.4. DirectFTP ..................................................................................... 34
2.3.4.5. DirectSFTP ................................................................................... 35
2.3.4.6. ZIP using ZIPArchive class ............................................................. 36
2.3.5. Data processing engines ............................................................................ 36
2.3.5.1. No post-processing ......................................................................... 36
2.3.5.2. Send by email ............................................................................... 37
2.3.5.3. Upload to Amazon S3 .................................................................... 37
2.3.5.4. Upload to DropBox ........................................................................ 39
2.3.5.5. Upload to RackSpace CloudFiles ...................................................... 40
2.3.5.6. Upload to Microsoft Windows Azure BLOB Storage service .................. 41
2.3.5.7. Upload to Remote FTP server .......................................................... 42

iii


2.4. Backup now ....................................................................................................... 44
2.5. Administer Backup Files ...................................................................................... 49
2.5.1. Integrated restoration ................................................................................ 52
2.5.2. Manage remotely stored files ...................................................................... 54
2.5.3. Discover and import archives ..................................................................... 55
2.6. View Log .......................................................................................................... 56
2.7. Access Control ................................................................................................... 57
2.7.1. Joomla! 1.5, Nooku Server and other Joomla! 1.5 distributions .......................... 58
2.7.2. Joomla! 1.6, Molajo and other Joomla! 1.6 distributions ................................... 59
2.8. Site Transfer Wizard ........................................................................................... 59
3. Include data to the backup .............................................................................................. 61
3.1. Multiple Databases Definitions .............................................................................. 62
3.2. Off-site Directories Inclusion ................................................................................ 64
4. Exclude data from the backup ......................................................................................... 65
4.1. Files and Directories Exclusion ............................................................................. 66
4.2. Database Tables Exclusion ................................................................................... 68
4.3. Extension Filters ................................................................................................. 70
4.3.1. Components ............................................................................................ 70
4.3.2. Modules ................................................................................................. 71
4.3.3. Plug-ins .................................................................................................. 71
4.3.4. Languages ............................................................................................... 72
4.3.5. Templates ............................................................................................... 72
4.4. RegEx Files and Directories Exclusion ................................................................... 73
4.4.1. Regular Expressions recipes for files and directories ....................................... 75
4.5. RegEx Database Tables Exclusion ......................................................................... 76
4.5.1. Regular Expressions recipes for database tables .............................................. 77
5. Automating your backup ................................................................................................ 78
5.1. Front-end backup, for use with CRON .................................................................... 78
5.1.1. A PHP alternative to wget ......................................................................... 80
5.1.2. Using the front-end backup in SiteGround CRON jobs .................................... 81
5.2. Native CRON script ............................................................................................ 81
5.2.1. Setting up a CRON job on cPanel ............................................................... 82
5.2.2. Overriding configuration variables ............................................................... 83
5.3. Alternative CRON script ...................................................................................... 84
5.3.1. Setting up a CRON job on cPanel ............................................................... 85
6. Miscellaneous features ................................................................................................... 86
6.1. Lite mode for cell phones, PDAs, MIDs, etc. ........................................................... 86
6.2. System Restore Points ......................................................................................... 86
4. Miscellaneous Extensions ....................................................................................................... 88
1. Akeeba Backup Notification Module ................................................................................ 88
2. The plugins powering the One Click Update feature ............................................................ 88
5. Restoring backups ................................................................................................................. 90
1. Overview of the restoration process .................................................................................. 90
2. Getting the files on your server ....................................................................................... 90
2.1. Uploading individual files .................................................................................... 90
2.2. Extracting on the server ....................................................................................... 91
3. Performing the restoration process .................................................................................... 94
3.1. Using the Akeeba Backup Installer (ABI) ................................................................ 94
3.1.1. Automating the Akeeba Backup Installer ..................................................... 104
3.2. Unorthodox: the emergency restoration procedure ................................................... 107
4. Finalizing the restoration process .................................................................................... 109
6. Step by step guides .............................................................................................................. 114
1. Backing up your site to a cloud storage service ................................................................. 114
1.1. Introduction ..................................................................................................... 114

iv


1.2. Basic configuration ............................................................................................ 114
1.3. Using Amazon S3 ............................................................................................. 115
1.4. Using DropBox ................................................................................................. 117
1.5. Where to go from here? ..................................................................................... 118
II. Security information .................................................................................................................... 119
7. Introduction ........................................................................................................................ 121
1. Foreword ................................................................................................................... 121
2. Why you need to care about ownership and permissions? .................................................... 121
8. How your web server works .................................................................................................. 122
1. Users and groups ......................................................................................................... 122
1.1. Users .............................................................................................................. 122
1.2. Groups ............................................................................................................ 122
1.3. How users and groups are understood by UNIX-derived systems ................................ 123
2. Ownership .................................................................................................................. 123
2.1. Process ownership ............................................................................................. 123
2.2. File ownership .................................................................................................. 124
3. Permissions ................................................................................................................ 125
3.1. The three types of permissions ............................................................................ 125
3.2. What permissions can control .............................................................................. 125
3.3. Permissions notation .......................................................................................... 126
3.3.1. The textual notation ................................................................................ 126
3.3.2. The octal notation ................................................................................... 126
9. Securing your Akeeba Backup installation ............................................................................... 128
1. Access rights .............................................................................................................. 128
2. Securing the temporary and output directories ................................................................... 128
3. Securing file transfers ................................................................................................... 129
III. Appendices ............................................................................................................................... 131
A. The JPA archive format, v.1.2 ............................................................................................... 133
B. The JPS archive format, v.1.9 ............................................................................................... 137
C. GNU Free Documentation License ......................................................................................... 141

v

Part I. User's Guide to
Akeeba Backup for Joomla!™

Table of Contents
1. Introduction ................................................................................................................................... 5
1. Introducing Akeeba Backup ...................................................................................................... 5
2. Indicative uses ........................................................................................................................ 5
3. A typical backup/restoration workflow ........................................................................................ 6
4. Server environment requirements ............................................................................................... 7
2. Installation, updates and upgrades ...................................................................................................... 9
1. Installing Akeeba Backup ......................................................................................................... 9
1.1. Getting the installation packages ..................................................................................... 9
1.2. Installing the backup component and language files ............................................................ 9
1.2.1. Manual installation ............................................................................................. 9
1.3. Installing the administrator panel icon module and plugins ................................................. 10
2. Upgrading from Core to Professional ........................................................................................ 10
3. Updating to the latest version .................................................................................................. 10
3. Using the Akeeba Backup component ............................................................................................... 11
1. Pages outside the Control Panel panes ...................................................................................... 11
1.1. Common navigation elements ....................................................................................... 11
1.2. The Control Panel ....................................................................................................... 11
1.2.1. Editing the component's Parameters ..................................................................... 15
1.2.2. I get a "JFTP::chmod: Bad response" error. What's wrong? ...................................... 18
1.2.3. I get an error about something regarding T_OBJECT / I get a blank page when I try to
access Akeeba Backup ............................................................................................... 18
2. Basic Operations ................................................................................................................... 19
2.1. Profiles Management ................................................................................................... 19
2.2. Configuration Wizard .................................................................................................. 20
2.3. Configuration ............................................................................................................. 21
2.3.1. The main settings ............................................................................................. 21
2.3.1.1. Basic Configuration ................................................................................ 21
2.3.1.2. Advanced configuration .......................................................................... 25
2.3.1.3. Optional filters ...................................................................................... 26
2.3.1.4. Quota management ................................................................................. 27
2.3.1.5. Fine tuning ........................................................................................... 27
2.3.2. Database dump engines ..................................................................................... 28
2.3.2.1. Native MySQL Backup Engine ................................................................ 28
2.3.3. File and directories scanner engines ..................................................................... 30
2.3.3.1. Smart scanner ....................................................................................... 30
2.3.4. Archiver engines .............................................................................................. 31
2.3.4.1. ZIP format ............................................................................................ 31
2.3.4.2. JPA format ........................................................................................... 32
2.3.4.3. Encrypted Archives (JPS format) .............................................................. 32
2.3.4.4. DirectFTP ............................................................................................. 34
2.3.4.5. DirectSFTP ........................................................................................... 35
2.3.4.6. ZIP using ZIPArchive class ..................................................................... 36
2.3.5. Data processing engines .................................................................................... 36
2.3.5.1. No post-processing ................................................................................. 36
2.3.5.2. Send by email ....................................................................................... 37
2.3.5.3. Upload to Amazon S3 ............................................................................ 37
2.3.5.4. Upload to DropBox ................................................................................ 39
2.3.5.5. Upload to RackSpace CloudFiles .............................................................. 40
2.3.5.6. Upload to Microsoft Windows Azure BLOB Storage service .......................... 41
2.3.5.7. Upload to Remote FTP server .................................................................. 42
2.4. Backup now ............................................................................................................... 44

2

User's Guide to Akee-
ba Backup for Joomla!™

2.5. Administer Backup Files .............................................................................................. 49
2.5.1. Integrated restoration ........................................................................................ 52
2.5.2. Manage remotely stored files .............................................................................. 54
2.5.3. Discover and import archives ............................................................................. 55
2.6. View Log .................................................................................................................. 56
2.7. Access Control ........................................................................................................... 57
2.7.1. Joomla! 1.5, Nooku Server and other Joomla! 1.5 distributions .................................. 58
2.7.2. Joomla! 1.6, Molajo and other Joomla! 1.6 distributions .......................................... 59
2.8. Site Transfer Wizard ................................................................................................... 59
3. Include data to the backup ...................................................................................................... 61
3.1. Multiple Databases Definitions ...................................................................................... 62
3.2. Off-site Directories Inclusion ........................................................................................ 64
4. Exclude data from the backup ................................................................................................. 65
4.1. Files and Directories Exclusion ..................................................................................... 66
4.2. Database Tables Exclusion ........................................................................................... 68
4.3. Extension Filters ......................................................................................................... 70
4.3.1. Components .................................................................................................... 70
4.3.2. Modules ......................................................................................................... 71
4.3.3. Plug-ins .......................................................................................................... 71
4.3.4. Languages ....................................................................................................... 72
4.3.5. Templates ....................................................................................................... 72
4.4. RegEx Files and Directories Exclusion ........................................................................... 73
4.4.1. Regular Expressions recipes for files and directories ............................................... 75
4.5. RegEx Database Tables Exclusion ................................................................................. 76
4.5.1. Regular Expressions recipes for database tables ..................................................... 77
5. Automating your backup ........................................................................................................ 78
5.1. Front-end backup, for use with CRON ............................................................................ 78
5.1.1. A PHP alternative to wget ................................................................................. 80
5.1.2. Using the front-end backup in SiteGround CRON jobs ............................................ 81
5.2. Native CRON script .................................................................................................... 81
5.2.1. Setting up a CRON job on cPanel ....................................................................... 82
5.2.2. Overriding configuration variables ....................................................................... 83
5.3. Alternative CRON script .............................................................................................. 84
5.3.1. Setting up a CRON job on cPanel ....................................................................... 85
6. Miscellaneous features ........................................................................................................... 86
6.1. Lite mode for cell phones, PDAs, MIDs, etc. ................................................................... 86
6.2. System Restore Points ................................................................................................. 86
4. Miscellaneous Extensions ............................................................................................................... 88
1. Akeeba Backup Notification Module ........................................................................................ 88
2. The plugins powering the One Click Update feature .................................................................... 88
5. Restoring backups ......................................................................................................................... 90
1. Overview of the restoration process .......................................................................................... 90
2. Getting the files on your server ............................................................................................... 90
2.1. Uploading individual files ............................................................................................ 90
2.2. Extracting on the server ............................................................................................... 91
3. Performing the restoration process ............................................................................................ 94
3.1. Using the Akeeba Backup Installer (ABI) ....................................................................... 94
3.1.1. Automating the Akeeba Backup Installer ............................................................ 104
3.2. Unorthodox: the emergency restoration procedure ........................................................... 107
4. Finalizing the restoration process ............................................................................................ 109
6. Step by step guides ...................................................................................................................... 114
1. Backing up your site to a cloud storage service ......................................................................... 114
1.1. Introduction ............................................................................................................. 114
1.2. Basic configuration .................................................................................................... 114

3

User's Guide to Akee-
ba Backup for Joomla!™

1.3. Using Amazon S3 ..................................................................................................... 115
1.4. Using DropBox ........................................................................................................ 117
1.5. Where to go from here? ............................................................................................. 118

4

Chapter 1. Introduction
1. Introducing Akeeba Backup
Akeeba Backup is a complete site backup solution for your Joomla!™ powered website. As the successor to the
acclaimed JoomlaPack component, Akeeba Backup builds on its strong legacy to deliver an easy to use, yet powerful,
solution to backing up, restoring and moving your site between servers of the same or different architecture.

Its mission is simple: backup your entire site - including all files and database contents - inside a standalone archive.
You can then restore your entire site from the contents of this archive, without the need of installing Joomla!™ prior
to the restoration. You can do so in a single click manner, without the tedious work required to set up and test external
utilities, without changing your server configuration and without having to dive into obscure configuration options.

If you want absolute power and flexibility, Akeeba Backup is right for you, too! It puts you in charge of fine-tuning
your backup, choosing which directories, files or database tables to exclude. It can even allow you to backup non-
Joomla!™ content, as long as you specify which off-site directories and databases you want to add.

Akeeba Backup has won the J.O.S.C.A.R. award in the Administrator Only Extension at J and Beyond 2010. The
award was the result of a peer voting process, where the high-end Joomla! developers and web designers participating
in the J and Beyond 2010 conference picked the top extensions for Joomla!.

2. Indicative uses
Akeeba Backup can be used for much more than just backup. Some indicative uses are:

• Security backups. Taking a snapshot of your site should your server fail, or a hacker exploit some security hole
to deface or compromise your site.

• Template sites. Web professionals have used Akeeba Backup in order to create "template sites". This means that
you can build a site on a local server, install every component you usually do on most clients' sites and back it up.
You now have a canned site that can serve as a great template for future clients. Using the same method you can have
a snapshot of all the sites you have built for your clients, without the need to have them installed on your local server.

• Build a site off-line, upload the finished site easily. Web professionals can build a complete site off-line on a local
server and when done take a snapshot with Akeeba Backup, then restore it on the production site.

• Testing upgrades locally, without risking breaking the on-line site. Joomla!™ updates have the potential of
breaking things, especially in complex or badly written components and modules. Web masters use Akeeba Backup
to get a site snapshot, restore it on a local test server, perform the upgrade there and test for any problems without
the live site being at risk.

• Debugging locally. Almost the same as above, web professionals have used Akeeba Backup to take a snapshot of
a client's Joomla!™ site in order to perform bug hunting. Using Akeeba Backup again, they can upload the fixed
site back on the live server.

• Relocating a site to a new host. Web masters who want to take their site to a new host have found Akeeba Backup
to be their saviour. Just backup the original site and restore on the new host; presto, your site is relocated with
virtually no effort at all.

Akeeba Backup has the potential to save you hours of hard labor, according to our users. It is licensed under the GNU
General Public License version 3 or, at your option, any later version of the license. As a result, you are free to modify
it to your liking and install it on as many sites as you like without having to pay for a pricey "developer's license".

5

Introduction

Akeeba Backup comes in two editions, Core and Professional. Akeeba Backup Core is provided free of charge and
contains all the features a typical webmaster would like to have in order to easily complete backup and restoration
jobs. On top of that, we offer you unconditional free support, directly from members of our team, through our forum.
Even if this is not enough for you, we even give away our full documentation without charging a single penny! No, we
are not crazy and there are no strings attached. We simply believe that software - just like ideas - is born Free. It is our
duty to share it with you, for free. We just kindly ask you to donate some money to us if you find this software useful.

Akeeba Backup Professional is designed to take your experience to a whole new level. Featuring advanced options,
like embedded restoration, inclusion of external directories and databases, powerful filters based on regular expres-
sions, easy exclusion of Joomla!™ extensions and support for putting your backups on compatible cloud storage ser-
vices (such as Amazon's S3), it is designed to give the professional user a strong efficiency leverage. Akeeba Backup
Professional is the ideal choice for professional web developers. Thanks to its liberal GNU GPL v3 license, Akeeba
Backup Professional can be installed on an unlimited number of clients' websites, royalty-free! Amazing, isn't it?

3. A typical backup/restoration workflow
As stated, Akeeba Backup is designed to make your life easier. It does that by streamlining the workflow of backing
up and restoring (or migrating) your site. From Akeeba Backup's perspective, restoring to the same host and location,
copying your site in a subdirectory / subdomain of the same host or transfering your site to a completely new host is
identical. That's right, Akeeba Backup doesn't care if you are restoring, copying, cloning or migrating your site! The
process is always the same, so you only have to learn it once. The learning curve is very smooth, too!

The typical workflow involves using two utilities from the Akeeba Backup suite: the Akeeba Backup component itself,
and Akeeba Kickstart. Here is the overview:

1. Install Akeeba Backup and configure it to taste. Or use the automated Configuration Wizard to automatically con-
figure it with the perfect settings for your server. Hit on the Backup Now button and let your site back up. When it
finishes up, click on the Administer Backup Files button. Click on the download links on the far-right of the only
backup entry from the list - or, better yet, use FTP to do that - saving all parts of the backup archive somewhere
on your local PC.

2. Extract the kickstart- VERSION .zip file you downloaded from our Downloads repository. The only contained files
are kickstart.php and the translation INI files. Upload them to the server on which you want to restore your
site to.

3. Upload all parts of the backup archive (do not extract it yet, just upload the files) to the server on which you
want to restore your site to (called hereforth the target server ). Your server's directory should now contain the
kickstart.php and the parts of the backup archive (.jpa, .j01, etc).

4. Fire up your browser and visit the Kickstart URL on your target server, for example http://
www.example.com/kickstart.php .

5. Change any option - if necessary - and hit the Start button. Sit back while Kickstart extracts the backup archive
directly on the server! It's ultra-fast too (when compared to FTP uploading all those 4000+ files!). If it fails with
an error, go back, select the Upload using FTP option and supply your FTP connection information, then
click on Start again.

6. A new window pops up. It's the Akeeba Backup Installer (ABI), the site restoration script which was embedded
inside your archive. Do not close the Kickstart window yet!

7. Follow the prompts of the Akeeba Backup Installer, filling in the details of the new server (most importantly, the
new database connection and FTP connection information).

8. When the Akeeba Backup Installer is done, it prompts you to delete the installation directory. Ignore this prompt
and simply close the ABI window.

6

Introduction

9. Back to the Kickstart window, click the button titled Clean Up. Kickstart removes the installation directory, restores
your .htaccess file (if you had one in the first place), removes the backup archive and itself.

10.Believe it or not, you have a working site! Honestly! Click on the View the front-end button to visit your new site.

If you are restoring to a different subdirectory on the same server as the original site, or to a whole different host, you
might need to edit your .htaccess file for your site to work properly. This is all described in the restoration section of
this guide. If you need help backing up your site, take a look in the Backup Now section of this guide.

4. Server environment requirements
In order to work, Akeeba Backup requires the following server software environment:

• Joomla!™ 1.5.14 or later in the 1.5.x or 1.6.x range. It is a native component; it doesn't require Legacy Mode but
can work with it if it's enabled.

• PHP 5.1.3 or greater, 5.2.1 or later highly recommended. Akeeba Backup will not work on PHP 4! PHP 5.2.4 and
5.2.5 are not supported because they contain grave bugs which will not allow Akeeba Backup to function properly.
Akeeba Backup is also compatible with the newest PHP 5.3 releases.

• MySQL 4.1 or later. MySQL 5.0 or greater recommended for optimal performance. Even though Akeeba Backup
may run on MySQL 4.0, restoring the backup generated on such a host may be impossible.

• Minimum 16Mb of PHP memory_limit (sufficient only for smaller web sites, without many plug-ins and modules
running). More is better. 32Mb to 64Mb recommended for optimal performance on large sites.

• The PHP function opendir must be available.

• Available free space or quota limit about 75%-80% of your site's size.

• The cURL PHP module must be installed for FTP and cloud backup to work.

As far as the browser is concerned, you can use:

• Internet Explorer 7, or greater

• Firefox 2.0, or greater

• Safari 3, or greater

• Opera 9, or greater (Opera 10 highly recommended)

• Google Chrome 3 or greater

• Konqueror 3.5.9, or greater

Important
Google Chrome 4 introduced a feature where it permanently "remembers" redirections. Since redirections are
a key component to the internal working of Joomla!™, using Google Chrome 4+ to administer your Joom-
la!™ site can lead to unexpected results, unless you are using Joomla! 1.5.17 or any later version. Therefore
we strongly recommend upgrading your sites to the latest Joomla! release. Akeeba Backup does include
workarounds for Chrome's behaviour, but we can't guarantee that anything else in Joomla! (including instal-
lation) will work smoothly.

7

Introduction

In any case, you must make sure that Javascript is enabled on your browser for the backup to work. If you are using
AVG antivirus, please disable its Link Checker feature as it is known to cause problems with several Javascript-based
web applications, including Akeeba Backup and its tools.

8

Chapter 2. Installation, updates and
upgrades
1. Installing Akeeba Backup
Installing Akeeba Backup is no different than installing any other Joomla!™ extension on your site. You can read
the complete instructions for installing Joomla!™ extensions on the official help page [http://help.joomla.org/con-
tent/view/1476/235/]. Throughout this chapter we assume that you are familiar with these instructions and we will
not duplicate them.

1.1. Getting the installation packages
You can download the latest installation packages by visiting our site at http://www.akeebabackup.com. Just click on
the Download, Official Releases menu item on the top menu of our site. Then click on Akeeba Backup. The releases
are listed with the newest release always on top. Click on it to view the files. If you are not a subscriber, click on
the Akeeba Backup Core to download the ZIP installation package. If you are a subscriber to the Professional release
(AKEEBAPRO or AKEEBADELUXE levels), please log in first. You should then see an item on this page reading
Akeeba Backup Professional. Click on it to download the ZIP installation package.

All Akeeba Backup installation packages contain the component, the backup notification icon module for your ad-
ministrator area, our plugins and all translation files. Installing it will install all of the above items automatically. The
installation package can be installed on both Joomla! 1.5 and Joomla! 1.6 sites. It can also be used to upgrade Akeeba
Backup; just install it without uninstalling the previous release.

In any case, do not extract the ZIP files yet!

1.2. Installing the backup component and language files
Log in to your site's administrator section. Click on the Extensions, Install/Uninstall (Joomla! 1.5) or Extensions,
Manage (Joomla! 1.6 users) link on the top menu. In this page, locate the Browse button in the Upload Package File
area. Locate the installation ZIP file you had previously downloaded and select it. Back to the page, click on the Upload
File & Install button. After a short while, Joomla!™ will tell you that the component has been installed. It will also
let you know if the icon module and plugins were installed.

1.2.1. Manual installation
Sometimes Joomla!™ is unable to properly extract ZIP archives due to technical limitations on your server. In this
case, you can follow a manual installation procedure.

First, you have to extract the installation ZIP file in a subdirectory named akeeba on your local PC. Then, upload the
entire subdirectory inside your site's temporary directory. At this point, there should be a subdirectory named akeeba
inside your site's temporary directory which contains all of the ZIP package's files.

If you are unsure where your site's temporary directory is located, you can look it up by going to the Global Configura-
tion, click on the Server tab and take a look at the Path to Temp-folder setting. The default setting is the tmp directory
under your site's root. Rarely, especially on automated installations using Fantastico, this might have been assigned the
system-wide /tmp directory. In this case, please consult your host for instructions on how to upload files inside this
directory, or about changing your Joomla!™ temporary directory back to the default location and making it writable.

Assuming that you are past this uploading step, click on the Extensions, Install/Uninstall (Joomla! 1.5) or Extensions,
Manage (Joomla! 1.6 users) link on the top menu. In this page, locate the Install Directory edit box in the Install

9

Installation, updates and upgrades

from Directory area. It is already filled in with the absolute path to your temporary directory, for example /var/
www/joomla/tmp. Please append /akeeba to it. As per our example, it should look something like /var/www/
joomla/tmp/akeeba. Then, click on the Install button.

If you still can't install Akeeba Backup and you are receiving messages regarding unwritable directories, inability to
move files or other similar file system related error messages, please do not ask us for support. These errors stem from
your site set up and can best be resolved by asking for help in the official Joomla!™ forums [http://forum.joomla.org].

1.3. Installing the administrator panel icon module and
plugins
These are automatically installed or upgraded when you install the component. No further action is necessary.

2. Upgrading from Core to Professional
Upgrading from Akeeba Backup Core to Akeeba Backup Professional is by no means different than installing the
component. You do not have to uninstall the previous version; in fact, you are discouraged from doing so. Simply
follow the installation instructions so as to install Akeeba Backup Professional over the existing Akeeba Backup Core
installation. That's all! All your settings are preserved.

3. Updating to the latest version
Checking for the latest version and upgrading
You can easily check for the latest published version of the Akeeba Backup component by visiting http://
www.akeebabackup.com/latest. The page lists the version and release date of the latest Akeeba Backup release. You
can check it against the data which appear on the right-hand pane of your Akeeba Backup Control Panel. If your release
is out of date, simply click on the Download link to download the install package of the latest release to your PC.

Updating Akeeba Backup to the latest version is by no means different than installing the component. You do not have
to uninstall the previous version; in fact, you are discouraged from doing so. Simply follow the installation instructions
so as to install the latest Akeeba Backup version over the existing Akeeba Backup installation. That's all! All your
settings are preserved.

Live update
There is also an alternate update path, if your server supports it. It is called the "Live Update" feature and it is available
since Akeeba Backup 3.0.b1. Whenever you visit the Akeeba Backup Control Panel, it will automatically check for
the existence of an updated version and it will notify you. Clicking on the notification allows you to perform a live
update without further interaction. Do note that if your server is protected by a firewall you'll have to enable port 80
and 443 TCP traffic to www.akeebabackup.com and joomlacode.org for this feature to work properly.

10

Chapter 3. Using the Akeeba Backup
component
In this chapter you are going to find detailed reference of all the pages, options and features of the Akeeba Backup
components. To get things organized in a logical manner, we chose to present the individual pages in the same manner
they appear on the component's Control Panel page, i.e. the first page which is presented to you when you launch the
component's back-end. Some of the pages are not available as Control Panel icons, but from different areas of the
component. These are discussed first.

1. Pages outside the Control Panel panes
1.1. Common navigation elements
All pages have their title displayed above their contents. On the tool bar there is a Back icon. Clicking it will bring
you back to the Control Panel .

On pages where editing takes place (e.g. the Configuration page, the profiles editor, etc) instead of the Back icon there
is a Cancel icon which discards any changes made and returns you to the previous page. On those pages you will also
find a Save icon which saves settings and returns you to the previous page, as well as an Apply icon which saves
settings and returns you to the same editing page.

On the bottom of each page, just above the Joomla!™ footer, there is the license information. On the Control Panel
page there is also a donation link appearing on the right sidebar; if you feel that Akeeba Backup was useful for you
do not hesitate to donate any amount you deem appropriate.

1.2. The Control Panel
The main page which loads when you click on Components > Akeeba Backup is called the Control Panel screen. From
here you can see if everything is in working order and access all of the component's functions and configuration options.

If Akeeba Backup detects a problem with loading the necessary Javascript files, it will issue a big warning message
notifying you that it couldn't load the necessary Javascript files. Sometimes, depending on your server settings, this
message will not be shown but the interface will behave erratically and appear different than the screen shots provided
in here. In this case, you have to follow these simple steps:

1. Use your favorite FTP client and give the media/com_akeeba directory and all of its contained subdirectories
and files 0755 permissions (read/write/execute for the owner, read/execute for group and others).

2. If and only if you have completed the first step to no avail, click on the Parameters icon on the toolbar and change
the jQuery and jQuery UI sources to Google AJAX API Library.

Akeeba Backup will try to automatically do this for you, as long as you have provided FTP connection information to
your site's Global Configuration and enabled the FTP option in that page.

If you see a blank page instead of the Control Panel, you may have a very old version of PHP installed on your server.
Akeeba Backup requires PHP 5.1.3 or later in order to work. You can check your PHP version by going to your site's
administrator back-end and clicking on the Help, System Info menu item. Take a look at the PHP Version row. If the
number in there is in the 4.x.y range, you can't use Akeeba Backup on your server before upgrading to PHP 5.

11

Using the Akeeba Backup component

Important
Even though the Control Panel may load in PHP 5.0.x, the backup won't run on such old versions of PHP.
You can check your PHP version by going to your site's System Information menu item. We strongly suggest
that you use the latest PHP 5.2.x or 5.3.x version for optimal operation of the component.

On the top of the page there is the component's title. Beneath it you can find quick links to the most vital functions
which is what you'll have to deal with 99% of your time using the component.

Under the quick links, there is the profile selection box. It serves a double purpose, indicating the active profile and
letting you switch between available profiles. Clicking on the drop down allows you to select a new profile. Changing
the selection (clicking on the drop down list and selecting a new profile) automatically makes this new profile current
and Akeeba Backup notifies you about that. Should this not happen, you can manually click on the Switch Profile
button on the right to forcibly make the selected profile current.

Tip
The active profile is applied in all functions of the component, including configuration, filter settings, inclu-
sion options, etc. The only settings which are not dependent on the active profile are those accessible from
the Component Parameters button. Keep this in mind when editing any of Akeeba Backup's settings!

On the right hand side of the page, you will find a slider with useful information arranged in panels. There are several
panels:

Status Summary

In this panel you can find information regarding the status of your backup output and temporary
directories. Akeeba Backup will warn you if any of these directories is unwritable. If the text
reads that there are potential problems you must take a look at the details below to find out what
these might be!

Important
No matter what the PHP Safe Mode setting is, it is possible that your host enforces
open_basedir restrictions which only allow you to have an output or temporary directory

12


under a handful of predefined locations. On this occasion, Akeeba Backup will report
the folder unwritable even though you might have enforced 0777 (read, write and exe-
cute allowed for all) permissions. These restrictions are reported in the section below the
overall status text as an item entitled "open_basedir restrictions".

If any potential problems have been detected, right below the overall status you will find one or
several warnings links. Just click on each warning's description to get a pop up window explaining
the potential problem, its impact on your backup and precautionary or corrective steps you can
take. If this section is empty, no detectable problems were found; this is a good thing, indeed!

Important
You are supposed to read the full text of the warnings by clicking on each item. Quite
often users post for support on our forum asking something which is already written
in the full text of the warnings. DO NOT SEEK SUPPORT IN OUR FORUM IF
YOU HAVE NOT TRIED TO READ THE DETAILED DESCRIPTION OF PO-
TENTIAL PROBLEMS APPEARING ON THIS BOX! I KNOW MOST OF YOU
IGNORE THIS, BUT I WILL NOT ANSWER ANY MORE QUESTIONS COV-
ERED IN THOSE DESCRIPTIONS.

Below of all this information you can find a donation link. If you feel that Akeeba Backup has
saved your day - and you do not wish or can't afford subscribing to the Professional edition - you
can donate a small amount of money to help us keep the free version going!

Backup Statistics

This panel informs you about the status of your last backup attempt. The information shown is
the date and time of backup, the origin (remote, backend or frontend), the profile used and the
backup status.

13


Akeeba Backup
News

This is service provided by FeedBurner, displaying a rendering of the RSS feed of the
AkeebaBackup.com project page. You should check it out as it contains important release an-
nouncements. Remember, each new version of Akeeba Backup contains several important bug
fixes and amazing new features.

Translation Cred-
its

Each translation file contains information about the language and the translator. This information
is displayed in this panel.

14


The left navigation panel set allows access to the different functions of the component, by clicking on each icon.

There are two icons which need special mention, the updates icon and the Component Parameters icon.

Since Akeeba Backup 3.2 there is a "Live Update" feature integrated in the navigation panel. Every time you display
the Control Panel page, Akeeba Backup will query AkeebaBackup.com for the existence of a new release and cache
this data for a maximum of 24 hours. If it discovers that your version is out of date, it will allow you to upgrade to the
latest release by clicking on the update icon which displays as the last item of the Basic Operations set of icons.

Important
For this feature to work you must ensure that your server can communicate with akeebabackup.com. If you
are behind a firewall, make sure that you open TCP traffic over port 80 and 443 to www.akeebabackup.com
(our update server location) and joomlacode.org (our file repository system).

If you are a subscriber to the Professional release, the live update will not work properly unless you also specify your
AkeebaBackup.com Download ID in the Component Parameters page. Since the Professional release is provided on
a subscription basis, whenever you ask Akeeba Backup to update it, it has to provide your Download ID to our site to
verify that you have a valid subscription before downloading the update installation package. You can find out your
Download ID by logging in to AkeebaBackup.com and clicking on the My Subscriptions item on the right-hand user
menu module.

The Component Parameters button allows you to edit component-wide parameters, i.e. settings which apply to all
backup profiles. These options are mentioned in the following section.

1.2.1. Editing the component's Parameters
The second-to-last icon in the Basic Operations set is titled Component Parameters. Clicking on it will open the editor
page in a modal dialog (lightbox) on your browser. These parameters take effect regardless of the active profile.

15


Do note that this popup looks slightly differently in Joomla! 1.6, i.e. it has tabs for each set of options instead of
horizontal ruler lines to separate them. However, the naming of the options and their associated meaning is exactly
the same.

jQuery Source Akeeba Backup uses the jQuery Javascript library to render all special effects and GUI items, as
well as handle its AJAX operations. Depending on your server configuration you may want to
change how it loads the jQuery library:

• Included in component. This is the recommended setting. It will use the copy of the library
distributed with the component.

• Use Google AJAX API libraries. This is recommended only for live sites. Instead of using
the copy distributed with the component, it loads the library from Google's content delivery
network. This significantly speeds up the load time of Akeeba Backup's pages.

• None (already loaded) If you have a plug-in which automatically loads the jQuery library on
the back-end, it's prudent to have Akeeba Backup not load its own copy of the library so as to
avoid any conflicts. In this case, select this option.

jQuery UI Source Akeeba Backup uses the jQuery UI Javascript add-on library to render most GUI items. Depending
on your server configuration you may want to change how it loads the jQuery UI library:

• Included in component. This is the recommended setting. It will use the copy of the library
distributed with the component.

• Use Google AJAX API libraries. This is recommended only for live sites. Instead of using
the copy distributed with the component, it loads the library from Google's content delivery
network. This significantly speeds up the load time of Akeeba Backup's pages.

16


• None (already loaded) If you have a plug-in which automatically loads the jQuery UI library
on the back-end, it's prudent to have Akeeba Backup not load its own copy of the library so as
to avoid any conflicts. In this case, select this option.

Minimum access This setting defines which is the minimum Joomla! privileges required to access Akeeba Backup's
level backup functionality. Remember that giving someone access to Akeeba Backup is like giving him
a free pass to all of your site's configuration options, including those in your configuration.php
file, i.e. database and FTP connection details. Never, ever give access to people who you don't
fully trust. That's why the default setting is Super Administrators, which allows only Super Ad-
ministrators (by definition full access users) to access the component.

Important
Even if you have a third party ACL system, such as JUGA, this setting will work on
top of your system. If you have set this setting to Super Administrators and try to give
a Manager access to the component through the ACL system he won't be able to use it.
Even though your ACL system will let her through, Akeeba Backup's own setting will
slam the door on her face. You have been warned!

Enable front-end Akeeba Backup allows you to take backups from the front-end, or from a desktop application
and remote back- called Akeeba Remote Control. In order to be able to do so, you have to enable this option.
up

Secret word Whenever you need to take a front-end backup, you have to supply this secret word to let Akeeba
Backup know that you really have access to its functions and you're not an impostor, or a hacker
attempting to cause a massive denial of service attack by overloading your server with backup
operations. Please use only alphanumeric characters, i.e. lower and upper case a-z letters and the
digits 0-9. Do not use special characters, as they tend to cause problems when passed in the front-
end backup URL without converting them to URL encoded format (which is beyond the scope of
this manual - so just use a-z, A-Z and 0-9, OK?)

Email on backup When enabled, Akeeba Backup will send an email regarding the backup status every time a front-
completion end or remote backup is complete or failed.

Email address When the above option is enabled, the email will be sent to this email address. If you leave it
blank, Akeeba Backup will send a copy of the email to all Super Administrators of the site.

Email subject This option lets you customise the subject of the email message which will be sent when a remote,
CRON or front-end backup succeeds. You can use the same variables you can use in file names,
i.e. [HOST] for the domain name of your site and [DATE] for the current date and time stamp.
Leave blank to use the generic default option.

Email body This option lets you customise the body of the email message which will be sent when a remote,
CRON or front-end backup succeeds. Leave blank to use the generic default option. The email is
delivered as plain text; you may not use any HTML to format it. You can use the same variables
you can use in file names, i.e. [HOST] for the domain name of your site and [DATE] for the
current date and time stamp, inside the body text. Moreover, you may also use any or all of the
following variables in order to enhance the clarity of your message:

[PROFILENUM- The numeric ID of the current backup profile
BER]

[PROFILE- The description of the current backup profile
NAME]

17


[PARTCOUNT] The number of archive parts of the backup archive which was just generated

[FILELIST] A list of filenames of the archive parts of the backup archive which was just
generated

Update only to When selected, the Live Update feature will not notify you of official releases (alphas, betas, RCs
developer releas- and stables). Instead, it will notify you whenever a Developer's Release is published and allow
es you to update to it. This should only be used on test sites and only if you want to try out the latest
and greatest features before they are well-tested and released to the public. Developer's Releases
may be broken or malfunction in unexpected ways. You have been warned.

Download ID If and only if you are using the Professional release you have to specify your Download
ID for the live update feature to work properly. You can get your Download ID by visiting
AkeebaBackup.com and clicking My Subscriptions. Your Download ID is printed below the list
of subscriptions. Filling in this field is required so that only users with a valid Professional sub-
scription can download update packages, just as you'd expect from any commercial software.

Note
Users of Akeeba Backup Core do not need to supply this information. Akeeba Backup
Core is provided free of charge to everybody, therefore there is no need to validate the
update against a username and a password.

Use Encryption If you are using Akeeba Backup Professional, your settings can be automatically stored encrypted
using the industry standard AES-128 encryption scheme. This will protect your passwords and
settings from prying eyes. If, however, you do not want to use this feature, please set this option
to No and reload the Control Panel page to apply this setting. Do note that your server must have
the mcrypt extension installed for this feature to work.

Enabling or disabling this feature on Akeeba Backup Core has no effect whatsoever. Akeeba
Backup Core does not support encryption at all and this option will be silently ignored.

1.2.2. I get a "JFTP::chmod: Bad response" error. What's wrong?
When you launch Akeeba Backup, it will try to determine the permissions of the media/com_akeeba directory and
all its contents. If they are not 0755 for directories and 0644 for files, it will try to fix those permissions automatically
as they are vital for the correct operation of the component. If you have enabled Joomla!'s FTP mode in your site's
Global Configuration page, Akeeba Backup will automatically use it to fix those permissions. Some servers, though,
do not support using the SITE CHMOD command to perform this change and will cause Joomla!'s FTP library to
spit out this error.

As long as you do not get a permanent big yellow warning box notifying you that the permissions need to be fixed
and/or that jQuery is not properly loaded there is nothing to worry about. Unfortunately, there is nothing we can do to
make this message disappear, as Joomla! itself does not give us an option to suppress such expected error messages.

1.2.3. I get an error about something regarding T_OBJECT / I get a
blank page when I try to access Akeeba Backup
Your host is running PHP4, the no longer developed and completely unsupported version of PHP. Akeeba Backup, like
most other web software developed the last two years, requires PHP 5. More specifically, we suggest using the latest
PHP 5.2 on your website. It's not only a matter of being able to run Akeeba Backup, it's a matter of not compromising
your site's security due to known PHP bugs.

18


2. Basic Operations
The Basic Operations group contains the most common functions you will need on your daily Akeeba Backup usage.
In fact, you will only use the other pages sparingly, mostly when you create a backup profile or want to update it after
doing significant changes to your site.

2.1. Profiles Management

The Profiles Management page is the central place from where you can define and manage backup profiles . Each
backup profiles can be regarded as a container holding Akeeba Backup configuration values and filter settings. Each
one uniquely and completely defines the way Akeeba Backup will perform its backup process.

The main page consists of a list of all backup profiles. On the left hand column there is a check box allowing the
selection of a backup profile so that one of the toolbar operations can be applied. The other column displays the
description of the backup profile. Clicking on it leads you to the editor page, where you can change this description.

On the page's toolbar you can find the operations buttons:

New Creates a new, empty profile. Clicking on this button will lead you to the editor page, where you can define
the name of the new profile, or cancel the operation if you've changed your mind.

Copy Creates a prostine copy of the selected backup profile. The copy will have the same name and include all
of the configuration options and filter settings of the original.

Delete Permanently removes all selected backup profiles. All associated configuration options and filter settings
are removed as well. This is an irreversible operation; once a profile is deleted, it's gone forever.

You can only delete one profile at a time. If you select multiple profiles, only the first one (topmost) will
be removed.

When you create a new profile or copy an existing profile, the newly generated profile becomes current. This means
that you can work on your new profile as soon as you're finished creating it, without the need to manually make it
current from the Control Panel page.

The editor page which appears when creating or editing a profile is trivial. The only changeable parameter is the
profile's description. Clicking on Save applies the settings and gets you to the main Profiles Management page. Clicking
on Apply applies the settings and returns you to the editor page. Finally, clicking on Cancel will disregard any changes
made and get you to the main Profiles Management page.

19


2.2. Configuration Wizard
Akeeba Backup 3.1.5 and later include the Configuration Wizard feature. This is an automated process which will
benchmark your server's performance and try to fine tune common configuration variables for optimal backup perfor-
mance. The Configuration Wizard settings are applied to the current profile only. If you want to fine tune a different
profile, you have to select it from the drop-down list in the Control Panel page before clicking on the Configuration
Wizard button. Do note that using the Configuration Wizard has the following effects:

• Your backup type is switched to "Full site backup"

• The archiver engine is switched to "JPA (Recommended)"

If you want to use a different backup type and/or archive type, you can review the configuration changes after the
wizard is finished.

The Configuration Wizard will automatically fine tune the following configuration parameters:

• AJAX method (use AJAX or IFrames)

• Optimize the minimum execution time so as to make the backup as fast as possible without your server throwing
403 Forbidden errors

• Adjust the location and/or permissions of the output and temporary directories. Useful if you just transferred your
site to a new server or location.

• Optimize the database dump engine settings to make database dump as fast as possible, while avoiding memory
outage errors

• Optimize the maximum execution time so that as few steps as possible are performed during the backup, without
causing a timeout

• Automatically determines if your server needs archive splitting.

Important
The Configuration Wizard does not address the archive splitting required when you are using a post-pro-
cessing engine (such as backup-to-email, S3, DropBox, etc). If you are using post-processing you may
have to manually set the Part Size for Split Archives to a different value manually.

At the end of the wizard process, you can either try taking a backup immediately or review and possibly modify the
configuration parameters.

20


2.3. Configuration
The Configuration page is split in many sections - or panes, if you like - each one serving as a group for closely related
options. Each of those panes displays a title and below it you can find all of the options. Hovering your mouse of the
label - the left hand part of each row - you will be presented with a quite big tooltip providing short documentation of
the setting and its available options. This way you won't have to refer to this document constantly when configuring
Akeeba Backup.

Some of the settings also feature a button. They can either do some action, like browsing for a folder and testing
connection parameters, or it may be labeled Configure.... This latter case is mostly interesting, as pressing the button
will toggle the display of a sub-pane which contains options pertaining to this specific option. This GUI pattern is
primarily used for "engines" type settings.

Another interface element worth mentioning are the composite drop-downs. Whenever you are supposed to enter a
number, Akeeba Backup presents you with a drop-down menu of the most common options. You can either select a
value from the list, or select "Custom...". In the latter case, a text box appears to the right of the drop-down. You can now
type in your desired value, even if it's not on the list. Do note that all of these elements have preset minimum/maximum
values. If you attempt to enter a value outside those boundaries, or an invalid number, they will automatically revert
to the closest value which is within the presents bounds.

Note
If you had been using earlier releases of Akeeba Backup, you will remember that these values used to use a
draggable slider. Since the slider was rather "jumpy" and hard to configure, we reverted to using composite
drop-downs in order to make entry of settings easier and faster.

On the top of the page you can see the numeric ID and title of the active backup profile. This acts as a reminder, so
that you know which profile's settings you are editing. The toolbar also contains a Parameters button. Clicking on
it will launch the profile-independent, component-wide parameters editor. It's the same as clicking the Component
Parameters button in the Control Panel.

The rest of this document is separated into sub-sections. The first sub-section describes the settings of each of the main
configuration panes, whereas the rest of the sections discuss the settings made available to you through sub-panes.

2.3.1. The main settings
2.3.1.1. Basic Configuration

21


Output Directory This is the directory where the result of the backup process goes. The result of the backup -
depending on other configuration options - might be an archive file or an SQL file. This is also
where your backup log file will be stored. The output directory must be accessible and writable
by PHP.

Important
Providing a directory with adequate permissions might not be enough! There are oth-
er PHP security mechanisms which might prevent using a directory, for example the
open_basedir restriction which only allows certain paths to be used for writing files
from within PHP. Akeeba Backup will try to detect and report such anomalies in the
Control Panel page before you attempt a backup.

You can use the following variables to make your setting both human readable and portable across
different servers - or even different platforms:

• [DEFAULT_OUTPUT] is replaced by the absolute path to your site's administra-
tor/components/com_akeeba/backup directory. This is assigned as the default loca-
tion of output files unless you change its location. If you leave it as it is, you are supposed to
make sure that the permissions to this directory are adequate for PHP to be able to write to it.

• [SITEROOT] is automatically replaced by the absolute path to your site's root

• [ROOTPARENT] is automatically replaced by the absolute path to the parent directory of
your site's root (that is, one directory above your site's root)

Is this over your head? No problem! Just click on the Browse... button and a pop-up directory
navigator will allow you to find the proper directory. Next to the folder's location there is the
button labeled Use. Click on it to make the current directory the selected one and close the pop-up.
To make it even easier for you, Akeeba Backup displays a small icon next to the Use button. If it's a
green check mark the directory is writable and you can use it. If it's a red X sign, the directory is not
readable and you either have to select a different directory, or change this directory's permissions.

Warning
NEVER, EVER, UNDER ANY CIRCUMSTANCES SHOULD YOU USE YOUR
SITE'S ROOT AS YOUR OUTPUT OR TEMPORARY DIRECTORY! This will
usually lead to corrupt backup or backup failure. The reason is that the output and tem-
porary directories and all of their contents are automatically excluded from the backup
set. However, even if your backup succeeds due to a bug (remember, it's supposed to
fail!), using your public, web accessible site root as your output or temporary directory
is like a party invitation to hackers worldwide. If you come to our forum with such a
setup and a broken backup we can't help you.

Temporary Di- During the backup process, Akeeba Backup needs to store various pieces of temporary information
rectory such as a copy of your database's dump - before putting it inside the archive - and a "memory" file
which allows it to keep track of the backup process while it spans multiple discrete steps (page
calls). The same notes as for the Output Directory setting are, of course, in place.

You can use the following variables to make your setting both human readable and portable across
different servers - or even different platforms:

• [SITETMP] is replaced by the absolute path to your site's temp-folder, as configured in your
site's Global Configuration.

22


Warning
If your site uses the system-wide /tmp directory, do not use it for your Temporary
Directory setting! Most servers wipe out this directory's contents every minute, which
will make the backup process fail, as Akeeba Backup's "memory" file will be de-
stroyed. If unsure, use the same directory as your backup output.

• [SITEROOT] is automatically replaced by the absolute path to your site's root

• [ROOTPARENT] is automatically replaced by the absolute path to the parent directory of
your site's root (that is, one directory above your site's root)

Log Level This option determines the verbosity of Akeeba Backup's log file:

• Errors only. Only fatal errors are reported. Use this on production boxes where you have
already confirmed there are no unreadable files or directories.

• Errors and warnings. The minimum recommended setting, reports fatal errors as well as warn-
ings. Akeeba Backup communicates unreadable files and directories which it wasn't able to
backup through warnings. Read the warnings to make sure you don't end up with incomplete
backups! Warnings are also reported in the Backup Now page GUI irrespective of the log ver-
bosity setting as a convenience.

• All information. As "Error and Warnings" but also includes some informative messages on
Akeeba Backup's backup process.

• All Information and Debug. This is the recommended setting for reporting bugs. It is the most
verbose level, containing developer-friendly information on Akeeba Backup's operation. This
is what we need to help you in case of a problem. This will also create a 2-5Mb log file on most
sites, so you should only use this until you have achieved consistently valid backup archives
creation.

• None. This log level is not recommended. You should only use this if you are paranoid and
want no log files written on the server. However, if you are truly concerned about security, you
should protect the backup output directory instead of using this log level!

Our servers usually run on Errors and Warnings or All Information levels. When we are testing
new releases or change our server setups, we switch to All Information and Debug until we are
sure everything is flowing smoothly.

Backup archive Here you can define the naming template of backup files. There are a few available variables.
name Variables are special pieces of text which will be expanded to something else at backup time.
They can be used to make the names of the files harder to guess for potential attackers, as well
as allow you to store multiple backup archives on the output directory at any given time. The
available variables and their expansion at backup time are:

[HOST] The configured host name of your site.

Note
This doesn't work in the native command-line CRON mode, i.e. using
backup.php for producing automated backups. In such a case, it will be
replaced with an empty string (no text).

23


[DATE] The current server date, in the format YYYYMMDD (year as four digits, month
as two digits, day as two digits), for example 20080818 for August 18th 2008.

[YEAR] The year of the current server date, as four digits

[MONTH] The month of the current server date, as two digits (zero-padded)

[DAY] The day of the current server date, as two digits (zero-padded)

[WEEK] The current week number of the year. Week #1 is the first week with a Sunday
in it.

[WEEK- Day of the week, i.e. Sunday, Monday, etc. The full name is returned in your
DAY] current Joomla! language. Front-end, remote and CRON backups may return this
in English or your default Joomla! language. This is not a bug, it is how Joomla!'s
translation system is supposed to work.

[RANDOM] A 64-character random string. Use sparingly, it can cause backup failure due to
the file name being too long for your server

[TIME] The current server time, in the format HHMMSS (hour as two digits, minutes as
two digits and seconds as two digits), for example 221520 for 10:15:20 pm.

Backup Type It defines the kind of backup you'd like to take. The backup types for Akeeba Backup are:

• Full site backup which backs up the Joomla! database, any extra databases you might have
defined and all of the site's files. This produces a backup archive with an embedded installer
so that you can restore your site with ease. This is the option 90% of the users want; it is the
only option which creates a full backup of your site, capable of producing a working site if
everything is wiped out of your server.

• Main site database only (SQL file) which backs up only the Joomla! database. It results in a
single SQL file which can be used with any MySQL administration utility (e.g. phpMyAdmin)
to restore only your database should disaster strike. This option is recommended for advanced
users only.

• Site files only which backs up nothing but the site's files. It is complementary to the previous
option.

Warning
Having one "main site database" backup and one "sites files only" backup is not equal
to having a full site backup! The full site backup also includes an installation script
which, just like Joomla!'s web installer, allows you to effortlessly recover your site
even if everything is wiped out of your server. It acts as the glue between the two
pieces (files and database).

• All configured databases (archive file) which creates an archive file containing SQL files
with dumps of your main site's database and all of the defined multiple databases. The database
dumps can be restored by any MySQL administration tool (for example phpMyAdmin). The
difference to the second option is that it produces an uncompressed SQL file and doesn't include
any extra databases which you might have defined.

24


Note
Extra - or "multiple" - database definitions are only available in the Professional edi-
tion of the component.

• Incremental (files only). This is the same as the Site files only option, but instead of backing
up all of your site's files, it only backs up the files which changed since the last time you
performed a backup. The only comparison made is between the file's modification time and the
last successful backup's time. The "last successful backup" refers to the last backup made using
this backup Profile and which has a status of "OK" or "Obsolete".

Restoring an incremental backup set is a manual process. You have to manually extract the
files from your "base" backup (an archive made with a Full Site Backup profile), then extract
all incremental archives on top of it. Finally, used this collection of extracted files to restore
your site. This process should only be used if you really know what you are doing. Do not trust
that Akeeba Backup can sort out the collection of incremental backups and help you restore
them. It won't.

Use IFRAMEs Normally, Akeeba Backup is using AJAX postbacks to perform the backup process without timing
instead of AJAX out. Its ability to do so depends on how well your server plays along with your browser's Javascript
engine. Sometimes, this is just not possible at all and you'll experience the backup stalling at
random points through the backup process. If modifying the other options doesn't help, enable
this feature. When enabled, instead of using AJAX calls, Akeeba Backup will create a hidden
IFRAME in the page and perform all server communications through it. Since IFRAMEs load
the backup URL as if it were a regular web page, it minimizes the probability of conflicts. The
major drawback is that this method is about 50% slower than the AJAX one, so your backup will
take substantially longer.

Use database Normally, Akeeba Backup stores temporary information required to process the backup in multi-
storage for tem- ple steps inside files in your Temporary Directory. Sometimes, especially on low-end hosts with
porary data ancient versions of PHP, this causes backup issues such as the backup restarting all the time. In
those cases, you can check this box and Akeeba Backup will use your site's database to store this
temporary information.

Do note that on some hosts this will cause the backup to fail with a "MySQL server has gone
away" error message. That is a problem with the host's configuration. In those cases, nothing can
be done. Our suggestion: if you receive such an error, migrate your site to a new host as the one
you are using is most likely very restricted and severely under-performant. Moving to a faster,
more reliable host can benefit your site in many more ways than just being able to run a backup.

2.3.1.2. Advanced configuration

Database backup This option controls how Akeeba Backup will access your database and produce a dump of its
engine contents to an SQL file. It is used with all backup types, except the files only type. The available
options for this setting are discussed in the Database dump engines section of this document.

25


Filesystem scan- This option controls how Akeeba Backup will scan your site for files and directories to back up.
ner engine The available options for this setting are discussed in the File and directories scanner engines
section of this document.

Archiver engine This option controls which kind of archive will be produced by Akeeba Backup. The available
options for this setting are discussed in the Archiver engines section of this document.

Data processing Akeeba Backup allows you to post-process the backup archives once the backup process is over.
engine Post-processing generally means sending them somewhere off-server. This can be used, for ex-
ample, to move your backup archives to cloud storage, increasing your data safety. The available
options for this setting are discussed in the Data processing engines section of this document.

File writing en- This setting allows you to define how Akeeba Backup will write to archives and temporary files.
gine
This feature is under development; there are no available options yet.

Embedded Akeeba Backup will include a restoration script inside the backup archive in order to make restora-
restoration script tion easy and the backup archive self-contained. You do not need anything else except the archive
in order to restore a site. Restoration scripts honour the settings in your configuration.php, mod-
ifying only those necessary (for example, the database connection information), allowing you to
create pristine copies ("clones") of your site to any host. You can find more information about
restoration scripts in the next Chapter.

Virtual directory Using the off-site directories inclusion of Akeeba Backup Professional, the component will be
for off-site files instructed to look for files in arbitrary locations, even if they are outside the site's root (hence the
name of that feature). All the directories included with this feature will be placed in the archive
as subdirectories of another folder, in order to avoid directory name clashes. We call this folder
the "virtual directory", because it doesn't physically exist on the server, it only exists inside the
backup archive.

If you have Akeeba Backup Core or Professional and running it under Joomla! 1.6 with a cus-
tomized Joomla! library path (i.e. you have moved Joomla!'s libraries directory off your site's
root), Akeeba Backup will automatically add an off-site directory inclusion for these files and will
create a subdirectory inside this virtual directory with a name of JPATH_LIBRARIES.

2.3.1.3. Optional filters

Since Akeeba Backup 3.2 this section contains optional inclusion and exclusion filters which can be activated to
customize your backup procedure. The available filters are:

Date conditional filter

It allows you to backup only files modified after a specific date and time. This is different than the incremental file only
backup. It allows you to backup files newer than the specified date no matter which backup mode (full site backup,
files only backup, incremental files only backup) you are using. The available options are:

Date conditional Tick the checkbox to activate this filter
filter

Backup files Files before this date and time will be skipped from the backup set. The format for the date and
modified after time parameter is YYYY-MM-DD HH:MM:SS TIMEZONE. This means that you have to specify
the year as four digits, followed by a dash, then the month as two digits (e.g. 09 for September),
followed by a dash, then the day as two digits (e.g. 01 for the 1st day of the month). For example,

26


September 1st, 2010 is written as 2010-09-01. If you want to specify the time, leave a space after
the date and write down the time as the hour using two digits (00-23, no a.m./p.m. is supported!),
then a semicolon, then the minutes as two digits, followed by a semicolon, then the seconds as
two digits. For example 59 seconds after 11:05 p.m. is written as 23:05:59. You can optionally
leave a space after the time and specify the timezone as GMT+/-time. For example, GMT-6 is
Dallas time which is six hours behind the GMT and GMT+2 is two hours ahead of GMT which
is the Eastern Europe Time. If you do not specify a timezone the GMT timezone is assumed.

Important
You have to set your server's timezone in Joomla!'s Global Configuration for this feature
to work reliably. If you get strange results, try editing your site's Global Configuration
before asking us for support.

2.3.1.4. Quota management

Enable remote When checked, the quota settings will also be applied to remotely stored files. This option actually
files quotas works only for files stored on Amazon S3 or a remote FTP server.

Obsolete records When the locally stored files of a backup record are deleted (either manually or automatically
to keep after uploading it to a remote storage) the record is marked as obsolete. Some users prefer to
limit the number of the backup entries showing in the Administer Backup Files page. This option
instructs Akeeba Backup to keep at most that many obsolete records and automatically delete
older obsolete entries. This is different than the rest of the quotas because it doesn't remove files
from your server, it removes the backup entry from Akeeba Backup's interface.

Enable size quota When checked, old backup archives will be erased when the total size of archives stored under
this (and only this) profile exceed the Size quota setting.

Size quota Defines the maximum aggregated size of backup archives under the current profile to keep. Only
has an effect if the previous options is activated.

Enable count When checked, old backup archives will be erased when there are more backups stored under this
quota (and only this) profile exceed the Count quota setting.

Count quota Defines the maximum number of backups under the current profile to keep. Only has an effect
if the previous options is activated.

2.3.1.5. Fine tuning

Minimum execu- Some servers deploy anti-hacker measures (such as mod_evasive or mod_security) which will
tion time deny connections to the server if the same URL is accessed multiple times in a limited amount
of time. Akeeba Backup has to call its backup URL multiple times, so it runs the risk of being
treated as a potential hacker and denied connection to your server, resulting to backup failure.

27


In order to work around this issue, Akeeba Backup can throttle the rate of server requests using
this setting. A minimum execution time of 2 seconds means that calls to the backup URL will
happen at most once every two seconds. You are suggested to keep the default value.

Maximum execu- Akeeba Backup has to divide the backup process in individual small steps in order to avoid server
tion time timeouts. However, it has to know how small they have to be; that's why this setting exists. Akee-
ba Backup will try to avoid consuming more time per step than this setting. You have to use a
number lower than the maximum_execution_time setting in your host's php.ini file. In fact,
we suggest using 50% of that value here: if your host allows up to 30 seconds in the php.ini, you
have to enter no more than 15-17 seconds here. If unsure, 7 seconds is a very safe value under
most configurations.

Execution time When Akeeba Backup calculates the available time left for performing operations within the cur-
bias rent backup step a number of external settings may skew this result and lead to timeout errors. This
setting defines how conservative the backup engine will be when performing those calculations
and is expressed as a percentage of the Maximum execution time parameter. The less this setting
is, the more conservative Akeeba Backup gets. It is suggested not to use a value over 75%, unless
you have a very fast server. If you experience timeouts, you may want to lower this setting to a
value around 50%.

2.3.2. Database dump engines
2.3.2.1. Native MySQL Backup Engine
This engine will take a backup of your MySQL database using nothing but PHP functions in order to accomplish that.
This database dump engine supports all of the ground-breaking features available in MySQL 5, such as views, stored
procedures and functions, triggers, merge tables, temporary/memory tables, even federated tables.

Important
Restoring views, triggers, stored procedures and functions requires adequate privileges for the database user
during the restoration process. Most hosts do not assign this kind of privileges. If your restoration fails with a
MySQL error when restoring such database entities you may have to ask your host to assign those privileges
to your database user.

MySQL Compat- his option controls the MySQL version compatibility when creating the database SQL dump file.
ibility In fact, it forces Akeeba Backup to request the appropriate CREATE TABLE commands from
your database server. It is useful when migrating your site to another host with a different MySQL
version. The available options are:

• Default. This is the recommended option. The full feature set of your database server will be
used when generating the CREATE command. Your target database server must run MySQL
of a matching major version, i.e. MySQL 5 if the host you're backing up runs on MySQL 5.

• MySQL 4.1. Akeeba Backup will request from your database server to provide definitions
(CREATE commands) in a MySQL 4.1 friendly format.

28


Important
This option will take effect in MySQL 4.1 or greater database hosts. If you use it on
older MySQL version the backup might fail!

Warning
Do not use this option if your site is already running on MySQL 4.x or if both your
site and the target host run on MySQL 5.x. Otherwise, crucial information about the
database's encoding might be lost in the process, causing broken text on sites using
non-ASCII character sets.

Generate extend- When this is not checked, Akeeba Backup will create one INSERT statement for each data row
ed INSERTs of each table. When you have lots of rows with insignificant amount of data, such as banner and
click tracking logs, the overhead of the INSERT statement is much higher than the actual data,
causing a massively bloated database dump file. When this option is enabled, the dump engine will
create a single INSERT statement for multiple rows of data, reducing the overhead and resulting
into significantly smaller backup archives. Moreover, this will lead to much less SQL commands
being run during restoration, which is of paramount importance on many restrictive shared hosting
environments. It is suggested to turn this setting on, unless you are going to restore to a MySQL
4.1 host.

Max packet size If the previous setting is enabled, this setting defines the maximum length of a single INSERT
for extended IN- statement. Most MySQL servers have a configured limit of maximum stement length and will not
SERTs accept an INSERT statement over 1Mb. It is suggested to leave the default conservative setting
(128Kb) unless you know what you're doing. If you get restoration failures indicating that you
exceeded the maximum query length, please lower this setting.

Dump PRO- By default, Akeeba Backup will only back up database tables and VIEWs. If your host supports
CEDUREs, this, you can also back up and restore advanced aspects of your MySQL database: stored proce-
FUNCTIONs and dures, stored functions and triggers. If your site makes use of any of those features you will have
TRIGGERs to tick the box. If the backup operation crashes or you the database tables filter page is blank you
must turn this option off for Akeeba Backup to work properly.

Warning
Using this feature requires that your host allows you to execute privileged SQL com-
mands against the MySQL database:

• SHOW PROCEDURE STATUS

• SHOW FUNCTION STATUS

• SHOW TRIGGERS

Most shared hosting providers do not allow you to execute these commands. Trying to
do so will usually cause the script execution to abruptly halt, most often without indicat-
ing the source of error. If you are in doubt, disable this option and retry backup. This
shouldn't be an issue with dedicated hosting, as long as you grant the SUPER privilege
to the database user you use to connect to your site's database.

Size for split Akeeba Backup is able to split your MySQL database dump to smaller files. This allows for an
SQL dump files improved compression ratio and also helps avoid several problems with certain cheap hosts which
put a restriction on the maximum size a file generated by PHP code can have.

29


Ideally, you should specify a setting which is about half as much as your Big file threshold setting
in the archiver engine's configuration options pane. The reason to do that is that the archiver
engines will not compress files with sizes over the value this threshold. Since it's impossible to
have absolute control of the size of the database dump, using half the value of this setting allows
for the expected size fluctuation.

If you want to disable this feature and create a single big SQL dump file instead, just set this
option to 0 Mb.

Important
This setting has no effect on "Main site database only" backup profiles. This is because
the nature of this backup type does not allow splitting the database archive dump. If
you want something equivalent, please use the "All configured databases" backup type
instead, as it creates an archive file which contains your (split) database dump and takes
up MUCH less space on your web server.

Number of rows Dumping table data happens in "batches", i.e. a few rows at a time. This parameter defines how
per batch many rows will be fetched from the table at any given time. If you are backing up tables with large
chunks of binary data (e.g. files stored in BLOB fields) or if you have very large chunks of text
stored in the database, the default value - 1000 rows - may cause a PHP memory or MySQL buffer
exhaustion. If you get memory outage errors during the table backup, it is advisable to lower this
setting. This is especially true if your MySQL and PHP combination does not allow a cursor to
be effectively created and all data has to be transferred in PHP's memory. A value of 20 is a very
safe value, at the expense of making your backup process slower and run more queries against
your database server. Most servers work fine with the default value of 1000 rows per batch.

No dependency When this option is enabled, Akeeba Backup's database dump engine will no longer try to figure
tracking out table and VIEW dependencies. This will speed up the database dump initialization step. This is
recommended if and only if you have too many tables (over 200) in your database, you get time-
out errors during the database dump initialization step and you do not use foreign keys, VIEWs,
FUNCTIONs, PROCEDUREs, TRIGGERs or any tables using the MERGE database engine. If
you do use any of those MySQL features in your tables there is a high probability that your SQL
dump will be unable to be restored.

2.3.3. File and directories scanner engines
2.3.3.1. Smart scanner
This engine is the culmination of three years of research in optimizing file system scanning for PHP scripts. The Smart
Scanner will browse your file system tree for directories and files to include in the backup set, automatically breaking
the step upon detecting a very large directory which could lead to timeout errors.

Large directory This option tells Akeeba Backup which directories to consider "large" so that it can break the
threshold backup step. When it is encountered with a directory having at least this number of files and
subdirectories, it will break the step. The default value is quite conservative and suitable for most
sites. If you have a very fast server, e.g. a dedicated server, VPS or MVS, you may increase this
value. If you get timeout errors, try decreasing this setting.

Directory listing Akeeba Backup can use two different methods for asking your server to list the contents of a
method directory. The Regular method is very fast and works on the vast majority of servers. However,

30


some servers refuse to list files with permissions lower than 0755 (it's absurd, I know!) and require
the slightly slower, Alternate method. If your backup archive is missing files and you do not get
"Unreadable file" or "Unreadable directory" warnings during backup, please switch this option to
Alternate (failsafe) and retry backing up.

2.3.4. Archiver engines
2.3.4.1. ZIP format
The ZIP format is the most well known archive format and is integrated in many operating systems and desktop
environments, including Windows™, Mac OS X™, KDE and GNOME.

Warning
The ZIP format requires the calculation of CRC32 checksums for each file added in the archive. This is a
resource intensive operation which will slow down your backup and may lead to timeouts when archiving
big files on slow hosts. If this happens, your only choice is not to use the ZIP format; use JPA instead.
Unfortunately, we can't do anything about it: it is a combined limitation of the ZIP specification, how PHP
works and how your server is set up.

Dereference sym- This setting is only valid on Linux and compatible *NIX hosts. Normally, when Akeeba Back-
links up encounters symbolic links ("symlinks"), it follows them and treats them as regular files and
directories, backing up their contents. Some site configurations may have symbolic links set up
in such a way as to create an infinite loop, causing the backup to fail. When this option is set to
No, Akeeba Backup will not follow symbolic links, but store their name and their target in the
archive. Of course, if your symbolic links use absolute paths, restoring to a different server than
the one you backed up from will result in broken symlinks.

Note
Even though Windows 7 supports symbolic links, it does so in a way that it's not possible
for PHP to make use of this feature. As a result, this setting will only work on Linux,
FreeBSD, Solaris and other compatible *NIX hosts.

Part size for split Akeeba Backup supports the creation of Split Archives. In a nutshell, your backup archive is
archives spanned among one or several files, so that each of these files ("part") is not bigger than the value
you specify here. This is a useful feature for hosts which impose a maximum file size quota. If
you use a value of 0Mb, no archive splitting will take place and Akeeba Backup will produce a
single backup archive (default).

Warning
If you want to post-process your archive files it is suggested that you use small, non-
zero values here. The time it takes the post-processing engine to transfer an archive from
your server to the remote server equals part size divided by available bandwidth. Since
the available execution time is finite and the available bandwidth is constant, the only
way to avoid a timeout is creating small parts.

31


Important
Split ZIP archives can not be opened with 7-zip, Linux unzip and other GUI clients.
Only WinZIP and PKZIP understand them. If you want to extract them, you must use
WinZIP, PKZIP, Akeeba Kickstart or Akeeba eXtract Wizard. This is not an Akeeba
Backup "bug", it's a problem with most free archiver extraction tools.

Chunk size for Each file is read in small increments, we call chunks, while being copied in the archive. Larger
large files pro- chunks will result in faster backup, at the price of taking longer to process each one of them
cessing and risking a timeout. Smaller chunks lead to slower but safer backups. On very slow hosts, this
parameter should be set to a low value, for example 256Kb, or even lower - especially true if you
constantly get timeout errors when backing up large files. On fast hosts you may want to increase
this value in order to speed up your backup operation.

Big file threshold Files over this size will be stored in the archive file uncompressed. Do note that in order for a file
to be compressed, Akeeba Backup has to load it in its entirety to memory, compress it and then
write it to disk. As a rule of thumb, you need to have free memory equal to 1.8 times the size of the
file to compress, e.g. 18Mb for a 10Mb file. Joomla! with a lot of plug-ins might consume as much
as 16Mb and Akeeba Backup's engine might consume another 5Mb, so plan this value carefully,
or you will run into memory exhaustion errors. Compression is also resource intensive and will
increase the time to produce a backup. If this value is too high, you might run into timeout errors.

Chunk size for At the end of the ZIP archive creation we have to attach a lookup table containing the names of
Central Directory all included files to the end of the archive file. This table is called the Central Directory. We have
processing to do this in small chunks so as to avoid timeout or memory exhaustion errors. It is recommended
that you leave the default value (1Mb) unless you know what you're doing.

2.3.4.2. JPA format
The JPA format was conceived as an alternative to ZIP, designed to be extremely suitable for PHP scripts. The trick
is that the JPA format doesn't store a checksum for each file - therefore it reduces the processing overhead during
archiving - and it doesn't use a "lookup table" (central directory) as ZIP does. Both of these design decisions lead to
extremely fast, low resource usage archiving processes.

Tip
It is recommended that you use the JPA format for all of your backups. You can extract JPA files either on
your server using Kickstart, or on your desktop using Akeeba eXtract Wizard.

The settings for this engine are identical to those used in the ZIP engine.

2.3.4.3. Encrypted Archives (JPS format)

Note
This feature is only available in the Akeeba Backup Professional release.

The JPS is a further evolution of the JPA format, designed with the major goals of improving compression rations and
enhancing the security of your data by encrypting the entire archive's contents with the industry standard AES-128

32


encryption format. The latter goal ensures that even in the unlikely event of your backup files ending up in the hands of
hacker or another untrusted party, they would be useless. As per the strictest security standards, all information in the
archive (including file names and file data) are encrypted. Without the password nobody can deduct any information
about your site by examining a JPS archive. The contents of all files in the archive are compressed and encrypted in
64Kb blocks, allowing for better compression ratios over the JPA format.

Important
In order for JPS to work it requires that both the zlib and mcrypt PHP extensions are installed and activated
on your server. Moreover, the mcrypt library installed on the server must support AES-128 in CBC mode. If
any of these conditions is not met, the backup process will halt with an error mentioning that encryption is
not enabled on your server. In this case, please contact your host with the information in this paragraph so
that they can perform the necessary server-side changes.

Important
JPS archives can only be extracted on hosts fulfilling the same per-requisites (zlib and mcrypt extensions
installed and activated). They can also be extracted only by Kickstart 3.1.2 and Akeeba eXtract Wizard 3.0.4
or later. Earlier version can't read the JPS archives at all.

The settings for this engine are:

Encryption key This is the password to be used for encrypting the archive. For the sake of security, you are en-
couraged to enter a long passphrase which is hard to guess.

Warning
The key is case sensitive. This means that Abc, ABC and abc are three completely dif-
ferent keys!

Dereference sym- This setting is only valid on Linux and compatible *NIX hosts. Normally, when Akeeba Back-
links up encounters symbolic links ("symlinks"), it follows them and treats them as regular files and
directories, backing up their contents. Some site configurations may have symbolic links set up
in such a way as to create an infinite loop, causing the backup to fail. When this option is set to
No, Akeeba Backup will not follow symbolic links, but store their name and their target in the
archive. Of course, if your symbolic links use absolute paths, restoring to a different server than
the one you backed up from will result in broken symlinks.

Note
Even though Windows 7 supports symbolic links, it does so in a way that it's not possible
for PHP to make use of this feature. As a result, this setting will only work on Linux,
FreeBSD, Solaris and other compatible *NIX hosts.

Part size for split Akeeba Backup supports the creation of Split Archives. In a nutshell, your backup archive is
archives spanned among one or several files, so that each of these files ("part") is not bigger than the value
you specify here. This is a useful feature for hosts which impose a maximum file size quota. If
you use a value of 0Mb, no archive splitting will take place and Akeeba Backup will produce a
single backup archive (default).

33


Warning
If you want to post-process your archive files it is suggested that you use small, non-
zero values here. The time it takes the post-processing engine to transfer an archive from
your server to the remote server equals part size divided by available bandwidth. Since
the available execution time is finite and the available bandwidth is constant, the only
way to avoid a timeout is creating small parts.

2.3.4.4. DirectFTP

Important
This feature is not meant for everyday users. It is designed for web professionals. If you don't understand
the rest of this section, please do not use it. Akeeba Backup is equally useful as a site migration tool without
using DirectFTP.

The DirectFTP engine allows power users to directly export a website from one server to another, without the need to
download the backup file to their PC, upload it and extract it on the other server. In order to do so, instead of backing
up to an archive, it directly writes the backed up files to the remote server using FTP, hence the name.

Do note that when using the DirectFTP engine, the post-processing engine will not run, as there is no archive produced.

In a nutshell, when this option is activated, Akeeba Backup operates as usual, backing up your database and files.
Instead of putting the site files, installer files and database dump inside a backup archive, it transfers them to a remote
server using FTP. You can then visit the installation URL on the remote server to complete the site transfer progress.

Warning
This is considered an advanced feature. Since there are many things which might go wrong in the process and
due to the fact that the success of the operation depends on the server configuration of both the originating
and target servers, you are advised not to use it unless you know what you're doing.

Moreover, bear in mind that the target server must not contain any files! If it does, it may not be possible to
overwrite them, leading to an incomplete site transfer.

Your originating server must support PHP's FTP extensions and not have its FTP functions blocked. Your originating
server must not block FTP communication to the remote (target) server. Some hosts apply a firewall policy which
requires you to specify to which hosts your server can connect. In such a case you might need to allow communication
to your remote host.

Normally, remote FTP connections consume a lot of time, therefore DirectFTP is very prone to time-outs. Theoret-
ically, Akeeba Backup can automatically estimate the time required for transferring each file and avoid timing out.
However, this is not always technically possible. In such a case you might want to lower the maximum execution time
allowance and bias in the Configuration. Do note that large files have to be transferred in a single step, as most PHP
and FTP configuration combinations disallow resuming uploads (chunked uploads). This means that a very large file,
or a very large database dump may cause the process to fail with a timeout error.

34


The available configuration options are:

• Host name. The hostname of your remote (target) server, e.g. ftp.example.com.

• Port. The TCP/IP port of your remote host's FTP server. It's usually 21.

• User name. The username you have to use to connect to the remote FTP server.

• Password. The password you have to use to connect to the remote FTP server.

• Initial directory. The absolute FTP directory to your remote site's location where your site will be cloned to. This is
provided by your hosting company. Do not ask us to tell you what you should put in here because we can't possibly
know. There is an easy way to find it, though. Connect to your target FTP server with FileZilla. Navigate to the web
server's root (usually it's a subdirectory named httpdocs, htdocs, public_html, http_docs or www). Above the right-
hand folder pane you will see a text box with a path. Copy this path and paste it to Akeeba Backup's setting.

• Use FTP over SSL. If your remote server supports secure FTP connections over SSL (they have to be implicit SSL;
explicit SSL - a.k.a. FTPES - is not supported), you can enable this feature. In such a case you will most probably
have to change the port. Please ask your hosting company to provide you with more information on whether they
support this feature and what port you should use. You must note that this feature must also be supported by your
originating server as well.

• Use passive mode. Normally you should enable it, as it is the most common and firewall-safe transfer mode sup-
ported by FTP servers. Sometimes, you remote server might require active FTP transfers. In such a case please
disable this, but bear in mind that your originating server might not support active FTP transfers, which usually
requires tweaking the firewall!

2.3.4.5. DirectSFTP

Important
This feature is only available in the Akeeba Backup Professional edition.

Important
This feature is not meant for everyday users. It is designed for web professionals. If you don't understand
the rest of this section, please do not use it. Akeeba Backup is equally useful as a site migration tool without
using DirectSFTP.

The DirectSFTP engine allows power users to directly export a website from one server to another, without the need to
download the backup file to their PC, upload it and extract it on the other server. In order to do so, instead of backing
up to an archive, it directly writes the backed up files to the remote server using SFTP (Secure File Transfer Protocol
over SSH), hence the name.

Do note that when using the DirectSFTP engine, the post-processing engine will not run, as there is no archive pro-
duced.

In a nutshell, when this option is activated, Akeeba Backup operates as usual, backing up your database and files.
Instead of putting the site files, installer files and database dump inside a backup archive, it transfers them to a remote
server using SFTP. You can then visit the installation URL on the remote server to complete the site transfer progress.

Warning
This is considered an advanced feature. Since there are many things which might go wrong in the process and
due to the fact that the success of the operation depends on the server configuration of both the originating
and target servers, you are advised not to use it unless you know what you're doing.

35


Moreover, bear in mind that the target server must not contain any files! If it does, it may not be possible to
overwrite them, leading to an incomplete site transfer.

Your originating server (where you are backing up from) must a. support PHP's SSH2 extensions, b. allow outbound
TCP/IP connections to your target host's SSH port and c. not have the SFTP functions of the SSH2 extension blocked.
Please note that some hosts apply a firewall policy which requires you to specify to which hosts your server can connect.
In such a case you might need to allow communication to your remote host. Moreover, your target host must support
SFTP connections using a username and password for authentication. If your remote server only allows authentication
using certificate files it won't work with Akeeba Backup's DirectSFTP feature.

Normally, remote SFTP connections consume a lot of time, therefore DirectSFTP is very prone to time-outs. Theoret-
ically, Akeeba Backup can automatically estimate the time required for transferring each file and avoid timing out.
However, this is not always technically possible. In such a case you might want to lower the maximum execution time
allowance and bias in the Configuration. Do note that large files have to be transferred in a single step, as most PHP
and SFTP configuration combinations disallow resuming uploads (chunked uploads). This means that a very large file,
or a very large database dump may cause the process to fail with a timeout error.


• Host name. The hostname of your remote (target) server, e.g. sftp.example.com.

• Port. The TCP/IP port of your remote host's FTP server. It's usually 22.

• User name. The username you have to use to connect to the remote SFTP server.

• Password. The password you have to use to connect to the remote SFTP server.

• Initial directory. The absolute FTP directory to your remote site's location where your site will be cloned to. This is
provided by your hosting company. Do not ask us to tell you what you should put in here because we can't possibly
know. There is an easy way to find it, though. Connect to your target FTP server with FileZilla. Navigate to the web
server's root (usually it's a subdirectory named httpdocs, htdocs, public_html, http_docs or www). Above the right-
hand folder pane you will see a text box with a path. Copy this path and paste it to Akeeba Backup's setting.

2.3.4.6. ZIP using ZIPArchive class
This engine produces ZIP archive using PHP's built-in ZIP archive class. It is only recommended for extremely small
sites hosted on very slow hosts. If you have a larger site or quite big files you can expect that this engine will time out,
crash the backup or throw a memory outage error. Also note that this engine has absolutely no options and is bound
to fail on hosts which impose limitations on the maximum size per file.

Frankly, this is the worst archiver engine. It was added because some users argued that it is faster (it is not) and this
is why it is being used by competitive products. Well, try it out if you want. As soon as it causes backup errors do not
ask for support, just switch to the classic ZIP engine or, even better, the JPA engine.

2.3.5. Data processing engines
2.3.5.1. No post-processing
This is the default setting and one of the two available to Akeeba Backup Core. It does no post-processing. It simply
leaves the backup archives on your server.

36


2.3.5.2. Send by email

This handy feature is available both in Akeeba Backup Core and Akeeba Backup Professional. It will send you the
backup archive parts as file attachments to your email address. That's right! No need to worry about downloading your
backup archives, they will be emailed to you. That said, beware of the restrictions:

Warning
You MUST set the Part size for split archives setting of the Archiver engine to a value between 1-10
Megabytes. If you choose a big value (or leave the default value of 0, which means that no split archives will
be generated) you run the risks of the process timing out, a memory outage error to occur or, finally, your
email servers not being able to cope with the attachment size, dropping the email.

The available configuration settings for this engine, accessed by pressing the Configure... button next to it, are:

Process each part If you enable this, each backup part will be emailed to you as soon as it's ready. This is useful
immediately if you are low on disk space (disk quota) when used in conjunction with Delete archive after
processing. When using this feature we suggest having 10Mb plus the size of your part for split
archives free in your account. The drawback with enabling this option is that if the email fails,
the backup fails. If you don't enable this option, the email process will take place after the backup
is complete and finalized. This ensures that if the email process fails a valid backup will still be
stored on your server. The drawback is that it requires more available disk space.

Delete archive af- If enabled, the archive files will be removed from your server after they are emailed to you. Very
ter processing useful to conserve disk space and practice the good security measure of not leaving your backups
on your server.

Email address The email address where you want your backups sent to. When used with GMail or other webmail
services it can provide a cheap alternative to proper cloud storage.

Email subject A subject for the email you'll receive. You can leave it blank if you want to use the default.
However, we suggest using something descriptive, i.e. your site's name and the description of the
backup profile.

2.3.5.3. Upload to Amazon S3

Using this engine, you can upload your backup archives to the Amazon S3 cloud storage service. With dirt cheap
prices per Gigabyte, it is an ideal option for securing your backups. Even if your host's data center is annihilated by
a natural disaster and your local PC and storage media are wiped out by an unlikely event, you will still have a copy
of your site readily accessible and easy to restore.

Since Akeeba Backup 3.2 we support multi-part uploads to Amazon S3. This means that, unlike the other post-process-
ing engines, even if you do not use split archives, Akeeba Backup will still be able to upload your files to Amazon S3!
This new feature allows Akeeba Backup to upload your backup archive in 5Mb chunks so that it doesn't time out when
uploading a very big archive file. That said, we STRONGLY suggest using a part size for archive splitting of 2000Mb.
This is required to work around a PHP limitation which causes extraction to fail if the file size is over roughly 2Gb.

37


The required settings for this engine are:

Process each part If you enable this, each backup part will be uploaded as soon as it's ready. This is useful if you
immediately are low on disk space (disk quota) when used in conjunction with Delete archive after processing.
When using this feature we suggest having 10Mb plus the size of your part for split archives free
in your account. The drawback with enabling this option is that if the upload fails, the backup fails.
If you don't enable this option, the upload process will take place after the backup is complete and
finalized. This ensures that if the upload process fails a valid backup will still be stored on your
server. The drawback is that it requires more available disk space.

Delete archive af- If enabled, the archive files will be removed from your server after they are uploaded to Amazon
ter processing S3.

Access Key Your Amazon S3 Access Key

Secret Key Your Amazon S3 Secret Key

Use SSL If enabled, an encrypted connection will be used to upload your archives to Amazon S3. In this
case the upload will take longer, as encryption - what SSL does - is a resource intensive operation.
You may have to lower your part size.

Bucket The name of your Amazon S3 bucket where your files will be stored in. The bucket must be
already created; Akeeba Backup can not create buckets.

Directory The directory inside your Amazon S3 bucket where your files will be stored in. If you want to
use subdirectories, you have to use a forward slash, e.g. directory/subdirectory/sub-
subdirectory.

Disable multipart Since Akeeba Backup 3.2, uploads to Amazon S3 of parts over 5Mb use Amazon's new multi-part
uploads upload feature. This allows Akeeba Backup to upload the backup archive in 5Mb chunks and
then ask Amazon S3 to glue them together in one big file. However, some hosts time out while
uploading archives using this method. In that case it's preferable to use a relatively small Part
Size for Split Archive setting (around 10-20Mb, your mileage may vary) and upload the entire
archive part in one go. Enabling this option ensures that, no matter how big or small your Part
Size for Split Archives setting is, the upload of the backup archive happens in one go. You MUST
use it if you get RequestTimeout warnings while Akeeba Backup is trying to upload the backup
archives to Amazon S3.

Regarding the naming of buckets and directories, you have to be aware of the Amazon S3 rules (these rules are a
simplified form of the list S3Fox presents you with when you try to create a new bucket):

• Folder names can not contain backward slashes (). They are invalid characters.

• Bucket names can only contain lowercase letters, numbers, periods (.) and dashes (-). Accented characters, interna-
tional characters, underscores and other punctuation marks are illegal characters.

38


Important
Even if you created a bucket using uppercase letters, you must type its name with lowercase letters.
Amazon S3 automatically converts the bucket name to all-lowercase.

• Bucket names must start with a number or a letter.

• Bucket names must be 3 to 63 characters long.

• Bucket names can't be in an IP format, e.g. 192.168.1.2

• Bucket names can't end with a dash.

• Bucket names can't have an adjacent dot and dash. For example, both my.-bucket and my-.bucket are invalid.

If any - or all - of those rules are broken, you'll end up with error messages that Akeeba Backup couldn't connect to
S3. This is normal and expected behaviour, as Amazon S3 drops the connection when it encounters invalid bucket
or directory names.

2.3.5.4. Upload to DropBox
Using this engine, you can upload your backup archives to the low-cost DropBox cloud storage service (http://
www.dropbox.com). This is an ideal option for small websites with a low budget, as this service offers 2Gb of storage
space for free, all the while retaining all the pros of storing your files on the cloud. Even if your host's data center is
annihilated by a natural disaster and your local PC and storage media are wiped out by an unlikely event, you will still
have a copy of your site readily accessible and easy to restore.

Before you begin, you should know the limitations. DropBox does not allow appending to files, so the archive has to
be transferred in a single step. PHP has a time limit restriction we can't overlook. The time required to upload a file
to DropBox equals the size of the file divided by the available bandwidth. We want to time to upload a file to be less
than PHP's time limit restriction so as to avoid timing out. Since the available bandwidth is finite and constant, the
only thing we can reduce in order to avoid timeouts is the file size. To this end, you have to produce split archives, by
setting the part size for archive splitting in ZIP's or JPA's engine configuration pane. The suggested values are between
10Mb and 20Mb. Most servers have a bandwidth cap of 20Mbits, which equals to roughly 2Mb/sec (1 byte is 8 bits,
plus there's some traffic overhead, lost packets, etc). With a time limit of 10 seconds, we can upload at most 2 Mb/sec
* 10 sec = 20Mb without timing out. If you get timeouts during post-processing lower the part size.

Tip
If you use the native CRON mode (backup.php), there is usually no time limit - or there is a very high time
limit in the area of 3 minutes or so. Ask your host about it. Setting up a profile for use only with the native
CRON mode allows you to increase the part size and reduce the number of parts a complete backup consists of.

Warning
You can not upload files over 50Mb to DropBox using Akeeba Backup's post-processing engine. This is a
limitation of the engine. We regret to inform you that there is no workaround to this.

You should also note that we do not use DropBox's official API, because the way it works would mean that Akeeba
Backup would instantly time out or throw a memory outage error when trying to upload files from the majority of
shared hosting plans. The solution used in Akeeba Backup is a "workaround"; it logs you in DropBox's web file
management interface and tries to use the web upload form for storing your files. This has two major consequences.
First, the login procedure takes a substantial amount of time (1-3 seconds, depending on your connection speed), which

39


limits the maximum file size you may use. Second, if DropBox.com decides to change something in the way their site
works, this feature will probably stop working. As a result, until the official DropBox API is modified for taking into
account large file uploads from restrictive PHP environments, this storage option should only be used when you are
very low on budget and accept the risk of it suddenly stopping working.



Delete archive af- If enabled, the archive files will be removed from your server after they are uploaded to DropBox.
ter processing

Email The email associated with your DropBox.com login

Password Your DropBox.com password

Directory The directory inside your DropBox account where your files will be stored in. If you want to use
subdirectories, you have to use a forward slash, e.g. /directory/subdirectory/sub-
subdirectory.

2.3.5.5. Upload to RackSpace CloudFiles
Using this engine, you can upload your backup archives to the RackSpace CloudFiles [www.rackspacecloud.com/
cloud_hosting_products/files] cloud storage service. This service has been around for a long time, under the Mosso
brand, and is considered one of the most dependable ones. Its cheap prices make it ideal for applications where storing
large quantities of backup archives is more likely than downloading them.

Before you begin, you should know the limitations. As most cloud storage providers, CloudFiles does not allow ap-
pending to files, so the archive has to be transferred in a single step. PHP has a time limit restriction we can't overlook.
The time required to upload a file to CloudFiles equals the size of the file divided by the available bandwidth. We
want to time to upload a file to be less than PHP's time limit restriction so as to avoid timing out. Since the available
bandwidth is finite and constant, the only thing we can reduce in order to avoid timeouts is the file size. To this end,
you have to produce split archives, by setting the part size for archive splitting in ZIP's or JPA's engine configuration
pane. The suggested values are between 10Mb and 20Mb. Most servers have a bandwidth cap of 20Mbits, which
equals to roughly 2Mb/sec (1 byte is 8 bits, plus there's some traffic overhead, lost packets, etc). With a time limit of
10 seconds, we can upload at most 2 Mb/sec * 10 sec = 20Mb without timing out. If you get timeouts during post-
processing lower the part size.

Tip

40


Akeeba Backup is using the very stable official PHP bindings for CloudFiles access, which is unlikely to stop working
for the foreseeable future. As a result, we consider it a good candidate for backup archives storage.



Delete archive af- If enabled, the archive files will be removed from your server after they are uploaded to Cloud-
ter processing Files.

Username The username assigned to you by the RackSpace CloudFiles service

API Key The API Key found in your CloudFiles account

Container The name of the CloudFiles container where you want to store your archives in.

Directory The directory inside your CloudFiles container where your files will be stored in. If you want to
use subdirectories, you have to use a forward slash, e.g. /directory/subdirectory/sub-
subdirectory. Leave blank to store the files on the container's root.

2.3.5.6. Upload to Microsoft Windows Azure BLOB Storage service
Using this engine, you can upload your backup archives to the Microsoft Windows Azure BLOB Storage [http://
www.microsoft.com/windowsazure/windowsazure/] cloud storage service. This new cloud storage service from Mi-
crosoft is reasonably priced (the cost is very close to CloudFiles) and quite fast, with lots of local endpoints around
the globe.

Warning
Azure, unlike other cloud storage providers, doesn't support storing files over 64Mb without resorting to
proprietary hacks. As a result you MUST use a part size for archive splitting lower than 64Mb at all times.
Failure to do so might cause your backup uploads to fail.

Before you begin, you should know the limitations. As most cloud storage providers, Azure does not allow appending
to files, so the archive has to be transferred in a single step. PHP has a time limit restriction we can't overlook. The time
required to upload a file to CloudFiles equals the size of the file divided by the available bandwidth. We want to time to
upload a file to be less than PHP's time limit restriction so as to avoid timing out. Since the available bandwidth is finite
and constant, the only thing we can reduce in order to avoid timeouts is the file size. To this end, you have to produce
split archives, by setting the part size for archive splitting in ZIP's or JPA's engine configuration pane. The suggested
values are between 10Mb and 20Mb. Most servers have a bandwidth cap of 20Mbits, which equals to roughly 2Mb/sec
(1 byte is 8 bits, plus there's some traffic overhead, lost packets, etc). With a time limit of 10 seconds, we can upload
at most 2 Mb/sec * 10 sec = 20Mb without timing out. If you get timeouts during post-processing lower the part size.

41


Tip

Akeeba Backup is using the very stable official PHP bindings for Microsoft Windows Azure access, which is unlikely
to stop working for the foreseeable future. As a result, we consider it a good candidate for backup archives storage.



Delete archive af- If enabled, the archive files will be removed from your server after they are uploaded to Cloud-
ter processing Files.

Account name The account name for your Microsoft Azure subscription. If your endpoint looks like
foobar.blobl.core.windows.net then your account name is foobar.

Primary Access You can find this Key in account page. It is lengthy and always ends in double equals marks.
Key

Container The name of the Azure container where you want to store your archives in.

Directory The directory inside your Azure container where your files will be stored in. If you want to use
subdirectories, you have to use a forward slash, e.g. /directory/subdirectory/sub-
subdirectory. Leave blank to store the files on the container's root.

2.3.5.7. Upload to Remote FTP server
Using this engine, you can upload your backup archives to any FTP or FTPS (FTP over implicit SSL) server. There are
some "FTP" protocols and other file storage protocols which are not supported, such as SFTP, SCP, Secure FTP, FTP
over explicit SSL and SSH variants. The difference of this engine to the DirectFTP archiver engine is that this engine
uploads backup archives to the server, whereas DirectFTP uploads the uncompressed files of your site. DirectFTP is
designed for rapid migration, this engine is designed for easy moving of your backup archives to an off-server location.

Your originating server must support PHP's FTP extensions and not have its FTP functions blocked. Your originating
server must not block FTP communication to the remote (target) server. Some hosts apply a firewall policy which
requires you to specify to which hosts your server can connect. In such a case you might need to allow communication
to your remote host.

Before you begin, you should know the limitations. Most servers do not allow resuming of uploads (or even if they
do, PHP doesn't quite support this feature), so the archive has to be transferred in a single step. PHP has a time limit
restriction we can't overlook. The time required to upload a file to FTP equals the size of the file divided by the

42


available bandwidth. We want to time to upload a file to be less than PHP's time limit restriction so as to avoid timing
out. Since the available bandwidth is finite and constant, the only thing we can reduce in order to avoid timeouts is
the file size. To this end, you have to produce split archives, by setting the part size for archive splitting in ZIP's or
JPA's engine configuration pane. The suggested values are between 10Mb and 20Mb. Most servers have a bandwidth
cap of 20Mbits, which equals to roughly 2Mb/sec (1 byte is 8 bits, plus there's some traffic overhead, lost packets,
etc). With a time limit of 10 seconds, we can upload at most 2 Mb/sec * 10 sec = 20Mb without timing out. If you
get timeouts during post-processing lower the part size.



Delete archive af- If enabled, the archive files will be removed from your server after they are uploaded to the FTP
ter processing server.

Host name The hostname of your remote (target) server, e.g. ftp.example.com.

Port The TCP/IP port of your remote host's FTP server. It's usually 21.

User name The username you have to use to connect to the remote FTP server.

Password The password you have to use to connect to the remote FTP server.

Initial directory The absolute FTP directory to your remote site's location where your archives will be stored.
This is provided by your hosting company. Do not ask us to tell you what you should put in here
because we can't possibly know. There is an easy way to find it, though. Connect to your target
FTP server with FileZilla. Navigate to the intended directory. Above the right-hand folder pane
you will see a text box with a path. Copy this path and paste it to Akeeba Backup's setting.

Alternatively, use the button next to the edit box to launch an interactive FTP folder browser
which allows you to select the directory visually.

Use FTP over If your remote server supports secure FTP connections over SSL (they have to be implicit SSL;
SSL explicit SSL - a.k.a. FTPES - is not supported), you can enable this feature. In such a case you
will most probably have to change the port. Please ask your hosting company to provide you with
more information on whether they support this feature and what port you should use. You must
note that this feature must also be supported by your originating server as well.

Use passive Normally you should enable it, as it is the most common and firewall-safe transfer mode supported
mode by FTP servers. Sometimes, you remote server might require active FTP transfers. In such a case

43


please disable this, but bear in mind that your originating server might not support active FTP
transfers, which usually requires tweaking the firewall!

2.4. Backup now
Before we go on describing the Backup Now page, we have to discuss something important pertaining to the overall
backup and restoration process. In order for the restoration to work properly, the original site must have a readable and
valid configuration.php on its root. This means that a 'trick' many webmasters use, that is providing a configuration.php
which includes an off-server-root PHP file, is incompatible with the restoration procedure. If the 'trick' has been ef-
fective on the original site, the installer will have blanks in its options and if the user proceeds with the restoration/in-
stallation procedure the site will not work as expected, as crucial options will have the default or no value at all!

That being said, the initial backup page lets you define a short description (required) and an optional lengthy comment
for this backup attempt. This information will be presented to you in the backup administration page to help you
identify different backups. The default description contains the date and time of backup. Both the description and
comment will be stored in a file named README.html inside your archive's installation directory, but only
if the backup mode is full backup.

Since Akeeba Backup 3.1.b1 both the description and the comment support Akeeba Backup's file naming "variables",
e.g. [SITE], [DATE] and [TIME]. These variables are documented in the Output Directory configuration option's
description. It goes without saying, but these variables can also be used in the case of automated backups, e.g. CRON-
mode backups.

Whenever you are ready to start the backup, just click the Backup Now button. Do note that above the description
field, there might be one or more warnings. These are the same warnings appearing in the Control Panel's right-hand
pane and act as a reminder.

Important
Default output directory is in use is not an error message! It's just a reminder that the default output directory
is a well known location on your site. In theory, a malicious user could figure out the name of the backup
archive and download it directly over the web. In order to deter that, Akeeba Backup places a .htaccess file
(compatible with virtually all Apache installations) and a web.config file (compatible only with IIS 7) to
deter that. If you are using a host which doesn't support the directives of those two files, the contents of that
directory may be inadvertently available over the web to malicious users. If in doubt, ask your host. Do not
ask us. We can't know this information; we haven't set up your host's server.

Our recommendation: consult your host about the proper way to create a backup output directory above your
site's root and make it writable by PHP. Then, use that directory as the Output Directory and Temporary
Directory in all of your backup profiles. This method offers the greatest degree of protection.

44


Once you click on the Backup Now button, the backup progress page appears. You must not navigate away from this
page or close your browser window until the backup is complete. Otherwise, the backup process will be interrupted and
no backup file will be created (or you'll end up with an incomplete backup file). Akeeba Backup disables the Joomla!
menu during backup to prevent accidentally switching to a different page. If, however, the timeout bar (the second
one which looks as a progress bar and changes its color from green to yellow to red) fills up, you can safely assume
that your backup has crashed. Only in this case you should navigate away from the backup page and take a look at
the log file for any error messages. Always try different configuration options - especially toying with the minimum
execution time - before submitting a bug report on our support forum.

The backup progress page consists of a large pane. The top section of the pane lists the steps Akeeba Backup has to take
in order to complete your backup. Steps in gray background have not been dealt with yet. Steps in green background,
featuring a green check mark on the left-hand side, have been successfully completed. The step in yellow background,
featuring a blue arrow on the left-hand side, is the one being currently processed.

Below that, you will find two lines, called Step/Substep in Akeeba Backup jargon. The first line will show you which
table or directory has been backed up until now. This is very important. When the backup crashes, it hasn't crashed
on the table or directory you see on the screen! In fact, you can be sure that this table/directory has been successfully
backed up. The real problem appears in the log file and this is why we are adamant in asking for a backup log to be
posted with your support request. The Substep line below is normally used for messages of lesser importance, such as
noting the percentage of a table already completed (especially useful when backing up huge tables) and the name of
the archive part which was processed by a data processing engine.

The big bar is the overall progress bar and displays an approximation of the backup progress. Do note that during file
backup you may see this bar jump back and forth. This is normal and, please, do not report it as a bug. It is exactly
how it is supposed to behave. The reason is rather simple. Before your site is backed up, Akeeba Backup doesn't know
how many files and directories it contains. As a result, it tries to do an educated guess and display an approximate
backup progress. Guesswork is never accurate, which causes some jumping back and forth. Nothing to worry about,
your backup is working without a problem.

The next thing you see is the "timeout bar". This is not a progress bar. This bar counts the time elapsed while running
the current step. Each time a new backup step starts, it resets to zero. The bar changes color from green to yellow to
red. Green means that it's within the expected limits. Yellow means that we have exceeded the time we expected to
consume, but are still within the configured limits. The red area means that this step is taking substantially more time
than we expected. This doesn't mean that your backup is stuck; it may just be network latency or other unexpected
issues which delay the server response. Do not consider the backup failed unless you either see an error page, or the
timeout bar fills up all the way to the right - which means no server response was received within 3 minutes, which
is just too long, therefore the backup has most probably failed.

Should a minor (non fatal) error occur, Akeeba Backup displays a new Warnings pane with yellow background. This
box holds the warnings which have occurred during the backup process, in chronological order. These are also logged

45


in the Akeeba Backup Debug Log and marked with the WARNING label, that is if your log level is at least Errors and
Warnings. Usual causes of warnings are unreadable files and directories. Akeeba Backup regards them as minor errors
because, even though the backup process can go through, what you get might be a partial backup which doesn't meet
your expectations. In case warnings appear on your screen you are advised to review them and assess their importance.

After the whole process is complete, Akeeba Backup will clean up any temporary files it has created. Akeeba Backup
will also clean temporary files and delete incomplete archive files upon detecting a backup failure.

By that point, your site backup file has been created. You can now navigate out of the backup page and possibly into
the backup administration page, clicking on the handy button which appears below the backup completion message.

Where are my backup files?
The backup files are where you told Akeeba Backup to put them, i.e. in the Output directory you specified in the
Configuration page. If you haven't touched the Configuration yet, the default backup output directory is adminis-
trator/components/com_akeeba/backup under your web site's root.

How can I download my backup files?
The easiest method is by navigating to the Administer Backup Files page and using the download links on the far right
of each entry, but this is not the recommended method.

Important
There have been reports that some server settings in conjunction with certain browsers may prevent you from
downloading a usable archive. We recommend AGAINST using the download feature of the Administer
Backup Files page for downloading your backup archive.

The suggested, tested and guaranteed method of downloading your backup files is nothing else than using FTP and its
variants, such as FTPS, FTPES and SFTP. We recommend using FileZilla as your FTP client. The default location of
the backup archives is administrator/components/com_akeeba/backup in your web site's root, unless
you have specified a different output directory in the Configuration page.

Important
When you use FTP you must turn on the Binary transfer type or your backup archives will be corrupt!
ALWAYS ENABLE THE BINARY TRANSFER MORE WHEN DOWNLOADING OR UPLOADING
YOUR ARCHIVES THROUGH FTP, FTPS, SFTP, etc.

Once more, NEVER, EVER, USE THE "AUTO" OR "ASCII" TRANSFER MODES; ALWAYS EX-
PLICITLY ENABLE THE BINARY TRANSFER MODE OR YOU WILL NOT BE ABLE TO RE-
STORE YOUR BACKUP.

If you use FileZilla, you can ensure you are using the correct transfer mode by clicking on Transfer, Transfer Type
and clicking the Binary menu item before downloading your archives. If you disregard this warning and download

46


your files through your browser, test your backups. Do not ask for support on restoring corrupt archives downloaded
through the browser. We warned you for a good reason.

I got an "AJAX loading error" when backing up. What should I do?
First check your PHP version. You can check your PHP version by going to your site's System Information menu item.
Even though the interface may load in PHP 5.0.x, the backup won't run on such old versions of PHP. We strongly
suggest that you use the latest PHP 5.2.x or 5.3.x version for optimal operation of the component.

This error message by itself means pretty much nothing. All it tells us is that the backup failed. Normally, you should
post your log file to our forum so that we can take a look at it to figure out what went wrong. However, there are
some common issues you can work around yourself, without looking at the log file. You should follow the following
troubleshooting steps one by one until your backup works. If nothing works, please post your support request to our
forum, attaching your log file in a ZIP archive, indicating which of the following steps you have already tried.

1. The first thing you must do is to use the Configuration Wizard button in the Control Panel page to automatically
adjust a series of configuration parameters to safer settings. The wizard performs benchmarking of your server to
determine those values. It is not always 100% accurate, but the settings it creates are at the very least a good starting
point for tweaking them manually.

2. Try visiting the Configuration page and clicking on Save. This may be necessary if you just upgraded. This simple
move will refresh your configuration and pick up the default values for any new parameters which might have been
introduced in the new release.

3. Check your free space. Akeeba Backup is trying to create an archive with your entire database and all of your site's
files; it needs adequate free space to do that. If you don't have enough free space, your host will kill the script in
mid-process, making Akeeba Backup's interface throw this error. As a rule of thumb, we propose having about
40-50% of your account's allocated quota free.

4. Which temporary directory are you using? If you are using the system wide temporary directory or your account's
default temporary directory you might run into problems. Most host periodically clear thes contents of these direc-
tories to ensure that their server doesn't run out of free space. If in doubt, you can always work around this easily.
First, make sure that the tmp directory inside your Joomla! installation's root directory is writable. You can give
it 0777 permissions if in doubt. Then, go to Akeeba Backup's Configuration page. Find the Temporary directory
setting and set it to [SITEROOT] (including the brackets!). Then click on the Browse... button next to it. In the
window which opens, click on the tmp entry. The view refreshes itself. Click on the Use button on the top right.
The pop-up window closes and you are back to the Configuration page. Click on Save and retry backup.

5. If you are using the ZIP archive format it is possible that you run into timeouts. The problem with the ZIP format
is that we have to read each file twice. We read it once in order to calculate a "file signature" (properly called a
"CRC32 checksum"), then we read it again in order to add it inside the archive. Unfortunately these steps can't be
combined and, on top of that, the very slow signature calculation step must be able to run in one go. With larger files
and slower hosts this will consistently lead to timeouts. If you suspect this is the case, please use the JPA format
setting in the Archiver Engine option of the Akeeba Backup's Configuration page.

6. Some hosts impose a maximum size for files stored on their server. We are not talking about the quota size, but
the maximum size an individual file can have. Since Akeeba Backup archives tend to get rather big, this can cause
your server to kill the backup process before it completes. In such a case, you need to do two tweaks in the Akeeba
Backup's Configuration page:

• Go to Akeeba Backup's Configuration page. Find the Archive Engine option. Make sure that JPA Format is
selected. Next to it, there is a Configure..." button. Click it. A new pane opens right below. In this pane, locate
the Part size for archive splitting option. Select the value you want from the list, or select the "Custom..." option
and type in your desired value in the text box that appears to the right of the drop-down. we suggest using a value
of 10Mb. Save the configuration and retry backup. This will cause your backup archive to be split into multiple
files having extensions .jpa, .j01, .j02, .j03 and so on.

47


Some servers do not work even with the 10Mb setting. Other safe values we have discovered (depending on your
host) are: 5Mb, 2Mb, 500Kb.

• Similarly, you can change the part size for the MySQL dump file. The reason you might want to do that is that
the SQL dump file is first written to disk and then written inside the archive. If the dump file grows beyond your
host's file size limits, it will crash the backup. Furthermore, splitting your SQL dump will have one positive side-
effect: it will improve the compression ratio of your backup, result in a much smaller overall backup size!

Go to Akeeba Backup's Configuration page. Find the Database Dump Engine option. Next to it, there is a Con-
figure..." button. Click it. A new pane opens right below. In this pane, locate the Size for split SQL dump files
option. Select the value you want from the list, or select the "Custom..." option and type in your desired value
in the text box that appears to the right of the drop-down. We suggest using a value of 500Kb. Save the config-
uration and retry backup.

7. Some servers have a very strict limit on the maximum execution time of PHP scripts. By default, Akeeba Backup is
configured with a maximum execution time allowance of 14 seconds. In order to work around such hosts, please go
to your Akeeba Backup Configuration page and scroll all the way down to the Fine Tuning pane. You will find an
option labeled Maximum Execution Time. Select the value you want from the list, or select the "Custom..." option
and type in your desired value in the text box that appears to the right of the drop-down. We suggest using a value
of 7 seconds. Click on the Save button and retry backing up your site.

We have heard of hosts which require settings even lower than that. If in doubt, ask your host what their PHP
maximum_exec_time setting is, then subtract one second and use this value in Akeeba Backup's Maximum Exe-
cution Time setting.

8. If all else fails, see the following paragraphs for details on getting support from us. Please do not post on other
forums (like the official Joomla! forums, or local Joomla! support forums). We can't monitor the entire Internet
for your requests. However, we do answer all questions posted on our forum within 24-48 hours (most of them
in under 8 hours).

How do I know that my backup archive works? What happens if I
have a backup problem? How do I get support?
We also strongly recommend testing your backup files, at least the first time you produce a backup and whenev-
er you make major changes/upgrades to your site. Testing the backup archives is trivial. Just download and install
WAMPserver, XAMPP, MAMP or a similar package on your local PC to create a local testing server environment.
Then try restoring your backup file on the local testing server environment. Should you run into problems, you are
welcome to post to our forums. We respond to all support requests within one or two business days, usually within
a few hours. Posting to the support forum requires a free user account registration. That's right! We will not charge
you for support! We take pride for being one of the few Open Source projects which provide top quality software,
thorough documentation and fast support from the project's team for free.

In order to get fast and accurate support, we will need:

• A clear description of your problem. Saying "Um... it just doesn't work" is not a clear description. Tell us exactly
what you were trying to do, at what exact operation it failed and any error messages which were output on the page.
If you can get a screenshot of the error message that's even better!

• Exact version of Akeeba Backup. It's visible on the right-hand pane in Akeeba Backup's Control Panel. If you do
not tell us the version, you will waste a day as we'll first ask you to upgrade to the latest version.

• Joomla! version. It is best to tell us the exact version, for example 1.5.22. If you have Joomla! 1.5.14 or earlier, do
not ask for support. Instead, updgrade your site to the latest version of Joomla!.

48


• Exact MySQL and PHP version. From your Joomla! back-end go to Help, System Info and report the values in the
Database Version and PHP Version rows. If your MySQL version is 4.0 or earlier or if your PHP version is 5.0.x,
5.2.4 or 5.2.5 do not ask for support. Instead, ask your host to update their severely outdated servers.

• A copy of the debug log taken with log level set to All Information and Debug when the problem happened.
You can download a copy of the log from within the View Log page. DO NOT COPY AND PASTE FROM THE
BOX. Use the download button ABOVE the box. If you copy & paste the log, you will waste a day as we will tell you
to download, ZIP and attach the raw log file to your post. If it doesn't work for you (for example, you get an empty
file), the log is available inside the configured output directory, named akeeba.backend.log. Since our forum rejects
certain file extensions, zip it before attaching it. If you are concerned about the possibility of revealing potentially
sensitive information, password-protect the ZIP file and send a private message with the password, addressed to
user nicholas.

• If you are writing about an error related to the restoration process do not forget to tell us which restoration script is
embedded in the backup (take a look at your Configuration page) and how you extracted the archive file, i.e. using
Kickstart or using Akeeba eXtract Wizard. Also inform us about the method you used to download the backup file
to your PC - if applicable - and the method you used to upload the backup file to your host, for example "I used
FTP in Binary mode", "I used Akeeba Remote Control 2.5", "I just clicked on the Download button and ignored
the warning box". Remember to mention the EXACT version of Kickstart you are using; it's printed with very big
letters on the top of Kickstart's page.

Finally, do not tell us that "Kickstart x.y.z stucks in the database restoration page" because such a thing is impossible.
Kickstart extracts the archive. Then it launches Akeeba Backup Installer (a.k.a. ABI), the restoration script included
in your archive. It's ABI restoring the database. Since ABI is in the archive, we need to know which version of
Akeeba Backup Produced the archive. The Kickstart version is completely irrelevant in this case.

The more information you provide the faster and more accurate a response you'll get. In any case, please tell us the
symptoms. Do not attempt to find an explanation yourself and present that explanation as the problem you experience.
More often than not this will derail our support efforts and it will take us significantly longer to effectively help you.
We help you faster and better if we're given just the facts. Thank you!

2.5. Administer Backup Files

This page is the single place you can review all your Akeeba Backup backup history, as well as administer the backup
files. The bulk of the page consists of a standard Joomla!™ list table. Each row represents a backup attempt and
displays a whole lot of information:

The check box Clicking the check box on the leftmost cell of a row selects this backup for an operation to be
column applied to it. Operations are activated by clicking on tool bar buttons. In case of an operation
allowing a single row to be selected, the topmost selected row is considered as the sole selection.

Description Displays the description you have set when you started the backup. In case of frontend backups,
this contains the default description which was assigned. If your backup has a comment attached

49


to it, an info icon will also appear. Hovering your mouse over the info icon will show you a
preview of that comment.

Start The date when the backup started. The date is expressed in the user's preferred time zone, as it is
set in the User Managment page of Joomla!™ itself.

Note
Backups taken without a logged in user, i.e. remote, front-end and native CRON backups,
express the time in the UTC time zone. We can't "fix" that; without a user, Joomla!™
can't reliably report the time zone.

Duration The duration of the backup in hours : minutes : seconds format. This information is not available
for failed backups!

Status Indicates the status of the backup and can be one of:

OK A complete backup whose backup archive is available for download.

Obsolete A complete backup whose backup archive is either deleted, or was overwritten by
another backup attempt.

Note
If you move your backup output directory's location, all your previous
backups will appear as "Obsolete", even though you might have moved
these backup files as well. This is not a bug. Akeeba Backup internally
stores the absolute path to the backup files. When you move the output
directory its absolute path changes, so Akeeba Backup is unable to locate
the old backup files.

Important
If your host uses MySQL 4.0 the status will always appear as Obsolete and
you will be unable to download the backup archive through your brows-
er, as the result of limitations of this ancient, obsolete and unsupported
MySQL version. You can still use your favorite FTP client to download
the backup archives, though.

Pending A backup attempt which is still running. You should not see any such record, un-
less a backup attempt started while you were loading this page. In this case, you
should not navigate to the Control Panel page! Doing so would invalidate the back-
up and wreck havoc. You have been warned! Another reason to see such an entry
is a backup attempt which failed with a PHP fatal error, or which was abruptly in-
terrupted (by the user or a PHP error). In this case, you can safely delete the entry
and get rid of the backup file as well.

Failed A backup attempt which failed with a catchable error condition.

Origin Indicates the origin of the backup and can be either frontend for backups originating from the
front-end - or remote interface - or backend for backups originating from the back-end (regular
backups).

Type Indicates the backup type and can be Full for full site backups (database and files), DB Only for
database only backups, Files only for files only backup or Multi DB for multiple databases backup
(an archive containing SQL dumps of the main site's database and the defined multiple databases).

50


Profile Displays the numeric identifier of the backup profile used during the backup. It is possible that
since then the profile may have been modified or even deleted!

Size The total size of the backup archive in Mb. If the files are not available on your server, i.e. the
record is marked as "obsolete", the size appears inside parentheses to let you know that the files
are not available for download.

Archive Displays the name of the backup file, if it is available. Clicking on the backup file name will let
you download it, directly from your browser. If it is a split archive the file name is not clickable but
you will be given as much download links as the parts of your backup are. For example, you might
see links labelled "Part 00", "Part 01" through "Part 09" in a split archive consisting of ten files.

Important
The only supported and guaranteed method of downloading your backup archives er-
ror-free is using FTP/SFTP in BINARY transfer mode. Anything else has the potential
to CORRUPT your backup archives.

If the file is stored on a remote storage location, e.g. Amazon S3 or a remote FTP server, you will
also see a Manage remote stored files link if you are using Akeeba Backup 3.2 or later. Clicking
on it will allow you to transfer the files back to your server, download them directly from the
remote location or remove them from the remote storage.

Clicking on the label of each column allows you to sort the backup entries by the contents of that column. By default,
Akeeba Backup sorts the records by Start descending, so that the newest backup attempts will appear on top. Below
the header there are three filter boxes. The first one allows you to filter by the backup description. The other two allow
you to select a date range so that only backups attempted within this date range will be displayed. You can leave either
of these boxes empty to allow an open start or end date respectively.

On the top of the page you can find a tool bar with operations buttons. The Delete button will remove the selected
backup attempt entries along with their backup archives (if applicable), whereas the Delete Files button will only
remove the files (if found on your server). The Restore button will run the integrated restoration feature for the selected
archive file. This feature can be used to restore your backup archive on the same server you backed up from or even a
different server (live transfer of your site to another host!). The Discover and Import Archives (available since Akeeba
Backup 3.2) allows you to import any ZIP, JPA or JPS file in the Administer Backup Files page in order to restore
it on this or any other site.

Important
Integrated restoration is only supported for Full Site and Files Only backup archives. Trying to use it with
any other type of backup files will ultimately result in an error.

51


The View / Edit Comment button will open a page showing the description and comment of the currently selected
backup row. You can freely edit both the description and the comment on that page and save your changes using the
Save button. The same page will open if you click on a backup record's description (appearing as a link).

2.5.1. Integrated restoration
Warning
THE INTEGRATED RESTORATION FEATURE MAY DESTROY YOUR SITE IF YOU ARE NOT
CAREFUL.

Remember that you are OVERWRITING your site with the one contained in the backup archive. Do not do
that on a live site unless it is absolutely necessary, i.e. you have already destroyed something vital in your
site and want to revert to a "last known good" state.

As with any backup restoration method, practise on a local testing server first. Don't push your luck by trying
a potentially dangerous procedure you are unfamiliar with on a live server. Many sites have been destroyed
by human error, augmented by the "bliss of ignorance" effect. Never, ever, under any circumstances, attempt
a restoration on a live site unless you are familiar with the procedure and confident of all the steps you take.

That said, we trust our own software and use it on our sites. Do note that we are extremely familiar with the
procedure and extremely careful when doing restorations. This message tries to excessively - if that's ever
possible - stress the point that you must be careful and that the best method to achieve that is practising on
a local testing server first.

The integrated restoration feature allows you to easily restore a previous backup directly on your server, as long as
your backup archive still exists on your server of course. The whole idea behind this feature is that it is not necessary to
manually download Kickstart, place it in your site's root and move the backup archive from the output directory to the
site's root in order to perform the restoration. Instead, the integrated restoration feature takes care of extracting your
backup archive directly from the backup output folder into your site's root and then allow you to run the embedded
installer (Akeeba Backup Installer) to complete the restoration procedure.

The communication between your browser and the archive extraction script is encrypted with the AES128 (Rijndael)
encryption method, using a random key produced as soon as you initiate the restoration of a backup archive. This
ensures that a malicious user can't exploit the restoration script to mischievously extract your backup archive in your
site's root with the intent to steal your database password. The encryption/decryption algorithm is implemented with
standard PHP and Javascript code, eliminating the need for third party cryptography libraries and ensuring that under
no circumstances unencrypted data will be exchanged between the browser and the server.

52


When you first start the integrated restoration feature, you are presented with a few settings. The first setting, appearing
above the Start Restoration button, determines how the file extraction will be performed. The two available options are:

Write directly to All files will be extracted directly to their final location using direct PHP file writes. If your
files permissions settings do not allow some files or directories to be created/overwritten the process
will fail and your site will be left in a half-restored state.

Use FTP uploads Using this method, each file is first extracted to the temporary directory specified by the current
profile and then moved to its final location using FTP. This is a "best effort" approach and can
work with most servers. Do note that only unencrypted FTP (plain FTP) is supported. If you
choose this option, you'll also have to specify the FTP connection settings.

You MUST use this option if you want to restore your backup archive to a different site than the
one you are in right now. Just select this option and provide the FTP connection details to the
other site before clicking on Start Restoration.

The default mode is writing directly to files, unless your site's Global Configuration indicates that the FTP layer should
be used.

In the event that a partial restoration happens, your site will be left in a semi-restored state. Trying to access it will
pop up the restoration script (Akeeba Backup Installer, a.k.a. ABI). If you want to retry the restoration using different
settings, please remove the installation directory from your site's root manually, for example using FTP, before
trying to access your site's administrator back-end.

If you chose to use the FTP mode, there are some connection settings you have to take care of. Do note that they are
filled in with Joomla!'s FTP layer settings by default. Unless you chose not to store your FTP password in Joomla!'s
configuration or if you have not configured the FTP layer yet, there is no need to change them. The settings are:

Host name The host name of your site's FTP server, without the protocol. For example, ftp.example.com
is valid, ftp://ftp.example.com is invalid.

Port The TCP/IP port of your site's FTP server. The default and standard value is 21. Please only use
a different setting if your host explicitly specifies a non-standard port.

User name The username used to connect to the FTP server.

Password The password used to connect to the FTP server.

Initial directory The FTP directory to your web site's root. This is not the same as the filesystem directory and
can't be determined automatically. The easiest way to determine it is to connect to your site using
your favourite FTP client, such as FileZilla. Navigate inside your web site's root directory. You'll
know you are there when you see the file configuration.php and directories such as ad-
ministrator, component, language, includes, cache and xmlrpc in that directory.
Copy (in FileZilla it appears on the right hand column, above the directory tree) and paste that
path in Akeeba Backup's setting.

Alternatively, click on the Browse button next to the text box to launch an interactive FTP direc-
tory browser. Navigate into the directory where you want your files to be restored and click on
the OK button.

Test FTP connec- Clicking on this button will tell you if the FTP connection could be established or not. If the
tion connection is not successful you should not proceed with a restoration in FTP mode as it will fail
immediately.

The whole process is fully automated, so there is not much to tell you about it. However, you must not that in order
for the restoration procedure to work properly you must take care of the following:

53


1. This feature is directly calling the administrator/components/com_akeeba/restore.php script. If
you have a server-side protection, i.e. .htaccess rules, or permissions settings which prevent this file from being
called directly the process will fail.

Security note: The restore.php file is of no use to potential hackers. In order for it to work at all, it requires the
restoration.php file (more on that on the next point of this list) to load. Even then, it expects encrypted data
with a key which is not predefined and is only known to the restore.php script and the integrated restoration
page of Akeeba Backup. As a result, it can't be used as a potential attack vector.

2. Before the restoration begins, Akeeba Backup needs to create the administrator/compo-
nents/com_akeeba/restoration.php file with all the archive extraction setup parameters. It is intelli-
gent enough to use Joomla!'s FTP mode if it is enabled so as to overcome any permission problems, but you are
ultimately responsible for ensuring that the permission settings are adequate for Akeeba Backup to create this file.

If you have disabled Joomla!'s FTP layer, the permissions of the administrator/compo-
nents/com_akeeba directory should be 0777 for the integrated restoration to work, or 0755 on hosts which
use suPHP.

If you are using Joomla!'s FTP layer and it was active when you were installing Akeeba Backup, you'll need to give
this directory at least 0744 permissions, but you may have to manually remove restoration.php (but NOT
restore.php!!!) after the site restoration is over.

3. When the extraction of the backup archive finishes, you will be automatically forwarded to the Akeeba Backup
Installer page on a new tab or window. DO NOT CLOSE THE INTEGRATED RESTORATION PAGE'S TAB/
WINDOW! After you have competed the Akeeba Backup Installer process you are supposed to return to the Inte-
grated Restoration page and click on the Finalize button to:

• remove the installation directory from your site's root, and

• remove the administrator/components/com_akeeba/restoration.php setup file to nullify the,
already non-existent, potential risk of a malicious user abusing this script.

4. If you are restoring to a remote server, the previous step will result in a 404 page. Just point your browser
to http://www.yoursite.com/installation/index.php (where www.yoursite.com is the domain
name of the site you are restoring to) to access the restoration script. After finishing the restoration procedure, do
NOT click the Finalize button. Instead, use your favorite FTP client to remove the installation directory from
the site you were restoring to and rename any htaccess.bak file back to .htaccess.

2.5.2. Manage remotely stored files
Since Akeeba Backup 3.2 you have the option to manage backup archives stored in a remote storage location, for
example Amazon S3 or a remote FTP server. You can do that by clicking on the Manage remotely stored files link on
the far right of supported backup records in the Administer Backup Files page. Do note that, if you have upgraded from
Akeeba Backup 3.0.x or 3.1.x, backup records created by older versions of the software do not support this feature.
Clicking on that link opens a lightbox (modal dialog) with the options compatible with your backup archive.

Please note that not all of the following features may appear in the dialog. It depends on the remote storage engine
used for the backup record. All options currently appear only for files stored on Amazon S3 and remote FTP.

54


The Fetch back to server button will automatically download the backup archive from the remote location and store
it again on your server. This allows you to easily import backup archives stored on a remote location back to your
server's storage so that you can easily restore them on the same or a different site. If you are using S3, please make
sure that the user credentials you have supplied have enough privileges for the files to be downloaded (i.e. they don't
grant write-only access to the bucket). Also make sure that you have adequate free disk space on your server for the
operation to complete.

The Delete button will permanently delete the archives from the remote storage. There is no confirmation. Once you
click this button, your remotely stored files will be removed.

Finally, there are links under the Download to your desktop header. Clicking on them will instruct your browser to
download the respective backup archive's part directly to your PC. Currently, only Amazon S3 and remote FTP support
this feature. Do note that the backup archives are transferred directly from the remote storage to your PC. They are
not stored to your site's server. If you want to store them to your server, use the Fetch back to server button instead.

If none of the above options are available, Akeeba Backup will display an error message. In that case, just close the
modal dialog.

After finishing your remote files administration, please close the modal dialog by clicking on the X button on its top-
right corner and reload the Administer Backup Files page. Until you reload the page the changes you made WILL
NOT be visible. This is not a bug, it is the way it is meant to be.

2.5.3. Discover and import archives
Sometimes you may have accidentally deleted a backup record from the Administer Backup Files page, or simply
want to restore a backup file taken from another site. Normally, the only way to do that is to upload the archive file
and Kickstart to your site and launch the restoration process from there. However, some users insisted that they are
better off doing that from inside Akeeba Backup itself. In order to accommodate for their needs, we introduced the
Discover and Import Archives features in Akeeba Backup 3.2.

This feature allows you to automatically find and import archives stored anywhere on your account. This means that
you can upload backup archives anywhere in your site's folder structure, or even on a private off-site directory and

55


Akeeba Backup will be able to import them. All backup archives are imported as backup records of the default backup
profile (profile with ID #1) and can be restored just like any other backup archive.

In order to launch this feature, go to the Administer Backup Files page and click on the Discover and import archives
button on the toolbar. A new page appears which lets you select a directory.

Use the Browse... button to open an interactive folder browser in a modal dialog. Navigate to the directory which
contains the uploaded backup archives and click on the Use button. The dialog closes and you can now click on the
Scan for files button to let Akeeba Backup search for backup archives inside that directory. You are presented with
a new page, listing the discovered backup archives.

Select the backup archive you want to import by clicking on them. If you want to select multiple files, Control-click
(Windows, Linux) or Command-click (Mac OS X) the archive you want to import. After that, click on the Import the
files button. After a short while Akeeba Backup takes you back to the Control Panel page with a message that the
import operation completed successfully. You can now click on the Administer Backup Files button to view the newly
imported backup archives. You can now download or restore the imported backup archives.

2.6. View Log
The View Log option allows you to download or view the output from the most recent backup operation attempted on
each origin. This information may be useful in diagnosing problems if you are having a problem completing a backup.

The first page allows you to select an origin. Backups attempted using the Joomla! administrative back-end belong
to the Backend origin. The Frontend origin applies to backup archives taken with the front-end backup method (also
referred to as legacy CRON in our documentation) or using the altbackup.php script. The Command Line origin
applies only to backups taken with the backup.php script file of the Professional release. The XML-RPC origin
applies to backups taken with Akeeba Remote Control up to version 3.x. Finally, the JSON API origin applies to
backups taken with Akeeba Remote Control 4.x or later.

56


Tip
If you just tried taking a backup using Akeeba Backup's interface, please select the Backend option from
the drop-down.

This takes you to the View Log visualization page.

If you wish to ask for support, you must download the raw log (a text file). Just click on the download button above
the log viewer. Do not copy and paste the text appearing in the log viewer. If you do that, you will lose a day as we're
going to tell you to download the raw log, ZIP it and attach it to your next post. Once again, please DO NOT copy
and paste text. We absolutely and beyond any doubt need the raw log file in order to support you. Help us help you
so that we can solve your issues as soon as possible.

Warning
When asking for support, make sure that the Log Level was set to "All Information and Debug" in the Basic
section of the Configuration page before backing up. Otherwise the log will be useless in supporting you.

The bulk of this page is the log visualization box. Each line is preceded by a time stamp, in the format YYMMDD
hh:mm:ss (that's year, month, date with two digits, a space and time in 24-hour format). Each line is colour coded, for
your convenience. Debug information is in smaller, grey type. Normal information is in black type. Warnings appear
in bold yellow letters. It is important to read them as they convey information about skipped directories or other things
that will be missing from the backup archive. If any errors occurred, these appear in bold red type.

Whenever you report bugs, all of this information is absolutely necessary. In order to reveal as little sensitive infor-
mation as possible, whenever a file path has to be logged, your site's root folder is replaced with the string '<root>'.
Keep this in mind when reading warnings and errors.

2.7. Access Control
Akeeba Backup is able to run on a variety of Joomla! based CMS system, including Joomla!™ 1.5, Joomla! 1.6, Nooku
Server and Molajo. By default, it's restricted to users with Super Administrator privileges. This makes sense, as anyone
who is able to take and download a backup archive immediately has full access to every bit of information in your
site, including database passwords.

That said, many web professionals asked for a way to setup Akeeba Backup in a way that makes it possible for their
clients to backup their sites, but not touch any configuration options. Some others asked for a way to allow some people
act as "backup operators", i.e. take a backup but not being able to download or restore it. In order to cope with this
requirement, Akeeba Backup includes fine-grained access control (ACL) since version 3.2. The exact ACL method
is specific to the platform it's running on.

57


Important
The following options apply to back-end backups only. Front-end backups, including legacy front-end CRON
jobs, remote backups and Lite Mode backups, are controlled by means of the Secret Word you define in the
Component Parameters page. These backup modes are not controlled by the access control settings because
they do not require a user to be logged in to take a backup; they only require knowledge of the Secret Word.

2.7.1. Joomla! 1.5, Nooku Server and other Joomla! 1.5 distributions
When Akeeba Backup runs on Joomla! 1.5, Nooku Server or any other CMS distribution based on Joomla! 1.5, there
are two levels of access control: component access and per-user ACL (permissions) settings.

The first level of access control defines who can access the component at all, i.e. who can see its interface. In order
to configure it, go to Components, Akeeba Backup and click on the Component Parameters button. In the parameters
interface look for the Minimum access level option. Each one of the three options has the following meaning:

Super Adminis- Only Super Administrators can access the component
trator

Administrator Only users in the Administrator or Super Administrator group can access the component

Manager Any user with back-end access (Manager, Administrator or Super Administrator) can access the
component

Please note that this setting has precedence over the per-user ACL. This means that if you set this setting to Super
Administrator, an Administrator will not be able to use Akeeba Backup even if you grant him all permissions in the
per-user ACL settings.

The second level of access control is per-user ACL. By default Super Adminsitrator can do everything, Administrators
can backup and download backup archives and Managers can only perform a backup but not download backup archives
or configure the component. This feature allows you to have fine grained control over what each user can and can
not do. To access it go to Components, Akeeba Backup and click on the Access Control button. You will see a list
with all users granted back-end access (Managers, Administrators and Super Administrators). On each row, you will
see the following columns:

Username The username this row applies to

Group Which user group (Manager, Administrator, Super Administrator) this user belongs to

Backup A green check means that the user can use the Backup Now button to take a new backup. A white
X in red background means he has no access to that feature. Click on the icon to toggle between the
two states.

Download A green check means that the user can use the download links in the Administer Backup Files page to
download the backup archives. If you are using Akeeba Backup Professional, a user with the Download
privilege will also be able to download or delete files from a remote storage location (e.g. Amazon
S3). A white X in red background means he has no access to that feature. Click on the icon to toggle
between the two states.

Configure A green check means that the user can use all of the configuration pages of Akeeba Backup, including
filter pages, to modify the backup settings. A white X in red background means he has no access to
that feature. Click on the icon to toggle between the two states.

Setting up a backup operator is trivial: make sure that the user only has the Backup privilege (green check), whereas
all of the other options are disabled. Similarly, to allow a user backup and restore a site but not touch the configuration
settings just give him the Backup and Download privileges. The power is yours!

58


2.7.2. Joomla! 1.6, Molajo and other Joomla! 1.6 distributions
Joomla! 1.6 comes with a very powerful and somewhat complex ACL system on its own. Akeeba Backup is designed
to make full use of it ever since the early 3.1.x releases. In order to access the ACL setup, go to Components, Akeeba
Backup and click on the Component Parameters button. Then, click on the Permissions tab. Each group can be setup
with the following privileges:

Configure (the Allows access to Component Parameters button. This is a core Joomla! privilege.
one on top)

Access Compo- Self explanatory. If a user doesn't have this privilege, he won't be able to access the component!
nent This is a core Joomla! privilege.

Backup Now The user can use the Backup Now button to take a new backup. This is a privilege specific to
Akeeba Backup.

Configure (the The user can use all of the configuration pages of Akeeba Backup, including filter pages, to modify
one towards the the backup settings. This is a privilege specific to Akeeba Backup; it has nothing to do with the
bottom) first "Configure" item on that list.

Download The user can use the download links in the Administer Backup Files page to download the backup
archives. If you are using Akeeba Backup Professional, a user with the Download privilege will
also be able to download or delete files from a remote storage location (e.g. Amazon S3). This
is a privilege specific to Akeeba Backup.

We won't go into more details regarding the ACL setup on Joomla! 1.6. If you want more information about how the
ACL system works in Joomla! 1.6, please consult its documentation or ask on the Joomla! forums.

2.8. Site Transfer Wizard
Many times you simply want to move your site between hosts, e.g. from a local or development server back to the live
server or move your site from Host A to Host B. Traditionally, this was a multi-step process: take a backup, download it
to your local PC, upload it to the live server, upload Kickstart, run Kickstart and finalize the restoration. Since version
2.2 we offer a backup engine called DirectFTP which allows you to take a backup directly to a remote FTP server
instead of an archive. This means that you no longer need to download/upload a backup archive or even use Kickstart.
By the time the backup is finished, you are able to simply point your browser to the new host and start the restoration.
The biggest drawback of this approach was that setting it up was a little difficult for novice users. Our Site Transfer
Wizard feature is here to make using that feature dead simple!

The Site Transfer Wizard guides you through a series of steps which allow you to define the connection parameters
to your remote server and automatically takes care of all the details necessary for moving your site to the new host.
It consists of only three simple steps.

Step 1: Choose your profile
The Site Transfer Wizard requires to create a dedicated backup profile for the site transfer backup job. This step allows
you to select how this is going to happen.

Use the existing If you had already used the Site Transfer Wizard in the past, all of its settings are stored in its
profile dedicated backup profile. Selecting this option will recall them and allow you to modify them or
use the same settings to transfer your site again.

Copy settings Select an existing backup profile to copy all settings from. This allows you to "clone" special
from configuration options (such as the optimal settings defined by the Configuration Wizard) as well
as any filter options, e.g. directories, files and database tables to exclude from the backup. If it is

59


the first time you are running the wizard and you are not a very experienced user, it's suggested
to copy the settings from the Default Backup Profile.

Create a new pro- This will reset all the configuration and filter options of the Site Transfer Wizard backup profile
file, resetting its to factory defaults. This should only be used by experienced users who know what they are doing
settings to default or if you are willing to apply special configuration and/or filter settings manually.

Clicking on Next will take you to the next and most important step.

Step 2: Chose your transfer settings
In this step you will tell Akeeba Backup how to connect to your new host in order to transfer your site there.

Connection You can choose between FTP, FTP over SSL (FTPS) or –if you have the Professional version–
method Secure File Transfer over SSL (SFTP). If you are not sure which one to use, please ask your host.
Most hosts support FTP, a few of them FTPS and very few of them SFTP. Please do not ask us
which method to use. We are not your host and we can not possibly know which method your
host's servers support.

Host name The hostname of your FTP, FTPS or SFTP server. Please do not specify a protocol. For example,
ftp.example.com is a valid host name whereas ftp://ftp.example.com IS NOT. If
unsure, please ask your host. Once more, we can't possibly know how to connect to your server,
it's your host that has to give you this information

Port This is the number of the TCP port used to connect to your server. Usually it's 21 for FTP, 22 for
SFTP and 990 for FTPS. If unsure, please ask your host.

Username The username used to connect to your remote server. Do note that if your host requires an SSH
certificate to connect to their server through SFTP, you will not be able to use SFTP with Akeeba
Backup to transfer your site. Our software only supports username/password authentication to the
remote server.

Password The password used to connect to your remote server

FTP/FTPS/SFTP This is the full FTP, FTPS or SFTP directory to your remote site's web root. This may not always
directory to the be obvious and most likely should not be left blank. You can always connect to your remote site
remote site's root using FileZilla, navigate to the web root directory of your new host and take a look above the
right-hand directory pane. You will see a path. Copy it and paste it in this box of the Site Transfer
Wizard.

Use Passive For FTP/FTPS connections only. The default behaviour is to use FTP Passive Mode for all site
mode transfers, as it is the only guaranteed way to pass through firewalls. If your remote site requires
FTP Active Mode (very rare) uncheck this box. If you are unsure if this is required, please ask
your host.

URL to the re- Enter the full URL to the remote site, e.g. http://www.example.com/joomla. Please, do
mote site not include a trailing slash.

Clicking on Next, Akeeba Backup will try to establish an FTP/FTPS/SFTP connection to your remote host and upload
a small file named akeeba_connection_test.png. If that fails, it will let you know about the error which occurred so that
you can fix it. If you have entered an incorrect directory, i.e. it doesn't correspond to the location used to store the files
accessible through the "URL to the remote site" address, you will also get an error telling you that you have to fix it.

Important
Not all hosts are able to initiate FTP/FTPS/SFTP connections to other servers. The most common limiting
factor is a server-side firewall which disallows outbound connections. If you are perfectly sure that your FTP/

60


FTPS/SFTP connection settings are correct and you still can not connect to your remote site, do not ask us
for support. If you do, we'll tell you to read the documentation (this paragraph!). What you have to do instead
is to contact your current host and ask them to open their firewall so that you can connect to your new host
through FTP/FTPS/SFTP.

If you get an error about not being able to change to the requested directory, you have entered the "FTP/FTPS/
SFTP directory to the remote site's root" wrong. Please refer to the section above about how to determine
its correct setting.

If you get an error reading "Your FTP/FTPS/SFTP directory is not defined correctly. You will be redirected
back to the previous page to correct it. If in doubt about what this means, please read our documentation."
then you have entered the "FTP/FTPS/SFTP directory to the remote site's root" wrong. Please refer to the
section above about how to determine its correct setting.

Do not ask for support if you have not read the above and followed all of these instructions. Such requests
will be deleted without a reply.

Step 3: Transfer your site
In the final step, you are ready to transfer your site! Click on the button titled Begin the site transfer to start transferring
your site to the remote host.

If you get an error message about not being able to write to a remote file or directory, please check that this file or
directory doesn't already exist on your remote site. If it does, try removing it or adjust its permissions so that it is
writable through FTP/FTPS/SFTP. If you are not sure how to do that, please ask your host for instructions, as the
solution is entirely host-specific.

When the transfer is complete, you will be forwarded to the restoration script which was uploaded together with your
site's files and database dump to the remote server. Follow all of its steps to restore your site's database and configure
your site so that it can be used on the remote host.

If you end up back on your source site (the one you are transferring from), a blank page or an Internal Server Error
page, please use your favourite FTP client (e.g. FileZilla) to rename or remove the .htaccess file from the remote
site and reload the page. Do not contact us for support unless you do that first. For your information, it is possible that
your .htaccess file contains directives which either have a hardcoded site URL in them or are simply not compatible
with your new host. Renaming the file "neutralizes" it and you can access the installation script normally. If your
new host is GoDaddy, do note that it may take anywhere from 10 to 30 minutes after you rename .htaccess before
the changes take any effect at all!

After the restoration is over, click on the "remove the installation directory" link to remove the installation directory
from your new host and begin using your site. If that is not possible or throws an error, please use your favourite FTP
client (e.g. FileZilla) to manually remove the installation directory and all of its contents from your new host. Please
do not ask for support if trying to access your site is causing the installation script to appear again. The solution is to
remove the installation directory manually.

If, after the restoration, you have any problems accessing the remote site, please refer to these troubleshooting instruc-
tions [https://www.akeebabackup.com/documentation/troubleshooter/prbasicts.html] first. Unless you have followed
all of them, please do not ask us for support. 99.9% of all post-restoration problems that have ever been reported to
our forum are solved by following these simple instructions.

3. Include data to the backup
By default, Akeeba Backup automatically includes the whole database of your Joomla!™ installation as well as all
the files under your site's root in the backup set. Sometimes you want to include a different database - for example,

61


one used by your non-Joomla!™ newsletter software - or files you have placed above your site's root for increased
security. Akeeba Backup Professional can cope with that need by providing you with handy data inclusion filters.

3.1. Multiple Databases Definitions
Sometimes your site grows beyond Joomla!. A forum, a torrent tracker, a custom script... Some of them get to be
installed in a database of their own, not as tables in the same database as the one Joomla! is using. If you really want to
take a full site backup, you really need these databases backed up as well. The solution to this is the Multiple databases
definitions option of Akeeba Backup. You can define an unlimited number of additional MySQL databases which will
get to be backed up (and restored!) along with your regular Joomla! database.

Warning
Do not use this feature to add your site's database. It is automatically added anyway. Doing so will cause
errors during the restoration of your site! You have been warned. Do not seek support for this kind of
issues.

Warning
Do not confuse the term "database" with your Joomla!™ tables. It is possible that a single database contains
tables for the current Joomla!™ site, tables from a standalone photo gallery script, tables from another Joom-
la!™ site on the same server (e.g. a subdomain), tables from a standalone PHPList installation and so forth.
As far as Akeeba Backup is concerned, all of those tables exist in the same database. Unless you tell it
otherwise, it will backup ALL tables of the database.

A common misconception is that if you want to also backup a subdomain running on Joomla!™ and having
its tables inside the same database as the main site, you should add its database a multiple database definition.
DO NOT DO THAT, IT WILL MAKE THE RESTORATION FAIL! After all, Akeeba Backup already
backs up those tables. Why should you have to back them up a second time?

Warning
If you add an empty database (one which has no tables) it will result in backup errors!

Note
The settings on this page are defined per profile . Make sure you have selected the desired profile in the
Control Panel page.

At first, you are presented with a grid view, listing all database definitions. On the left of each entry, there are two icons:

•
The trashcan. Clicking on this icon will remove the current database definition from the backup set.

• Pencil or Add. Both will open the database definition editor: the former to edit the database definition, the
latter to create a new one.

62


The database definition editor opens as a dialog box inside the multiple databases definitions page. The options you
can select for each database are:

• Database driver. You can select which database driver Akeeba Backup will use to connect to the database. Your
options are:

• mysql. This is the regular MySQL connection driver for PHP. It has the widest compatibility, but the lowest
performance.

• mysqli. This is an improved MySQL 5 connection driver. It must be supported by your server in order to work
at all.

• Database server hostname. The host of your database server. Usually it's localhost, but many hosts use some-
thing different. If in doubt, ask your host.

• Database server port. Leave it blank, unless your host has told you to use a non standard port for connecting to
his database server.

• Username. The username of the database user needed to connect to the database.

• Password. The password of the database user needed to connect to the database.

• Database name. The name of the database you are connecting to.

• Prefix. The prefix used in the table name's prefixes. If you leave this blank, you won't be able to assign a different
prefix when restoring your database.

Warning
Some hosts use your account name as a prefix for the database and username. This is not the same as the
Prefix setting above! In fact, you have to incorporate that account prefix in your database and username
values. For example, you're hosted under the account name foobar and you create a database mydata
and a user myuser. Your host displays a prefix foobar_ on the left of the edit boxes where you entered
the database and user names. This means that your REAL database name is foobar_mydata and your
real username is foobar_myuser. This is especially true for accounts hosted in cPanel and Plesk powered
hosts. It goes without saying that your password doesn't take a prefix!!! Don't laugh, this question has been
already asked in the forum.

63


If in doubt, contact your host. We can't guess the right values for you because we are neither your host nor
your host's client (that is, you). If you ask your host to give you the connection information to your database,
they must be able to do so.

When you think you have all the connection information ready, click on Test Connection. This will check all settings
except the Prefix. If the connection test succeeds, it will inform you:

Same goes if it fails:

If your connection works properly, it's time to save your changes by clicking the Save button. The top panel will briefly
display a "loading" message and the dialog box will go away. That was it, your extra database definition is now saved.

3.2. Off-site Directories Inclusion
More often than not, seasoned web masters prefer to place file repositories outside the site's root (usually, outside the
web server's root as well!) in order to deter potential crackers and "leechers" from having direct access to those files.
Such repositories can include downloads, image galleries, media (audio and video) or controlled access documents
files. As you know, Akeeba Backup Core will only backup file under the site's root, which made these files impossible
to backup. Well, it's possible with Akeeba Backup Professional.

Using the off-site directories inclusion, Akeeba Backup can be instructed to look for files in arbitrary locations, even
if they are outside the site's root (hence the name). All the directories included with this filter will be placed in the
archive as subdirectories of another folder, in order to avoid directory name clashes. We call this folder the "virtual
folder", because it doesn't physically exist on the server, it only exists inside the backup archive.

For example, if you want to backup an off-site directory named images , if we weren't using the virtual folder it's
contents would end up being backed up (and subsequently restored!) inside the Joomla! images directory. This is
something you'd like to happen. If your virtual folder is called my_offsite_includes , this directory would end
up being backed up as something like my_offsite_includes1-images . Notice the number and the dash
before the actual directory name? This is a smart feature which allows you to backup many directories of the same
name. You could, for instance, backup two directories named images , confident that there would be no name clash
inside the archive.

Since keeping track of these folders is a pain, Akeeba Backup includes a readme.txt text file inside the virtual
folder which tells you which backed up folder corresponds to which physical folder, making it easy for you to restore
these directories to their rightful place.

Important
Akeeba Backup will not automatically restore the off-site directories to their original location. Since Akeeba
Backup is meant for backing up, restoring and migrating sites to another host we chose not to automatically
restore off-site directories, as this would break the migration process. A future version of Akeeba Backup
might address this issue more elegantly. We are open to suggestions!

64


Warning
Under no circumstances should you add your site's root as an off-site directory inclusion! Akeeba Back-
up already adds the contents of your site's root to the backup set without any manual intervention. If you
manually add this directory you will be backing up the same files twice, bloating your backup size - which
could in turn lead to backup problems, such as running out of disk space.

Tip
If you are using Joomla! 1.6 and have moved your libraries directory to an off-site location, you do not
need to add it as an off-site inclusion. Akeeba Backup will do that automatically for you.

At first you are presented with a grid view, listing all the off-site inclusions you may have already added. Next to each
row and on the left hand side of it you will find two icons:

•
The trashcan. Clicking on this icon will remove the current directory definition from the backup set.

• Pencil or Add. Both will toggle the row to edit mode: the former to edit the directory definition, the latter
to create a new one.

When a row enters the edit mode, the pencil icon changes to two different icons:

• The diskette. Clicking on this icon will save any changes you have made.

• Cancel. Clicking it will abort any changes you have made.

You will also observe that the path to the external directory has also turned to an edit box with a folder icon on its left.
You can type in the absolute path to the external directory using the edit box, or click on the folder icon to launch a
visual folder browser, much like the one you use to select an output directory in the component's Configuration page.
If you choose to use the edit box, you can use the following variables:

• [SITEROOT] is the absolute path to your site's root

• [ROOTPARENT] is the absolute path to your site root's parent directory, i.e. one level above your site's root.

4. Exclude data from the backup
More often than not you have data on your site you don't want to include in the backup set. This can be host-specific
directories (e.g. cgi-bin, stats, etc), log files, temporary data, an huge but immutable collection of large media
files, click tracking tables, download log database records and so forth. The exclusion filters allow you to fine tune
what should be left out of the backup set.

65


4.1. Files and Directories Exclusion
Ever had a file in your site's root put there by your host? Or how about that 200Mb video file in the media directory
you don't want to backup? If you need to exclude just a few files here and there but let the other files in the directory
be backed up, you can use this filter. Or, let's say you have a downloads folder with a size of 10Gb you don't want
to backup every time. Or, maybe, your host saves Apache logs in your site's root so that they can be accessible by
the provided analyser script. Possibly, you have another script (for example, a forum, a torrent tracker, you name it)
in a subdirectory of your site's root - or even buried deeper in the directory structure - that you don't want to backup.
Anyway, you need to exclude the contents of a directory from your backup. The Files and Directories Exclusion filters
are just right for you.

Before we begin our discussion regarding the operation mode of this filter, you have to know some automatic filters
put in place by Akeeba Backup. It will automatically exclude your site's temp-folder, the "cache" directory on your
site's root as well as all files and directories inside the component's output and temporary directories. This means that
you should never, ever use a folder whose contents you want to backup as your output or temporary directory.

The normal view of this page consists of three discrete areas.

The top area contains the component and page names and two links to switch between the normal and the tabular
view modes.

The middle area contains two interface elements:

• The Root Directory drop-down menu. Akeeba Backup can define filters for the site's files or for each of the off-
site directories separately. The default selection, [SITEROOT], contains all filters pertaining to the main site's files.
If you have defined off-site directories, you can select the appropriate directory from the drop-down list in order
to define filters for that directory.

• The Current directory bread crumb list. It shows the current path relative to the Root directory above. Clicking on
a subdirectory allows you to quickly navigate to it.

Below that, there is a button to Reset all filters. Clicking it will remove all Files and Directories Filters, for all of the
current root's subdirectories. This is useful in case you have messed up with the filters a lot and you need a quick way
to revert to the factory default settings.

The lower area consists of two panes. Each pane contains rows with icons and text. The icons represent an exclusion
type and can have three states: on (yellow background), off (white background), or force enabled (red background). You
can toggle between the on and off states by clicking on the icon. The force enabled state means that this exclusion type
is active (on) and forcibly enabled by another feature of Akeeba Backup, such as the automatic exclusions discussed
above, the regular expressions filters or a programmatic filter (plug-in) by a third-party developer.

The left hand pane is a list of subdirectories of the Current directory. Each row consists of:

66


• Exclusion. When enabled, the entire directory will be skipped from the backup set. It will be as if this directory
never existed on your server.

•
Skip subdirectories. When enabled, the subdirectories of this directory will be skipped from the backup set. It
will be as if this directory's subdirectories never existed on your server.

•
Skip files. When enabled, the files inside this directory will be skipped from the backup set. It will be as if the
files inside this directory never existed on your server.

• The directory name. Clicking on it will load the contents of this directory in both panes and will make this directory
current.

The right hand pane is a list of files contained inside Current directory. Each row consists of:

• Exclusion. When enabled, the file will be skipped from the backup set. It will be as if this file never existed
on your server.

• The file name.

• The file size. It will be expressed in the unit which is more convenient, i.e. bytes, Kb, Mb or Gb. This enables you to
quickly pick very large files within your site, which are usually the ones you'd like to exclude from the backup set.

When you click on the Tabular View link, the page radically changes format. Instead of browser panes, you now have
a grid.

On the top side of the grid you have the Add new filter buttons:

• Exclude directory. Completely skips backing up the given subdirectory.

• Exclude file. Completely skips backing up the given file.

• Skip subdirectories. Skips backing up all the subdirectories inside the given directory.

• Skip files. Skips backing up all the files inside the given directory.

Each line of the grid displays the following information:

• The filter type. It can be one of:





67


•
Trashcan. When you click it, the filter row will be removed.

• Pencil. When you click it, the row switches to edit mode

• The filter item itself. It is the relative path to the directory or file which the filter row applies to. The path is relative
to the Root directory displayed on the selection box on top.

When you click on the pencil icon, the filter item becomes an edit box. You can type in the new relative path and
then click outside the edit box, or press Tab on your keyboard, to immediately save the changes. There is no way to
undo your changes.

4.2. Database Tables Exclusion
Sometimes you can have multiple sites installed in the same database, a common situation with sub-domains on cheap
hosts who allow only one MySQL database per account. Some other times you have installed a forum, a torrent tracker
or whatever on a subdirectory of your site and it has created tables in your site's database. Now it is possible to exclude
these tables using the Database tables exclusion feature.

The normal view of this page consists of three discrete areas.

The top area contains the component and page names and two links to switch between the normal and the tabular
view modes.

The middle area contains the Current Database drop-down list. Akeeba Backup can define filters for the site's main
database or for each of the extra database definitions separately. The default selection, Site's main database, contains
all filters pertaining to the main site's database, i.e. the one your Joomla!™ site runs on. If you have defined extra
databases, you can select the appropriate database from the drop-down list in order to define filters for that database.

The middle area also contains two quick buttons:

• Exclude non-core tables. This option automatically filters out the tables whose name doesn't begin with your site's
prefix. These are usually tables which do not belong to the current Joomla! installation. However, be warned of
the major pitfall! If you host many Joomla! installations on the same database you'll have to use this option every
time you add a new extension on any of the other Joomla! sites. Alternatively, you can use the Regular Expressions
Database Tables feature of the Professional edition which can be set up to automatically deal with such installations.

• Reset all filters. Clicking this button will delete all database table filters.

The lower area consists of a single pane, showing the contents of the database: tables, views, triggers, stored procedures
and functions. Each row represents one database entity and consists of icons and text. The two leftmost icons represent
an exclusion type and can have three states: on (yellow background), off (white background), or force enabled (red

68


background). You can toggle between the on and off states by clicking on the icon. The force enabled state means
that this exclusion type is active (on) and forcibly enabled by another feature of Akeeba Backup, such as regular
expressions filters or simply denote that a specific filter is not applicable to this entity. For example, there is no point
skipping dumping the data of a view, or a stored procedure, as they have no data in the sense a table does. The third
icon, next to the database entity's name, represents the type of the entity, e.g. table, view, etc. You can hover your
mouse over the icon to get a tooltip describing the kind of this entity.

Important
The prefixes of the entities' names appear abstracted. If your site's prefix is jos_ (the default Joomla!™
setting), the table jos_users will appear as #__users. This is done to help you quickly identify the
tables your site runs on.

Each row of this pane consists of the following elements:

• Exclusion icon. If enabled, this database entity will not be backed up at all, i.e. it will be missing from the
database dump.

• Data exclusion icon. If enabled, only the structure of a table will be backed up, but not its contents. This is useful
e.g. for banner tracking or log tables. You need to keep their structure so that your site works, but you don't need to
back up tens of thousands of historical data rows you can certainly live without.

• Entity type icon. Depends on the entity type, e.g. if it's a view, table, procedure, etc.

• Entity name. The name of the entity, as described above.

When you click on the Tabular View link, the page radically changes format. Instead of a database browser pane,
you now have a grid.

Above the grid you have the Add new filter buttons:

• Exclude this. Completely skips backing up the given database entity.

• Do not backup its contents. Backs up only the structure but not the contents of the given table.

Each line of the grid displays the following information:

• The filter type. It can be one of:

• Exclude this. Completely skips backing up the given database entity.

• Do not backup its contents. Backs up only the structure but not the contents of the given table.

•

69



• The filter item itself. It is the abstracted database entity name which the filter row applies to. When we say "ab-
stracted" we mean that the site's prefix has to be replaced by #__.

When you click on the pencil icon, the filter item becomes an edit box. You can type in the new abstracted database
entity name and then click outside the edit box, or press Tab on your keyboard, to immediately save the changes. There
is no way to undo your changes.

4.3. Extension Filters
In our quest to provide the optimal feature set for web professionals, Akeeba Backup Professional includes the Exten-
sion Filters feature. Using it you can exclude any Joomla!™ extension (component, module, plug-in, language or tem-
plate) from the backup set, as if it was never installed! This allows web professionals to have a single "template site",
where every common extension is installed. Creating a new site's skeleton is as easy as taking a backup with a different
exclusion set. The benefit is that instead of maintaining multiple "template sites" - having to update Joomla!™ and the
installed extensions on every issued update - you only have to manage one master installation. It's sheer efficiency!

When you use this feature, Akeeba Backup Professional will automatically exclude the extension's files and/or direc-
tories, as well as any database entries pointing to it, effectively "cleaning" the backup from any traces of the extension.

The Extensions Filters page has four sub-pages, presented as links below the page's toolbar.

All sub-pages share the same toolbar icons. The Back icon gets you back to Akeeba Backup Professional's Control
Panel.

4.3.1. Components
The most evident use of the Extension Filters is to exclude components, the essential building blocks of any Joom-
la!-powered web site.

The Components exclusion page presents a list with all installed non-core components. Each component lists its State
and the Component name. When the State column contains a green check mark, it means that this module will be
included in the backup. A white X in a red circle means that the component will be excluded from the backup set.
Clicking on the status icon toggles its state.

70


Important
Akeeba Backup Professional is unable to automatically identify the database tables used by components.
Joomla! enforces no naming standard for components' tables and there is also no standard way to automatically
determine which tables are created by which component either. As a result, excluding components' database
tables is your responsibility . Do not ask us to automate this process. The only method to do so is to implement
a workaround for certain components only. This is not an optimal solution as it would mislead most users
into believing that Akeeba Backup Professional can do this for every component they might have installed,
which would simply be false.

4.3.2. Modules
From this page you can exclude any installed front-end or back-end non core module. The modules are displayed as
a flat list spanning three columns.

The first column, labelled State , indicates the filtering status of this item. A green check mark, it means that this
module will be included in the backup. A white X in a red circle means that the module will be excluded from the
backup set. Clicking on the status icon toggles its state.

The Module column contains the module's name.

The Area column indicates if this is a front-end (labelled as Public front-end ) or a back-end module (labelled as
Administrator back-end ). The front-end modules are always listed first.

4.3.3. Plug-ins
From this page you can exclude any installed front-end or back-end non core plug-ins. The plug-ins are displayed as
a flat list spanning four columns.

71


The first column, labelled State , indicates the filtering status of this item. A green check mark, it means that this plug-
in will be included in the backup. A white X in a red circle means that the plug-in will be excluded from the backup
set. Clicking on the status icon toggles its state.

The Plug-in column contains the plug-in's name. The Type column displays the plug-in type, as reported by Joomla!.

The Area column indicates if this is a front-end (labelled as Public front-end ) or a back-end plug-in (labelled as
Administrator back-end ). The front-end plug-ins are always listed first.

4.3.4. Languages
From this page you can exclude any installed, non-default language. This means that each and every language marked
as default for the back-end or the front-end will not be listed at all in this page! Languages are displayed in a list
spanning three columns.

language will be included in the backup. A white X in a red circle means that the language will be excluded from the

The Language column contains the language's ISO code, for example en-GB for British English.

The Area column indicates if this is a front-end (labelled as Public front-end ) or a back-end language (labelled as
Administrator back-end ). The front-end languages are always listed first.

4.3.5. Templates
From this page you can exclude any installed, non-default template. This means that each and every template marked
as default for the back-end or the front-end will not be listed at all in this page! Templates are displayed in a list
spanning three columns.

72


template will be included in the backup. A white X in a red circle means that the template will be excluded from the

The Template column contains the template's name.

The Area column indicates if this is a front-end (labelled as Public front-end ) or a back-end template (labelled as
Administrator back-end ). The front-end languages are always listed first.

4.4. RegEx Files and Directories Exclusion
Sometimes you know that you have to exclude files or directories following a specific naming pattern, but they are so
many that it's completely impractical going to the normal exclusion filters page and click them one by one. Or they are
scattered around the file system tree, making it extremely complex to track them down and exclude them. Wouldn't it
be nice to have an automated way to say, for example, "exclude all SVN directories from the backup"? Enter regular
expressions. What are those regular expressions? Let's see what Wikipedia has to say on the subject:

In computing, regular expressions, also referred to as regex or regexp, provide a concise and flexible
means for matching strings of text, such as particular characters, words, or patterns of characters.
A regular expression is written in a formal language that can be interpreted by a regular expression
processor, a program that either serves as a parser generator or examines text and identifies parts
that match the provided specification.
—"Regular expression" article [http://en.wikipedia.org/wiki/Regular_expression] from Wikipedia

In a nutshell, regular expressions allow you to quickly define filters which span multiple subdirectories and match
file or directory names based on a number of criteria. If you want a quick cheatsheet you can use, I suggest the Reg-
ular Expressions Cheat Sheet (V2) [http://www.addedbytes.com/cheat-sheets/regular-expressions-cheat-sheet/] from
AddedBytes.com. Some practical examples will be presented at the end of this section.

There are some special considerations experienced regular expressions users must have in mind:

• You are supposed to specify a full regular expression, including its opening and ending separators. So "^foo" is
invalid, but "/^foo/" and "#^foo#" are valid.

• Akeeba Backup supports an extension to the PCRE syntax. If you prefix the regex with an exclamation mark you
negate its meaning. So "/^foo/" will match all entities starting with "foo", whereas "!/^foo/" will match all entities
NOT starting with "foo".

73


• Akeeba Backup stores and parses your data as raw Unicode (UTF-8), provided that your database meets the mini-
mum requirement of MySQL 4.1 or greater. This eliminates the need to use the u suffix of regular expressions in
order to reference Unicode characters.

When it comes to files and directories exclusion filters in particular, you have to bear in mind:

• The path separator is always the forward slash, even on Windows. This means that c:wampwwwindex.php is
internally represented as c:/wamp/www/index.php. Therefore, all regular expressions must use the forward slash
whenever referencing a path separator.

• The filenames are always relative to the root. That's why you have to select a root before entering a regex filter. For
instance, the images/stories directory on the root of your Joomla!™ site is internally referenced as "images/stories".
You have to take this into account when writing regular expressions.

This page primarily consists of a grid view. Above the grid, you can find the Root Directory drop-down menu. Akeeba
Backup can define filters for the site's files or for each of the off-site directories separately. The default selection,
[SITEROOT], contains all filters pertaining to the main site's files. If you have defined off-site directories, you can
select the appropriate directory from the drop-down list in order to define filters for that directory.

The grid contains three columns:

Icons column You can perform the basic operation by clicking on this column's icons:

•


• Add (only on the last row). Clicking this icon adds a new row at the end of the list and
switches it to edit mode. You can select the type of the newly added filter.

Type The filter type defines what will happen when a directory or file matches the regex filter and can
be one of:





Filter Item This is the actual regular expression you have to write.

74


When you click on the pencil or add icons, the respective row enters the edit mode. In this mode, the filter type becomes
a drop-down list where you can select the type of this filter row. The filter item column also turns into an edit box so
that you can enter your filter definition. The icon column now contains two different icons:

• Diskette. When you click it, the changes will be saved.

• Cancel. When you click it, any changes will be cancelled and the row will resume its previous state.

In order to make sure that your filters match the directories and/or files you meant to, you can do so very easily. Just go
back to the Control Panel and click on the Files and Directory Exclusion button. The items filtered out by the regular
expressions filters will be automatically highlighted in red. You can browse through the file system structure to make
sure that only the items you really meant are being excluded.

4.4.1. Regular Expressions recipes for files and directories
No matter how good you are on writing regular expressions, it's always a good idea to have some recipes which serve
as a starting point for cooking your own.

1. Exclude AVI files in all directories (note: the i at the end causes the regex to match .avi, .Avi, .AVI, etc without
discriminating lower or upper case):

#.avi$#i

2. Exclude AVI files in your site's images directory and all of its subdirectories:

#îmages/(.*).avi$#i

3. Exclude AVI files in your site's images directory but not its subdirectories

#îmages/[^/]*.avi$#i

4. Exclude AVI files in your site's images/video subdirectory but not its subdirectories

#îmages/video/[^/]*.avi$#i

5. Exclude all files except for files ending in .php (note: the exclamation mark in the beginning is a custom Akeeba
Backup notation which negates the meaning of the following regular expression)

!#(?>.php$)#

6. Exclude all .svn subdirectories anywhere and everywhere in your site. The idea is to match everything which ends
in a slash (directory separator) and .svn, therefore it's a .svn subdirectory.

#/.svn$#

However, this won't match the .svn directory in your site's root, so you will have to add yet another filter:

#^.svn$#

This second filter matches only the .svn directory in your site's root.

75


4.5. RegEx Database Tables Exclusion
Sometimes you know that you have to exclude database tables which follow a specific naming pattern, but they are
so many that it's completely impractical going to the normal exclusion filters page and click them one by one. Or
you want to exclude everything which doesn't match a specific pattern (e.g. it's not part of the site's main database),
but the matching set dynamically and constantly changes over time, making it impossible to create an accurate filter
without lots of maintenance. Enter regular expressions. What are those regular expressions? Let's see what Wikipedia
has to say on the subject:

In computing, regular expressions, also referred to as regex or regexp, provide a concise and flexible
means for matching strings of text, such as particular characters, words, or patterns of characters.
A regular expression is written in a formal language that can be interpreted by a regular expression
processor, a program that either serves as a parser generator or examines text and identifies parts
that match the provided specification.
—"Regular expression" article [http://en.wikipedia.org/wiki/Regular_expression] from Wikipedia

In a nutshell, regular expressions allow you to quickly define filters which match table names based on a number
of criteria. If you want a quick cheatsheet you can use, I suggest the Regular Expressions Cheat Sheet (V2) [http://
www.addedbytes.com/cheat-sheets/regular-expressions-cheat-sheet/] from AddedBytes.com. Some practical exam-
ples will be presented at the end of this section.

There are some special considerations experienced regular expressions users must have in mind:

• You are supposed to specify a full regular expression, including its opening and ending separators. So "^foo" is
invalid, but "/^foo/" and "#^foo#" are valid.

• Akeeba Backup supports an extension to the PCRE syntax. If you prefix the regex with an exclamation mark you
negate its meaning. So "/^foo/" will match all entities starting with "foo", whereas "!/^foo/" will match all entities
NOT starting with "foo".

• Akeeba Backup stores and parses your data as raw Unicode (UTF-8), provided that your database meets the mini-
mum requirement of MySQL 4.1 or greater. This eliminates the need to use the u suffix of regular expressions in
order to reference Unicode characters.

When it comes to database table filters in particular, you have to bear in mind:

• All Joomla!™ tables have their prefix stripped and replaced by the standard #__ placeholder. So, if your database
prefix is jos_, jos_users is internally referenced as #__users. You must take this into account when writing
regex filters, as this is the name you will have to match!

• The prefix replacement is not made in Database Only backup modes (either main site database, or all databases).
As a result, you have to reference the tables by their full, normal name, e.g. jos_users.

• The examples at the end of this section apply to a full site backup scenario, where the replacement does take place.

76


This page primarily consists of a grid view. Above the grid, you can find the Root Directory drop-down menu. Akeeba
Backup can define filters for the site's main database or for each of the extra databases you may have defined. The
default selection, Site's main database, contains all filters pertaining to the main site's database, of course. If you have
defined extra databases, you can select the appropriate database from the drop-down list in order to define filters for
that database.

The grid contains three columns:

Icons column You can perform the basic operations by clicking on this column's icons:

•


• Add (only on the last row). Clicking this icon adds a new row at the end of the list and
switches it to edit mode. You can select the type of the newly added filter.

Type The filter type defines what will happen when a directory or file matches the regex filter and can
be one of:

• Exclude a table. Completely skips backing up tables whose names match the regular expres-
sion.

• Do not backup a table's contents. Only backs up the structure of tables whose names match
the regular expression, but not their contents.

Filter Item This is the actual regular expression you have to write.

When you click on the pencil or add icons, the respective row enters the edit mode. In this mode, the filter type becomes
a drop-down list where you can select the type of this filter row. The filter item column also turns into an edit box so
that you can enter your filter definition. The icon column now contains two different icons:

• Diskette. When you click it, the changes will be saved.

• Cancel. When you click it, any changes will be cancelled and the row will resume its previous state.

In order to make sure that your filters match the directories and/or files you meant to, you can do so very easily. Just
go back to the Control Panel and click on the Database Tables Exclusion button. The items filtered out by the regular
expressions filters will be automatically highlighted in red. You can browse through the database structure to make
sure that only the items you really meant are being excluded.

4.5.1. Regular Expressions recipes for database tables
No matter how good you are on writing regular expressions, it's always a good idea to have some recipes which serve
as a starting point for cooking your own.

1. Exclude non-Joomla! database tables:

/^(?>[^#]{1}|##|#_[^_]{1})/

2. Since nobody understood the previous filter, I have rewritten it in Akeeba Backup's compact proprietary notation
which uses the non-standard negation operator (exclamation mark):

77


!/^#__/

Much simpler, huh?

3. Exclude VirtueMart tables. We know that these tables have vm_ in their name after the table prefix, e.g.
jos_vm_foobar becomes #__vm_foobar, so you only need to filter #__vm.

/^#__vm_/

5. Automating your backup
Even though Akeeba Backup makes it very easy to take a backup of your Joomla!™ site, it still requires you to log
in to the site's backend, click on the Backup Now button and wait for the backup to finish. If you do this daily, it is a
drag. Our job is to automate your life, making repeated and time consuming procedures a breeze. To this end we offer
not just one, but 3 (yes, THREE!) different backup automation possibilities for Akeeba Backup.

Important
Only one of those options is available in the free (as in "free beer") Akeeba Backup Core release

5.1. Front-end backup, for use with CRON
Tip
This option is available in both the Akeeba Backup Core and Akeeba Backup Professional releases. You don't
need to subscribe to the Professional edition to use it.

The front-end backup feature is intended to provide the capability to perform an unattended, scheduled backup of
your site.

The front-end backup URL performs a single backup step and sends a redirection (HTTP 302) header to force the client
to advance to the next page, which performs the next step and so forth. You will only see a message upon completion,
should it be successful or not. There are a few limitations, though:

• It is not designed to be run from a normal web browser, but from an unattended cron script, utilizing wget or
cron as a means of accessing the function.

• The script is not capable of showing progress messages.

• Normal web browsers tend to be "impatient". If a web page returns a bunch of redirection headers, the web browser
thinks that the web server has had some sort of malfunction and stop loading the page. It will also show some kind
of "destination unreachable" message. Remember, these browsers are meant to be used on web pages which are
supposed to show some content to a human. This behaviour is normal. Most browsers will quit after they encounter
the twentieth page redirect response, which is bound to happen. Do not come to the Free Support Forum complaining
that Firefox, Internet Explorer, Chrome, Safari, Opera or another browser doesn't work with the front-end backup
feature. It was NOT meant to work by design.

• Command line utilities, by default, will also give up loading a page after it has been redirected a number of times.
For example, wget gives up after 20 redirects, curl does so after 50 redirects. Since Akeeba Backup redirects once
for every step, it is advisable to configure your command line utility with a large number of redirects; about 10000
should be more than enough for virtually all sites.

Most hosts offer a CPanel of some kind. There has to be a section for something like "CRON Jobs", "scheduled tasks"
and the like. The help screen in there describes how to set up a scheduled job. One missing part for you would be the
command to issue. Simply putting the URL in there is not going to work.

78


Warning
If your host only supports entering a URL in their "CRON" feature, this will most likely not work with Akeeba
Backup. There is no workaround. It is a hard limitation imposed by your host. We would like to help you,
but we can't. As always, the only barrier to the different ways we can help you is server configuration.

If you are on a UNIX-style OS host (usually, a Linux host) you most probably have access to a command line utility
called wget. It's almost trivial to use:

wget --max-redirect=10000 "http://www.yoursite.com/index.php?option=com_akeeba&

view=backup&key=YourSecretKey"

Of course, the line breaks are included for formatting clarity only. You should not have a line break in your command
line!

Important
Do not miss the --max-redirect=1000 part of the wget command! If you fail to include it, the backup will
not work with wget complaining that the maximum number of redirections has been reached. This is normal
behavior, it is not a bug.

Warning
Do not forget to surround the URL in double quotes. If you don't the backup will fail and it will be your fault!
The reason is that the ampersand is also used to separate multiple commands in a single command line. If
you don't use the double quotes at the start and end of the backup URL, your host will think that you tried to
run multiple commands and load your site's homepage instead of the front-end backup URL.

If you're unsure, check with your host. Sometimes you have to get from them the full path to wget in order for CRON
to work, thus turning the above command line to something like:

/usr/bin/wget --max-redirect=10000 "http://www.yoursite.com/index.php?option=com_akeeba&

view=backup&key=YourSecretKey"

Contact your host; they usually have a nifty help page for all this stuff. Read also the section on CRON jobs below.

Optionaly, you can also include an extra parameter to the above URL, &id=profile_id, where profile_id is
the numeric ID of the profile you want to use for the backup. If you don't specify this parameter, the default backup
profile (ID=1) will be used. In this sense, the aforementioned URL becomes:

/usr/bin/wget --max-redirect=10000 "http://www.yoursite.com/index.php?option=com_akeeba&

view=backup&key=YourSecretKey&profile=profile_id"

wget is multi-platform command line utility program which is not included with all operating systems. If your
system does not include the wget command, it can be downloaded at this address: http://wget.addictivecode.org/
FrequentlyAskedQuestions#download. The wget homepage is here: http://www.gnu.org/software/wget/wget.html.
Please note that the option --max-redirect is available on wget version 1.11 and above.

Important
Using a web browser (Internet Explorer, Firefox, ...) or wget version 1.10 and earlier will most probably
result into an error message concerning the maximum redirections limit being exceeded. This is not a bug.

79


Most network software will stop dealing with a web site after it has redirected the request more than 20
times. This is a safety feature to avoid consuming network resources on misconfigured web sites which have
entered an infinite redirection loop. Akeeba Backup uses redirections creatively, to force the continuation of
the backup process without the need for client-side scripting. It is possible, depending on site size, Akeeba
Backup configuration and server setup, that it will exceed the limit of 20 redirections while performing a
backup operation.

Warning
The ampersands above should be written as a single ampersand, not as an HTML entity (&). Failure
to do so will result in a 403: Forbidden error message and no backup will occur. This is not a bug, it's the
way wget works.

5.1.1. A PHP alternative to wget
As user DrChalta pointed out in a forum post, there is an alternative to wget, as long as your PHP installation has
the cURL extension installed and enabled. For sterters, you need to save the following PHP script as backup.php
somewhere your host's cron feature can find it. Please note that this is a command-line script and needn't be located
in your site's root; it should be preferrably located above your site's root, in a non-web-accessible directory.

The script below is a modification over DrChalta's original script, taking into account changes made in later versions
of our software. In order to configure it for your server, you only have to change the first three lines.

<?php
define('SITEURL', 'http://www.example.com'); // Base URL of your site
define('SECRETKEY', 'MySecretKey'); // Your secret key
define('PROFILE',1); // The profile's ID

// ====================== DO NOT MODIFY BELOW THIS LINE ======================
$curl_handle=curl_init();
curl_setopt($curl_handle,CURLOPT_URL,
SITEURL.'/index.php?option=com_akeeba&view=backup&key='.
SECRETKEY.'&profile='.PROFILE);
curl_setopt($curl_handle,CURLOPT_FOLLOWLOCATION,TRUE);
curl_setopt($curl_handle,CURLOPT_MAXREDIRS,10000); # Fix by Nicholas
curl_setopt($curl_handle,CURLOPT_RETURNTRANSFER,1);
$buffer = curl_exec($curl_handle);
curl_close($curl_handle);
if (empty($buffer))
echo "Sorry, the backup didn't work.";
else
echo $buffer;
?>

Where www.yoursite.com and YourSecretKey should be set up as discussed in the previous section.

Warning
The ampersands above should be written as a single ampersand, not as an HTML entity (&). Failure
to do so will result in a 403: Forbidden error message and no backup will occur. This is not a bug, it's the
way wget and PHP work.

In order to call this script with a schedule, you need to put something like this to your crontab (or use your host's
CRON feature to set it up):

80


0 3 * * 6 /usr/local/bin/php /home/USER/backups/backup.php

Where /usr/local/bin/php is the absolute path to your PHP command-line executable and /home/US-
ER/backups/backup.php is the absolute path to the script above.

If you set up your cron schedule with a visual tool (for example, a web interface), the command to execute part is "/
usr/local/bin/php /home/USER/backups/backup.php".

Thank you DrChalta for this wonderful tip!

5.1.2. Using the front-end backup in SiteGround CRON jobs
As one of our users pointed out in the support forum, finding the correct command to issue for the CRON job is tricky.
What he writes applies not only to his host, SiteGround, but many other commercial hosts as well. We'll simply quote
our user, bzcoder.

In the CPanel for SiteGround there is a cronjob option, you create a cronjob using that and use:

curl -b /tmp/cookies.txt -c /tmp/cookies.txt -L --max-redirs 1000 -v "<url>"

as your command.

Replace <url> with your backup URL. Make sure to use the initial url displayed on the backend NOT the final URL
when you run the backup manually (been there, done that) - when you do that you end up with a url that doesn't work
because of the extra parameter used in continuing the backup process.

5.2. Native CRON script
Tip
This option is only available in the Akeeba Backup Professional releases. You need to subscribe to the Pro-
fessional edition to use it.

If you have access to the command-line version of PHP, Akeeba Backup Professional includes an even better - and
faster - way of scheduling your backups. All Akeeba Backup Professional releases include the file administra-
tor/components/com_akeeba/backup.php, which can be run from the command-line PHP interface (PHP
CLI). In contrast with previous releases, it doesn't require the front-end backup in order to work; it is self-contained,
native backup for your Joomla!™ site, even if your web server is down!

In order to schedule a backup, you will have to use the following command line to your host's CRON interface:

/usr/local/bin/php /home/USER/webroot/administrator/components/com_akeeba/backup.php

where /usr/local/bin/php is the path to your PHP CLI executable and /home/USER/webroot is the abso-
lute path to your web site's root. You can get this information from your host.

The backup script accepts three optional parameters:

• -profile profile_id allows you to select which backup profile you would like to use for the scheduled backup.
The profile_id is the numeric profile ID you can see in your Control Panel page.

• -description "Your description" allows you set a backup description different than the default. Do not
forget to enclose your description in double quotes, or this parameter will not work! Since Akeeba Backup 3.1
the description supports Akeeba Backup's file naming "variables", e.g. [SITE], [DATE] and [TIME]. These
variables are documented in the Output Directory configuration option's description. This allows you to use them
in conjunction with this parameter to provide flexible backup descriptions.

81


• -override "keyname=value" allows you to override profile configuration variables. This parameter can appear an
unlimited number of times in the command line. It can be used, for example, to provide the username and password
to your cloud storage service in the command line, without having to store it in the backup profile's configuration,
therefore never storing it in database and hiding it from other administrators. Please take a look at the "Overriding
configuration variables" subsection for more information.

In order to give some examples, I will assume that your PHP CLI binary is located in /usr/local/bin/php - a
common setting among hosts - and that your web site's root is located at /home/johndoe/httpdocs.

1. Backup with the default profile (ID = 1) and default description:

usr/local/bin/php /home/johndoe/httpdocs/administrator/components/com_akeeba/backup.php

2. Backup with profile number 2 and default description:

-profile=2

3. Backup with the default profile (ID = 1) and a description reading "My automated backup":

-description="My automated backup"

4. Backup with profile number 2 and a description reading "My automated backup":

-profile=2 -description="My automated backup"

It goes without saying that the line breaks are for readability only. You should not include line breaks in your command
line.

Special considerations:

• Most hosts do not impose a time limit on scripts running from the command-line. If your host does and the limit
is less than the required time to backup your site, the backup will fail. We are working on a workaround to allow
operation even within such time constraints.

• This script is not meant to run from a web interface. If your host only provides access to the CGI or FastCGI PHP
binaries, backup.php will not work with them. The solution to this issue is tied to the time constraint above. The
workaround we're planning will solve both issues.

• Some servers do not fully support this backup method. The usual symptoms will be a backup which starts but
is intermittently or consistently aborted in mid-process without any further error messages and no indication of
something going wrong. In such a case, trying running the backup from the back-end of your site will work properly.
If you witness similar symptoms please use the Alternative CRON Script, outlined in the next section.

5.2.1. Setting up a CRON job on cPanel
Go to your cPanel main page and choose the CRON Jobs icon from the Advanced pane. In the Add New CRON Job
box on the page which loads, enter the following information:

Common Settings Choose the frequency of your backup, for example once per day.

Command Enter your backup command. Usually, you have to use something like:

/usr/bin/php5-cli /home/myusername/public_html/administrator/components/com_a

82


where myusername is your account's user name (most probably the same you use to login to
cPanel) and YourProfileID is the numeric profile number you want to use for your backup
job. Do note the path for the PHP command line executable: /usr/bin/php5-cli. This is
the default location of the correct executable file for cPanel 11 and later. Your host may use a
different path to the executable. If the command never runs, ask them. We can't help you with
that; only those who have set up the server know the changes they have made to the default setup.

Finally, click the Add New Cron Job button to activate the CRON job.

5.2.2. Overriding configuration variables
Since Akeeba Backup 3.1 the Native CRON Script allows you to override or supply missing configuration variables
in the command line. This is especially useful for security reasons. One security issue with the cloud storage service
integration is that other administrators can peek at Akeeba Backup's configuration and read the username, password
or API keys used to access the cloud storage service. You can, however, leave these fields blank in the configuration
and supply their values in the command line.

Overriding a configuration variable requires knowing its key name. The key names are represented in dot-format,
i.e. engine.postproc.dropbox.email for DropBox's email field. Determining the key name is quite easy, as
they are stored in INI files throughout the component's back-end. The first location you should look at is adminis-
trator/components/com_akeeba/akeeba/core, where you will find four INI files with general settings.
Inside the administrator/components/com_akeeba/akeeba/engines and administrator/com-
ponents/com_akeeba/akeeba/plugins/engines directories and their subdirectories you will find one INI
file per engine.

In order to save you from trouble, here are the most useful key names for providing cloud storage engine credentials.
The names are designed to be self-explanatory.

Amazon S3 • engine.postproc.s3.accesskey

• engine.postproc.s3.secretkey

RackSpace • engine.postproc.cloudfiles.username
CloudFiles
• engine.postproc.cloudfiles.apikey

DropBox • engine.postproc.dropbox.email

• engine.postproc.dropbox.password

Microsoft Win- • engine.postproc.azure.account
dows Azure
BLOB Storage • engine.postproc.azure.key

Remote FTP • engine.postproc.ftp.host
server
• engine.postproc.ftp.port

• engine.postproc.ftp.user

• engine.postproc.ftp.pass

Applying them on the command line is easy. Take this command line as an example:

-profile=2 -description="My automated backup"

83


-override "engine.postproc.dropbox.email=foobar@example.com"
-override "engine.postproc.dropbox.password=VerySecretPassword"

In this case, we are telling the backup script to use the backup Profile with ID=2, give the backup description of "My
automated backup" and then supply the DropBox email and password.

Important
The values of the override parameters MUST be enclosed in double quotes, otherwise the operating system
will not pass them back to the backup.php script.

Finally, it should be noted that you can use the command-line override feature to do more tricky configuration over-
rides, for example turning off the archive splitting or using different backup output and temporary directories to en-
hance your security. If it's something you can do in the Configuration page of the component, you can also do it using
command line overrides.

5.3. Alternative CRON script
Tip
This option is only available in the Akeeba Backup Professional releases. You need to subscribe to the Pro-
fessional edition to use it.

On some hosts it is impossible to use the native CRON script outlined in the previous section. On such hosts the CRON
script will get aborted if it is using too much CPU time, or if the system load exceeds a value predefined by your
host company. In order to accomodate for these hosts, Akeeba Backup Professional includes an alternative CRON
script. The alternative CRON script performs the backup by using the front-end backup feature of Akeeba Backup.
The alternative CRON script is located in administrator/components/com_akeeba/altbackup.php,
and must be run from the command-line PHP interface (PHP CLI).

In order to schedule a backup, you will have to use the following command line to your host's CRON interface:

/usr/local/bin/php /home/USER/webroot/administrator/components/com_akeeba/altbackup.php

where /usr/local/bin/php is the path to your PHP CLI executable and /home/USER/webroot is the abso-
lute path to your web site's root. You can get this information from your host.

The backup script accepts only one optional parameters:

• -profile profile_id allows you to select which backup profile you would like to use for the scheduled backup.
The profile_id is the numeric profile ID you can see in your Control Panel page.

In order to give some examples, we will assume that your PHP CLI binary is located in /usr/local/bin/php -
a common setting among hosts - and that your web site's root is located at /home/johndoe/httpdocs.

1. Backup with the default profile (ID = 1)

usr/local/bin/php /home/johndoe/httpdocs/administrator/components/com_akeeba/altbackup.ph

2. Backup with profile number 2

usr/local/bin/php /home/johndoe/httpdocs/administrator/components/com_akeeba/altbackup.ph
-profile=2

It goes without saying that the line breaks are for readability only. You should not include line breaks in your command
line.

84


Special considerations:

• Most hosts do not impose a time limit on scripts running from the command-line. If your host does and the limit is
less than the required time to backup your site, the backup will fail.

• This script is not meant to run from a web interface. If your host only provides access to the CGI or FastCGI PHP
binaries, backup.php will not work with them. The solution to this issue is tied to the time constraint above. The
workaround we're planning will solve both issues.

• You must enable the front-end backup feature of your Akeeba Backup Professional instalaltion and assign a "secret
key" for it. This is possible by going to the Akeeba Backup Professional's Control Panel page and clicking on the
Parameters button on the top right corner of the toolbar. You will find the front-end backup options further down
the Parameters page.

• Before using the alternative CRON script for the first time, you must visit the Akeeba Backup's Control Panel page
at least once. Since the command-line version of PHP used to run the backup is oblivious to the domain name used
by your site, we have to cache this information. Caching of this information occurs as soon as you visit the Control
Panel page. The host name is absolutely required in order for the script to be able to access your Akeeba Backup
installation's front-end backup feature.

• Your host must support one of the three methods used by the helper script to access your front-end backup URL:

1. The PHP cURL module.

2. The fsockopen() method

3. The fopen() URL wrappers

If none of these methods is available, the backup will fail.

• Your host may have a firewall setup which doesn't allow the CRON script to access the front-end backup URL.
In such a case, the backup will consistently fail without a new log file being produced and without a backup entry
being written to the database. You will have to contact your host so that they can allow the script to access the front-
end backup URL. Do note that despite the alternative CRON script and your site running on the same server, the
firewall restriction might still be in place. This is counter-intuitive, but we've seen this happening on man hosts.

If you are seeking assistance in our forums regarding a failed CRON job, please indicate if and which of these steps
you have already tried. Not doing so will hinder our ability to help you in a timely manner.

5.3.1. Setting up a CRON job on cPanel
Go to your cPanel main page and choose the CRON Jobs icon from the Advanced pane. In the Add New CRON Job
box on the page which loads, enter the following information:

Common Settings Choose the frequency of your backup, for example once per day.

Command Enter your backup command. Usually, you have to use something like:

/usr/bin/php5-cli /home/myusername/public_html/administrator/components/com_a

where myusername is your account's user name (most probably the same you use to login to
cPanel) and YourProfileID is the numeric profile number you want to use for your backup
job. Do note the path for the PHP command line executable: /usr/bin/php5-cli. This is
the default location of the correct executable file for cPanel 11 and later. Your host may use a
different path to the executable. If the command never runs, ask them. We can't help you with
that; only those who have set up the server know the changes they have made to the default setup.

85


Finally, click the Add New Cron Job button to activate the CRON job.

6. Miscellaneous features
Some features do not fall under any other category. We decided to reserve a place in our manual for these lesser-known
but very useful features.

6.1. Lite mode for cell phones, PDAs, MIDs, etc.
In contrast to the classic front-end backup which is meant primarily for backup automation, the "Light Mode" is meant
for performing site backups from a browser, without even having to log in to the administrator backend. It goes further
than that, enabling you to backup your site from any web-capable device, including Pocket PC's, netbooks, your iPod
or even your cell phone!

The "Light Mode" requires that your browser has at least rudimentary support for Javascript. Most recent web-capable
devices, including low end cellphones, fulfill this requirement. This feature has been tested on Pocket Internet Explorer
running on a Mio P560 and a HTC Touch, as well as Sony Ericsson and Nokia mobile phones. We have tested it with
mobile WebKit-based browsers, such as those supplied with Android phones and iPhones. It also works on devices
running Opera Mobile.

The "light mode" performs user authentication using the front-end backup's secret word and allows you to select the
backup profile. It does not give you, however, the option to download your backup. If you want to do so, you'll either
have to log in to the administrator back-end of your site, or use other means - e.g. FTP client software.

In order to access the "Light Mode" you have to visit the URL:

http://www.example.com/index.php?option=com_akeeba&view=light

Just replace www.example.com with the actual domain name and path to your site!

Important
The front-end backup feature option must be enabled from the Parameters button in the Control Panel. If it's
not, you'll get an "Access Denied" message.

In the first page you get upon accessing this URL just select the backup profile from the drop down list and enter your
secret word in the text box, then click on the Backup Now button. The backup process will proceed automatically,
giving you a cut-down version of the backup progress information you would get from the backend backup mode.
Akeeba Backup advances through the pages automatically, using Javascript.

6.2. System Restore Points
Since Akeeba Backup 3.3.a1 we support an exciting new feature called System Restore Points. In order to let you
understand what it is, let's start with a simple exercise.

Imagine that you have a site on which you've spent countless hours configuring, say, a web shop component. One
day you see that there is an update available. It's a minor update, so you decide to not take a backup (it takes several
minutes, you're too impatient to wait for it) and go ahead with the update. Unfortunately, the update completely breaks
your site. You try to re-install the previous version of your web shop component but, due to database changes, it no
longer works. Your latest backup is from several weeks ago. You're stuck. You have to spend countless hours, all over
again, losing sales in the meantime, to get your site working properly again.

Wouldn't it be very cool if Joomla! was able to backup the extension you're upgrading (all of its files and data) when you
are upgrading it? Wouldn't it be very cool if you could just roll back to the previous state of the component, from that

86


automatic backup, with a single click? It sounds like science fiction. No other CMS does that. It must be impossible to
do, right? WRONG! We present you our System Restore Point feature which does that and is available even in the free
of charge Core release of our software. And it's fully compatible with Joomla! 1.5 and later versions, out of the box!

How does it work?
All you have to do is to enable the "System - System Restore Points" plugin which is installed with Akeeba Backup
3.3.a1 or later. By default, the plugin is automatically enabled when you install Akeeba Backup. This plugin allows
us to intercept your interaction with Joomla!'s Extension Installer, providing our enhanced version without modifying
your Joomla! core files.

All you have to do is install a component upgrade, just like you always did. Our enhanced extensions installer will
see that and before Joomla! installs it, Akeeba Backup will take a backup of the extension files and database contents.
After that, the original Joomla! extensions installer will take care of the extension's installation. So simple!

What if you don't want to take a System Restore Point? That's very simple as well. Just click on the Back to regular
installer link on the bottom of the page to deactivate the System Restore Point temporarily, or unpublish the plugin
to deactivate System Restore Points permanently.

How do I restore a System Restore Point?
Just go to Akeeba Backup, Administer Backup Files. You will see two links below the toolbar, Backups and Restore
Points. Just click on Restore Points to see a list of all restore points. Select the one you want and click on Roll Back.
That's all!

If you want to reclaim free space on your host, just select the restore points which are no longer relevant and click
on Delete.

Where are restore points stored?
System Restore Point backup archives are always stored in the Output Directory of the default backup profile (profile
#1). By default, that is administrator/components/com_akeeba/backup. You can change it by editing
the default profile's configuration. All restore points are named restore-point-*.jpa to make it easier for you
to find them with, say, an FTP client.

How can I make my extension compatible with System Restore
Points?
All you have to do is to add a small snippet of XML inside your extension's XML manifest. We provide up-to-date doc-
umentation for developers in a dedicated page on our site [https://www.akeebabackup.com/documentation/item/1127-
system-restore-points.html]. If you get stuck, do not hesitate to contact us, as instructed on the end of that page.

87

Chapter 4. Miscellaneous Extensions
1. Akeeba Backup Notification Module
The "Akeeba Backup Notification Module" is an administrator module that installs an icon which notifies you of the
backup status. It's mission is rather simple: it checks the latest backup record and if it's a failed backup or if it was
taken a long time ago (configurable) it tells you that the backup is out of date. Clicking on the icon takes you directly
to the Backup Now page of Akeeba Backup.

In order to configure the module's behaviour, just go to your Module Manager and click on the Administrator link
(Joomla! 1.5) or click on the Site drop-down and select Administrator (Joomla! 1.6). Find the "Akeeba Backup Noti-
fication Module" entry from the list and click on it. The available options are:

• Enable warning icon to show the backup is out of date icon (otherwise it's always just a "Backup Now" icon
without a warning sign)

• Warn on failed backups. When enabled, if the last backup is marked as failed, the icon will be a warning sign
that reminds you to take a new backup.

• Stale backup time, in hours. If the last successful backup (in any profile) was taken more than this many hours
ago, the warning icon will appear.

Please note that the icon does not look for a specific backup type (profile). It just checks the last backup record, no
matter which profile or backup method was used.

2. The plugins powering the One Click Update
feature
Akeeba Backup 3.3.a1 and later comes with two very important plugins, System - One Click Actions and System
- Akeeba Update Check. When both are enabled, Akeeba Backup will periodically check for new versions of itself
without having you to log in to your site's back-end; it will perform those checks as long as your site receives about
ten visits every day at minimum.

When a new version is detected, it will send an email to all Super Administrators on your site notifying you of the fact.
But we go one step further than simply notifying you of the availability of the new version. Clicking on the link found
in the update notification email you are automatically logged in to your site and forwarded to the Akeeba Backup's
Live Update page, which starts installing the new version automatically (the link is valid only for 24 hours since the
email was sent and can only be used once). So, basically, you click on a link and Akeeba Backup updates itself. One
click updates are no longer science fiction!

This feature is available in both Akeeba Backup Core and Akeeba Backup Professional and is fully compatible with
Joomla! 1.5 and 1.6. The only prerequisite is that your site supports Akeeba Backup's Live Update feature. You can
check this by visiting Akeeba Backup's Control Panel page. If it says that you already have the latest version or that
an update is available, your server supports Live Update. If it says that "Live Update is not supported" then the one-
click update will not work.

Wow! That's awesome! I am a developer and would like
to do the same thing for my components. Is it possible?
Yes! It's all distributed under the GPLv3 and can be reused with any component/module/plugin/template using the
same license. For starters, you can dissect the two plugins. It's very easy to figure out how they work. In fact, it's so

88

Miscellaneous Extensions

darn simple that will make you wonder why this wasn't in use for decades already. If you have questions, contact us
through our site's Contact Us page or by posting on our forum and we will help you. That's the spirit of Free and Open
Source Software: spreading knowledge.

89

Chapter 5. Restoring backups
1. Overview of the restoration process
The restoration process consists of three individual steps:

1. Getting your files off the archive and into the server. This usually has two sub steps:

a. Extracting the files from the archive

b. Uploading the files to your server

2. Running the actual restoration process

3. Removing the installation script from your server

As you may have observed, we did not talk at all about using or installing Joomla!™ in the restoration process. In
fact, we strongly discourage you from installing Joomla!™ prior to the restoration. The backup archive has everything
you need: your database; your site's files (including the Joomla!™ CMS); and the PHP script to restore your database
and re-configure your site - in case you moved to another server or subdomain. You can use the backup archives to
perform bare metal restoration of your site. Even if the server which used to host you blows up and vanishes in a black
smoky cloud, your entire site is safely stored in the backup archive.

Do note that this section does not cover the Integrated Restoration. If you need to use it, please refer to the relevant
chapter.

The following sections will present the different alternatives to each of the previous three steps and coach you through
a site's restoration.

2. Getting the files on your server
There are two broad venues for getting the files off the backup and into the server. The first way is to extract the backup
file locally, then use your FTP client to upload them to the site. This is the safest way to do so, but it's also the slowest.
Transferring 4,000 to 10,000 files - that's how many files there are in a mid-sized Joomla!™ site - by FTP is a mighty,
lengthy, boring procedure. The FTP protocol was designed to transfer a few large files at a time. When confronted
with thousands of files, the overhead of processing them is higher than the actual file data upload time.

This brings us to our second venue, extracting the archive files directly on the server. Using this method we upload the
backup archive itself to the server, then use a PHP script (called Akeeba Kickstart; available free of charge from our
website) to extract it directly on this server. The major benefit is time. The FTP protocol is extremely well-suited for
bulky uploads. Your upload time of a single, big file is only determined by your available bandwidth. The drawback
of this approach is that, depending on file and directory permissions, you may have to tweak the process to make it
work smoothly.

As the developer of Akeeba Backup, I suggest investing the time to master the second way, unless you are on a very
strict deadline. Use the individual files upload as your fallback plan, if you can't get Akeeba Kickstart to work on
a specific server. I'll be honest with you. I have not used the individual files upload ever since I created Kickstart.
I have much better things to do with my time than waiting two hours for a small site to upload when I can do it in
less than 15 minutes.

2.1. Uploading individual files
This is the easiest, but most time consuming, way to get your files on the server.

90

Restoring backups

First, you'll have to extract the backup archive on your local PC. If you have a ZIP backup archive you can do so
using your favorite ZIP extraction software, such as 7-Zip. If you get extraction errors, such as CRC errors, or an
indication that your archive may be corrupt, it doesn't necessarily mean that you have a bad archive. It might just be
that the host of the site you took the backup from didn't support all the necessary features for Akeeba Backup to create
standards-compliant ZIP archives. In this case, we urge you to use Akeeba eXtract Wizard, available free of charge
from the Download section of our website, and extract the ZIP archive using this software. If your backup archive is
in the JPA format, the only way to extract it is the Akeeba eXtract Wizard.

Note
If you are using split archives (default), the ZIP files produced with Akeeba Backup will only be readable by
PKZIP for Windows and WinZIP. Other archive handling software such as 7-ZIP, WinRAR, Linux' unzip or
your host's unzip feature may not work. This is a limitation of the library (InfoZip library) these applications
are using, not a bug in Akeeba Backup. The ZIP archives produced by Akeeba Backup are routinely tested
against PKZIP, the software created by the inventors of the ZIP format, for validity.

Warning
If you get a message that your archive is corrupt, of an invalid format or that Akeeba eXtract Wizard can't
read data from the archive, you have a broken backup. The most common cause for broken backup files is
the way you transfer them to your PC. If you want a trouble free restoration experience, always use FTP in
BINARY transfer mode to transfer the backup archives from the server to your local PC. As a precaution,
selectively test extract some of your backup files to make sure that they have no problem. UNTESTED
BACKUP ARCHIVES ARE AS GOOD AS HAVING NO BACKUP AT ALL. Be paranoid about testing
your backup archives. It may as well be the difference between saving or losing your site one day.

Once you have extracted the backup archive, you have a bunch of files inside a directory on your PC. Take a good
look at them. Is there a file named .htaccess (note the dot in the beginning) inside this directory? If the answer is
yes, please rename it to htaccess.bak before continuing.

Now use your favorite FTP client - I recommend FileZilla - to upload all those files to your server. Once you do, visit
the URL http://www.yoursite.com/installation/index.php, where www.yoursite.com is your
own site's domain, of course! Then proceed to Using the Akeeba Backup Installer section.

2.2. Extracting on the server
We have created a nifty web-based backup extraction utility called Akeeba Kickstart. It is able to extract your backup
archive directly on your server, using normal PHP file writing functions or FTP mode. For more information, please
refer to the Kickstart documentation or our Quick Start Guide. This section is just a quick overview of that software.

Note
Make sure that you have already downloaded Kickstart on your local PC and unzipped it.

First things first. You will have to upload your backup archive on your server. To be more precise, upload the backup
archive to your site's root directory. On most servers it's a directory named www, public_html, httpdocs, ht-
docs or http_docs. If in doubt, ask your host. Upload using your FTP client, but make sure that you are using the
BINARY transfer mode. If you don't, you are wasting your time; the archive will become corrupt during transfer and
you'll have to re-upload. If the archive file is already on a subdirectory of the server, you just have to copy it to the
site's root directory. Consult the documentation of your FTP client for more information on doing so. Usually it's a
drag and drop operation, but different FTP clients use different methods.

Then upload the files from the Kickstart.zip package. Do not upload the Kickstart.zip itself! You really need nothing
but kickstart.php itself. The rest of the files are just translations. You can skip them if you like.

91

Restoring backups

In order to launch the Kickstart wizard, you simply have to visit http://www.example.com/mysitefolder/
kickstart.php , replacing www.example.com with your server's host name and mysitefolder with what-
ever folder you uploaded your files into. If you have uploaded to your server's root, you should omit both mysite-
folder and its trailing slash.

For example, if you uploaded the files to a folder named joomla and your host name is www.mygreatsite.com,
location to put in your browser's address bar is http://www.mygreatsite.com/joomla/kickstart.php
. If you uploaded your files to the web server root and the host name is www.mybigsite.com then the location in
the address bar should be http://www.mybigsite.com/kickstart.php.

The initial page of Kickstart consists of the basic configuration parameters it will use during the archive extraction
process. On the top of the page there is a drop down list (combo box) containing all the JPA and ZIP archives it has
found in the same directory as the script during the script's start up. You must choose the correct one. Conveniently,
it pre-selects the first archive found, since most users will only have one archive present anyway.

The next configuration group, labelled Extraction Method, allows you to specify how the extracted files are going
to be written to their final location.

• The Write directly to files option uses the quickest and most conservative approach of writing the files directly
from within the PHP code. However, it might impossible to use if there are insufficient permissions, PHP Safe Mode
is activated or there are other server-specific restrictions. Kickstart will attempt to detect this kind of errors and warn
you just before the extraction process begins.

• The Use FTP option will attempt to use FTP access to write the extracted files to disk, using the FTP options you
can configure on the text box below.

Important
FTP mode requires normal write access to the directory where kickstart.php resides in. This is be-
cause each file gets extracted as a temporary file in this folder first and is then "uploaded" using FTP. This
is a limitation of PHP not (widely) supporting appending file writes using FTP.

Some restrictions apply to the FTP mode. You can only use plain FTP servers, but not any of the FTP variants such
as SFTP, FTPS, etc. If you try to do something like that, Kickstart will not be able to connect to the FTP server.

The FTP host must be given as a domain or IP address, with a protocol prefix. Valid examples are "local-
host", "ftp.example.com", "example.com", "192.168.0.1". However, using something like "ftp://localhost", "ftp://
example.com/var/www", "ftp://user@pass:example.com/var/www" will not work. The FTP connection parameters
(username and password) are to be typed in in the respective fields below the FTP host.

A note on what the initial directory is and how to set it up. It is the absolute FTP path where kickstart.php resides
in and where your site's root will be located after the restoration is over. In order to find it, you can use FileZilla or
any other FTP software. Just connect to your site, navigate to the directory where kickstart.php and your archive are
and copy the FTP path. In FileZilla's default theme this is located above the right-hand directories pane (showing
the directories on your FTP server). It usually looks something like /public_html or /httpdocs or /www, but this
basically depends on your host so my guess is as good as any. Just copy this whole string (including the leading
slash, if any!) and copy it to the initial directory field of Kickstart.

The final settings group is the "Fine Tuning". Here you can define various parameters which influence the way
Kickstart operates:

• Maximum archive chunk to process per step (Bytes). Kickstart splits the extraction process in smaller chunks,
in order to avoid server timeouts. There are two conditions which define a chunk: the minimum amount of data
extracted and the maximum number of files extracted. This option controls the former condition and is expressed
in bytes. The default value, 1024768, means that Kickstart will try to extract at least 1Mb of data before concluding
the chunk.

92

Restoring backups

Setting this to higher values will speed up the process, because it creates less chunks and, therefore, less time has
to be spent rendering the extraction process and wasted on network operations to and from the browser. On the
downside, on slower hosts it might cause a timeout.

• Maximum number of files to process at once. Kickstart splits the extraction process in smaller chunks, in order
to avoid server timeouts. There are two conditions which define a chunk: the minimum amount of data extracted
and the maximum number of files extracted. This option controls the latter condition and is expressed in number
of files. The default values, 40, means that at most 40 files will be extracted, even if their total size is less than
MAXBATCHSIZE bytes.

Setting this to higher values will speed up the process, because it creates less chunks and, therefore, less time has
to be spent rendering the extraction process and wasted on network operations to and from the browser. On the
downside, on slower hosts it might cause a timeout.

• Minimum execution time per step (milliseconds). Kickstart 2.4 onwards uses the same anti-DoS solution com-
patibility scheme as the Akeeba Backup component. This means that it tries to make each page load last at least
as many milliseconds as this setting. This allows Kickstart to avoid failing with 403 Forbidden error messages if it
runs too fast on your server. The default value, 2000, means that Kickstart's page loads will last at least 2 seconds
(2000 milliseconds divided by 1000 milliseconds per second equals 2 seconds). While this is a sane value for very
sensitive hosts, it will slow Kickstart down considerably on faster hosts. In such a case, you may try lowering this
value to 1000, 500 or even lower. Setting it to 0 will result in Kickstart running at full speed. This is no exact science,
so you may want to experiment with it a bit. According to my experience values around 600 yield a perfect balance
between speed and avoiding 403 Forbidden error messages.

• Temporary directory. Kickstart needs a writable temporary directory for its normal operation. By default, it is set
to be the same directory as the one Kickstart is located in. If for any reason this directory is not writable (for example,
FTP mode is required to write to that directory) you can manually override the temporary directory location using
this setting. For instance, if you want to set the temporary directory location to /tmp (a common writable temporary
directory in Linux systems) change this setting to /tmp.

Another useful tip, especially if neither the Direct File Writes nor the FTP modes are working, is to create a directory
named kicktemp inside your site's root directory with your favorite FTP client and set its permissions to 0777 (read,
write and execute to user, group and "others"). Then, change this setting by appending kicktemp to it. For instance,
on Windows hosts this setting might read something like C:wampwwwtest; modify it to read C:wampwww
testkicktemp. On Linux, Solaris, Mac OS X, FreeBSD and other UNIX variants hosts it will read something
like /home/myuser/httpdocs; modify it to read /home/myuser/httpdocs/kicktemp.

This trick only works if PHP Safe Mode is not enabled on your account. If the PHP Safe Mode is enabled, there
is no known way to use Kickstart, except than begging your host to change the owner of your site's root to be the
same as the user the web server runs under. Do keep in mind that this approach is not very secure and the ownership
should be reverted after the restoration process is over.

• Pass-through chunk size while extracting large files (bytes) . When Kickstart is extracting files stored uncom-
pressed in the archive (large files), it does so by reading a chunk of the uncompressed data to memory, then writing
it to disk. It repeats this procedure until all file data has been processed.

The most time consuming part of this process is writing to the disk. Increasing the chunk's size results in fewer write
operations and less time is consumed, at a risk of running out of memory. This setting is expressed in bytes and the
default value, 1024768, represents 1Mb of information. You can usually set it to 6200000, or even higher depending
on your PHP configuration settings, without any side effects, greatly increasing Kickstart's performance, especially
if you have a large number of big files in your backup archive.

When you are done setting the options, please click the large, green Start button. The extraction process should now
start.

93

Restoring backups

Note
Some steps involving large files might take a while to finish. If you the page appears to be frozen give it a
couple of minutes before concluding that it is stuck.

During the extraction process, if Kickstart encounters a .htaccess file it will extract it as htaccess.bak in order to avoid
potential server configuration conflicts during the restoration process. Similarly, a php.ini file on your site's root will
be backed up as php.ini.bak so as not to interfere with the restoration process. This change will be reverted in the final
step of Kickstart. Just read on!

Now, as soon as the extraction process is over, you will be presented with Kickstart's final page. Clicking on the Start
the installer button on this page will attempt to open a new window or tab in your browser, pointing to the Akeeba
Backup Installer screen. At this point, do not close the Kickstart tab or window ! Just switch to the new tab/window
and go through the restoration process.

At this point, you should read the Using the Akeeba Backup Installer section.

As soon as the restoration process is over and it tells you that you should remove the installation directory, close
the ABI tab/window and return to the Kickstart window. Clicking on the Clean Up button will "fix" the name of
the .htaccess file - if your original site had one it is temporarily extracted as htaccess.bak - and remove kickstart.php
and the backup archive. After that, you can use the restored site.

3. Performing the restoration process
The actual restoration process is the easiest part of restoring or migrating a web site, as it is normally handled by a
semi-automated script, the Akeeba Backup Installer (ABI for short). In extremely rare cases you may have to perform
the restoration manually, for example if you have a partial backup or you encountered a grave bug in ABI and are on
a strict deadline. The following sections will cover both methods.

3.1. Using the Akeeba Backup Installer (ABI)
The Akeeba Backup Installer (ABI for short) is the latest generation of backup installer scripts we have developed.
This one is not based on the original Joomla!™ installer, but written entirely from scratch. It's based on jQuery for
its interface. It is more streamlined and more stable than the original installers in the JoomlaPack backup software.
It is loaded with all the standard backup installer features, like multiple database restoration, automatic handling of
configuration.php and some even more exciting features, like the ability to restore database tables with foreign
keys and changing the password of a specific Super Administrator account, should you have multiple Super Admin-
istrators on a single site.

Tip
You can have a "safe haven", a clean (no extensions) dedicated browser installation in order to perform
restoration of your sites. Portable Firefox from PortableApps.com and Iron Portable work wonders for this
task!

All of the pages have a Next and a Previous button, taking you to the next or previous restoration step, respectively.
All pages are divided in panes, denoted by clickable headers. Upon clicking each header, the relevant pane's contents
come into view. The first pane - opened by default - contains the most basic information for the current page, whereas
the other panes contain more advanced information and options.

Important
If you get the error message "Your session write path and the installation directory are not writable. One of
them must be writable for the installation to continue." when the installer launches, you need to do either
of these:

94

Restoring backups

• contact your host and ask them to fix your account's PHP session save path to something writable; or

• change the permissions of the installation directory to 0777 (or 0755 on some servers) using your
favourite FTP client and reload the page. Do note that on Windows servers (i.e. if the paths shown in the
Directories pane look like Windows paths) there is no notion of permissions. On Windows hosts you
have to login to your host's Control Panel and use the file manager in there to edit the ACLs and make the
installation directory either world-writable or at least writable by the user the web server runs under. You
should be able to get your host guide you through this process.

The first page you see is the Check page:

The first pane contains the required settings. If any of these items is in red type, you can not proceed with the restoration
at all.

The next pane contains the Optional Settings, which are suggested for optimal operation of the restoration process and
the restored site, but not a pre-requisite. Do note, however, that if the Display Errors setting is set to On, it is possible
that the database restoration might fail.

95

Restoring backups

The last pane displays the default location (as read from the existing configuration.php file) of three Joomla!
core directories and if they are writable. You will have the chance to change them later on, but if you decide to leave
them at their pre-defined locations it's a good idea to make them writable by changing their permissions, e.g. using
your favorite FTP client program.

Just click on Next to go to the next page.

The Database Restoration page allows you to configure the connection information to your database so that you can
restore your database. The first pane, Connection parameters, contains the most basic connection information. Initially,
the fields are populated with the settings which were used on the site you backed up.

Warning
If you are transferring your site to a new server it is imperative that you change these settings! Failure to do
so can result in restoration failure and/or malfunction of the restored site. You have been warned!

Important
Akeeba Backup Installer doesn't have adequate permissions to create a new database on most commercial
hosts. In this case, you have to create the database manually, using your hosting control panel. The specifics
differ among hosts, so you'd better ask your host about how to do that. If you are, however, restoring locally
ABI should be able to create the database for you. If it fails, you should create it manually, paying attention
to use the utf8_general_ci collation. This last bit is extremely important, as doing otherwise will lead to
international characters (such as Arabic, Cyrillic, Greek and decorated latin characters) not appearing properly
on the restored site.

The available settings are:

96

Restoring backups

• Database type. This can either be mysql or mysqli. Generally, mysqli is a more rigid interface to the MySQL
database, but it's not supported by all hosts. If unsure, use mysql, unless you are sure it doesn't work on your server.
Choosing the wrong type is not catastrophic, it will just report a connection error.

• Database server host name. The MySQL server host name. Usually it's localhost, but you mst ask your host for this
setting, or consult your hosting account control panel, as this setting is usually displayed there.

• Username. The username of the database server user. Again, consult your host.

• Password. The password of the database server user. Again, consult your host.

• Database name. The actual name of the MySQL database you want to restore to. If you choose an existing database,
existing tables will be overwritten by default. You may want to ask your host for the correct value of this setting.

The Advanced Options pane contains some more advanced settings regarding your database restoration process. The
options are:

• Existing tables. The first option will delete any existing database tables with the same name. This is the standard
behaviour. The second option will rename existing database tables by changing their prefix to 'bak_' (these are
usually called backup tables). Any existing backup tables will be removed.

• Database prefix. ABI picks up the database prefix used on your original site. If you want to change it for the restored
site, you have the option to do it here.

Note
The term "prefix" is standard Joomla! jargon and refers to the table name prefix, not the name prefix of the
database itself. Some hosts - usually CPanel-powered - add a prefix to the database name, e.g. myuser_joomla,
where myuser is your account's login name. In this case, you must use the full database name, in this case
myuser_joomla. The tables in this database are prepended with the "Database prefix" option in this page. For
example, if you use the prefix "foo_", the content table holding your articles' text will be named foo_content.

Warning
If you are creating a copy of your site on the same hosting account, for example in a subdomain or subdirectory
of the original site, using the same database, you must change the prefix. Failure to do so will overwrite
your original site's contents with the modifications you make on the copy. Usually, this is catastrophic for
the original site!

97

Restoring backups

Finally, the Fine Tuning pane allows you to tweak the restoration process in ways not previously possible. The options
are:

• Suppress foreign keys while restoring. Leave this checked if restoring database tables with foreign keys. This option
will instruct MySQL to stop complaining about foreign key restrictions during the restoration. If you don't use it and
you have tables with foreign keys, the restoration will halt with a MySQL error mentioning foreign key constraints.

• Maximum execution time (seconds). ABI will read and process SQL commands until this amount of time has
elapsed. As a rule of thumb, set it to at most three quarters of your PHP max_exec_time. The default value, 5 seconds,
should be adequate for most hosts. If you get a timeout error, please reduce this value to 3, 2 or even 1 second.

• Use REPLACE instead of INSERT. If you get a "duplicate entry" error while restoring your site, please enable
this option. It will make sure that if existing tables could not be dropped or renamed you will still be able to restore
your site by replacing their contents with the data from the backup archive.

• Force UTF8 collation on tables. Ideally, your MySQL database should have been created with the default collation
set to utf8_general_ci as explained a few paragraphs above, in the Important box. If you haven't done so and restoring
a site which uses non-ASCII characters —Greek, Cyrillic, some Latin characters with diacritical marks, calligraphic
quotes, ligatures and so on— the restored site will display these characters either as question marks or as broken
text. In this case, please select this option. This will force Akeeba Backup Installer to forcibly set UTF-8 collation
on all text columns of each table restored. Do note that this is considered to be a last ditch attempt to fixing this
issue! The proper solution, absolutely required if you are planning on installing more extensions on your site, is to
set the default collation of your MySQL database to utf8_general_ci.

When you're done, click on Next to begin the restoration process. Doing so, will pop up a sort of window in the middle
of the page with the status of the restoration progress:

98

Restoring backups

If there was an error during this process, a message will describe what happened and give you the option to go back
to the previous page in order to rectify any options which caused the problem to happen. In the screenshot below, you
can see what happens if you enter the wrong connection information to your database server:

Warning
If you are always getting a "Could not connect to MySQL server" error on Windows despite entering your
database credentials, or if this occurs in mid-process, you have to use the "mysql" driver, NOT the "mysqli"
one. Below is the technical, lengthy description.

Windows has a small pool of temporary ports for use by applications and services, including Apache, MySQL and
PHP. Every time a PHP script tries to connect to the MySQL server through TCP/IP (the default behavior in most
consumer-grade WAMP packages, such as WAMPserver, XAMPP and Uniform Server) it uses up a few of them.
When the PHP script ends its execution, Windows - quite stupidly - leaves the port open for another 2 minutes. As
a result, mid-way in the restoration process Windows runs out of spare ports and the restoration script can no longer
connect to MySQL! In order to work around this, the "mysql" driver uses a feature called "persistent connections".
This means that the connection to the MySQL server never closes, so we don't have to use a new TCP port. On the
other hand, the mysqli driver started supporting this feature since PHP 5.3. Unfortunately, at the time of this writing,
no pre-packaged WAMP package has this PHP version. As an alternative, you can enable the so-called named pipe
connection feature of MySQL. This is what Linux and production-grade Windows servers use (and why they DO
NOT display this problem), but it requires configuration tweaking beyond the scope of this manual.

As the restoration goes on, the progress bar will start to fill up. When the restoration is over, the progress bar will be
full and the OK button will appear:

99

Restoring backups

Just click on the OK button to proceed to the database restoration page of other databases you have backed up, if
any. When ABI has cycled through restoration of all of the databases, clicking on the OK button will bring you to
the Site Setup page:

The first pane is the Site Parameters pane:

This is the basic information which describes your Joomla! site. It is populated with the settings of the backed up site's
configuration.php file. The settings are:

• Site name. The name of your site.

• Site e-mail address. The e-mail address which will appear to be sending your site-wide e-mail messages.

• Site e-mail sender name. The person name (sender name) which will appear to be sending your site-wide e-mail
messages.

• Live site. Normally Joomla! is able to determine the URL to your site automatically. On some servers it is not
possible and you have to type it in manually in this field. You have to type in the URL with the protocol (http://

100

Restoring backups

or https://) but without a trailing slash. For example, if your domain is www.example.com and you have
installed Joomla! in a directory named portal, you have to type in http://www.example.com/portal.

• Override tmp and log directories. By default, ABI will determine if the temporary and log directories specified
in the original site exist and are writable and will use them by default. However, if you are replicating a site in a
subdirectory or subdomain of the original doing so might lead to problems, as these directories are not supposed to
be shared between multiple sites. In this case you can either change them manually from the Fine-Tuning section
or simply check this box to automatically use the tmp and log directories under your restored site's root.

In the second pane, FTP Options, you are given the chance to set up your Joomla! site's FTP layer. The parameters
you have to setup are just like what Joomla! itself needs:

• Enable the FTP layer. Check this box to enable the FTP layer. If you leave it unchecked, providing the following
parameters will have no effect to your site's operation.

• Host name. The host name of the FTP server of your site. Usually it's something like ftp.example.com, but you
may want to ask your host.

• Port. The port where the FTP server listens to. Usually, this is port 21. If unsure either leave the default, or ask
your host.

• Username. The username you use to login to the FTP server.

• Password. The password you use to login to the FTP server.

• Directory. The absolute FTP directory where your Joomla! installation is in. If you have provided all the information
above, you may use the Auto find directory button to attempt to automatically determine this directory.

Note
This feature is not fail-safe. There is a high chance that ABI will not be able to automatically detect the
directory. In this case, you can use your favourite FTP client (we use FileZilla, which is free and rocks)
to browse to the root of your Joomla! installation and copy the absolute directory displayed there to the
Directory text box of ABI.

You can use the Test connection button to let ABI validate your settings.

Next up, it's the Super Administrator pane, allowing you to modify your site's Super Administrator settings:

101

Restoring backups

This pane is optional. It allows you to change the parameters of one and only one Super Administrator account on
your site. The parameters are:

• User name. You can select one of the Super Administrator accounts of your site from the drop down list. The settings
below will be applied only to this user account.

• New password. Enter (and re-type below) the new password for this user account, or leave these fields blank to
retain your old password.

• E-mail address. The e-mail address of this user. Do note that it's supposed to be unique (Joomla! restriction) but
ABI will not test for uniqueness.

Finally, there is the Fine-tuning pane, with the most advanced (optional) parameters:

Here you can fine-tune the absolute path to some of your site's system directories.

Important
ABI will test at the beginning of the restoration process if your old site's temporary and logs directories already
exist and are writable. In this case, it will keep them (useful if you have customized them and you are restoring
to the same site you backed up from). If they don't, it'll calculate and provide the Joomla! default paths.

If you are restoring on the same server / user account as your original site, you must manually change them,
in order to avoid one site messing up with the other site. If you don't, nothing could happen, or all hell could
break loose. Anyway, it's a good idea to inspect these settings nonetheless.

102

Restoring backups

• Absolute path to site's root. This is automatically determined and you can't change it (Joomla! has no such feature).
It is provided as reference only.

• Temporary Directory. The absolute path to the temporary directory. Normally, it's the tmp folder on your site's root.

• Logs Directory. The absolute path to the logs directory. Normally, it's the logs folder on your site's root.

When you're ready, click the Next button to have ABI write your configuration.php file and go to the final page.

If ABI could not write to the configuration.php file, it will present you with a dialog box informing you of this fact.

You can close the message by clicking on the "X" button on its top right corner. You can then copy the contents of the
text area and paste it into your configuration.php file - replacing any and all existing content - manually.

This is only required if your configuration.php file was not writable in the first place. Under most circumstances this
won't happen.

Warning
If you get this message and you do not copy the text box's contents to the configuration.php file, your site
will not work. You have been warned! YOU MUST ABSOLUTELY AND WITHOUT QUESTION COPY
THE TEXT BOX CONTENT INTO YOUR CONFIGURATION.PHP FILE.

After the restoration is over remember to remove the installation directory or, if you're using Kickstart, close
the ABI window and click the second "here" link in the Kickstart window. Or, you can click on the remove installa-
tion directory link on this page to have ABI attempt to automatically remove the installation directory. If it's
successful, it will present you with a dialog; as soon as you dismiss it you are redirected to your restored, operational
site. That's all, folks!

Warning
If you are using Kickstart, do NOT click on the remove installation directory link. Doing so will interfere
with the last of Kickstart and can result in a partially working site.

Important
Sometimes, after the restoration is over, you get a site front page which looks as if all images and CSS
files are not loading. This is normal if your live site had a non-empty $live_site parameter in its
configuration.php file and you are restoring your backup to a different domain name or a different
subdirectory of the original domain name, you have to manually edit configuration.php and change
the $live_site to reflect the new site's location.

For example, if the new site is located in http://www.example.com/mysite/, you have to edit the
configuration.php file, locate the line starting with var $live_site and change it to become:

var $live_site = 'http://www.example.com/mysite';

103

Restoring backups

Creating a database on GoDaddy
If you're on GoDaddy, just like on most commercial hosts, Akeeba Backup Installer can not automatically create the
database for your restored site. In order to create a database you must do the following:

• Go to your Hosting Control Center

• Click on Databases, then MySQL and finally on Create Database.

• Fill in your description, name, etc.

• Click on OK

• Go back to MySQL.

• The new database will be there or if you keep adding them there will be more than one.

• Hover of the "Pencil" on the Action Tab and then click the pencil. All the MySQL Database Information will now
appear here. You fill in the Akeeba Installation field with this info so make a note of it.

• When you come to install the Akeeba Backup installation fill in the details from it. Don't forget to replace localhost
with the new godaddy host name: similar to this: yourakeebanamehere.db.12345.hostedresource.com.

Credits go to our user jcjweb for kindly providing this step-by-step guide on our forum.

3.1.1. Automating the Akeeba Backup Installer
Sometimes you perform the same kind of restoration over and over again. For example, you might want to regularly
test the backup archives of your live site on a local environment. Having to type in the same kind of information all
the time is a waste of time. Our software suite supports one-click site restorations using the automation feature of
Kickstart and the Akeeba Backup Installer.

Automating the restoration is very easy. All you have to do is create a file named abiautomation.ini and place
it in the same directory as kickstart.php. As soon as the extraction is over, Kickstart will automatically open the
Akeeba Backup Installer. On its turn, ABI will try to locate abiautomation.ini in its parent directory, parse it
and use its information to automatically perform all the restoration steps. When ABI is done it will close its window
and all you have to do is click on the Clean Up button in the Kickstart window to finalize the restoration procedure.

This section discusses the part of the abiautomation.ini file which pertains to the Akeeba Backup Installer automation.
The part of this file which pertains to automating Kickstart can be found in Kickstart's documentation. Both sections
must be present for a fully automated restoration to take place.

The section named [abi] is where all parameters regarding your site (but not its database) are stored. Typically, it
looks like this:

[abi]
ftp_enable=off
ftp_host=ftp.example.com
ftp_port=21
ftp_user=myuser
ftp_pass=mypass
ftp_root=/public_html
sitename=The Site Name
mailfrom=someone@example.com
fromname=Site Name Email Notification System
sauser=62

104

Restoring backups

sapass1=secret_password
saemail=sa@example.com
tmp_path="$SITEROOT/tmp"
log_path="$SITEROOT/log"
live_site="http://www.example.com"

All parameters are saved on the configuration.php file of the restored site, or directly stored in the database.

Tip
If PHP throws a warning about parsing jpi4automation.ini and the JPI4 restoration process doesn't proceed
automatically, you will have to include all parameters' values in double quotes, like this:

myparameter="my_value"

The available parameters are:

• ftp_enable. Should the Joomla! FTP layer be enabled for the new site? It can be on or off. The other ftp_*
parameters are only required if this is on. Otherwise, they can be left blank. However, the ftp_enable must be defined
in the abiautomation.ini.

• ftp_host. The FTP host name, without the ftp:// protocol prefix, e.g. ftp.example.com.

• ftp_port. The FTP port to connect to, normally it's 21.

• ftp_user. The username to use when connecting to the FTP server.

• ftp_pass. The password to use when connecting to the FTP server.

• ftp_root. The FTP directory where your site has been restored. You can find this out by launching a graphical FTP
client, for example FileZilla, finding where kickstart.php is stored and noting down the FTP path shown. This is
the path you have to use in this variable.

• sitename. The name of the restored Joomla! site. If you don't include it, the old site's parameter will be used.

• mailfrom. The email which will appear as the sender of all of the site's emails. If not included, the old site's parameter
will be used.

• fromname. The sender name for all of the site's emails. If not included, the old site's parameter will be used.

• sauser. The numerical Super Administrator user ID for who you want to change his password and/or email. If not
defined, no change to the Super Administrator credentials will occur (the old site's login credentials will be still
in effect). You can find the numerical ID of the Super Administrator user from Joomla!'s backend, in the User
Management page.

• sapass1. The Super Administrator password for the new site. If not included, the old site's Super Administrator
password will be used.

• saemail. The Super Administrator email for the new site. If not included, the old site's Super Administrator email
will be used.

• tmp_path. The absolute path to the temporary files directory of the restored site. If not included, JPI4 will auto-
matically determine the correct path. If the old site's temporary files path exists and is writable, it will be used in
the new site as well. If not, the tmp directory inside the restored site's root will be used.

You can start the path with $SITEROOT, just like in the example above. The $SITEROOT will be automatically
replaced with the absolute path to the restored site's root directory.

105

Restoring backups

• log_path. The absolute path to the log files directory of the restored site. The same as above holds true, with the
exception that the default value is the log directory inside the restored site's root.

• live_site. Optional. The URL to your live site, without the trailing slash, e.g. http://www.example.com. You
only need to specify this if your host does not allow Joomla! to properly identify the site's URL automatically. You
can safely skip this setting.

In order for the JPI4 restoration to work, only the ftp_host parameter has to exist. Everything else is optional.

The next few sections define how each and every database backed up with Akeeba Backup will be restored, one
section per backed up database. The names of the sections must be the same as those listed in the installa-
tion/sql/databases.ini file inside the backup file. The section regarding the site's main database is always
named [joomla.sql]. A database section looks like this:

[joomla.sql]
dbtype=mysql
dbhost=localhost
dbuser=myuser
dbpass=mypass
dbname=joomladb
prefix=jos_
existing=backup
suppressfk=on
maxchunk=1048756
maxqueries=1000

The available parameters are divided into two groups: Obligatory and optional. The obligatory ones must appear for
each database which is to be restored and are:

• dbtype. The database connection type, it can be mysql or mysqli. If unsure, pelase use mysql.

• dbhost. The database server host name.

• dbuser. The database server user name.

• dbpass. The database server password.

• dbname. The name of the actual MySQL database to be used for restoration, for example joomla or
myaccount_joomla, etc.

• prefix. The prefix of the restored database. This is required only for the [joomla.sql] section and for databases for
which you have defined a non-blank prefix in their configuration in the Multiple Databases configuration page of
Akeeba Backup.

The optional parameters are the fine-tuning options of ABI:

• existing. What to do with any tables already existing in the database. This can be drop to delete the old tables, or
backup to create backup copies of the existing tables.

• suppressfk. It can either be on or off. When set to on, ABI will suppress foreign key checks, so that databases
having tables with foreign keys can be restored. It is a good idea to always set to on.

• maxchunk. ABI will read at most this amount of data from the database dump in one go while restoring. This is
useful if the restoration times out. The default value, if this option is omitted, is 1048756 (this 1Mb expressed in
bytes). Use a lower value if you get timeouts, or a higher value to speed things up.

106

Restoring backups

• maxqueries. This is the maximum number of SQL queries ABI will execute in a single go while restoring your
database. The default value is 1000. If the restoration times out, please lower this to 500 or even 100. Some incredibly
slow servers might require an even lower value, e.g. 100, but restoration will be extra slow then.

3.2. Unorthodox: the emergency restoration procedure
Note
These instructions are meant to be first read before disaster strikes. Therefore, a fair amount of humour has
been used throughout. If you try to read it after disaster struck you will naturally find the humorous parts
inappropriate, or even offensive. Rest assured that this is because you are under a huge amount of stress. As
soon as you'll have finished following the instructions herein, you will be able to re-read this document with
a light heart and enjoy the humorous puns as they were intended.

Inevitably, some people will end up with a backup file, a ruined site and a problem in the restoration procedure they
can't work out. Almost always, the recipe includes a pressing deadline which requires that the site is on-line... yesterday.
If you are in a situation like the one we just described, breathe. Do not panic. We've got you covered, with this concise
manual site restoration guide. So, here it goes... it's manual Joomla! Site restoration In 7 steps or even less.

Step 1. Making sure it won't get worse.
Assuming such a situation, it's only human to be in panic and despair. Panic is a bad counsellor. It will give you wrong
advice. Despair will only make you careless. So, people, get it together! Make a backup of the only thing separating
you from complete disaster: the backup file. Burn it on a CD. Write it on your USB key. Put it on a couple of locations
on your file server. Just make sure you'll have an extra copy in case you screw up.

This exercise has been proven to lower the probability of anything going wrong. Furthermore, it's good for your
psychology. It gives you a sense of security you didn't have five minutes ago.

Step 2. Extracting the archive.
Now, we have to extract the archive somewhere on your local hard drive.

If the archive is of the JPA type, you'll have to use Akeeba eXtract Wizard, available without charge from our website.

If you have a ZIP package, there are a couple of gotchas. If you are working on a Linux machine, unzip will work
just fine. If you're on Windows and under certain configuration circumstances on the server you took the backup on,
you might not be able to extract it with WinZIP, WinRAR, 7-Zip or other archiver software. So you'll have to use
Akeeba eXtract Wizard available for free from our website. This is a GUI utility which allows direct extraction of
backup archives on your Windows™ PC. It is possible to run it under other operating systems, such as Mac OS X™
and Linux™, using DarWINE and WINE respectively. Please refer to the Akeeba eXtract Wizard documentation,
available on-line on our site, for more information on using it.

Step 3. Editing your database backup.
Take a look at the directory where you extracted your backup archive. Inside it there is a directory named instal-
lation. Inside this, there is a subdirectory named sql. Inside this there is a file, joomla.sql, containing your
database data. COPY THIS TO ANOTHER LOCATION NOW! We'll have to edit it, so please, don't tamper with the
original, will you?

Open the copy of joomla.sql. Use a text editor (we recommend gedit and Kate on Linux™, Notepad++ on Win-
dows™; do not use Wordpad or Word!). If you were ever familiar with SQL, you'll recognize that each line consists
of a single SQL command. But they have a problem: table names are mangled. You'll see that tables are in a form
similar to #__banner instead of jos_banner. Ah, nice! We'll have to fix that.

107

Restoring backups

Using your text editors Replace command, do the following changes:

• search for CREATE TABLE `#__ replace with CREATE TABLE `jos_

• search for DROP TABLE IF EXISTS `#__ replace with DROP TABLE IF EXISTS `jos_

• search for INSERT INTO `#__ replace with INSERT INTO `jos_

• search for CREATE VIEW `#__ replace with CREATE VIEW `jos_

• search for CREATE PROCEDURE `#__ replace with CREATE PROCEDURE `jos_

• search for CREATE FUNCTION `#__ replace with CREATE FUNCTION `jos_

• search for CREATE TRIGGER `#__ replace with CREATE TRIGGER `jos_

The idea is to replace all instances of #__ (note that there are two underscores after the hash sign) with jos_ in the
MySQL command part (not the data part). DO NOT PERFORM A BLIND SEARCH AND REPLACE OF #__ WITH
jos_ AS IT WILL CAUSE SEVERE PROBLEMS WITH SOME COMPONENTS. Easy, wasn't it? NOW SAVE THAT
FILE!

Step 4. Restoring the database.
In order to restore the database on the server you'll have to use some appropriate tool. For small to moderately sized
database dumps (up to 2Mb), we find that phpMyAdmin [http://www.phpmyadmin.net] does the trick pretty well,
plus it's installed on virtually all PHP enabled commercial hosts. For larger dumps, we found that bigdump.php from
Alexey Ozerov [http://www.ozerov.de/bigdump.php] works wonders. Use either of those tools - or any other of your
liking - to restore your database.

If the restoration gets stuck with SQL errors on some CREATE TABLE command, it seems that you are restoring to
a server with an older MySQL version than the one you took the backup from. In this case, if you have still access to
the original site, you can perform a new Akeeba Backup backup with the database compatibility mode set to MySQL
4 and start over. You did read the User Guide section on configuration options, right?

If you don't have access to the original site... Oh, this is gonna be such a long night. In a nutshell, you have two
options: a) Edit all of the CREATE TABLE commands, eliminating everything between the last parenthesis and the
semi-colon of each command. b) Set up a MySQL 5 enabled local server (for example, XAMPP, WAMP, LAMPP,
MAMP, depending on your operating system), restore the site in there, take a backup with the database compatibility
mode set to MySQL 4 and start over.

Step 5. Upload your site's files.
First of all, delete the installation subdirectory from the directory you extracted the backup archive to. We won't be
needing this any more. Then, using FTP - or any method you please - upload all of the files to the target server.

If you want to be thorough remember to set the directory and file permissions accordingly. If you just want to get the
damn thing on-line ASAP, just skip this permissions thing; it will remind you of itself as soon as you try to do some
website administration (like uploading a picture) after the site's back on-line.

Step 6. Edit configuration.php, if necessary.
If you were restoring to the same server location you took the backup on, nothing else is necessary. Your site should
be back on-line now. If not, you'll have to edit the configuration.php.

You have Joomla! 1.5.x. Good news! Joomla! 1.5.x doesn't require you to specify some of the hard-to-obtain param-
eters. Your configuration.php consists of several lines. Each one is in the following form:

108

Restoring backups

var $key = "value";

The key is the name of the configuration variable and value (inside double quotes!) is the value of the variable. Below
we provide a list of the configuration variables which have to be modified to get up on-line.

dbtype is the database driver Joomla! will use. It can be either mysql or mysqli (notice the extra i in the end).
If unsure, your best bet is mysql.

host is the database host name, usually localhost

user is the database user name, assigned from your host company

password is - obviously - the database password, assigned from your host company

db is the database's name, assigned from your host company

dbprefix is the database prefix; if you followed our instructions, it is jos_

live_site Normally this is an empty string. If, however, your Joomla! site's front page looks as if all images and
CSS files are not loading, you have to modify it and enter your site's base URL. For example, if the
new site is located in http://www.example.com/mysite/, you have to locate the line starting
with var $live_site and change it to become:

var $live_site = "http://www.example.com/mysite";

That's all! You're good to go.

Step 7. Enjoy success.
Your mission is accomplished. You are exhausted. Go drink whatever is your favourite drink and enjoy sweet success!

4. Finalizing the restoration process
This is a trivial part, either method you use to restore your site, so we'll just cover this in a couple of paragraphs.

If you are using Kickstart, as soon as ABI is done and presents its final page, simply close ABI's tab or window. Back
to Kickstart's tab, click on the Clean Up button. That's all there is to it. You now have a working site and you should
not read the rest of this section as it doesn't apply to you.

If you are not using Kickstart, or if Kickstart failed to perform the last step, you have to do two simple actions with
your favorite FTP client. The first is to remove the installation directory. The reason is very simple. As long as
Joomla! detects the existence of this directory on your site, trying to access your site will redirect you to ABI's first
page. Just remove it with the FTP client to enable access to your site.

If your site originally had a .htaccess file, it is renamed to htaccess.bak in a previous step, either automatically
by Kickstart or manually. Rename this file to .htaccess (note the dot in front). You are now ready to access your
site.

Generic troubleshooting non-functional restored sites
If after the restoration you experience the index.php downloading as a file instead of executing (download dialog
on your browser), or you get a blank page or a 500 Internal Server Error page you have to make sure that there
are now settings transferred in files from your old server which are not compatible with your new hosts. The most
notable culprits are .htaccess and local php.ini directives. Look in your .htaccess file for directives such as
php_value, php_flag and AddHandler. Try commenting them out (putting a hash in front of the line) to see if it helps.
Another thing you should look into is the RewriteBase line. Normally, you need something RewriteBase / if your

109

Restoring backups

site is on the root of the domain, or RewriteBase /mydirectory if it's inside a directory named mydirectory.
Moreover, if you are restoring on a local host, you have to make sure that your server is loading the mod_rewrite
module, otherwise you will most assuredly get a blank page or a 500 Internal Server Error. If none of this helps, look for
a file named php.ini inside your site's root. If it exists, try renaming it to php.ini.bak and retry loading your site.

Warning
GoDaddy users will find out that the .htaccess changes need 10-30 minutes to take effect. This is a stupid and
inexplicable limitation of your host. Normally, these changes should take effect immediately, as happens with
pretty much every other host including local installations. You can feel free to write an email to GoDaddy and
urge them to fix this broken behaviour. Please don't write to us claiming that changing the .htaccess bears no
result. We know! You just have to wait... and wait... and wait some more. We can't fix their broken servers.

If you are using WAMPserver on Windows you must note that mod_rewrite is not loaded by default. In order to enable
it, you have to click on WAMPserver's tray icon, Apache, Modules and make sure that Rewrite is checked. If not, click
on it and wait for the server to restart. This is required only the first time you restore to a WAMPserver installation
and only if you have SEF URLs turned on and you are using Joomla!'s .htaccess file.

Sometimes you might be getting URL errors. For example, the first page might display but clicking on any link returns
a 404 error. Some other times the first page displays very weird, like the CSS and images are not loading. Both
of those issues have nothing to do with the restoration itself, but your server setup and a clash with how Joomla!
works. The easiest way to work around it is using the $live_site variable in your configuration.php. Edit the
configuration.php file in the root of your site and modify it so that the line starting with var $live_site looks
like this:

var $live_site = "http://www.mysite.com";

or (if you have installed in a subdirectory):

var $live_site = "http://www.mysite.com/mypath";

This will let Joomla! figure out the correct URLs to your site's CSS files, images and links and these errors will go away.

Tip
If you restored to a server which required the $live_site hack, next time do yourself a favour: use ABI's feature
for changing the $live_site variable. It is available in the second to last step of the restoration procedure, just
under the text boxes where you define your site's name and email details.

Something else you might want to consider is the PHP version of the original and new server. If your original server
was running on a newer version of PHP than the new server, you might end up with a blank page. This is especially
true if your original server was using PHP 5.2 or later and your new server is using PHP 5.1, or if your new host has
disabled some critical PHP functions. This is not a restoration problem, rather than a hosting configuration error. Some
modules, components or plugins you have installed might be using functions which are not available on your new host.
The only way to understand if this is the case is to have your host take a look at the error log and reconfigure your
hosting environment to fix this issues. If you are restoring to a local server, you might have one version of PHP which
is too new for Joomla! to work with. Most prepackaged server environments use the latest PHP 5.3 release which might
cause some glitches with Joomla!. In this case, the only solution is to downgrade your server environment to a version
which uses PHP 5.2. WAMPserver users might want to download and use PHP 5.2 packages from WAMPserver's site.

Finally, some people see PHP errors (Deprecated, Notice, Warning) when accessing their website. Again, most of
the times this is not a problem with the restoration, but an issue with the server configuration. In most cases you can
simply set Error Reporting to None in Joomla!'s Global Configuration page. If this doesn't work, please ask your host
for information on disabling PHP's error output to the browser. Anyway, it's a good idea to do so in the first place!
You don't want any minor glitch to reveal sensitive server configuration information to potential hackers. If you are

110

Restoring backups

your own host, e.g. using a local installation of WAMPserver, XAMPP, MAMP, etc., the easiest way to do that is
by editing your php.ini file and setting error_reporting = E_ERROR. Remember to restart Apache for the change to
have any effect at all!

If you came across another case of post-restoration woes, feel free to write to our forums. We'll try our best to help you.

What happens if I get a blank page or an HTTP error 500?

"Help! Accessing my site downloads PHP code or the
index.php file instead of displaying the front page!"
This most probably means that your .htaccess file contains directives which your web server doesn't understand.
We'll try to work around this issues.

The first thing you have to check if your server has mod_rewrite enabled. On most commercial hosts using the
Apache or Lighttpd web server software it is already enabled and shouldn't cause any problem. If in doubt, ask your
host. On local servers, it's another story. For example, on WAMPserver it is not enabled by default, so you have to
click on its tray icon, go to Apache, Modules and make sure that mod_rewrite is ticked; if not, click on it to enable
it. Other server packages require you to edit the httpd.conf or run other system commands. Please consult your server
package's documentation for more information on enabling mod_rewrite.

The other thing which might interfere is directives enabling PHP 5 on one host, but causing a conflict on another host,
or on a local server. Usually they have a format like this:

AddHandler application/x-httpd-php5 .php

You most probably have to remove those lines beginning with AddHandler, especially if your problem is that you get a
bunch of code, or the web browser offers to download index.php, instead of your site's front page. You most certainly
have to remove such lines if you are restoring on a local server.

You should also try commenting out lines which look suspicious to you, because any of those directives may cause
trouble. If in doubt, get a fresh Joomla! package, extract the htaccess.txt file from it, rename it to .htaccess
and upload it to your host.

Finally, you should note that some servers do not accept .htaccess. Putting such a file on your site's root will make
the server throw an HTTP Error 500: Internal Server Error as soon as you try to access your server. If this happens,
you need to have a little chat with your host.

As a side note, we might also add that some third party components, such as DOCman 1.4.x and VirtueMart 1.x, store
absolute paths in their configuration files. If you restored to a different location / server than the one you originally
had the site you backed up, trying to access your new web site's public front-end might result in blank pages or HTTP
Error 500. You will have to edit the configuration of those components and ensure that you have changed the paths
to reflect the correct paths on your new server / location.

My original site loads instead of the restored site
The front-page displays, but clicking on any link throws
a 404 error?!
There are two possibilities here. The first is that you have redirections in your .htaccess file, for example direct-
ing all traffic to the www prefixed site or to a specific domain, e.g. all traffic to www.example.com, even if it refer-
enced example.com or example.net in the URL. Such problems are easy to spot because you have put this code in the
.htaccess file and you should know about what it does. Just remove it or comment it out.

111

Restoring backups

Another possibility is that you have to set or change the $live_site parameter in your site's
configuration.php. Normally, Joomla!™ is able to determine the absolute URL to your site's root without
your help. However, it looks like that some servers lie, most notably Microsoft™ IIS™, so we have to help our fa-
vorite CMS with that. You had the chance to set this URL during the restoration, but it's never too late. Just edit the
configuration.php file on your site's root with a plain text editor, e.g. Notepad++ or Kate, and find the line
which starts with var $live_site. Change the rightmost part (the one between single quotes) to your site's URL,
without a trailing slash. For example http://www.example.com - see? No trailing slash!

Finally, on some hosts it's required to change or enable the RewriteBase parameter in your .htaccess file. Most
often than not it's enough to edit the file and find the line beginning with RewriteBase. If there is a hash in front,
remove it. Change this line so that it reads:

RewriteBase /

or, if you restored in a subdirectory named myjoomla:

RewriteBase /myjoomla

Whenever I update something in the restored site, the
original site's content changes!
The problem is that you didn't read the part of the manual regarding the restoration. As it is written in there, during
the restoration you are presented with your database connection information. By default, ABI displays the parameters
pertaining to your original (old, backed up) web site. However, you are restoring to a new server, or a subdomain in
the same server. How can it ever be possible that you use exactly the same database information? It can't, because
Joomla!™ stores all of the site's content (except media files) in the database. As a result you'll have to restore the site
again, this time after reading the part on using the Akeeba Backup Installer. I'm sorry, there is no easier workaround
to this problem.

I get a 500 Internal Server Error or a blank page when
trying to access my administrator back-end
First, make sure that you have followed the advice above regarding .htaccess, php.ini and
configuration.php changes. If none of these changes helped, take a look for a .htaccess file inside your
administrator directory. Try renaming it to htaccess.bak.

If this allowed you to gain access to your site, the problem was in that file. Most commonly, if you have password-pro-
tected the administrator directory using your hosting control panel, Admin Tools or any other method prior to moving
your site to a new server then your .htaccess file in your administrator area contains an absolute path reference
to the password storage file. After moving your site to a new server this reference is no longer valid and causes the
500 Internal Server Error. In order to get rid of it and still have your administrator area password-protected, please
delete the old .htaccess file and use Admin Tools or your hosting control panel to re-apply the password protection
on the new host.

If this still doesn't help, you may be receiving a hidden PHP error. In this case, first make sure that there is no
php.ini file in your administrator directory. If there is, rename it to php.ini.bak. After that, edit your
configuration.php file and find the line starting with var $error_reporting. Change it to read:

var $error_reporting = '30719';

Try accessing your site again. On most servers this should allow you to see the actual PHP error occurring. If this
doesn't work, ask your host for access to the raw PHP error log for your account so that you can see the error message.

112

Restoring backups

Special considerations for VirtueMart
If you are trying to restore a VirtueMart shop to a different server, domain, subdomain or directory than the orig-
inal site you will discover that it stopped working. This is due to VirtueMart storing absolute URLs and abso-
lute paths in its configuration. They are very easy to change. Start by opening the administrator/compo-
nents/com_virtuemart/virtuemart.cfg.php file with a plain text editor (e.g. Notepad, but not Word-
Pad). Find the two lines looking like this:

define( 'URL', 'http://www.example.com/' );
define( 'SECUREURL', 'https://www.example.com/' );

These two lines contain the URLs to your regular site's root and to your HTTPS site's root. Edit them to match your
new settings. For example, if you moved your site to http://shop.example.com the above lines should now read:

define( 'URL', 'http://shop.example.com/' );
define( 'SECUREURL', 'https://shop.example.com/' );

Finally, if you are offering downloads as products, you will also have to change the download root directory. Find
the line which looks like this:

define('DOWNLOADROOT', '/home/myuser/public_html/vmdownloads');

and change the path to reflect the absolute filesystem path to your downloads directory. Determining it is not so
difficult. During the restoration you are presented with the absolute path to your new site's root in the Fine-Tuning
section of the Site Info (second to last) page. Let's say that this path is /home/foobar/www and your VirtueMart
downloads directory is vmdownloads under your site's root. The new path you have to type in is, therefore, /home/
foobar/www/vmdownloads.

If you are wondering why ABI can't handle this automatically, do note that out of the three changes illustrated here
only one can be automated: the regular site's root. The secure URL may or may not be the same as the normal URL,
with or without HTTPS or it can be a completely different URL than the regular site's URL! There is no way ABI
can know that. The downloads root is even trickier, as ABI would have to know the path layout of the original server,
parse the path against it and re-parse it against your current directory structure. This is pretty much a hit-and-miss
operation so you're really better off doing those changes manually than having an automated system routinely mess
up your settings on restoration.

Special considerations for Community Builder (CB)
Warning
DO NOT ATTEMPT TO BACKUP AND RESTORE A CB-POWERED SITE WITH AKEEBA BACKUP
3.0 OR EARLIER. DOING SO WILL LEAD TO A BROKEN, NON-OPERATIONAL INSTALLATION
OF CB. ALWAYS USE AKEEBA BACKUP 3.0.1 OR LATER.

Community Builder stores table names in its database fields in an abstracted format identical to that used by Akeeba
Backup to allow it to perform a prefix change operation. This means that jos_users is stored in the 'table column of
your site's jos_comprofiler_fields table as #__users. Akeeba Backup 3.0 Stable and lower would erroneously restore
it as 'jos_users', which caused Community Builder to stop working. As a result, you MUST use Akeeba Backup 3.0.1
or greater to backup and restore your CB-powered site.

When you finish restoring your site you have to perform one simple step. Go to your site's backend and click on the
Components, Community Builder, Tools menu item, then click on Check Community Builder Database. This will find
one error in the CB tables. Allow CB to fix this error. This is all that is required to make CB work again on your site.

113

Chapter 6. Step by step guides
Even though the previous chapters provide a good reference, they assume that you know what you're doing. Many
times, especially when you are a novice user, just the number of options can be intimidating. We are perfectly aware of
that, hence this section. It is designed to get you up to speed with performing complex operations or creating advanced
setups for your backup operation needs. It is not meant to be a thorough reference; if you have questions about how each
of the individual settings work, you should refer to the appropriate section of the other chapters in this User's Guide.

1. Backing up your site to a cloud storage ser-
vice
1.1. Introduction
For most of us, our websites are a key element to our business. Either being the business itself, or acting as the storefront
to the Internet, they provide a significant added value. The last thing any web site owner want is to see their site defaced,
damaged or even lost. Dangers lurk everywhere. From a simple human error in site administration to malicious activity
and from hardware failure to natural disasters, no web server is the bulletproof vault we’d like it to be.

While nobody expects a catastrophe to hit his site, a good deal of precaution is required. It's pretty much the same
rationale as in wearing a seatbelt while driving; you don't expect to crash, but if you do you most certainly want to
evade the incident unharmed. The web site equivalent to a safety belt is none other than backup.

Web site backup comes with its own set of limitations and pitfalls. If you trust your web host for backup you might
find your expectations fall short. Most hosts take daily backups – if any at all –on a secondary hard disk on the same
server or, even worse, on a secondary partition of the same hard disk. If the server goes down due to a hardware fault,
so does your backup. A few enlightened hosts also take backups on remote storage, for example NAS arrays. Even
they do so on rather sparse intervals, for example twice per week. This means that on a complete catastrophe you will
most assuredly lose a fair amount of data.

The solution is simple in concept. Take your own backups and store them on a cloud storage service, like Amazon S3
or even DropBox. Taking your own backups means that you get to decide which data and how often has to be backed
up, making sure that the crucial, regularly updated information routinely ends up in a backup archive. Using a cloud
storage device adds a strong data safety clause to your procedure, while keeping costs low. Cloud storage is designed
to be redundant and reliable, boasting a negligible risk of data corruption or data loss. Combined with its incredibly
low cost (or even no cost for very low storage requirements!), it is reasonably attractive to businesses of all sizes: from
hobbyists and sole proprietorships up to large corporations and government agencies.

But how can you implement this seemingly Utopian data protection scheme on your Joomla!™ site today, with the
lowest possible cost? Enter Akeeba Backup Professional. The Professional edition sports significant features added
on top of those offered to our free of charge Akeeba Backup Core edition (formerly known as JoomlaPack). One of
those features we are going to use to accomplish our objective: transferring backup archives to cloud storage.

This section describes how to set up your site to store its backup archives to either Amazon S3 or DropBox. More
cloud storage providers will be added in the future. The setup always follows the same principle, no matter which
cloud storage you want to use. Read along and you'll pick up the idea really fast.

1.2. Basic configuration
The most essential step is to download and install the Akeeba Backup Professional component to your site. In order to
do that, you'll have to subscribe to the Professional download service first. After that, simply follow the step-by-step
installation instructions. You can try to take your first, non-cloud backup to make sure that everything’s in working

114

Step by step guides

order. If something goes wrong, just post as much information you can on our support forum. We will get back to you
in 24-48 hours. Usually, we'll reply in much less time, even on weekends and bank holidays.

Provided that you are in your Joomla!™ administrator back-end, just click on the Components, Akeeba Backup menu
item. In the Control Panel page which loads, click on the Configuration button. This will bring you to a quite lengthy
configuration page. Locate the Archiver Engine setting in the pane titled Advanced Configuration. Click the button
labeled Configure… next to it in order for the detailed settings to display. You should get something like this:

We will have to change just one option: Part size for archive splitting. Select the "Custom..." option and type in 20 in
the text box that appears to the right of the drop-down. This setting will chunk our backup archive into multiple files,
the maximum size of each one being the value of this setting.

You might wonder why we need to do that. PHP always has a strict time limit, i.e. the maximum time a PHP page
may process data before the web server aborts it. Uploading the backup archives to cloud storage takes time, the exact
amount of which depends on the size of the file and the network speed. The time limit and the bandwidth are beyond
our control, so we can change the only parameter we can touch in order to avoid timeouts: the file size. Akeeba Backup
Professional is smart enough to upload each part of the backup archive on a PHP page load of each own, so as to
avoid timing out.

1.3. Using Amazon S3
If you've followed the instructions so far, it's Amazon S3 setup time! In the Configuration page, right below the
Archiver Engine setting there's another setting called Data processing engine. Use the drop-down to select the Upload
to Amazon S3 value and then click the button titled Configure… next to it. You should now see something like this:

In this configuration details pane you have to enter your Amazon S3 Access key and Private key. You should have
been given those keys during your signup to Amazon S3. If you haven't noted them down, just sign in to your Amazon

115

Step by step guides

S3 account and go to the Security Credentials page. You will find this information in the Access Keys section. Back to
our configuration page, checking the Use SSL setting will make your data transfer over a secure, encrypted connection
at the price of taking a little longer to process. I recommend turning it on anyway. The Bucket setting defines the
Amazon S3 bucket you are going to use to store your backup into. The Directory defines a directory inside the bucket
where you want the backup files stored and must have been already created.

Do note that as per S3 standards the path separator for the directory is the forward slash. For example, writing
first_levelsecond_level is wrong, whereas first_level/second_level is the correct form. I rec-
ommend using one bucket for nothing but site backups, with one directory per site or subdomain you intend to backup.
If you want to use a first-level directory, just type in its name without a trailing or leading forward slash.

Tip
Should you need a visual interface for creating and managing Amazon S3 buckets, I highly recommend using
S3Fox Organizer [http://www.s3fox.net/], a free plug-in for the FireFox web browser.

Enough said. Click on Save to store the changed settings. Back to the Akeeba Backup Professional Control Panel,
click on the Backup Now icon. It's backup time!

Ignore any warning about the Default output directory in use. We don't need to care about it; our backup archives will
end up securely stored on Amazon S3 anyway. Just click on the big Backup Now! button and sit back. The upload to
Amazon S3 takes place in the final step of the process, titled Finalizing the backup process. If during this stage you
observe that the timeout bar – the bar which looks like a progress bar – fills all the way to the right, you have a timeout
error. This means that you have to go back to the configuration and lower the Part size for archive splitting setting.

Important
On local testing servers you will have to use ridiculously small part sizes, in the area of 1-5Mb, as the xDSL
consumer Internet service has a much more limited bandwidth than your host.

Warning
If you get a RequestTimeout warning while Akeeba Backup is trying to upload your backup archive to the
cloud, you MUST go to the Configuration engine and enable the "Disable multipart uploads" option of the
S3 engine. If you don't do that, the upload will not work. You will also have to use a relatively small part size
for archive splitting, around 10-20Mb (depends on the host, your mileage may vary).

As you can see, I just backed up my personal blog to Amazon S3:

116

Step by step guides

1.4. Using DropBox
Under some circumstances using a for-a-fee cloud storage service may be beyond the budget of the client, as is usually
the case with personal or very small business websites. DropBox offers an inexpensive storage service, giving out the
first 2 Gb of storage for free. Moreover, they offer a desktop client application which synchronizes the files stored
in the cloud with those stored locally on a specified directory. Within the scope of backup, this is a very desirable
feature, as it allows for automatic redundant storage of the backup archives on the local PC (actually, on any number
of local PCs!), without any manual intervention.

To this end, we decided to include a preliminary support for DropBox storage. We call this preliminary because there
is no formal API published for DropBox yet. What we use is a workaround solution which transparently signs in the
DropBox.com web site and submits each backup archive part to the file upload form located in there. This means
that if DropBox decides to change the layout of their site, this solution might stop working - although we have strong
reasons to believe that this is highly unlikely.

If you've followed the instructions so far, it's DropBox setup time! In the Configuration page, right below the Archiver
Engine setting there's another setting called Data processing engine. Use the drop-down to select the Upload to Drop-
Box value and then click the button titled Configure… next to it. You should now see something like this:

In this configuration details pane you have to enter your DropBox.com email and password. You should have been
given those keys during your signup to DropBox.com. They are the same you use to sign in to your DropBox.com
account. The Directory defines a directory inside your DropBox account where you want the backup files stored and
must have been already created.

Do note that as per DropBox.com standards the path separator for the directory is the forward slash. For example,
writing first_levelsecond_level is wrong, whereas first_level/second_level is the correct form.
I recommend using one directory for nothing but site backups, with one subdirectory per site or subdomain you intend
to backup. If you want to use a first-level directory, just type in its name without a trailing or leading forward slash.

117

Step by step guides

Tip
If you have installed DropBox' desktop client application on your PC you can simply create the directory on
your local DropBox directory (usually found under My Documents in Windows™ machines). The desktop
client application will automatically synchronize the folders to your on-line account.

Enough said. Click on Save to store the changed settings. Back to the Akeeba Backup Professional Control Panel,
click on the Backup Now icon. It's backup time!

Ignore any warning about the Default output directory in use. We don't need to care about it; our backup archives
will end up securely stored on DropBox anyway. Just click on the big Backup Now! button and sit back. The upload
to DropBox takes place in the final step of the process, titled Finalizing the backup process. If during this stage you
observe that the timeout bar – the bar which looks like a progress bar – fills all the way to the right, you have a timeout
error. This means that you have to go back to the configuration and lower the Part size for archive splitting setting.

Important
On local testing servers you will have to use ridiculously small part sizes, in the area of 1-5Mb, as the xDSL
consumer Internet service has a much more limited bandwidth than your host.

1.5. Where to go from here?
Backing up your site to the cloud is the first step to backup autonomy and data safety. However, you still have to login
to your site's back-end to take a cloud backup. This is suboptimal. What about when you are on the road for days,
without reliable Internet connection? What about not wanting to go through this daily drill?

I am 100% behind you on this. I don't like routine either. You know, programmers are lazy and get bored easily.

With Akeeba Backup Professional you have three (that's not a typo, three) different options to automate your backup!
Two of them are designed to utilize your host's CRON scheduling, i.e. your host's ability to run specific commands
on his server, on a predefined schedule. This would mean that your backup is fully automated; you sleep at night,
your site backs up itself.

You can read more about Akeeba Backup's scheduling options in the Automating your backup section of this User's
Guide.

Overall, the Amazon S3 upload was our first, successful experiment in adding affordable, enterprise-grade qualities to
full a site backup solution. Even though that's years ahead of the competition, we do not settle with it. Akeeba Backup
has always been in very active development. Our desire to push the envelope is a core ingredient of the philosophy
behind the software. As a result, S3 - and DropBox - was just the beginning. Our roadmap includes support for several
options of taking the backup off your server. We will try to integrate practically all major storage facilities, as long as
they have a publicized integration API. If you have a specific need not covered by our base software, just contact us.
We listen carefully to the community feedback and we make the impossible happen. All that for a very low subscription
fee to the Professional downloads service.

118

Table of Contents
7. Introduction ................................................................................................................................ 121
1. Foreword ........................................................................................................................... 121
2. Why you need to care about ownership and permissions? ............................................................ 121
8. How your web server works .......................................................................................................... 122
1. Users and groups ................................................................................................................. 122
1.1. Users ...................................................................................................................... 122
1.2. Groups .................................................................................................................... 122
1.3. How users and groups are understood by UNIX-derived systems ........................................ 123
2. Ownership .......................................................................................................................... 123
2.1. Process ownership ..................................................................................................... 123
2.2. File ownership .......................................................................................................... 124
3. Permissions ........................................................................................................................ 125
3.1. The three types of permissions .................................................................................... 125
3.2. What permissions can control ...................................................................................... 125
3.3. Permissions notation .................................................................................................. 126
3.3.1. The textual notation ........................................................................................ 126
3.3.2. The octal notation ........................................................................................... 126
9. Securing your Akeeba Backup installation ....................................................................................... 128
1. Access rights ...................................................................................................................... 128
2. Securing the temporary and output directories ........................................................................... 128
3. Securing file transfers .......................................................................................................... 129

120

Chapter 7. Introduction
1. Foreword
Since you have chosen Akeeba Backup for backing your site up, it is obvious that you are using Joomla!™ as your
web-based Content Management System. By using Joomla!™ you have embarked to the joyful adventure of managing
a PHP powered website. Usually, this last part is gone unnoticed. The fact that you are using a PHP application is
often taken for granted, but when it comes down to security and problem solving, this is the key concept of which
you should have a strong grasp.

This part of the documentation deals with the basic concepts of PHP website management and their implications upon
using Akeeba Backup. In this part, we will see the intricacies of access permissions, web site users and the impact
of various PHP settings on your site's operability and security. This is not meant to be a concise manual on website
administration. There are plenty of web and off-line resources with more in-depth information on the subject, but this
introduction will quickly get you up to speed.

This document is no light reading; it is purposely sprinkled with a lot of tech-talk, albeit explained in layman's terms.
Our objective was not to write a document which can be read and understood in a single reading. Some things you
will understand by the first time you'll have read it. Most of it you will only get it after reading it again. A few shady
areas will only become clear reading over again and referring to it every time you get stuck managing your site.

2. Why you need to care about ownership and
permissions?
Most probably your server is running on Linux™, or another UNIX™-derivative operating system. You might have
read, or heard, how these operating systems are safer and more secure than others. This is just half the story. The real
security power of such operating systems stems from the way they manage files and directories, allowing or disabling
access to them depending on who asks for it and what he's trying to do.

This management is pretty much like electricity in the Western world. It never gets in your way and you don't think
about it, but you must have some basic understanding of it so as not to run the risk of getting toasted by it. That's
how it goes with ownership and permissions. You might not think about them a lot, but potentials crackers do. If you
don't manage permissions wisely, you might be creating a security hole on your server which can be exploited by a
malicious cracker. Nobody wants his site cracked, right?

The following chapter will analyze how your web server works under the hood, so that you can grasp the third chapter,
which analyzes all the ways you can secure your backup files so as not to fall prey on a cracker.

121

Chapter 8. How your web server works
1. Users and groups
The concept of users is the fundamental block of ownership separation on multiuser operating systems. All Windows™
versions based on the NT kernel are such; Windows™ NT, 2000, XP, Vista are all multiuser operating systems. Other
UNIX variants are also inherently multiuser, including Linux™ , BSD™ flavours, MacOSX™ , etc. Since most web
servers capable of running Joomla!™ are based on Linux™ , we will talk about the Linux™ user system, which is
in fact the same as the UNIX user system; after all, GNU/Linux is nothing but an open-source UNIX variant which
became very popular among geeks and recently among other people, too.

1.1. Users
As we mentioned, the fundamental block of ownership separation is a user . Each user has an entry in the system's
password database and consists of a user name and a numeric user ID . A user is not necessarily linked to a physical
person; in fact, most utilities and services create and operate under a user of their own.

The numeric user ID is an unsigned integer, therefore it can take a value between 0 and 65534. The user name and
the numeric user ID are usually linked with an one to one relationship, meaning that if you know either one you can
find the other one. The exception to this is most ISPs. In this case, because there are more users than the available
number of user IDs, some numeric IDs will be reused, breaking the one to one relationship. However, on most - if
not all - hosts, the one to one relationship exists.

Some user IDs are special. By convention, user IDs below 500 are reserved for system users. These are special users
which are not assigned to some physical person. One of them, zero (0), has a very special meaning; it is assigned to
the super user , commonly called root . This user is the God of the system. He has unlimited powers. He can override
all access restrictions and make any kind of modification. For this reason, no sane system administrator logs in under
that user. They will always log in under a normal user and only temporarily log in as root whenever they need to
change system-wide settings.

1.2. Groups
Defining permissions per user is tiresome on systems which have more than a few users. In order to combat this incon-
venience, all UNIX systems have the notion of groups . A group is nothing but a collection of users. The relationship
to users is a many-to-many relationship, meaning that one user can belong to many groups and one group can contain
many users. To keep things dead simple, groups have the same format as users. Each group has a group name and a
numeric group ID . Again, not all groups are linked to a physical person; in fact there are a number of de facto group
names used to control access to crucial system resources.

The numeric group ID is an unsigned integer, therefore it can take a value between 0 and 65534. The group name and
group ID are linked with an one to one relationship, meaning that if you know either one you can find the other one.
I am not aware of exceptions to this rule and I can't think a reason, either.

There are some special group ID's. By convention, zero (0), is assigned to the root's group. Its sole member should be
root, or other users with a user ID of 0. It empowers its members to do anything they please on the system, almost like
the user ID 0 does. Noticed the "almost" part? Belonging to the root group alone, without having a user ID of 0, does
not give you infinite powers but it does grant you very broad access indeed!

Every user can belong to many different groups. To simplify things a little bit, every user has a so-called default group.
This means that one of the groups he is a member of will be his effective group, unless otherwise specified, in all
operations.

122

How your web server works

1.3. How users and groups are understood by UNIX-de-
rived systems
This section is a bit ahead of the rest of this chapter, I know that. The information contained here, though, clarify a lot
of what will follow, so it seemed only appropriate to include it here.

Every time the system has to store the owning user and group of a system item, it does so by storing the numeric user
and group IDs, not the names! The names are only used as a convenience; you can't remember that John's user ID is
637, but it's easy to remember that his user name is john. Likewise, remembering that group ID 22 controls access to
the CD-ROM drive is improbable, while remembering that the group named cdrom does that is self-understood.

Important
User IDs for a user with the same user name on different systems can be different. A user named example
on system A and system B might have one user ID on system A and a completely different on system B.
However, all UNIX-derived systems really know about are IDs, not names!

This is very (read: extremely) important when you transfer files from one system to another. All archive types which
store owner information (for example GNU tar ) store nothing but the numeric ID's. Moving these to another system
and extracting them will screw up ownership and permissions. Just because you have the user ID 567 on Host A doesn't
mean that you won't end up with user ID 678 on Host B; extracting such an archive would make all your files owned
by someone else, effectively screwing up your site.

2. Ownership
The term ownership implies that system items belong to someone. In the context of web site management the items
we are interested in are files and processes . Everybody understands what files are, but the term processes is rarely
understood amongst webmasters. So, let's explain it.

2.1. Process ownership
Every time you run a program, be it interactive or a system service, you create a process. A process is a piece of
code being executed by the operating system. A process can spawn child processes which can spawn new threads .
In layman's terms, a program can start other instances of itself or another program and they, in turn, can start small
pieces of executable code which can run in parallel with the main program.

Programs do not start spontaneously. Someone has either got to start them, or instruct the system to start them when
some criteria are met. This sentence is the acknowledgement of the simplicity behind a computer system; it can't think
on its own, humans have to tell it what to do one way or the other. Based on how a program starts, it process will
be owned by some user.

In the first and simplest case, when you start a program, the ownership is almost self-understood. You are logged in
as some user, so the process of the program you have executed is owned by your user. It's simple as that. This also
implies that the process has the same permissions as the owning user, that's why we say that the process runs under
this user; its access level is at most as much as the owning user, so the process is under the user.

The other case, instructing the system to start a process, is somewhat different. Usually, the utilities which are used to
start programs automatically are the system initialisation scripts, time-based execution programs (for example, cron
and at ), etc. All of these programs are in most cases owned by root and are executed under root privileges. On top of
that, most programs started this way are system services, running as long as the system is up and running. But do you
remember what we said before? Root is the God of the system. Normally, these programs would get root's privileges,
posing a huge security hole. If there is a bug in the program and some malicious user exploits it, he could wreck havoc
on the system; root is above all restrictions.

123


In order to combat this possibility, UNIX systems employ a feature which allows processes to drop privileges and run
under a different user than the one which started them. In fact, they change their ownership! To prevent abuse of this
feature, a process must run under root privileges to be able to switch to another user. This feature is extensively used
by system services, including MySQL and Apache.

In the context of web site management, Apache is of special interest. Apache is the de facto web server for Linux
systems and is being used by over 50% of Internet sites, according to NetCraft's August 2008 survey. Chances are you
are using it on your site, too. Apache, like most UNIX services (affectionately called daemons) uses the feature to drop
privileges. The user and group under which it runs are defined in its configuration files. These configuration files are
usually out of the reach of regular users (like you!) on commercial hosts, for security reasons.

There is a special case which acts as the exception to the Apache rule. Many commercial hosts run suPHP-enabled
Apache installations. This is an extension to the normal PHP's mode of operation which allows each PHP page to run
in a process owned by the file's owner (more on file ownership in the next sub-section). This means that each of the
PHP files under your account on such a host run as the user which has been assigned to your account. And, if this still
isn't apparent to you, such hosts nullify the burden of ownership and permissions (more on permissions in the next
section). To put it clearly: with suPHP the file owner, your own user and the Apache user are one and the same. If you
are looking for a decent host, find one which is using suPHP. It's better for security and removes a lot of administrative
burden from you. A win-win situation.

2.2. File ownership
Everybody knows what a file is, right? Well, we all know intuitively what a file might be, but we seldom know what
exactly it is. A file is actually consisted of at least two parts. The first part is the file data, what we intuitively understand
as the file contents. The second part is the file system entry, which makes the file data an identifiable entity. This
is where the operating system stores all kinds of information, such as how the file is named, where it is located in
the file system hierarchy, when it was modified, etc. It also contains information about who owns the files and what
are the file's permissions. You might be surprised reading this, but only this latter, informative, part is required for
a file. Really!

It seems absurd to have a file without file data, but it is anything but that. There are some special "files" (more correctly:
file system entries) in the UNIX world. You have devices, whose "files" actually point to a serial input/output provided
by this device, for example the serial port of your computer. There are directories, which obviously don't have any
data contained; they are used for organising files only. There are soft links, which are pointers to other files in the file
system, used to have standardised names and locations on files which might be moved around or have varying names.
There are also these wired beasts called "hard links", some peculiar file system entries which point to the file data of
another file, making virtually impossible to know which is the "original" file and which is its clone. Their usefulness is
only apparent to the UNIX gurus, therefore out of the scope of this document. For the purpose of website management
we are only concerned about regular files (hereby called "files"), directories and soft links (hereby called "links").

All files, directories and links are owned by a user and a group, be they files or links. In fact, they are owned by a user
ID and a group ID. Normally, the ownership is inherited by the creating process's ownership. When you create a file
directly from an interactive editor application the editor's process is owned by your user ID and your default group ID,
therefore the file will be owned by your user ID and your default group ID.

Links are a special case on their own. They are not files, they are pointer to files. The ownership (and permissions)
of links is irrelevant. Whenever a process tries to access a link, the underlying operating system "follows" the link,
until it finds a regular file. Therefore, the ownership that matters is that of the file linked to, not the link itself. This
feature of the operating system prevents unauthorised access to arbitrary files, normally accessible to specific users
only, from users who just happen to know the path to those files.

What is especially interesting is the correlation between FTP, web server and file ownership. Whenever you access
FTP, you log in as some user. This user is linked to a system user (often the same user assigned to you by host), so
logging in FTP actually has the same effect as logging into the system as this user. Common sense implies that all file
operations are performed under this user and all files created (read: uploaded) through FTP will be owned by this user.

124


Conversely, whenever you are using a web interface to perform file operations, you are using a web application - or
any PHP script/application for that matter - running on the web server whose process is owned by a different user.
Therefore, whenever you create files from a web application, they will be owned by the user the web server runs under.

The distinction of file ownership in these two cases is of paramount importance when you get stuck with files which
are accessible to FTP but inaccessible to the web server, or vice versa. This minute distinction is the cause of a lot
of grief to many webmasters, so beware!

3. Permissions
So far you have learned about users, groups and ownerships. But how do they all stick together? Why these are
necessary to have in the first place? The reason is simple: security. In multiuser operating systems you normally
don't like users snooping around other people's files, especially when those files contain sensitive information, such
as passwords. The most common method for overcoming this problem is to assign permissions on each system item,
controlling who can do what. This simple concept works wonderfully; it's like putting doors on a building and giving
people only the keys for the doors to areas they should have access to.

3.1. The three types of permissions
We already learned that each system item is owned by a user ID and a group ID. Whenever a process tries to access
a system item, the operating system checks the permissions and decides if it will proceed with the operation or deny
access. It seems reasonable to have control over what a process with the same owning user ID can do with it, what the a
process with the same owning group ID can do with it and, finally, what the rest of the world can do with it. Indeed, this
is the rationale behind the three types of permissions we can define on UNIX systems. In order of precedence they are:

User permissions They are the access rights granted to the owning user of the item. Every process with the same
owning user ID as the item's owning user ID has these access rights. These access rights have
precedence over all other permissions.

Group permis- These are the access rights granted to the owning group of the item. Every process with the same
sions owning group ID as the item's owning group ID has these access rights. These access rights are
applied only if the owning user ID's of the process and the item do not match, but their owning
group ID's match.

Other permis- These are the access rights granted to the rest of the world. If the owning user ID's of the process
sions and the item do not match and the same happens for the owning group ID's as well, these access
rights will be applied.

3.2. What permissions can control
We will be focused on permissions on files and directories, the building blocks of a web site. Permissions can control
only three different actions:

Read The ability to read a file, or get a directory listing.

Write The ability to write to a file, or the ability to create, rename and delete files and subdirectories
on a directory.

Execute (or For files, it controls the ability to be directly executable from the command line. It is only mean-
Browse, for di- ingful for binary programs and executable scripts. For directories, it controls the ability to change
rectories) to that directory. Note that if this is disabled you can't usually obtain a directory listing and file
read operations might fail.

These three actions, combined with the three access request groups (owning user, owning group and the rest of the
world) give us a total of nine distinct operations which can be controlled. Each action is an on/off switch. If a permission

125


is set, it is turned on and the right to perform the action is granted. If the permission is not set, the switch is off and
the right to perform the action is not granted.

3.3. Permissions notation
The two most common notations for permissions is the textual notation and the octal notation. Each one has its own
virtues.

3.3.1. The textual notation
The textual notation is traditionally used in UNIX long directory listing format and in most FTP clients listings as well.
It consists of ten characters. The first one displays the file type. It can be one of dash (regular file), "d" (a directory) or
"l" (a link). The following nine characters display the permissions, consisting of three groups of three letters each. The
groups are in order of appearance: owning user, owning group and others. The permissions on each group are in order
of appearance: read (denoted with r), write (denoted with w) and execute/browse (denoted with x). If a permission is
not set, a dash appears instead of the letter.

For example, the string -rwxr-xr-x means that it is a regular file, the owning user has read/write/execute permis-
sions, the owning group has read and execute permissions and so does the rest of the world. On the other hand, the
string dr-x------ indicates that we have a directory whose owning user has read and browse permissions and
everybody else (owning group and the rest of the world) have no right to access it.

3.3.2. The octal notation
This is the de facto standard geeks use to communicate permissions. The benefit of this approach is that you only need
four characters to fully define them and they're easier to read (to the trained eye, at least).

Permissions are in fact a bit field. Each permission is a bit which can be turned on or off. If you put bits together they
form bytes (by grouping eight bits together). Many bytes one next to the other form a computer-readable representation
of a whole number (an integer). If you write this down in base 8, you've got the octal representation. If you didn't
understand this, it's OK. We'll explain it the easy way.

The octal notation consists of four numbers. In the context of web site management you can consider the first to be
always zero and sometimes omitted. The next three numbers describe each one the permissions. The second number
describes owning user permissions. The third number describes owning group's permissions. The fourth number de-
scribes the permissions for the rest of the world. Each number is 0 to 7. The meaning of each number is simple:

0 No access

1 Execute/browse access only

2 Write access only

3 Write and execute/browse access

4 Read access only

5 Read and execute/browse access

6 Read and write access

7 Full access

It is almost apparent that "1" stands for execute only, "2" stands for write only and "4" stands for read only. Adding
these values together gives you the rest of the combinations. You can't add together the same value (1+1 is forbidden

126


as it is meaningless), so each of the composite values can be broken down to its components very easily. You don't
even have to memorise the whole table!

A permission of 0777 means that the owning user, owning group and the rest of the world can read, write and execute
the file (full permissions for everyone). A 0764 permission means that the owning user has full access, the owning
group has read and write access and the rest of the world have read only access.

127

Chapter 9. Securing your Akeeba
Backup installation
1. Access rights
As with every software which can access your site as a whole, Akeeba Backup needs to control who's got access to its
backup functionality. Due to the lack of a thorough ACL mechanism in Joomla! 1.0 and 1.5, we have decided to make
the administrator (back end) of this component available by default to the Super Administrators only. This group of
people already has infinite access to the access, making them the ideal candidate for backup operators. You can change
this default behavior from the component's Parameters button in the Control Panel page.

The front-end backup feature is a different story. Since it has to be available to unattended scripts which can't use
cookies and interactive user authentication, a different approach was taken. Instead of requiring the user to have logged
in with Joomla! it uses a simple "secret word" authentication model. Because this "secret word" is transmitted in clear
text we strongly advise against using it over anything else than a local network (for example, an automated tool running
on the same host as the web server). If you have to use it over the Internet we strongly advise using a secure protocol
connection (HTTPS) with a valid commercially acquired certificate.

If you want to enhance the security of your site, we strongly advise you to use a commercial-grade ACL system,
such as Dioscouri's JUGA or `CorePHP` Community ACL on top of Akeeba Backup's rudimentary access control and
Joomla! 1.6's ACL system. Such ACL systems allow you to fine-tune the permission settings down to the user and
component view level, if so required. Using such an ACL scheme you can create, for example, a backup operator user
who has access to the Backup Now and configuration pages of Akeeba Backup, but not the Download function.

2. Securing the temporary and output directo-
ries
About the temporary directory
By default - and unless you specify something different - the same temporary directory as Joomla!™ is used. This is
normally a directory named "tmp" on your site's root. The temporary files are short-lived, unless a fatal PHP error
or a loss of connection abruptly halts Akeeba Backup's operation. In this case, the temporary file will not be deleted
before a new backup is attempted, or you visit the Control Panel page.

Important
The only temporary files the component uses are database dumps and internal state information ("memory")
data. Unauthorised access to them can lead to leakage of sensitive information or could be used to facilitate
compromising your site's integrity.

To this end, it is sane to restrict the access to the temporary directory. If you can't use an off-site temporary directory,
we srongly advice disabling direct web access to this directory. This can be done by creating an .htaccess file on
the directory with the following contents:

deny from all

Securing the backup output directory
By default the component uses a non secure location to store its backup files, within your site's file system hierarchy,
namely administrator/components/com_akeeba/backup. This location is well known and can be - the-

128

Securing your Akee-
ba Backup installation

oretically - accessed directly from a web browser. Since the backup output directory stores the results of your backup
attempts, that is SQL files containing database backups and archive files containing all of your site, a malicious person
with access to this location could steal sensitive information or compromise your site's integrity.

The first line of defense, is to use mangled, hard to guess, names for the SQL backup. However, in the era of mul-
ti-MBPS xDSL Internet connections and scripting, it wouldn't take an attacker that long to figure out the filename.
Remember: security through obscurity is no security at all!

As a second line of defense, we include a secure .htaccess on the default backup output directory to disable direct
web access. However, this is only possible on Apache-powered web servers which allow the use of .htaccess files.
You should check with your host to ensure that this kind of protection is possible on your site.

However, this is not enough. Security experts argue that storing backups within the potentially vulnerable system itself
might be a security risk. It is possible that a malicious person could gain access via other means. Think of a simple
scenario. You have an Administrator with a weak password a hacker eventually guesses. Now the hacker can log in to
your site, but doesn't have access to the component. Despite that, you have installed a file administration component,
such as eXtplorer, which allows administrators to browse the site's file system and download files. How long would
it take before your site got compromised? Right. Not very long indeed!

The best approach is to use a directory which is outside your web server's root. By definition, this is not directly
exposed to the web and is usually unavailable to file administration utilities.

If you are really paranoid about securing your site's backup files - like we are for our own sites! - you can use Akeeba
Remote Control. Remote Control is a desktop application for Microsoft Windows™ which allows backing up your
site from your desktop, with options to automatically downloading the backup archive and remove the server's copy of
this file. Alternatively, you can use our backup file post-processing options, for example uploading all backup archives
to Amazon S3 and removing your server copy.

3. Securing file transfers
Whenever you download your backup files you can fall prey to a malicious user. Backup files are transferred unen-
crypted (unless you access your site's administrator section through the HTTPS protocol). It is possible for a resource-
ful hacker to launch a man-in-the-middle attack. In such a case, whatever you download from your site will be directed
to the hacker's computer before reaching yours.

To avoid such insecure scenarios, we advise against using the Download button in the backup administration page. We
suggest that you use Secure FTP (SFTP) instead. Avoid using the plain old FTP, because your password and data are
transmitted in clear text (unencrypted) over the Internet. Also avoid FTPS and FTPES (FTP over SSL) as they have
some security restrictions, like requiring your FTP server to have a commercially obtained SSL certificate in order
to be really effective. Sometimes, your host will allow secure access to a web based control panel which has a file
download feature. You could use this, it's as safe as it gets.

There is also another reason why not to use the Download button in the backup administration page. Your host neither
discriminates the back end and front end pages of your Joomla! site, nor your IP from the rest of the world. As a
result, every time you use the Joomla!™ back end, the data transferred counts towards your monthly bandwidth quota.
Backup archives are large, sometimes in the hundreds of megabytes. Transferring them through the Download feature
will incur a huge loss on your monthly bandwidth quota. Using Secure FTP or your host's control panel usually does
not count through the bandwidth quota and should be used instead. It's better to ask your host, though; some include the
FTP and SFTP traffic in your monthly bandwidth quota. Finally, the Download feature doesn't work with all possible
configurations and has objective problems with the handling of very large archives; this is a technical limitation which
can not be overcome in the PHP level the component operates. Most notably, many servers which use the FastCGI
mode do not work at all with the Download button. They will simply throw an HTTP 500 error page, or a "file not
found" message. We've tried all the tricks in the book and then some more, but there's really absolutely nothing we
can do about it. Sorry.

129

Securing your Akee-
ba Backup installation

Important
The preferred and suggested method for downloading your backup files - for several reasons - is using FTP in
BINARY mode, preferably over an encrypted connection. Alternatively, you can use Akeeba Remote Control
which uses this approach when downloading backup archives.

130

Table of Contents
A. The JPA archive format, v.1.2 ...................................................................................................... 133
B. The JPS archive format, v.1.9 ....................................................................................................... 137
C. GNU Free Documentation License ................................................................................................. 141

132

Appendix A. The JPA archive format,
v.1.2
Design goals
The JPA format strives to be a compressed archive format designed specifically for efficiency of creation by a PHP
script. It is similar in design to the PKZIP format, with a few notable differences:

• CRC32 is not used; calculation of file checksums is time consuming and can lead to errors when attempted on large
files from a script running under PHP4, or a script running on PHP5 without the hash extension.

• Only allowed compression methods are store and deflate.

• There is no Central Directory (simplifies management of the file).

• File permissions (UNIX style) are stored within the file.

Even though JPA is designed for use by PHP scripts, creating a command-line utility, a programming library or even
a GUI program in any other language is still possible. JPA is not supposed to have high compression rations, or be
secure and error-tolerant as other archive formats. It merely an attempt to provide the best compromise for creating
archives of very large directory trees using nothing but PHP code to do it.

This is an open format. You may use it in any commercial or non-commercial application royalty-free. Even though
the PHP implementation is GPL-licensed, we can provide it under commercial-friendly licenses, e.g. LGPL v3. Please
ask us if you want to use it on your own software.

Structure of an archive
An archive consists of exactly one Standard Header and one or more Entity Blocks . Each Entity Block consists of
exactly one Entity Description Block and at most one File Data Block . All values are stored in little-endian byte order,
unless otherwise specified.

All textual data, e.g. file names and symlink targets, must be written as little-endian UTF-8, non null terminated strings,
for the widest compatibility possible.

Standard Header
The function of the Standard Header is to allow identification of the archive format and supply the client with general
information regarding the archive at hand. It is a binary block appearing at the beginning of the archive file and there
alone. It consists of the following data (in order of appearance):

Signature, 3 bytes The bytes 0x4A 0x50 0x41 (uppercase ASCII string “JPA”) used for identification purposes.

Header length, 2 Unsigned short integer represented as two bytes, holding the size of the header in bytes. This is
bytes now fixed to 19 bytes, but this variable is here to allow for forward compatibility. When extra
header fields are present, this value will be 19 + the length of all extra fields.

Major version, 1 Unsigned integer represented as single byte, holding the archive format major version, e.g. 0X01
byte for version 1.2.

Minor version, 1 Unsigned integer represented as single byte, holding the archive format minor version, e.g. 0X02

133

The JPA archive format, v.1.2

File count, 4 Unsigned long integer represented as four bytes, holding the number of files present in the archive.
bytes

Uncompressed Unsigned long integer represented as four bytes, holding the total size of the archive's files when
size, 4 bytes uncompressed.

Compressed size, Unsigned long integer represented as four bytes, holding the total size of the archive's files in their
4 bytes stored (compressed) form

Extra Header Field - Spanned Archive Marker
This is an optional field, written after the Standard Header but before the first Entity Block, denoting that the current
archive spans multiple files. Its structure is:

Signature, 4 bytes The bytes 0x4A, 0x50, 0x01, 0x01

Extra Field The length of the extra field, without counting the signature length. It's value is fixed and equals 4.
Length, 2 bytes

Number of parts, The total number of parts this archive consists of.
2 bytes

When creating spanned archives, the first file (part) of the archive set has an extension of .j01, the next part has an
extension of .j02 and so on. The last file of the archive set has the extension .jpa.

When creating spanned archives you must ensure that the Entity Description Block is within the limits of a single part,
i.e. the contents of the Entity Description Block must not cross part boundaries. The File Data Block data can cross
one or multiple part blocks.

Entity Block
An Entity Block is merely the aggregation of an Entity Description Block and at most one File Data Block. An Entity
can be at present either a File or a Directory. If the entity is a File of zero length or if it is a Directory the File Data
Block is omitted. In any other case, the File Data Block must exist.

Entity Description Block
The function of the Entity Description Block is to provide the client information about an Entity included in the archive.
The client can then use this information in order to reconstruct a copy of the Entity on the client's file system. It is a
binary block consisting of the following data (in order of appearance):

Signature, 3 bytes The bytes 0x4A, 0x50, 0x46 (uppercase ASCII string “JPF”) used for identification purposes.

Block length, 2 Unsigned short integer, represented as 2 bytes, holding the total size of this Entity Description
bytes Block.

Length of entity Unsigned short integer, represented as 2 bytes, holding the size of the entity path data below.
path, 2 bytes.

Entity path data, Holds the complete (relative) path of the Entity as a UTF16 encoded string, without trailing null.
variable length. The path separator must be a forward slash (“/”), even on systems which use a different path
separator, e.g. Windows.

Entity type, 1 • 0x00 for directories (instructs the client to recursively create the directory specified in Entity
byte. path data).

• 0x01 for files (instructs the client to reconstruct the file specified in Entity path data)

134


• 0x02 for symbolic links (instructs the client to create a symbolic link whose target is stored,
uncompressed, as the entity's File Data Block). When the type is 0x02 the Compression Type
MUST be 0x00 as well.

Compression • 0x00 for no compression; the data contained in File Data Block should be written as-is to the
type, 1 byte. file. Also used for directories, symbolic links and zero-sized files.

• 0x01 for deflate (Gzip) compression; the data contained in File Data Block must be deflated
using Gzip before written to the file.

• 0x02 for Bzip2 compression; the data contained in File Data Block must be uncompressed
using BZip2 before written to the file. This is generally discouraged, as both the archiving and
unarchiving scripts must be ran in a PHP environment which supports the bzip2 library.

Compressed size, An unsigned long integer representing the size of the File Data Block in bytes. For directories,
4 bytes symlinks and zero-sized files it is zero (0x00000000).

Uncompressed An unsigned long integer representing the size of the resulting file in bytes. For directories, sym-
size, 4 bytes links and zero-sized files it is zero (0x00000000).

Entity permis- UNIX-style permissions of the stored entity.
sions, 4 bytes

Extra fields data, The extra fields for each file are stored here. The total length of extra fields is included in the
variable length Block Length above

Each Extra Fields consists of:

Extra Field Iden- A signature denoting the data stored in the extra field
tifier, 2 bytes

Extra Field The length (in bytes) of the Extra Field Data
Length, 2 bytes

Extra Field Data, The internal structure varies by the type of the Extra Field, as noted in the Extra Field Identifier
variable length

Timestamp Extra Field
Its purpose is to store the date and time the file was modified. This extra field should be ignored for directories and
symlinks, or - if present - the Timestamp should be set to 0x00000000. Its format is:

Extra Field Iden- The bytes 0x00 0x01
tifier, 2 bytes

Extra Field The value 0x08 stored in little-endian format
Length, 2 bytes

Timestamp, 4 A 4-byte UNIX timestamp of the file's modification time, as returned by filemtime().
bytes

File Date Block
The File Data Block is only present if the Entity is a file with a non-zero file size. It can consist of one and only one
of the following, depending on the Compression Type:

135


• Binary dump of file contents or textual representation of the symlink's target, for CT=0x00

• Gzip compression output, without the trailing Adler32 checksum, for CT=0x01

• Bzip2 compression output, for CT=0x02

Change Log
Revision History
June 2009 NKD, Akeeba Developershttp://
www.akeebabackup.com
Updated to format version 1.1, fixed incorrect descriptions of header signatures

136

Appendix B. The JPS archive format,
v.1.9
Design goals
The JPS format strives to be a compressed archive format designed specifically for efficiency of creation by a PHP
script, while providing secure AES-128 encryption of the file descriptor and file contents. It is similar in design to
the JPA, with a few notable differences:

• Both the file descriptor and the file data are split to 64Kb blocks encrypted using AES-128 in CBC mode

• All files are compressed using Deflate (ZLib)

Even though JPS is designed for use by PHP scripts, creating a command-line utility, a programming library or even
a GUI program in any other language is still possible. JPS is supposed to have low to medium compression rations,
and be secure. However it is not as error-tolerant as other archive formats.

This is an open format. You may use it in any commercial or non-commercial application royalty-free. Even though
the PHP implementation is GPL-licensed, we can provide it under commercial-friendly licenses, e.g. LGPL v3. Please
ask us if you want to use it on your own software.

Important
When the password is blank, no encryption takes place. Archivers should take this into account when creating
files. Unarchivers should also take this into account when the user passes an empty string as their password.

When a non-blank password is used, all files are encrypted using the same password. More specifically, all
data blocks are encrypted using the same password.

Structure of an archive
An archive consists of exactly one Standard Header and one or more Entity Blocks . Each Entity Block consists of
exactly one Entity Description Block and at most one File Data Block. Each FIle Data Block consist of one or several
Data Chunk Blocks. All values are stored in little-endian byte order, unless otherwise specified.

All textual data, e.g. file names and symlink targets, must be written as little-endian UTF-8, non null terminated strings,
for the widest compatibility possible.

Standard Header
The function of the Standard Header is to allow identification of the archive format and supply the client with general
information regarding the archive at hand. It is a binary block appearing at the beginning of the archive file and there
alone. It consists of the following data (in order of appearance):

Signature, 3 bytes The bytes 0x4A 0x50 0x54 (uppercase ASCII string “JPS”) used for identification purposes.

Major version, 1 Unsigned integer represented as single byte, holding the archive format major version, e.g. 0X01

Minor version, 1 Unsigned integer represented as single byte, holding the archive format minor version, e.g. 0X09

137

The JPS archive format, v.1.9

Spanned archive, When set to 1, the archive spans multiple files
1 byte

Extra header The total length of extra headers. In version 1.9 of the format it is always 0.
length, 2 bytes

The total size of this header is 8 bytes, plus the size of the extra headers (if any).

Entity Block
An Entity Block is merely the aggregation of exactly one Entity Description Block, followed by the encrypted contents
of exactly one Entity Description Block Data and zero or one instances of a File Data Block. An Entity can be at
present a File, Symbolic Link or Directory. If the entity is a File of zero length or if it is a Directory the File Data
Block is omitted. In any other case, the File Data Block must exist.

Entity Description Block Header
The function of the Entity Description Block Header is to allow a client to read the encrypted Entity Description Block
Data. It is a binary block consisting of the following data (in order of appearance):

Signature, 3 bytes The bytes 0x4A, 0x50, 0x46 (uppercase ASCII string “JPF”) used for identification purposes.

Encrypted size, 2 The encrypted size of the following Entity Description Block Data
bytes

Decrypted size, 2 The decrypted size of the following Entity Description Block Data
bytes

Entity Description Block Data
it purpose is to provide the client information about an Entity included in the archive. The client can then use this
information in order to reconstruct a copy of the Entity on the client's file system. The data is written to the archive
encrypted with AES-128 in CBC mode. The Entity Description Block Data consists of the following information
before it is encrypted:

Length of entity Unsigned short integer, represented as 2 bytes, holding the size of the entity path data below.
path, 2 bytes.

Entity path data, Holds the complete (relative) path of the Entity as a UTF16 encoded string, without trailing null.
variable length. The path separator must be a forward slash (“/”), even on systems which use a different path
separator, e.g. Windows.

Entity type, 1 • 0x00 for directories (instructs the client to recursively create the directory specified in Entity
byte. path data). When the entity type is 0x00 the Compression Type MUST be 0x00 as well.

• 0x01 for files (instructs the client to reconstruct the file specified in Entity path data)

• 0x02 for symbolic links (instructs the client to create a symbolic link whose target is stored,
uncompressed, as the entity's File Data Block). When the type is 0x00 the Compression Type
MUST be 0x00 as well.

Compression • 0x00 for no compression; the data contained in File Data Block should be written as-is to the
type, 1 byte. file. Also used for directories, symbolic links and zero-sized files.

• 0x01 for deflate (Gzip) compression; the data contained in File Data Block must be deflated
using Gzip before written to the file.

138


• 0x02 for Bzip2 compression; the data contained in File Data Block must be uncompressed
using BZip2 before written to the file. This is generally discouraged, as both the archiving and
unarchiving scripts must be ran in a PHP environment which supports the bzip2 library.

Uncompressed An unsigned long integer representing the size of the resulting file in bytes. For directories, sym-
size, 4 bytes links and zero-sized files it is zero (0x00000000).

Entity permis- UNIX-style permissions of the stored entity.
sions, 4 bytes

File Modification The UNIX timestamp of the file's last modification time. For directories and symlinks it must be
Time, 4 bytes ignored and set to 0x00000000.

File Data Block
The File Data Block is only present if the Entity is a file with a non-zero file size. It consists of one or more Data
Chunk Blocks. Do note that the File Data Block has no header. The collection of one or several Data Chunk Blocks
is called the "File Data Block".

Data Chunk Block
Each Data Chunk Block consists of the following information:

Encrypted size, 4 Unsigned long containing the size, in bytes, of the encrypted data.
bytes

Decrypted size, 4 Unsigned long containing the size, in bytes, of the decrypted data. If the decryption yields more
bytes bytes, the extraneous bytes must be trimmed off.

Encrypted data, The decrypted data is compressed, depending on the Compression Type, and then encrypted using
variable length AES-128 in CBC mode. The compression format used may be:

• Binary dump of file contents or textual representation of the symlink's target, for CT=0x00

• Gzip compression output, without a trailing Adler32 checksum, for CT=0x01

• Bzip2 compression output, for CT=0x02

In split archives, the first 8 bytes must appear within the same part. They may or may not be in the same part as the
Entity Description Block Data. The Encrypted Data can span multiple parts. Since the minimum part size is 64Kb and
the maximum Decrypted Size can't be over 64Kb, the Encrypted Data will either be in the same part in its entirety,
or span exactly two parts.

End-of-archive header
This header is written after the end of the archive data, at the end of the last part of the archive.

When creating spanned archives, the first file (part) of the archive set has an extension of .j01, the next part has an
extension of .j02 and so on. The last file of the archive set has the extension .jps. You must also ensure that the Entity
Description Block is within the limits of a single part, i.e. the contents of the Entity Description Block must not cross
part boundaries. The File Data Block data can cross one or multiple part blocks, but the header of each Data Chunk
Block must both be inside the same part.

This header is written after the end of the archive data, at the end of the last part of the archive. Its structure is:

139


Signature, 3 bytes The bytes 0x4A, 0x50, 0x45 ("JPE")

Number of parts, The total number of parts this archive consists of. Non-spanned archives should set this to 1.
2 bytes

File count, 4 Unsigned long integer represented as four bytes, holding the number of files present in the archive.
bytes

Uncompressed Unsigned long integer represented as four bytes, holding the total size of the archive's files when
size, 4 bytes uncompressed.

Compressed size, Unsigned long integer represented as four bytes, holding the total size of the archive's files in their
4 bytes stored (compressed) form

The size of the EOA header is 17 bytes for version 1.9 of the format.

Change Log
Revision History
July 2010 NKD, Akeeba Developershttp://
www.akeebabackup.com
Described version 1.9

140

Appendix C. GNU Free Documentation
License
Copyright (C) 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St , Fifth Floor, Boston, MA 02110-1301
USA . Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not
allowed.

0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense
of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either
commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit
for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the
same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free
documentation: a free program should come with manuals providing the same freedoms that the software does. But this
License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether
it is published as a printed book. We recommend this License principally for works whose purpose is instruction or
reference.

1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder
saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license,
unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such
manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy,
modify or distribute the work in a way requiring permission under copyright law.

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied
verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the
relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and
contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of
mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical
connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position
regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sec-
tions, in the notice that says that the Document is released under this License. If a section does not fit the above def-
inition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant
Sections. If the Document does not identify any Invariant Sections then there are none.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the
notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and
a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification
is available to the general public, that is suitable for revising the document straightforwardly with generic text editors

141

GNU Free Documentation License

or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor,
and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input
to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has
been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not
Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, La-
TeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript
or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque
formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML
for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript
or PDF produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold,
legibly, the material this License requires to appear in the title page. For works in formats which do not have any
title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the
beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains
XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section
name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve
the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according
to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the
Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards
disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on
the meaning of this License.

2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that
this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced
in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical
measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you
may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also
follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering
more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that
carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the
back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover
must present the full title with all words of the title equally prominent and visible. You may add other material on the
covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and
satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as
fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a ma-
chine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-net-

142


work location from which the general network-using public has access to download using public-standard network
protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must
take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transpar-
ent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an
Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large
number of copies, to give them a chance to provide you with an updated version of the Document.

4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above,
provided that you release the Modified Version under precisely this License, with the Modified Version filling the role
of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy
of it. In addition, you must do these things in the Modified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous
versions (which should, if there were any, be listed in the History section of the Document). You may use the same
title as a previous version if the original publisher of that version gives permission.

B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications
in the Modified Version, together with at least five of the principal authors of the Document (all of its principal
authors, if it has fewer than five), unless they release you from this requirement.

C. State on the Title page the name of the publisher of the Modified Version, as the publisher.

D. Preserve all the copyright notices of the Document.

E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified
Version under the terms of this License, in the form shown in the Addendum below.

G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's
license notice.

H. Include an unaltered copy of this License.

I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new
authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History"
in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page,
then add an item describing the Modified Version as stated in the previous sentence.

J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Docu-
ment, and likewise the network locations given in the Document for previous versions it was based on. These may
be placed in the "History" section. You may omit a network location for a work that was published at least four
years before the Document itself, or if the original publisher of the version it refers to gives permission.

K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in
the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or
the equivalent are not considered part of the section titles.

M.Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version.

N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section.

143


O. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and
contain no material copied from the Document, you may at your option designate some or all of these sections as
invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These
titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified
Version by various parties--for example, statements of peer review or that the text has been approved by an organization
as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover
Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one
of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already
includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you
are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the
previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity
for or to assert or imply endorsement of any Modified Version.

5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under the terms defined in section
4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the
original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice,
and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be
replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make
the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or
publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list
of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one
section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled
"Dedications". You must delete all sections Entitled "Endorsements".

6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this License, and replace
the individual copies of this License in the various documents with a single copy that is included in the collection,
provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided
you insert a copy of this License into the extracted document, and follow this License in all other respects regarding
verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT
WORKS
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on
a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation

144


is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the
Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not
themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less
than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document
within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must
appear on printed covers that bracket the whole aggregate.

8. TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms
of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders,
but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant
Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty
Disclaimers, provided that you also include the original English version of this License and the original versions of
those notices and disclaimers. In case of a disagreement between the translation and the original version of this License
or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section
4) to Preserve its Title (section 1) will typically require changing the actual title.

9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License.
Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate
your rights under this License. However, parties who have received copies, or rights, from you under this License will
not have their licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time
to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new
problems or concerns. See http://www.gnu.org/copyleft/ [http://www.gnu.org/copyleft/] .

Each version of the License is given a distinguishing version number. If the Document specifies that a particular
numbered version of this License "or any later version" applies to it, you have the option of following the terms and
conditions either of that specified version or of any later version that has been published (not as a draft) by the Free
Software Foundation. If the Document does not specify a version number of this License, you may choose any version
ever published (not as a draft) by the Free Software Foundation.

ADDENDUM: How to use this License for your
documents
To use this License in a document you have written, include a copy of the License in the document and put the following
copyright and license notices just after the title page:

Copyright (C) YEAR YOUR NAME.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU
Free Documentation License, Version 1.2 or any later version published by the Free Software Foun-

145


dation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the
license is included in the section entitled "GNU Free Documentation License".

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts." line with this:

with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST,
and with the Back-Cover Texts being LIST.

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alterna-
tives to suit the situation.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel
under your choice of free software license, such as the GNU General Public License, to permit their use in free software.

146

Akeeba backup-guide

More Related Content

What's hot (17)

Similar to Akeeba backup-guide (20)

More from Vineet Kumar Saini (20)

Recently uploaded (20)

Akeeba backup-guide