Support

The current database filter implementation only allows completely skipping a table, not just its contents. This is a feature planned for no earlier than JoomlaPack 3.0, due to the modifications required to be carried out in the database backup engine.

However, your problem must have a cause. It's not wise to treat the symptoms when there is a cause.

Check this first: JoomlaPack automatically includes your site's main database. If you also include it in the Multiple Databases inclusion filter, you end up with double entries. In this case, you can simply remove the database definition from the inclusion filters.

The other idea is having tables of multiple Joomla! installation inside the same database. For example, let's say that a live site has tables starting with jos_ (which is the prefix used for this site) and some other tables starting with foo_ (of a previous or a parallel Joomla! installation). JoomlaPack will back up the tables starting with jos_ like this: jos_banners as akb_banners, jos_session as akb_session etc. The akb_ is a special marker which tells JPI to replace it with the prefix you enter. The other tables' names will be backed up verbatim e.g. foo_session as foo_session etc. If we restore the site and select foo_ as the new site's prefix, JoomlaPack will restore akb_banners as foo_banners, but later in the file there is also another definition for foo_banners (which was backed up verbatim from the original site's database). Since the table is created only if it doesn't already exist (now, it does exist), JoomlaPack Installer will skip over this and will attempt to INSERT the data. This is where an error occurs. In this case you should visit the Exclude Database Tables page in JoomlaPack and click the "Exclude non-Joomla! tables" link in order to avoid this double back-up of tables.

Sorry for the long and technical post, I tried to be as clear as possible. If you still have problems, feel free to post back.

Without a MySQL database dump (produced with phpMyAdmin) of the entire database the site is installed in, it's impossible for me to tell. As I said, the only reason for having exactly ONE table being double backed-up is to have it present twice in the database.

Here's one really f-in good piece of experience... On Linux, file casing matters. ABC is different to Abc and different to aBc. MySQL stores each table as disk files. If you have jos_session and JOS_session, they can both be stored as two distinct sets of files and both can happily co-exist on your database. Here comes the pain... Your site's prefix is jos_. So, the first is stored as akb_session and the other one as JOS_session. Try restoring them on Windows. Bummer. On Windows filename casing is unimportant. Both tables would try to write to same sets of disk files, namely jos_session. During the first run, the akb_session table would be restored to jos_session as expected. When the JOS_session CREATE TABLE command is being processed, MySQL would note that the file already exists, therefore the table already exists and restoration would fail. This has actually happened to me a few months ago. I can only check if we have such a case with a MySQL dump.