Support

This can happen when backing up a table which does not have a single column primary key (e.g. an AUTONUMBER integer field) and which is getting written to during backup. In this case the native MySQL paging is used for going through the rows of the table without having to lock the table for the duration of the backup, making your site unreachable. Since MySQL does not have a strictly defined behaviour for paginating this kind of tables you may end up with a duplicate row in the backup output.

You can work around that on restoration by selecting the “Use REPLACE instead of INSERT” option in the Database Restoration page, before starting the restoration of the database. This option is in the right-hand column. By using a REPLACE INTO instead of INSERT INTO the duplicate row is silently re-inserted without raising a MySQL error.

Note that the above behaviour is not unique to Akeeba Backup. It is what you will see with MySQLDump itself unless you use the --lock-tables option. Of course, if you were to use MySQLDump with this option then you'd have the aforementioned problem: since the table is locked for reading your site stops working as reading from the table is no longer possible.

Generally speaking, running into this problem is very rare. If this happens with all your backups you probably have a very big table without an auto-number column which changes too frequently (at least once a minute). Most tables like that are temporary, or can otherwise be rebuilt. Is this a table you really need to backup the data of?

This is easy to fix. It's caused by another table having a foreign key constraint with the same name.

In the database restoration page's right-hand site With Existing -> set to “Drop All”. All of the tables in that database will be dropped before restoration, regardless of their prefix. This ensures that any old / renamed tables won't get in your way. That's the reason I added this feature a few years ago :)

The problem with the previous database was that there was another table with the same constraint name. If I recall correctly, AcyMailing does not use the Joomla database table name metaprefix (#__) in the names of the constraints it creates. So, if you have another site using AcyMailing sharing the same database you can't install it on any other site. At least that was the case about a year and a half ago when I last took a look at it because my wife had reported the same issue to me.

Moreover, if you use the default option to backup (rename) tables on restoration the old AcyMailing table is renamed by substituting its table name prefix with bak_. This does not rename the constraints, though, so you end up with the same problem. Removing the bak_ tables manually and choosing an option which deletes existing tables (same prefix or all) also fixes this issue if you really want to use the same database.

It is always a good idea using a different database for different applications. You will typically get better performance and less headaches should a single table crash. The reasons are rather esoteric and have to do with how MySQL storage engines work, the database server configuration, as well as the Operating System and filesystem you are using.