Backup and migrate ça marche ?

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Bonjour,

<

p>

<

p>

J'ai voulu utiliser le module backup and migrate

  • aucun problème pour faire des backups qui, selon toutes apparence sont Ok
  • Impossible de restaurer en local avec easyphp
  • Impossible de restaurer chez mon hébergeur : toile-libre

Dans les deux cas, il ne fait que analyser le fichier de backup, mais ne restaure pas la base de donnée. Voir fichier.

Est-ce que quelqu'un a déjà réussit à restaurer une base de donnée avec ce module?

Merci d'avance
EM

Fichier attachéTaille
Icône PDF Détails _ 127.0.0.1.pdf93.7 Ko
Version de Drupal : 

Je l'ai installé pour un client qui voulait avoir la main sur les backups mais jamais pour restaurer donc je ne peux pas répondre par contre le fichier sql est complet et bien sauvegardé (en excluant en plus les tables qui vont bien genre cache).

J'ai jeté un oeil au PDF mais il semblerait que le log que tu communiques concerne http://localhost/ct/?q=admin/user/user/list et http://localhost/ct/?q=admin/content/backup_migrate/restore n'est que référent (la page d'où tu viens).

oui mais pas en passant par l'administration drupal (jamais essayé)
je vais dans phpMyAdmin, je vide complètement la base de données (ouh, le grand saut qui fait peur), et j'utilise la fonction Importer de phpMyAdmin avec le fichier sql généré par Backup.
En rentrant dans le site il faut se reconnecter.
Jamais eu de problème.

Oui je l'ai déjà fait marché mais il y a certains paramètres à vérifier :
* php timeout : doit être assez élevé. Plus le fichier est gros plus il doit être élevé.
* php memory : cela prends pas mal de mémoire
* La table session, il vaut mieux la retirer du backup
* fichier zip, regarde si cela marche avec un petit fichier non compressé

Et surement 2 ou 3 autres choses que je ne maitrise pas vu que je ne suis pas admin système...

Merci à tous, je commençais à désespérer.

Je vais essayer d'abord avec le module, maintenant que je sais que ça peut marcher.
Ne fusse que par curiosité. Je vous dirais ce que j'ai dû changer, ou si les recommandations d'ineation, ont suffit.

J'en profite pour vous dire que j'adore vos sites. C'est principalement avec drupalfr, inéation,et biboo que j'ai appris drupal. Je trouve l'idée de drupalistic super.

EM

J'en profite pour vous dire que j'adore vos sites. C'est principalement avec drupalfr, inéation,et biboo que j'ai appris drupal. Je trouve l'idée de drupalistic super.

Moi aussi ;-p
C'est gentil, merci ! Et pour inéation, tous les drupaliens français (et -cophones) savent ce qu'ils doivent à Alexandre...

Hello,

Mes premiers résultats :

J'ai essayé avec un petit fichier, ça marche

  • Avec Backup & migrate : J'ai des erreurs mais se sont des erreurs de contenu.
  • Avec phpMyAdmin : j'ai les mêmes erreurs.

J'ai essayé avec un gros fichier, sans toucher aux paramètres, j'ai des problèmes de timout, logique, mais la réaction n'est pas la même suivant la manière dont je m'y prends

  • Avec Backup & migrate : je n'ai pas d'erreur signalée, ni à l'écran, ni dans le log. Ce que j'avais décrit plus haut.
  • Avec phpMyAdmin : SQL tombe en timeout, normal. Il me donne un message d'erreur

J'ai adapté les paramètres : upload_max_filesize, max_, max_execution_time, et memory_limit de php.ini

  • Avec Backup & migrate : (pas encore testé)
  • Avec phpMyAdmin : il importe en plusieurs passes, il arrive au bout. Ceci-dit j'ai des erreurs qui rendent impossible l'utilisation du site

En ce qui concerne les erreurs de contenu :

  • Il y a celle celle évoquée ici.
  • Une pour laquelle je me demande s'il ne s'agit pas d'ajustement à faire dans les chemins de dossier, mais où?
  •     * warning: include_once(./) [function.include-once]: failed to open stream: No such file or directory in C:\Program Files\EasyPHP 3.0\www\ct\includes\theme.inc on line 155.
        * warning: include_once() [function.include]: Failed opening './' for inclusion (include_path='.;C:\PROGRA~1\EASYPH~1.0\\php\includes') in C:\Program Files\EasyPHP 3.0\www\ct\includes\theme.inc on line 155.
        * warning: include_once(./) [function.include-once]: failed to open stream: No such file or directory in C:\Program Files\EasyPHP 3.0\www\ct\includes\theme.inc on line 155.
        * warning: include_once() [function.include]: Failed opening './' for inclusion (include_path='.;C:\PROGRA~1\EASYPH~1.0\\php\includes') in C:\Program Files\EasyPHP 3.0\www\ct\includes\theme.inc on line 155.

  • Je n'ai pas enlevé la table session, je ne l'ai pas trouvé? Elle a quelle tête?

Je vais continuer mes recherches de solutions, je vous ferais un résumé.

EM

PS - désolée pour les différentes version de ce message, une erreur de frappe.

Bonjour,

J'utilise le module Backup & migrate depuis quelques semaines

En local, il suffit d'augmenter la ram.
Sur le serveur...
Le backup fonctionne très bien, mais le restore
ne "marche pas " si tu es en limite des 32Mo (limite en mutu).
J'ai passé une nuit "dificile" après un restore
"mal terminé" cause dépassement de ram

Je viens de prendre en essai un VPS (clause 60j satisfait ou remboursé!).
dupliqué le tout.
ça change! ça marche nickel.

Sinon, pour "ré-injecter" les modifs faites du VPS(perso) sur le site
"en ligne", j'utilise un petit script "dump_restore" en php
j'upgrade (tous les rep si modules modifiés), je copie
mon backup (gzip) lance le script...
Et ça roule (base petite, <25Mo pour l'instant)...
ET malgré la "surcharge pondérale" en modules, ça passe pour l'instant dur mon hébergement mutu,en utilisation (plus en gestion!)

Après, (40 ou 50 Mo) ce sera en ssh avec putty...

Trouvé sur la FAQ d'un hébergeur:

renommer le fichier sauvegarde en "dumpDB.sql.gz"
placer le script et le fichier à la racine
(les virer ensuite)

<?php
 
// Indiquez vos données d'accès
 
$host= 'xx.xx';
 
$user= 'xxxxxx';
 
$pass= 'xxxxxxxx';
 
$db=   'xxxxxx';

 
// Restauration du fichier Gzip
 
system(sprintf(
   
'gunzip -c %s/dumpDB.sql.gz | mysql -h %s -u %s -p%s %s',
   
getenv('DOCUMENT_ROOT'),
   
$host,
   
$user,
   
$pass,
   
$db
 
));
  echo
'+DONE';
?>

Hello,

Je regrette de ne pas avoir de smiley adapté, tu m'aurais vu dans la plus grande perplexité. Je ne comprends pas vraiment ce que tu dis, mais je vais creuser.

Il y a une chose qu'il faut savoir avec backup, c'est que même si on a fait une installation multisite de type "/site/monsite.fr/files/...", le backup est fait en pointant vers "/site/défaut/files" ...

Moi aussi, j'ai été perplexe un moment ... pour une autre raison :
j'avais le message suivant:
warning: opendir(/tmp) [function.opendir]: failed to open dir: Permission denied in /mysite/www/includes/file.inc on line 895.
après un bon week-end de recherche :-(, j'ai eu l'idée de désactiver tous les modules.
Et bien, c'est le dernier réactivé, "Backup & Migrate" qui me donne ce message.
Et justement, en liaison avec ton message,
Il y a une chose qu'il faut savoir avec backup, /.../, le backup est fait en pointant vers "/site/défaut/files" ...
je m'étais demandé pendant mes recherches (en tatonnant ici et là), si ce n'était pas lié au chemin.

Mais comme à ce point, je satisfais au Principe de Peter ...

Salut,

J'utilise Backup and Migrate très régulièrement :
- à la main (Backup/Export DB) avant une mise à jour
- de manière continue et automatique (Backup Schedule) pour une sauvegarde journalière, en ne gardant que les 10 dernières.

Ça marche au poil.

Un truc à savoir toutefois : dès que le site est en fonctionnement et que la base grossit un peu, il devient impossible de télécharger la base en ligne. Il faut alors utiliser Backup and Migrate pour sauvegarder la base dans le dossier /sites/default/files/backup_migrate du site et aller la chercher par FTP.

J'arrive ainsi sans souci à faire des copies de mon site pour faire des essais.

Tant mieux, mais j'étais en train d'éditer car il manquait un bout :

J'arrive ainsi sans souci à faire des copies de mon site sur hébergement distant pour faire des essais.
Par contre, j'avais pas réussi à en réinstaller une copie en local avec EasyPHP, sans trouver pourquoi.
As-tu essayé avec WampServer?
As-tu essayé de déposer le backup par FTP?

non, je suis en distant ovh 60gp mutualisé (j'ai arrêté de me battre avec les essais en local);
mais le problème que j'ai énoncé n'est pas au moment de l'utilisation de B&M, mais simplement quand il est activé : ce message apparait au niveau du tableau de bord, si je me rappelle bien.
(au moment des installations je fais tourner le cron régulièrement et ce message ne me semble pas être venu à ce moment : d'une belle couleur rouge, il est difficile de le louper! )
j'avais fait auparavant des sauvegardes B&M qui semblaient ok;
je ne sais pas après quel évènement ce message est apparu;
(pour l'instant, je ne suis qu'en test, et je fais les sauvegardes par phpmyadmin et les fichiers par ftp)

Je cherchais une piste pour emma...

Toi, corbin, si j'ai bien compris, ton message d'erreur vient quaand tu actives le module.
As-tu tout bien défini dans : Construction du site > Système de fichier ?
As-tu le fichier sites/default/files/backup_migrate ?

As-tu tout bien défini dans : Construction du site > Système de fichier ?

j'ai par défaut : sites/default/files/
j'ai essayé d'y rajouter backup_migrate
ayant aussi /tmp par défaut, j'ai essayé, dans le doute, d'en créer à la racine, dans sites/default/files/ et même sites/default/files/backup_migrate avec chmod 777

As-tu le (fichier) dossier sites/default/files/backup_migrate ?
oui

j'ai gardé le transfert publique

et je ne pense pas que le htaccess de /files:
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks
puisse intervenir

Chemin du dossier de stockage : sites/default/files
OK

Répertoire temporaire : /tmp
OK en principe, même si sur certains serveurs il peut y avoir des répertoires avant, à vérifier auprès de l'hébergeur.

Tu as essayé de créer un fichier attaché sur un de tes contenus, ça fonctionne?

1 - oui, j'utilise imce_wysiwyg avec tinymce pour inclure au contenu des images transférées de mon micro au site.
les images sont bien transférées en /www/sites/default/files/ ou en /www/sites/default/files/répertoire_créé_à_partir_d_imce/

2 - Répertoire temporaire : /tmp
OK en principe, même si sur certains serveurs il peut y avoir des répertoires avant, à vérifier auprès de l'hébergeur.

je ne suis pas sûr de bien comprendre (je ne l'étais déjà pas avant ;-) )
pour moi, la première idée était que je devais avoir :

/www/tmp

et comme il n'y avait pas d'amélioration en le créant à ce niveau en chmod 777, que j'interprétais mal la fenêtre Drupal et que c'était :

/www/sites/default/files/tmp

mais aucun résultat non plus.

En y réfléchissant, j'ai tenté un http://monsite.com/tmp dans système de fichiers à la place de /tmp : j'ai un message me signifiant qu'il ne le trouve pas;

3 - ayant fait un ftp en download de tout le répertoire Drupal, je ne trouve pas de répertoire tmp
(alors que /tmp seul ne pose pas de problème dans la sauvegarde de système de fichiers);

4 - en revanche, dans les fichiers de sauvegarde "/backup_migrate/scheduled/" (car ça fonctionnait), je trouve une ligne :
INSERT INTO variable VALUES ('file_directory_temp','s:4:"/tmp";');

mais je ne sais pas comment interpréter son action

Je ne suis pas spécialiste en matière de serveur, mais il me semble que le répertoire /tmp se trouve généralement dissocié du répertoire contenant le site lui-même. Il sert aux transferts temporaires de fichiers et n'a donc aucune raison d'être accessible en ligne.

Ce qui compte, c'est son chemin absolu depuis la racine du serveur.
S'il est à la racine, c'est /tmp , mais si le serveur est mutualisé, le chemin peut être différent sur chaque compte.
Va voir sur le site de ton hébergeur.

Merci Brn,

tu as totalement raison : sur un mutualisé, le tmp peut ne pas être accessible :
l'équipe OVH vient de me le confirmer :

le listage du contenu de /tmp est bloqué pour éviter les risques de hack de session.
on peut créer des fichiers dans /tmp, mais on n'a pas le droit de regarder ce que les autres sites créent dans /tmp

ce qui implicitement veut dire qu'effectivement le tmp est en amont du www ou, en d'autres termes, de son propre site, sur un mutualisé.

Concernant Backup and Migrate SUR UNE INSTALLATION MONOSITE:

Dans phpmyadmin ou autre il est important d'exécuter cette commande SQL:

UPDATE files set filepath = SUBSTRING_INDEX(filepath, 'sites/ancien_site/files/', -1);
UPDATE files set filepath = CONCAT('sites/nouveau_site/files/', filepath);

et bien sûr vous remplacez par les bons noms de répertoires :)

Cependant, dans une installation multisites B&M, sauvegarde avec le chemin du monosite: sites/default/files/

Mais pourtant au moment de l'import ça peut foirer.

Concernant l'histoire du tmp, j'ai le même souci sur le serveur d'une ville, dont je n'ai pas trop le contrôle, et la création d'un tmp à la racine a enlevé le message d'erreur, mais tout est en vrac quand même, donc bon ce n'est peut-être pas une solution. Cà fait plus d'un mois que j'essaye de migrer un site sur ce serveur et je commence à criser sérieux.