Importer avec phpMyAdmin les fichiers sql d'une sauvegarde Akeeba backup ?

[RobertG]

Bonjour,

J'avais créé un profil afin de sauvegarder avec Akeeba backup pro la base de données et un dossier (de fichiers joints provenant d'inscriptions Event Booking) dans le but de pouvoir restaurer rapidement si un incident survenait lors d'un nettoyage de certaines tables du site et du dossier concerné.

Il avait été décidé que les données à supprimer seraient celles datant de plus d'un mois, mais récemment, la responsable du site a voulu stopper ce nettoyage, afin de conserver une trace plus facile d'accès aux inscriptions concernées.

Toutes les données antérieures au 23 mars n'existent plus, mais j'ai des sauvegardes disponibles depuis début janvier, ce qui me permettrait de réinjecter le contenu des tables nettoyées jusqu'au début décembre 2022, mais compte tenu de la structure site.s01 à site.sql et du remplacement du préfixe des tables par "#__", impossible d'importer directement ces données.

Quelqu'un aurait-il une astuce évitant de faire de multiples manipulations ?
Merci d'avance

[jfque]

Pour le remplacement des préfixes, un chercher/remplacer avec un simple éditeur de texte peut faire l'affaire.
Pour le reste, je ne me souviens plus de la syntaxe des tables...

[RobertG]

Merci

Oui, ce remplacement n'est pas un problème. Ce qui l'est, c'est le nombre de fichiers, 24 plus le json sur une ancienne version du site.
Et autre souci : alors que dans le json les tables sont bien dans l'ordre alphabétique, j'ai plusieurs fichiers à partir du s01 qui concernent la table #__history, qui est la 78ème et non la première dans la liste du fichier json.
Je n'ai pas réussi à comprendre comment Akeeba s'y retrouve...
J'imagine quand même que la structure et les données se suivent bien à partir du fichier site.s01 au site.sql, et que donc la lecture et donc la concaténation doivent bien se faire dans l'ordre s01+s02+s03+...+site.sql

En fait, la procédure nécessiterait pour chaque sauvegarde une décompression du jpa, une concaténation de tous les fichiers s01 à sql, un remplacement des préfixes, une restauration dans une base temporaire, un export des données des seules tables concernées par la purge avec un remplacement de INSERT par INSERT IGNORE pour ne pas écraser les données lors de l'import dans la base actuelle.
Et ce pour a priori 8 ou 9 fichiers de sauvegarde à traiter.
Lourd !

[roland_d_alsace]

Hello.

De mon côté je fais les sauvegardes de mes bases directement via mysqldump, car je ne veux pas être tributaire d'un format de sauvegarde spécifique (propriétaire), et donc pouvoir remonter les tables sur n'importe quel serveur, simplement via commande mysql.

Dans ton cas je remonterai la sauvegarde (.jpa) akeeba sur une base mysql pour faire ensuite les suppressions nécessaires des éléments dans les tables, puis refaire une sauvegarde (.sql) via mysqldump ou phpmyadmin en supprimant les "drop table" et "create table" et en ne gardant donc que les "insert" (vu que les id en autoincrement sont corrects).
Et ensuite faire l'import de cette sauvegarde (.sql) via mysql ou phpmyadmin sur la base de prod.

Si j'ai bien compris ton problème...

[RobertG]

Merci Roland !

C'est bien une procédure à laquelle j'avais pensé, mais il faudra que je récupère des données depuis plusieurs sauvegardes.
J'ai utilisé ces sauvegardes Akeeba afin de pouvoir vérifier avant de nettoyer qu'il y en a bien une créée quelques instants avant la purge, qui supprime d'une part des fichiers sur le serveur, d'autre part les anciens inscrits et événements d'Event Booking.

Je dois dire que le but étant de pouvoir restaurer très vite données et fichiers en cas d'incident, je pensais pouvoir le faire directement depuis l'administration.
Et puis j'aurais dû limiter les tables à celles d'Event Booking, dans la mesure où les inscriptions aux événements ne créent pas des utilisateurs sur le site.

Je n'ai jamais essayé de restaurer ailleurs et individuellement ce type de sauvegarde, d'où mon idée de n'utiliser que la série de fichiers sql. Peut-être essaierai-je de créer un script capable de concaténer ces fichiers en changeant le préfixe, puis importer dans une base vierge et n'exporter que les données pour les rapatrier dans celle du site.
Il faudra aussi que je m'assure d'avoir toutes les données, et pas de trous entre deux backups... ce qui semble être le cas actuellement, auquel cas cette restauration aurait beaucoup moins d'intérêt.

[daneel]

Hello.

De mon côté je fais les sauvegardes de mes bases directement via mysqldump, car je ne veux pas être tributaire d'un format de sauvegarde spécifique (propriétaire), et donc pouvoir remonter les tables sur n'importe quel serveur, simplement via commande mysql.

Dans ton cas je remonterai la sauvegarde (.jpa) akeeba sur une base mysql pour faire ensuite les suppressions nécessaires des éléments dans les tables, puis refaire une sauvegarde (.sql) via mysqldump ou phpmyadmin en supprimant les "drop table" et "create table" et en ne gardant donc que les "insert" (vu que les id en autoincrement sont corrects).
Et ensuite faire l'import de cette sauvegarde (.sql) via mysql ou phpmyadmin sur la base de prod.

Si j'ai bien compris ton problème...

Cela me semble la solution la plus logique. Mais ce que je ne comprends pas, c'est pourquoi akeeba alors que tu propose LazyDbBackup dans tes extensions ?

[RobertG]

J'utilise Akeeba backup parce que j'ai aussi besoin de sauvegarder des fichiers au même moment.
Event Booking est utilisé ici pour des inscriptions à des examens, et une preuve d'identité est fournie lors de l'inscription (copie de carte d'identité, passeport, carte de séjour...).
Si j'utilisais Akeeba seulement pour les fichiers et LazyDbBackup pour les tables, il me faudrait m'assurer que les deux sauvegardes ont été quasi simultanées, ce qui est plus compliqué que vérifier dans la table Akeeba que la sauvegarde du type voulu date de moins d'une heure et a été réussie.

[RobertG]

Bon, un gros os !

J'ai commencé un petit script pour concaténer les fichiers sql, après avoir regardé une des sauvegardes et eu l'impression qu'on avait toujours un CREATE TABLE avant un INSERT INTO, mais dans celui testé, le ficher site.s01 commence par un insert, le dernier, site.sql a des create et des insert...
Ce qui veut dire que ma concaténation aura une structure incorrecte, avec tes tables n'existant pas encore quand l'instruction insert apparaît, donc impossible à importer dans une base vierge.
La seule solution pour un import direct serait d'arriver dans cette concaténation à supprimer toutes les sections "CREATE" pour ne conserver que celles d'insertion en changeant pour "INSERT IGNORE", et je ne vois pas comment arriver à enlever ces sections de création.
De plus, les fichiers ne comportent pas d'instruction "DROP TABLE".
Je crois que je risque fort de jeter l'éponge.

[RobertG]

Bonjour,

J'ai revue ma copie.

Mon script sait concaténer les fichiers. Tous commencent par une ligne

/**ABDB**/INSERT INTO

ou

/**ABDB**/INSERT INTO

En recherchant les CREATE et les INSERT, j'arriverai bien à ne récupérer que les parties INSERT en supprimant les CREATE.
J'aurai alors uniquement une série d'instructions d'insertion.

Il faudra que lors de la lecture de chaque fichier, ces parties de création soient supprimées, puis que le préfixe des tables soit remplacé par "le bon", mais aussi que

/**ABDB**/INSERT INTO

soit remplacé par

saut-de-ligne
INSERT IGNORE INTO

avant que la chaine obtenue puisse être écrite dans le fichier de destination.

Mais j'ai eu beau chercher, je n'ai pas compris comment, dans la chaîne avant écriture, placer un saut de ligne. Et à l'écran, si je teste ($contents étant la chaîne brute issue de la lecture d'un fichier)

$recup_file = $recup_file . "<br/>" . $contents;

puis

echo $recup_file;

aucun saut de ligne ne paraît, que ce soit avec "<br/>", "\r\n" ou '\r\n'.
Lors de l'écriture en mode "append", l'insertion de

fwrite($fp,"\n");

place bien un saut de ligne dans le fichier de destination.

Que me conseillez-vous ?

[RobertG]

Bon, finalement, le script est presque terminé (il faut encore que je restreigne aux seules tables EB) : il génère un fichier contenant toutes les instructions d'insertion, "IGNORE" ajouté et préfixe défini.
Il restera à cloner le site et tester après avoir décompressé tous les fichiers jpa disponibles (il en manque un sur les quatre derniers mois) et traité les fichiers sql. Il y aura aussi à récupérer les fichiers images qu'embarquent ces sauvegardes.
Et si ça fonctionne, il faudra recommencer sur le site de production...

[RobertG]

Bonjour,

J'avais oublié une chose : pour mon besoin actuel, il me faut importer des données sur une période de 4 mois, en commençant par celles de la sauvegarde du 1er janvier.
J'avais pensé utiliser INSERT IGNORE pour le premier fichier et REPLACE pour les suivants, mais si j'ai bien compris, "REPLACE" n'ajoutera pas des lignes nouvellement créées.
Faut-il que pour ces fichiers suivants il y ait une double passe "INSERT IGNORE" qui créerait les nouvelles données sans toucher à celles existantes, puis "REPLACE" pour mettre à jour de celles précédemment présentes ?
Merci de vos conseils !