Journal [Tuto/HowTo] Sauvegarder les fichiers joints de phpBB3 sur le cloud via rsync et webdav/dafvs2

• # Cohérence BDD

  Posté par lolop (site web personnel) le 12 janvier 2017 à 10:28. Évalué à 4.

  

  Salut, y'a rien à faire côté BDD pour s'assurer que le fichier qui contient la base soit bien cohérent (et que la sauvegarde ne tombe pas entre deux opérations sur la BDD)?

  Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

  • [^] # Re: Cohérence BDD

    Posté par Nils Ratusznik (site web personnel, Mastodon) le 12 janvier 2017 à 11:42. Évalué à 3.

    

    J'ai peut-être pas les yeux en face des trous, mais je ne vois rien concernant la base de données, que ce soit une copie brutale des fichiers, ou un mysqldump. Donc je ne suis même pas certain que cette copie serve à grand-chose.

    • [^] # Commentaire supprimé

      Posté par Anonyme le 12 janvier 2017 à 12:42. Évalué à 5.

      

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Cohérence BDD

        Posté par EauFroide le 12 janvier 2017 à 14:31. Évalué à 3.

        

        Pourquoi lancer deux fois la commande rsync dans un sens puis dans l'autre ?

        Le wiki de ubuntu-fr explique que rsync ne fonctionne que dans un sens, si on veut imiter le fonctionnement du client owncloud il faut lancer la commande dans les deux sens. Au départ j'étais parti sur l'utilisation de owncloud-client-cmd mais il est buggé.
        Le but étant qu'en cas de foirage on puisse directement ré-injecter les fichiers automatiquement (surtout que owncloud&nextcloud intègrent une corbeille permettant de restaurer des fichiers supprimé)

        Pourquoi ces commandes chown alors que rsync -a préserve les doits et que le scripts est lancé en root ?

        Au départ le but est de lancer rsync avec un utilisateur non privilégié. (mais j'ai un soucis avec les variables)
        Je dois aussi avouer que j'ai des doutes sur le fonctionnement des droits des fichiers lorsqu'on passe par un montage webdav/davfs2 (si root restaure un fichier depuis le cloud vers local, alors le fichier local appartiendra a root uniquement non?) hors il faut obligatoirement que l'user serveur (www-data) puisse créer/supprimer des fichiers dans /var/www/html/forum/files/

        PS: c'est la première fois que j'utilise rsync, n'hésitez pas a améliorer le script si vous en avez une meilleure compréhension que moi :)

        Merci pour vos retours ;)

        Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

        • [^] # Re: Cohérence BDD

          Posté par kna le 12 janvier 2017 à 17:29. Évalué à 4.

          

          Le wiki de ubuntu-fr explique que rsync ne fonctionne que dans un sens, si on veut imiter le fonctionnement du client owncloud il faut lancer la commande dans les deux sens.

          Oui mais non.
          Disons que tu lances un rsync de dossier1 vers dossier2 puis de dossier2 vers dossier1.
          * si tu le lances avec --delete, tu vas perdre les fichiers qui existent sur dossier2 et pas sur dossier1 avant la synchro
          * si tu le lances sans --delete, tu ne peux pas supprimer un fichier (sauf à le supprimer dans les 2 dossiers)
          * dans tous les cas, si un fichier est synchronisé, que tu fais une modif sur dossier2, la modif sera écrasée à la prochaine synchro.

          Rsync n'est pas adapté pour de la synchronisation bidirectionnelle. Point.

          Néanmoins, pour du backup, je ne vois pas l'intérêt de faire du bidirectionnel. En revanche, il serait judicieux d'avoir une rétention et ne pas écraser le backup précédent à chaque fois.

          • [^] # Re: Cohérence BDD

            Posté par EauFroide le 12 janvier 2017 à 21:24. Évalué à 1.

            

            Merci pour tes idées @kna je pense adapter mon script prochainement :)
            Genre ajouter un mode pour sauvegarder entre 1 et X last backup et une sauvegarde de la BDD.

            Néanmoins, pour du backup, je ne vois pas l'intérêt de faire du bidirectionnel.

            En gros ca permet de simplifier la ré-installation/restauration du forum :
            juste copier les fichiers, injecter la BDD puis les fichiers joints reviennent tout seul ^ ^
            
            Note que se serait une utilisation problématique si on backup en bidirectionnel tout les fichiers du forum (notamment le dossier /cache/).
            Après ce n'est que théorique perso je n'ai activé le backup que du local vers cloud :)

            si tu le lances avec --delete, tu vas perdre les fichiers qui existent sur dossier2 et pas sur dossier1 avant la synchro

            Bon à savoir, rsync n'est pas aussi "intelligent" que le client owncloud (qui lui a une mémoire)

            Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

    • [^] # Re: Cohérence BDD

      Posté par EauFroide le 12 janvier 2017 à 14:17. Évalué à 2. Dernière modification le 12 janvier 2017 à 14:18.

      

      J'ai peut-être pas les yeux en face des trous, mais je ne vois rien concernant la base de données, que ce soit une copie brutale des fichiers, ou un mysqldump. Donc je ne suis même pas certain que cette copie serve à grand-chose.

      Non ce tuto ne concerne pas la base de données (je suis en train de traiter le sujet, un tuto sur Mysql Cluster est en phase de finalisation et je rédigerai aussi un tuto plus générique pour automatiser un backup BDD de l'un ou l'autre CMS). Mais c'est vrai que j'aurai du l'intégrer directement dans ce tuto ça aurait été plus complet :)

      Cette copie vise à protéger les fichiers joints voir tout les fichiers du forum.
      Pour expliquer cette méthodologie : elle fait suite à un problème que j'ai subis cette semaine : l'update de phpbb vers 3.2 (rhea) qui a foutu en l'air mon forum.

      Comme j'étais persuadé que les fichiers joints étaient stocké en base de données (à cause de l'adresse pour y accéder dont voici un exemple download/file.php?id=468), je n'ai pensé qu'a sauvegarder ma base de données avant de tenter la mise à jours.
      La mise à jours a échoué (j'ai voulu tester la nouvelle méthode via Direct File Access) et ai donc restauré mon forum.
      Après restauration j'ai remarqué que tout était revenu en ordre sauf les fichiers joints qui eux ont disparut. Par contre ils sont encore mentionné dans les threads (exemple).

      Enfaîte phpBB stocke les fichiers joints, renommé avec un identifiant unique, dans le dossier /files/ et dans sa propre base de données il conserve une correspondance.
      Si vous voulez backup votre forum il est donc obligatoire de répliquer la BDD, les fichiers joints brute et tant qu'à faire tout les fichiers que vous avez modifié.

      Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

• # Nouveau Script

  Posté par EauFroide le 19 janvier 2017 à 16:05. Évalué à 0. Dernière modification le 19 janvier 2017 à 16:06.

  

  Suite à vos conseils et remarques j'ai recodé le script, que pensez-vous de cette version?

  Cette version va effectuer une copie vers un dossier latest ET un dossier nommé en fonction de la fréquence (hourly, daily, weekly, monthly, yearly) qui doit être passé en paramètre.
  Je me suis inspiré du mode de fonctionnement d'automysqlbackup. Je ne compresse pas les fichiers (sais pas si c'est utile, a vous de voir).

  Cordialement

  #!/bin/bash
  # Licence WTFPL - infos : https://www.0rion.netlib.re/forum4/viewtopic.php?f=71&t=496#p1081
  # synchronisation des fichiers joints d'un ou plusieurs forum phpBB sur le cloud
  # V 1.2 - lancer le software sans paramètre = backup dans dossierDistant/latest et dossierDistant/daily si non ajoutez un des paramètres cron suivant : hourly, daily, weekly, monthly, yearly (dans tout les cas le dossier latest sera update)
  
  montageLocal="/media/montageDistant" #le point de montage locale
  dossierDistant="/phpBB_fichiers_joints" #le dossier destination ne terminez pas par /
  dossierSource="/var/www/html/forum/files/" #le dossier source
  userPourCopie="root" #l'utilisateur a utiliser pour la copie
  
  if [ ! "$SUDO_USER" ]; then
  echo "this script need to be lunch by root"
  exit 0
  fi
  
     #VERIFICATION DU MONTAGE
  startTime=`date +%s`
  if [ -d "$montageLocal$dossierDistant" ];then
     endTime=`date +%s`
     runTime=$((endTime-startTime))
     if [ "$runTime" -lt "600" ];then
  
     #ACTION
  
  
              dossierTemps="/daily/"
  
              case "$1" in
              "hourly")
                  dossierTemps="/hourly/"
                  ;;
              "daily")
                  dossierTemps="/daily/"
                  ;;
              "weekly")
                  dossierTemps="/weekly/"
                  ;;
              "monthly")
                  dossierTemps="/monthly/"
                  ;;
              "yearly")
                  dossierTemps="/yearly/"
                  ;;
              esac
  
                  # VERIF IF DESTINATION FOLDER EXIST IF NOT CREAT IT 
              if ! [ -d "$montageLocal$dossierDistant$dossierTemps" ];then
                      mkdir -p "$montageLocal$dossierDistant$dossierTemps"
              fi
              if ! [ -d "$montageLocal$dossierDistantlatest" ];then
                      mkdir -p "$montageLocal$dossierDistant$dossierDistantlatest"
              fi
  
              sudo chown www-data:$userPourCopie -R $dossierSource & sudo chmod 770 -R $dossierSource
                #sauvegarde des fichiers locaux vers cloud
  #echo "copie dans $montageLocal$dossierDistant$dossierTemps"
              su $userPourCopie -c "rsync $dossierSource $montageLocal$dossierDistant$dossierTemps -r --delete"
  #echo "copie dans $montageLocal$dossierDistant/latest"
              su $userPourCopie -c "rsync $dossierSource $montageLocal$dossierDistant/latest/ -r --delete"
                #on reverrouille l'accès au dossier
              sudo chown www-data:root -R $dossierSource & sudo chmod 770 -R $dossierSource
     else
     echo "$montageLocal => not responding (408) / delais d'attente depasse"
     fi
  else
  echo "$montageLocal$dossierDistant => not exist"
  fi

  Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.