Support

Akeeba Backup for Joomla!

#32327 Akeeba backup does not backup DB table triggers

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by nicholas on Tuesday, 28 January 2020 01:37 CST

Lord KiRon
Although the setting set to dump triggers the output is rather useless and sql file can't be restored.

My settings - see in attachment.

Let's say I have a trigger in "##_book_comments_replays" table that defined in database like this:


CREATE TRIGGER `DecrementParentCommentWhenReplayDeleted` AFTER DELETE ON `ml_maxlib_book_comments_replays`

FOR EACH ROW BEGIN

DECLARE currentCount INT(11);

DECLARE recordExists INT(11);

-- check current value of replay count and if parent record exist at all

SELECT ml_maxlib_book_comments.replay_count, COUNT(*) INTO currentCount, recordExists FROM ml_maxlib_book_comments WHERE ml_maxlib_book_comments.comment_id = OLD.comment_id LOCK IN SHARE MODE;

IF (recordExists > 0)

THEN

-- decrement replay count

SET currentCount = currentCount -1;

-- if we get negative value it means something wrong with consistancy

IF (currentCount < 0)

THEN

-- so need to redetect real number of reply counts, this is longer so preffer to do it only here

SELECT COUNT(1) INTO currentCount FROM ml_maxlib_book_comments_replays WHERE ml_maxlib_book_comments_replays.comment_id = OLD.comment_id;

END IF;

-- put new count in

UPDATE ml_maxlib_book_comments SET ml_maxlib_book_comments.replay_count = currentCount WHERE ml_maxlib_book_comments.comment_id = OLD.comment_id;

END IF;

END


(Using PHPAdmin export)

After creating SQL backup with such table and trigger I get a .sql file containing:


/**ABDB**/DROP TRIGGER IF EXISTS `IncrementParentCommentWithNewReplay`;

/**ABDB**/CREATE TRIGGER `IncrementParentCommentWithNewReplay` AFTER INSERT ON `ml_maxlib_book_comments_replays`;;



And that's all , not only it does not contain the trigger content , the 2nd line also create an error preventing SQL file import using :


mysql.exe -uroot -hlocalhost < restore.sql



when restore.sql:


USE maxima

SET names 'utf8';

SOURCE mydbfile.sql;



The error is like this:


ERROR 1064 (42000) at line 359434 in file: 'mydbfile.sql': You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '' at line 1



But this syntax is a least problem as it can be fixed manually, the bigger problem is as I said that the backup does not include trigger at all.

nicholas
Akeeba Staff
Manager
Does the database user your site runs under have the show create privileges required to see the structure of the trigger you are trying to back up? If, for example, the definer is root and your database user is myuser1 it is very likely that you can use but not see the structure of the trigger. In this case an empty definition would be backed up because MySQL does not raise an error in this case, it simply reports that the structure of the trigger is empty.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Lord KiRon
Thanks,
I checked this by calling:


SHOW GRANTS



And I got:


Grants for myusaer@localhost

GRANT USAGE ON *.* TO 'myuser'@'localhost' IDENTIFIED BY PASSWORD 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

GRANT ALL PRIVILEGES ON `mydatabase`.* TO 'myuser'@'localhost'



So it looks like all privileges on for my user and that's not the case, unless I am mistaken something.
Also I use this user to create and see this Triggers from phpAdmin ...

nicholas
Akeeba Staff
Manager
I can definitely back up triggers from my databases on my own servers. If you have all privileges it implies that you have the trigger privilege which should allow you to view the definition of a trigger even if it's defined by a different user.

HOWEVER!

I would like to note that in your original post there is a disparity between the trigger you said you created and the trigger that was found on the database and attempted to be dumped. You said you created an after delete trigger. However, the excerpt of the SQL you are pasting is for an after insert trigger.

Is it possible that you are mistaken about what's going on and it's a simple case of actually having an empty, invalid after insert trigger that Akeeba Backup dutifully tries to back up?

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Lord KiRon
You understand me wrongly.
I am not creating and deleting trigger.
The trigger is there.
The code that delete and "kind of create" trigger you see above is from Akeeba backup generated SQL file.
Al I want is to create a restorable backup of my database but Akeeba Backup backs the tables but not the triggers, that's my problem.

nicholas
Akeeba Staff
Manager
The trigger is there.


Are you SERIOUSLY saying that the trigger magically appeared in your database without ANYONE, EVER creating it?

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Lord KiRon
No , I mean I created it like 5 years ago using PHPAdmin and same user I try to backup (that's btw the only user in DB) with full rights , since then it there :)

nicholas
Akeeba Staff
Manager
OK, so back to what I was saying. This trigger was created through phpMyAdmin. Are you sure that the database user phpMyAdmin runs under is the same database user your site runs under?

Also, the most important thing here is that THE TRIGGER WHOSE DEFINITION YOU PASTED IS NOT -- REPEAT: *********NOT*********** -- THE TRIGGER YOU ARE HAVING TROUBLE WITH.

So, for the last time. Can you please check HOW MANY and WHICH triggers you have on that table? Is it possible that there is indeed an empty AFTER CREATE trigger? If there is it would explain why you get an empty trigger in your backup, even though it's not valid.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Lord KiRon
I think I found the reason why the triggers were not included.
When I go to "database tables exclusion" page , "browser view" and look into "Database tables, views, procedures, functions and triggers" table, I see all my triggers bellow as excluded "red" and clicking on them does not change anything.

So now I kind of have 3 questions questions:
1. How they got excluded :)
2. How I "un-exclude" them ?
3. And why triggers are separate from their tables ? I mean I can see why the procedures listed separately, but triggers are part of tables , no ?

nicholas
Akeeba Staff
Manager
Let's take things from the start since you seem to have not read the documentation, ignoring the tooltips on your screen and making arbitrary assumptions.

By default, Akeeba Backup will not backup procedures, functions or triggers (let's call them "entities" collectively). If you want that to happen you have to go to the Configuration page, find the Database Dump engine and click the Confiugre button next to it. In the new pane make sure that "Dump PROCEDUREs, FUNCTIONs and TRIGGERs" is selected. Further to that you will need to have adequate privileges for the SHOW commands used to detect the existence of these entities, as well as adequate privileges to show the create commands of these entities.

It should be fairly obvious that these entities, much like views, are basically a special case of stored SQL code. They are not tables. They do not have data. Therefore the second column in the database exclusion page which refers to the contents of a table will always be red. In case it's not obvious: these entities are NOT tables, they do NOT have contents, therefore we cannot backup their non-existent "rows" by definition. That's why it appears red. The first column which refers to backing up the structure (DDL - Data Definition Language) is not red in your screenshot, meaning that they WILL be dumped.

I've been asking you to check if you have more than one triggers on that table after noting that the trigger you say you have on the table and the trigger you are reporting as problematic ARE FOR DIFFERENT TABLE EVENTS. Instead of following my instructions to answer a simple quetion you are completely ignoring me, do random things, make arbitrary assumptions and expect me to magically give you a solution. I'm sorry but if you don't care to follow my instructions I will refuse to provide any further assistance per our terms of service. I will close this ticket and immediately delete without further reply any tickets filed about the same issue from you.

For what it's worth, I have confirmed that triggers DO get backed up properly in version 7.0.0 AS LONG AS they are defined correctly AND the user your site is using to connect to the database has the TRIGGERS privileges. I would also like to note that I spent two weeks last July working on the backup of entities and I have a lot of very fresh experience on the subject. I'm not trying to brush you off. I am trying to gently tell you there's something in your database that you need to fix. Sorry, I don't know how else to put it which is why I'm giving up on this ticket. I've tried and tried and tried again but you don't want to let me help you. Maybe after closing your ticket you'll check why there are two triggers on the table and why only one of them is invalid and fix it.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!