Support

Are you sure you used 10.0.3 to create the backup? This immediately reminded me something that was solved two years ago. See https://www.akeeba.com/support/site-restoration/36567.

If this is not the case for your backup, is it possible that you actually backed up no tables? If you're unsure about whether that's the case –that message about a Super User not found makes me think that you might have an empty database backup– do send me the backup log file so I can see what was going on during the backup.

The log file did not get attached. Please ZIP and attach the backup log file. Make sure the log file in the ZIP file has a .txt (NOT .php) extension. Make sure the total size of the ZIP file is under 2 MiB. Otherwise, please upload your backup log file to something like Dropbox, OneDrive, Google Drive etc and paste here a public URL. Kindly note that the public share URL must be accessible without a login.

Thank you, the attachment worked. Now I know that the site's main database was backed up, which helps me answer your question precisely.

Skipping the restoration of the site's main database will indeed result to the "No super user found" error because the restoration script does not know how to connect to the site's database, and the user information is only present in the database. The message actually tells you that at least two specific tables need to be restored from the main site database.

As for the SQL error, I believe it's because you have backed up an old, junk table which has a name that is problematic.

Actually, you have a lot of old, junk tables on your site you need to tell Akeeba Backup to skip backing up:

• jos4_j2store_addressesbackup
• jos4_j2store_customfieldbackups
• jos4_j2store_emailtemplatesbackup
• jos4_j2store_queuesbackup
• jos4_user_keysbackup
• jos4_user_notesbackup
• jos4_user_profilesbackup
• jos4_user_usergroup_mapbackup
• jos4_usergroupsbackup
• jos4_usersbackup
• jos4_j2store_addresses_23
• jos4_j2store_addresses_sic
• jos4_j2store_cartitems_23
• jos4_j2store_cartitems_sic
• jos4_j2store_carts_23
• jos4_j2store_carts_sic
• jos4_j2store_geozonerules_sic
• jos4_j2store_geozones-sic
• jos4_j2store_orderhistories_23
• jos4_j2store_orderhistories_sic
• jos4_j2store_orderinfos_23
• jos4_j2store_orderinfos_sic
• jos4_j2store_orderitems_23
• jos4_j2store_orderitems_sic
• jos4_j2store_orders_23
• jos4_j2store_orders_sic
• jos4_j2store_ordershippings_23
• jos4_j2store_ordershippings_sic
• jos4_j2store_shippingmethods_sic
• jos4_j2store_shippingrates_sic
• jos4_j2store_queues_23
• jos4_j2store_userlogs_23
• jos4_languagessic
• jos4_users_23
• jos4_users_sic

The table in bold type is what I suspect causes the problem for you. Dashes in table names are a bad idea in general.

Excluding all the tables I listed above will make your backup file much smaller, the backup process much faster, and you are not losing anything on your site. These are all tables you created a copy of at some point in the past before making a change, then forgot to remove from your site.

The following tables are also very big and do not need to be backed up; they will be created afresh next time you use the third party service I am not allowed to name. You can instead tell Akeeba Backup to not include in the backup at all:

• bf_activitylog
• bf_core_hashes
• bf_files
• bf_files_last
• bf_folders
• bf_folders_to_scan

The following directories contain temporary data. You can tell Akeeba Backup to not back up their contents:

• media/com_jchoptimize/cache/js
• media/com_jchoptimize/cache/css

Finally, if you cannot take a new backup, then when restoring your site, in the restore database page you can change With Existing to Drop Same Prefix. This works around the issue you had as it tries to drop all tables whose name starts with the table name prefix you are using instead of trying to figure out the table name from the CREATE command.

You're welcome! I am glad I could help you :)