Support

Hello Gerald,

If a backup crashes for any reason, e.g. your host kills the backup process, the CRON server dies and so on, you will end up with an off-line site without any way to know about it. Considering that you'd end up running backups when you are not working on the site anyway this would be extremely bad for your business: your site would be off-line for several hours or days until you noticed.

Furthermore, as my experience of writing backup software for 10 years and using it on my own e-commerce site tells me, data consistency is a far far far far smaller issue than lost revenue during backup time.

Even if an order is in progress when the backup runs you'd only get an inconsistency if, for example, an order was paid between backing up the orders and the payments table. But does this REALLY matter? You are going to restore a backup if crap hits the fan, in which case you've lost your entire site. You'll restore it to a "last known good" state which does NOT include any of the orders placed since the last backup completed. You WILL have to manually rebuild the orders and payments between the last backup and the restoration time. Does it REALLY matter if it's going to be n orders (orders between the last backup and the restoration time) or n+1 (orders between the last backup and the restoration time AND the inconsistent entry) orders? Not really.

On the other hand what happens if you set your site off-line during backup? If the backup takes an hour to complete then your shop is unavailable to everyone for an hour. You are losing all these orders. Ideally you'd need to set the site off-line between backing up certain tables and set it back on-line afterwards. This is impossible to automate in a manner that does not require customization of the backup software for each individual site and deep knowledge of exactly how all the software on your site works. This kind of service would cost thousands of Euros per site to offer and, as I explained, would make no sense anyway.

For these reasons (danger of loss of revenue, improbability of data inconsistency, no actual ill-effects of data inconsistency in the unlikely case it occurs and huge cost of configuring a custom solution per client and site) this feature is not implemented and will never be available. This is exactly the same approach followed by all consumer backup software be it for sites, for files or for an entire computer. Data consistency is a concern only when you reach a certain volume of transactions per second. If you have this kind of volume you shouldn't be looking for a solution like Akeeba Backup. You should be looking at a master-multiple slave database system, synced filesystems, heartbeat servers and solutions which would take a node of the cluster and a database server off-line to take a consistent backup and then put them back into the resources pool to let them sync. But this is way beyond the scope of Akeeba Backup and far beyond what you actually need for a relatively small e-commerce based on Joomla.