Support

Hello Johannes,

It's not as a dire situation as it may seem. Akeeba Backup was designed with flexibility in mind. There are more than one ways to achieve something in the component in an attempt to make sure that no matter what you can have a reliable backup. Let's explore your alternatives.

First, I'd like to note that maybe you don't need to worry about being able to backup your site. The space consumed by your web site also includes data not being backed up by Akeeba Backup such as: log files, temporary files, cache files, emails, files outside your web root. My experience is that log files and cache files may take up several Gigabytes. For instance this site backs up to a cozy 150Mb but it consumes an excess of 8Gb of disk space. The bulk of the data on our server is log and cache files.

If a full backup is not possible, there is the possibility of doing a two phase backup. Create two backup profiles. In the first profile backup everything except your large media files. In the second profile backup the large media files and nothing else. It usually suffices to take daily backups with the first profile (resulting in a rather small backup archive) and weekly or monthly backups with the second profile.

Even if this is not acceptable, Akeeba Backup has a few aces up its sleeve. You said that your host does not allow connecting to external FTP servers. Well, Akeeba Backup also supports storing your backup archives to third party file storage services such as Box.net, Dropbox, Amazon S3, SugarSync, Microsoft Windows Azure BLOB storage, RackSpace CloudFiles and so on. These services are accessed via their web APIs, not FTP, so there is a good chance they are not blocked. I'd suggest trying Amazon S3. For those tight space situations, Akeeba Backup offers a way to take your backup in small chunks, upload them and immediately delete them from your server. In order to do that, in Akeeba Backup's Configuration page click on the Configure button next to the "Data processing engine" and check the following boxes:
- Process each part immediately
- Delete archive after processing
These options are available for the vast majority of data processing engines. Then click on the Configure button next to the Archiver engine and set the Part Size for Split Archives to a value of 50, 20, 10 or 5Mb. The exact value depends on the transfer speed between your server and the selected storage provider. Usually values around 10 and 20Mb work best. You will have to do some trial and error.

Hi Johannes,

1. You can use the "Files and Directories Exclusion" feature of Akeeba Backup to not backup those 11Gb of raw photos.

2. You can't use OwnCloud with Akeeba Backup. It requires using a WebDAV interface. WebDAV is not very well supported by PHP; it requires using the cURL library and it must have WebDAV support built in (it usually doesn't).

3. As long as Joomla! can read its own files and database (it does, otherwise the site wouldn't work!) Akeeba Backup –which runs inside Joomla!– can back it all up. Akeeba Backup was primarily designed to move sites across different servers. Site backup and restoration is just a small subset of this operation: it's moving a site back to its origin. This is to say that taking a backup is sufficient to move a site to a different server :)

Regarding your PS, it's a bad idea. Akeeba Backup shines when you let it perform full site (files + database) backups. It even adds its own restoration script (Akeeba Backup Installer) in the backup archive to make the site restoration extremely simple. If you take separate SQL and file backups you're shooting yourself in the feet, tying your hands behind your back and jumping off an airplane without a parachute. Of course you can do that... but why?

A slightly different approach would work (combining your two propositions in one procedure):
- Backup Joomla!, excluding the directory where com_gallery stores its images, not com_gallery itself
- Download backup
- Restore the backup locally
- Download the images manually

This approach works for both directions, live to local and local to live.

Pro tip: transferring all of the images every time you want to transfer a site between the two servers is a pain in the rear, as we're talking about a whooping 11Gb. You can use an FTP sync programme to only transfer the changed files. On my Mac I'm using Transmit, but I'm sure that other FTP clients support that as well.

You're welcome!

Regarding Linux sync tools, rsync is the first one which comes in mind thanks to SSH support and because it's purpose built to do file syncing only. wget and curl are close seconds. Beyond that I've not heard of anything else being used in production environments.