Support

Very valid question but the answer is that no, you cannot. The log is overwritten with each backup taken from the same origin.

Regarding the old restore points, you can set up the System Restore Points quota in the Configuration page. In Akeeba Backup 3.11.2 and earlier you MUST set this quota in profile #1 as this is the backup profile used with System Restore Points. In the upcoming 3.11.3 version and later versions you will be able to choose which profile to use with System Restore Points (by default it will still be #1), therefore you will need to set up this option in the backup profile used for SRPs.

No. It would make quota management, logging, backup record administration and most importantly the log view and troubleshooting documentation extremely problematic. I can live with making the first three more complicated, it's purely a coding issue and I can handle it. Log viewing becomes a dicey proposition once you start having a different log file per backup. Documenting where to find each log file in various documentation and troubleshooter pages and videos in a way that all users of the software can and will post to us the CORRECT log file is impossible. That would make it impossible for us to provide accurate support, making the software look complicated and badly supported, leading to a substantial loss of income.

So, no, we won't implement this kind of feature because it subtracts value from the software for most of its users.

Oh, that's a different feature and yes, it's already implemented :D We have a different log file per backup origin. The System Restore Points are a different origin than regular backups. This log file is named akeeba.restorepoint.log and is visible under the View Log page as the "Restore Point" origin. Of course, like any other log file, you only get the last log file of the origin, i.e. the log file of the latest system restore point attempt.

However, having a different log file per restore point attempt is a very, VERY different barrel of fish. The easy way would be storing the log file in the database along with the system restore point information. However, if the system restore point log file grows over a few hundred kilobytes it becomes an extremely dicey proposition to store them in the database without causing the SRP (and the extension update) fail out cold.

Another way to do this would be renaming the log file after each restore point is taken. However, this is problematic in two ways. First, it's a Catch-22 issue: you can't rename the log file while it is being written to it, but it will be written to it when you rename the log file in the course of an SRP backup. In theory we could but a 50 caliber artillery shell through our brains by having the rename take place AFTER the SRP is taken, which makes the SRP feature extremely unmaintainable since it now requires a complete fork of the Javascript, HTML and PHP code used to render the Backup Now page. Let me put some subtitles. The next time Joomla! changes something in their Javascript (in about 2 to 8 months) we would need twice the amount of time to get a working Akeeba Backup version out, with twice the cost and twice the probability of introducing a new bug. And it gets downhill from there.

And I'd wish that was the end of it. We have the management of system restore points. If you remove a backup archive (including a restore point) the log file is not deleted. So, we'd need to now fork the controller handling backup management, one for regular backups and one for SRP backups. That doubling of effort now became even worse. Moreover, having the log file deleted automatically would require storing even more information to the database, after the log file is renamed, in a place of the code that makes it a real pain in the hindquarters to maintain it.

The changes required increase the likelihood of bugs in the SRP system exponentially. Do I want to go there? Hm, I am a masochist with our extensions, but not THAT much :)

You're welcome, Wim :)