Das steht schon alles mehr oder weniger in diesem Thread (dass es nicht geht). Wir haben immer noch keine konkrete Lösung oder Erklärung. (wie es geht).
Die letzte Frage war: warum geht es per phpMyAdmin und nicht per mysqldump. Bzw. welche Argumente muss ich an mysqldump übergeben, damit es klappt. Bzw. kann ich irgendwo sehen wegen welchen Argumenten phpMyAdmin es schafft.
In dem Stackoverflow Thread steht klar, dass MariaDB ein Problem mit stored values hat und wie man diese nachträglich aus dem dump löscht. Ich habe diesen Ansatz jetzt nicht getestet, aber es ist immerhin ein Lösungsansatz.
Und zu deiner Frage. Jeder Server nutzt andere Software, andere Konfigurationen. Schwer, da eine pauschale Antwort zu finden. Vielleicht liegt es ja auch an der nicht kompatiblen MariaDB-Version (habe ich irgendwo mal hier im Forum gelesen).
Bei manchen hilft ja schon phpmyadmin zu nutzen… daher sieht man, dass das Problem vielschichtig ist.
Da ich das Problem nicht nachstellen kann, kann ich außer generelle Ratschläge leider nicht mehr dazu sagen bzw. empfehlen. Sorry.
Ich möchte euch nochmal an diesen Beitrag erinnern, der wohl unter geht:
Damit läuft es wunderbar und ich kann ohne Probleme Backups erstellen und einspielen.
Also ran an die Konsole, fertig los 
danke, hat für mich leider nicht funktioniert. Deswegen ging es dann weiter…
hab mal versucht nach zu verfolgen was dein problem sein sollte, was ich leider nicht habe.
daher frage ich ggf. noch mal.
was geht nicht an mysqldump ausführen und *.sql nachbearbeiten?
Das geht ja schon. Man macht es aber nicht um es zu machen, sondern um importieren zu können. Und nach dieser Bearbeitung bricht der Import genauso ab wie vor der Bearbeitung.
Fehlermeldung:
ERROR 3105 (HY000) at line 3600: The value specified for generated column ‚order_date‘ in table ‚order‘ is not allowed.
Der Dump via phpMyAdmin kann problemlos importiert werden.
bist du sicher, dass das backup verändert wurde?
COLLATE utf8mb4_unicode_ci GENERATED ALWAYS AS
wird zu
GENERATED ALWAYS AS
ja, das wird es. Ich sehe gerade, dass beim Import des editierten Dumps ein anderer Fehler auftaucht:
ERROR 1067 (42000) at line 583: Invalid default value for ‚cms_page_version_id‘
Evtl. weil ich ohne --hex-blob exportiert habe. Da kann ich mich leider nicht mehr erinnern. Ich teste beide „Tricks“ mal bei Gelegenheit. Ich kam ja weiter mit dem phpMyAdmin.
Ich habe jetzt die betreffenden Spalten im Insert gelöscht und jetzt gehts. Die Spalten werden beim Import neu erstellt und befüllt. Im betreffenden Shop sind nur eine handvoll Bestellungen drin, da geht das ja noch aber wenn man hunderte oder tausende Bestellungen hat bearbeitet man die Datei mal nicht ebenso.
Also bleibt immer noch die Frage: Mit welchen Parametern dumpen damit generierte Spalten nicht im Dump enthalten sind?
Edit
Ich habe jetzt mal verschiedene Dumps von der korrekt zurückgesicherten Datenbank gemacht. Weder mit mysqldump noch mit Adminer bekomme ich einen Dump ohne generierte Spalten in den Inserts hin. Nur phpmyadmin exportiert ohne generierte Spalten in den Inserts, im Quick Mode in der Standardeinstellung.
Ich sitze nun auch vor dem Problem, dass ich vor einem Update die Datenbank nicht kopieren kann.
Wie bereits genannt, hilft es nur weiter, im Dump die entsprechenden Spalten zu löschen.
Bei mir erzeugt leider auch der phpMyAdmin im Quick Mode die eigentlich zu generierenden Spalten.
`order_date` date GENERATED ALWAYS AS (cast(`order_date_time` as date)) STORED,
`amount_total` double GENERATED ALWAYS AS (json_unquote(json_extract(`price`,_utf8mb4'$.totalPrice'))) VIRTUAL,
`amount_net` double GENERATED ALWAYS AS (json_unquote(json_extract(`price`,_utf8mb4'$.netPrice'))) VIRTUAL,
`position_price` double GENERATED ALWAYS AS (json_unquote(json_extract(`price`,_utf8mb4'$.positionPrice'))) VIRTUAL,
`tax_status` varchar(255) GENERATED ALWAYS AS (json_unquote(json_extract(`price`,_utf8mb4'$.taxStatus'))) VIRTUAL,
`shipping_costs` json NOT NULL,
`shipping_total` double GENERATED ALWAYS AS (json_unquote(json_extract(`shipping_costs`,_utf8mb4'$.totalPrice'))) VIRTUAL,
Es kann doch nicht die Lösung sein, manuell alle GENERATED Felder zu löschen. 
Entweder eine aktuelle Version von mysqldump nutzen oder per phpmyadmin erstellen lassen. Dann gibt es das Problem nicht. Ansonsten, doch… die Zeilen auskommentieren. Per PHP Script oder …
Anmerkung:
Gerade bei SW6 habe ich mir angewöhnt, ein Dump nur über die Console zu machen.
mysqldump --hex-blob -u root --password=12345 meine_datenbank > meine_datenbank.sql
Und auch über die Console wieder einzuspielen. Passt Perfekt 
@Max_Shop phpMyAdmin und Adminer zeigen den identischen Fehler
@R4M Danke für den Hinweis. So funktioniert es. Finde es trotzdem traurig, dass phpMyAdmin und Adminer nicht genutzt werden können…
Ich habe in Stackoverflow gelesen, dass nur alte Versionen von mysqldump dieses Problem erzeugen, ebenso Adminer in der aktuellen Version.
Es geht nicht ums einspielen, sondern um die dump Erstellung.
Anscheinend habt ihr eine Lösung gefunden, ist ja top.
So unterschiedlich sind die Erfahrungen. Bei mir funktioniert nur die phpmyadmin Lösung. Denn phpmyadmin dumpt ohne die generierten Spalten. Somit funktioniert auch das wiederherstellen problemlos wenn vorher die Fremdschlüsselüberprüfung ausgeschaltet wird.
Im Dump von mysqldump bleiben die generierten Spalten erhalten und somit gibt’s dann Fehler beim wiederherstellen. Die Tabellen werden zwar angelegt aber die Daten fehlen dann. Da man sich bei einem Hoster die mysqldump Version nicht aussuchen kann ist das auch keine Lösung.
Mein Problem ist nun das ich per Cronjob jede Nacht ein Backup der Dateien und der Datenbank über mysqldump mache, diesen Dump aber nicht fehlerfrei wiederherstellen kann, da die generierten Spalten enthalten sind und diese mysqldump bzw. Mysql Version diesen Fehler eigentlich nicht haben sollte.
Im Moment mache ich alle paar Tage einen manuellen Dump mit phpmyadmin da das für mich die einzige funktionierende Lösung darstellt. Ich möchte mich aber darum gar nicht kümmern müssen und eine automatische Möglichkeit mit mysqldump nutzen.
Mit einem recht einfachen PHP-Script könntest du die Zeilen aus dem dump entfernen lassen. Ist umständlich, würde aber automatisiert erfolgen. Oder du versuchst den mysqldump von einem anderen Server, vielleicht funktioniert es ja dann.
Ich denke das sollte an der Version von mysqldump liegen.
Hab mal bei drei Providern nachgesehen.
Provider 1: (funktioniert bei mir)
mysqldump Ver 10.13 Distrib 5.7.18, for Linux (i686)
Provider 2:
mysqldump Ver 10.16 Distrib 10.1.38-MariaDB, for debian-linux-gnu (x86_64)
Provider 3:
mysqldump Ver 10.19 Distrib 10.6.5-MariaDB, for debian-linux-gnu (x86_64)
Die niedrigste Versionsnummer funktioniert bei mir.
Evtl. könnte es auch ein Unterschied zwischen MySQL und MariaDB sein. 
Es ist definitiv mysql vs. MariaDb. Beide Datenbanken implementieren virtuelle Spalten anders. Daher kann ein dump vom MySQL nicht ohne weiteres zu Maria dB importiert werden und umgekehrt. Außerdem ist deine mysql Version fehlerhaft, shopware setzt mindestens 5.7.21 voraus Shopware 6 - Erste Schritte - Systemvoraussetzungen
when we while duplicating the setup faced this problem with order tables, this helped us (MySQL 5.7):
All works then without workarounds,
hope this helps, have time to enjoy the nature!
MariaDB 10.3.34 nach MariaDB 10.3.22 hat einen Syntax Error bei der Zeile tax_status varchar(255) COLLATE utf8mb4_unicode_ci GENERATED ALWAYS AS (json_unquote(json_extract(price,'$.taxStatus'))) VIRTUAL, geworfen.
Nach einem Upgrade auf MariaDB 10.3.35 hat es funktioniert.