Support

Ah, I see that you are confused about a few things and with a good reason.

Background: character sets, PHP and databases

There are two distinct character sets you need to be aware of:

1. Database storage character set which is a property of the MySQL database, table or column itself. This defines how MySQL stores the database data to disk.

For historical reasons, MySQL's UTF-8 character set was not the canonical UTF-8 character set defined un the Unicode standard (characters consisting of 1 to 4 bytes). It was a botched down version that supported only up to 3 bytes per character. This had to do with memory constraints in the prehistoric days when this decision was made. We're talking about early 00s when computers had 128MB of RAM and anything over 512MB was a beast with plenty of RAM. Of course the problem with that is that a lot of valid Unicode characters could not be represented and MySQL would squash them as the invalid character grapheme which renders as a question mark. MySQL then introduced the UTB8MB4 character set which is the “real deal” UTF-8 character set, i.e. each character can occupy 1 to 4 bytes.

2. PHP character set which is how PHP itself stores data in its memory, expects to read from files and writes to files. This is always the “real deal” UTF-8 encoding that supports characters of 1 to 4 bytes, i.e. equivalent to MySQL's "UTF8MB4". 

PHP can only handle one kind of data, the “real deal” UTF-8 data. When PHP-based software, like Akeeba Backup, reads from the database the following happens. The software interfaces with PHP's MySQL access library (MySQLi or PDOMySQL). The access library interfaces with PHP's low-level MySQL driver (mysqlnd) which uses MySQL's official C library to talk to the database server. The connection character set (the format the database will receive and send back data) is set to “real deal” UTF-8. So, rhe database server reads the data from disk, processes it and returns it as “real deal” UTF-8 data back to mysqlnd which sends it to MySQLi/PDOMySQL which sends it back to Akeeba Backup. What Akeeba Backup got from the database use “real deal” UTF-8 data, i.e Unicode characters with a varying length of 1 to 4 bytes.

Akeeba Backup writes the SQL dump file with a verbatim copy of the data it received. Therefore it will be, by definition, real deal UTF-8 data with characters between 1 and 4 bytes in length. (There's a further note here that PHP always uses Big Endian format for multibyte data even on Little Endian platforms like ARM, e.g. Apple Silicon, which means we don't need to output a Byte Order Mark but that's super technical and besides the point — I only include it in case some poor soul is looking for this information in the future and bumps into this public ticket).

Restoring backup

There are two kinds of backups you can restore: archive files or SQL files.

Archive files are the .jpa, .jps and .zip files you get when you take a full site backup, an "All configured databases" backup or an "Incremental files, full database" backup. In this case the restoration takes place with our database restoration script, ANGIE. ANGIE is smart. It detects your database server and its version and knows when it supports UTF8MB4. If this is the case it will restore the data verbatim, i.e. you will not lose any 4 byte characters such as Emoji, lesser used traditional Chinese characters and less common writing scripts introduced in Unicode version 5 and later. When you are on a very, VERY old database server which does not support UTF8MB4 the 4-byte characters will be replaced by question marks by the database server itself.

SQL files are restored by you using software you provide. What will happen when you restore them depends on BOTH your database server AND the software you are using. If you use something like HeidiSQL, DBeaver or phpMyAdmin and your server supports UTF8MB4 your data will be restored correctly, including 4-byte data. In any other case the 4-byte characters will be converted to question marks by the database server itself.

TL;DR

As long as you are using the latest version of Akeeba Backup to backup and restore your database you don't need to worry about character sets. You will NOT lose any data, as long as the database server you are restoring your site to supports UTF8MB4.

Also, for what it's worth, Joomla only started UTF8MB4 because yours truly insisted on it and provided the original patch which enabled this behaviour. It would be really stupid if my own software didn't correctly support UTF8MB4, don't you think? 😉