Support

Yes, this shouldn't be in the description, because it is a manual process.

The idea is that you can have files-only and database-only backups which you can extract on top of the other to effectively simulate incremental backups. Since this process isn't automated, I'm removing this from the documentation and I'll also update our site in the next beta release.

Just call me Nicholas, I know that my surname is impossible to pronounce or remember (unless you're Greek) :)

The "incremental" backup strategy is not a truly incremental one, i.e. you won't be able to backup only the updated files. However, you can apply some smart rules to reduce the volume of backups. Most of the times, the bulk of your site's content exists in rarely modified and quite large media files. In this case, I would create two profiles:
1. The default profile which backs everything up. This would serve as a starting point for all incremental backups and I'd run it at least once per week, let's say every Sunday. It's good to have a "last known good" state to start over, in case everything goes awry.
2. "Small" full site backup. In this profile I would create a RegEx files filters with rules to avoid backing up media files. Let's say I have a lot of MP3s, MP4s and AVI files I would like to skip. I'd create the following three rules:
#\.mp3$#i
#\.mp4$#i
#\.avi$#i
This profile would run daily.

Let's assume that a site crash occurs on a Thursday. In order to roll back to Wednesday's backup I would have to extract last Sunday's backup from Profile #1 and extract on top of it Wednesday's "small" backup from Profile #2. The resulting set of files would be equivalent to a full site backup on Wednesday.

As I said, this is a manual and long process, far from perfect. I am now considering of creating an optional filter which will help in incremental backups. When activated, it will only back up files which have changed since the time the last backup taken using the same profile. This will be a truly incremental backup, however the restoration process will still require you to extract multiple archives one on top of the other. This filter will be present in the 3.1 release.

Thank you for your kind words :) I'll be working on this feature today and, probably, a bit of the rest of the week.

Yes, if you come from a Mediterranean country (Greece, Italy, Spain or Portugal) my surname should look very pronounceable :D

Hi!

Incremental backup is already implemented, albeit it works only for files, not for database content. It's technically infeasible to perform a table merge the way you describe it. What you need is called "Site synchronisation" and I had written a blog post last November explaining why that can not work. It's a long read, as it is an in-depth analysis of the technical challenges involved. I wrote it because people kept asking me to create something like that ;)

Regarding your practical question, restoring that backup will only overwrite the files and folders contained in that backup archive. Anything not in the archive will not be touched. This is true with the restoration of any and all Akeeba Backup backup archives.

Hi Paul,

Well, that's a scenario that will not work. The incremental backup works by examining the modification date of each file and comparing it to the last backup's date and time. If you backed up your site on the 1s of the month and you're backing it up again on the 5th, it will backup all files modified between the 1st and the 5th.

In your case, Profile #2 runs daily. The incremental backup would, therefore, not include all the modified files if you used the command line switch. You can, however, do something different.

Assuming that you want profile #2 to become an incremental backup profile, all you have to do is to set its type to "files only, incremental" and remember to DISABLE all quota settings (you wouldn't want to delete your old backups which are required to restore your images, would you?)

Alternatively, copy profile #2 and set the new profile to incremental. Run profile #2 every week and the incremental backup every day. Set the count quota of profile #2 to 1 and the incremental profile's Count quota to 7. This way all you need to restore your images directory is to restore the latest backup from profile #2 and all of the archives taken with the incremental profile (up to 7 of them, depending on the day of week). If you turn on the remote quotas setting, you have set yourself up with an amazingly simple and powerful solution to efficiently backup your very big images directory without paying a lot of money to Amazon :)

Copying the profile is very easy! Go to the Profiles page, select the checkbox on the left of profile 2 and click on the Copy toolbar icon. The profile -including all of its settings- is duplicated. Click on the copied profile to change its name. Back in the Control Panel page, select the new profile from the drop down. When the page reloads, click on Configure. That's all :)

And yes, everything else is as you understood them.

BTW, that was a use case I hadn't thought of when designing this feature. It's good to know that such unforeseen uses not only exist but are perfectly possible :)

Unfortunately, no. The backup log filename follows the conventions akeeba dot origin dot log. This naming convention is hardcoded and is mandatory to allow two essential things:
- Auto clean-up of older log files
- The ability for the View Log page to work without frustrating the user