Support

The table wp_dgwt_wcas_index_tmp was found when initially scanning the database, but when we come to the point where we need to back it up the table has disappeared. Based on a cursory search on the Internet, this appears to be a temporary table FiboSearch creates and removes as needed. We can tell Akeeba Backup to completely ignore that table since it shouldn't be part of your backup anyway.

Go to the wp-admin backend of your site as an Administrator, and click on Akeeba Backup.

Scroll down, and click on Database Tables Exclusion.

On the new page, click on Summary View towards the top right, just below the topmost Akeeba Backup header.

A new page loads.

Click on the “Exclude This” button towards the top of the page.

In the textbox which appears type #__dgwt_wcas_index_tmp and then click on the button with the pencil icon next to it.

Your backup will now ignore this temporary table, as if it doesn't exist, exactly what we need it to do.

Yes, your backup will randomly fail because it depends entirely on whether the wp_dgwt_wcas_index_tmp table exists when Akeeba Backup scans your database for tables at the start of the backup.

OK, some context is necessary – probably even more so since we'll be closed until Friday.

The way the database backup works is that at the very beginning we ask the database server for a list of all database tables, views, procedures, functions, triggers, and events it knows of for the database we are going to be backing up. This takes fractions of a second.

The second step is to apply filtering rules which tells us which of those tables, views, etc not to back up at all. This also takes fractions of a second.

The third step is to calculate dependencies. Which table references each other etc. This gives us the order in which everything has to be backed up. Again, this takes fractions of a second.

At this point we are about 0.8 to 1 seconds into the backup. The ordered list of what to back up is saved in temporary storage.

Then, we proceed to back up each individual entry. For each table we first dump its structure (takes a dozen or so milliseconds), and then start dumping its contents which –depending on how many rows the table has– can take anywhere from milliseconds to several minutes, or hours (I have a site with a table that has 15 million rows which takes about 90' to back up!).

As you can see, there is a time distance between interrogating the database about which tables it knows about and backing up each table. The wp_dgwt_wcas_index_tmp table may have appeared in the list of tables at the beginning of the backup, but it takes about 2 minutes on your site before it is its turn to get backed up. However, this table is temporary. It will disappear when it's not needed. Its lifespan is probably seconds, or fractions of a second. By the time we try to back it up it will have disappeared. This is why your backup was failing.

Filtering out that table means that even if the first step of the backup “sees” that table, the second step will remove it from the list of what we need to back up. Therefore, it won't matter if the table does or does not exist during the database backup; it is not something we would back up even if it exists – and we shouldn't be backing up as it is meant to disappear and be created afresh at any point in time.

I hope this longer explanation helps you understand better what I was talking about earlier.

Have a Happy New Year!

Are you absolutely sure that you have applied these exceptions to the same backup profile?

Are you sure that there are no spaces or other invisible characters before or after #__dgwt_wcas_index_tmp in the filter?

When you use the Browser View in the Database Table Exclusion page do you see any red icons to the left of wp_dgwt_wcas_index_tmp, and if so which ones?

The reason I am asking you these questions is that the filters you have applied seem okay (I can't be 100% sure that they are typed correctly; homomorphic glyphs and whitespace collapsing can hide the REALLY subtle issues), but the log file claims the filters are not applied. This tells me there is a mistake somewhere: entering the filters, which backup profile they were entered, or which site they were entered into.

Something doesn't add up here. Can I please have backend access to your site as an Administrator to take a look myself?

Thank you. Now I can see that the problem is that the extension creating the temporary tables doesn't create just one temporary table, but several. Every time your backup failed, it was a different temporary table. However, there is a pattern in their name: it's always #__dgwt_ followed by something followed by _tmp or, expressed as a regular expression /^#__dgwt_.*_tmp$/. This allowed me to create a new RegEx Database Tables Exclusion entry with that regular expression. I also removed the previous exclusions you had added manually; some of them were wrong (wouldn't do anything, or would exclude tables you do want to back up).

Wait for the next scheduled backup and let me know how that worked.