Sauvegarder son site avec Git !

Bien ou pas bien ?

Le problème exposé dans ce sujet a été résolu.

Bonjour les Z’amis !

Je développe mon site web depuis des années et des années, que j’améliore au fur et a mesure du temps. Il me sert à apprendre, m’améliorer, tester les nouvelles technos, parler, etc. C’est en quelque sorte un petit fourre-tout.

Je mets à jour les fichiers (PHP, CSS, etc.) environ toutes les semaines via SFTP. J’utilise Adminer via mon interface d’administration pour gérer ma BDD MySQL.

Au début, je sauvegardais les images, les fichiers uploadés, etc., à la main.

Ensuite, j’ai appris quelques lignes en bash et je me suis écrit un script, mais pas encore parfait à mon goût, car je devais sauvegarder encore des choses à la main.

Puis je me suis dit, pourquoi ne pas essayer Git pour la sauvegarde ?!

Je précise que je ne l’utilise pas pour ce projet, car je suis tout seul, et je n’en n’aurai pas vraiment l’utilité.

J’ai donc créé un repo sur GitLab (privé le repo :O), ainsi que sur Raspberry Pi à la maison + un Cloud Chiffrer AES 256bits sur Mega.nz (triple sauvegarde, donc :D, au cas où…). Mon script de sauvegarde fait maintenant 6 lignes; avant il en faisait une 50aines.

Je sauvegarde ma BDD SQL via mysqldump, et mon /var/www via Git.

mysqldump xx xx xxx xxxx cmde cmde xxx cmde
git add . && git commit -m "commit $1" && git push

Avant, c’était un gros pâté de script qui faisait tout est n’importe quoi, pour vérifier que telle image correspondait à telle date, etc.

Bon voilà, personnellement, je trouve cette méthode très utile pour la gestion de ma sauvegarde.

Mon premier commit m’a prit un peu de temps car le site pèse environ 7 Go, mais maintenant, elles sont rapides.

Ma question est la suivante, est-ce vraiment optimal pour une utilisation en production ? genre entreprise ou autre

Concrètement, est-ce bien de sauvegarder son site avec Git, ou est-ce mal ?

+0 -0

Salut.

D’abord une petite remarque :

Je précise que je ne l’utilise pas pour ce projet, car je suis tout seul, et je n’en n’aurai pas vraiment l’utilité.

Tu as mal compris l’utilité de git, on dirait. Ça ne sert pas qu’à collaborer mais à versionner un projet, notamment en différenciant les versions stables du code des versions en cours de développement, de façon à te promener facilement dans l’historique, découvrir quand un bug a été introduit pour mieux le corriger, etc. Rien à voir avec le fait de bosser seul ou à plusieurs, donc.

Ma question est la suivante, est-ce vraiment optimal pour une utilisation en production ? genre entreprise ou autre

Concrètement, est-ce bien de sauvegarder son site avec Git, ou est-ce mal ?

Non, on ne fait pas ça en entreprise parce qu’on sépare les problématiques de versionnement/cycle de developpement (ce à quoi sert git), de celles de déploiement, pour lesquelles il existe des tonnes de solutions plus adaptées : packages (RPM ou DEB ou autres), scripts de déploiement utilisant ansible ou salt, provisionnement des serveurs (openstack, docker, etc.). En fait c’est un metier bien à part.

Le fait de cloner le code en utilisant le gestionnaire de version, c’est une approche qui peut marcher pour des projets simples ou en début de vie, mais c’est très rarement de cette façon que ça se passe "dans la vraie vie".

+7 -0

Je précise que je ne l’utilise pas pour ce projet, car je suis tout seul, et je n’en n’aurai pas vraiment l’utilité.

+1 Pour nohar.
Définitivement.

Le fait de cloner le code en utilisant le gestionnaire de version, c’est une approche qui peut marcher pour des projets simples ou en début de vie, mais c’est très rarement de cette façon que ça se passe "dans la vraie vie".

nohar

Humm, oui et non. Car en entreprise, tu peux trouver des projets versionnés avec Git et installé avec git clone + un script d’installation. Ou simplement versionné car le déploiement peut également être effectuer par le client (ce qui veut dire une autre entreprise dans les faits …). Mais ce n’est pas le plus courant.

Pour des projets simples c’est pas mal. J’utilise git pour pratiquement tous mes projets.

+4 -0

@nohar : si si j’ai bien compris Git, je me suis mal exprimé, mais en gros, je n’en ai pas l’utilité pour ce projet. Sur un autre projet où je suis seul, je l’utilise et il m’aide énormément par contre. Là, c’était simplement pour expliquer que je n’utilisais pas Git pour versionner ce projet :P

Du coup, quelle est la solution la plus adaptée pour sauvegarder un site tous les jours ? dois-je retourner à mon script bash ?

  1. Sauvegarde la BDD dans le fichier /var/backup/backup.sql.date.gz
  2. Sauvegarde du site (/var/www/) dans le fichier /var/backup/backup.site.date.gz
  3. Je compresse les deux fichiers
  4. J’envoie le fichier vers un Cloud distant (mon Rpi et un Cloud à la mega.nz)
  5. Je supprime les fichiers

Tous les jours vers 3h du matin.

+0 -0

Je comprend pas ta nécessité de sauvegarder ton site. Il est pas déjà sauvegardé ailleurs ? Si tu mets à jour le site, c’est bien que tu as les fichiers quelque part et dans ce cas-là il faut sauvegarder depuis la source et non en production.

Pour la base de donnée/les uploads, c’est une bonne solution. Idéalement tu fais une grosse backup toutes les semaines/deux semaines, et des backups incrémentales le reste du temps.

+0 -0

Les fichiers sources sont sauvegardés sur mon PC oui.

Mais le reste ? c’est le plus important.

La base de données, les fichiers uploadés, les images uploadées, etc… c’est environ 200 fichiers par jours.

A chaque commit que je fais tous les jours, c’est 2.000 lignes modifiées, donc je pense que c’est important de faire des sauvegardes…

+0 -0

Euh … Git c’est pratique pour versionner le projet. Tout ce qui est données utilisateurs et BDD doit être sauvegarder à part, avec un autre système.

Que ce soit du RAID, de la réplication de données automatique (unison par exemple), de la sauvegarde journalière (à base de script par exemple rsync, …). Les solutions sont diverses et variée.

+0 -0

Ouais j’ai bien compris, mais je ne trouve pas solution ou de script qui permet de faire ce que je veux, c’est le soucis.

Avec Git, j’ai vraiment tout, et c’est vraiment super, après je ne vois pas quel est le soucis ? Certes Git n’est pas fait pour effectuer des sauvegardes, je l’ai bien compris.

Mais à la base, l’électricité n’était pas fait pour rouler, Tor n’était pas fait pour vendre des trucs bizarres, etc. :D

J’en ai détourné l’utilisation, et je trouve ça merveilleux. Après si c’est mal, j’aimerai vraiment savoir pourquoi. Car concrètement, il fait des backups incrémental avec les commits, si on change de serveur, un simple "git clone" et le site est en ligne en moins de 2 minutes, franchement j’adore.

+0 -0

Le truc, c’est que git ne fait pas des backup incrémentales la plupart du temps justement. Il stocke des versions entières et non des différences, jusqu’à ce que le garbage collector mette ce qu’il veut dans des archives.

T’as pas d’outils tout-en-un parce que chaque site a ses propres besoins, mais tu peux commencer par extraire ce que tu veux, puis tu as rsync comme l’a dit ache. Git ne t’apporte pas plus que rsync là.

Par contre le RAID c’est pas une solution de backup.

+2 -0

Avec Git, j’ai vraiment tout, et c’est vraiment super, après je ne vois pas quel est le soucis ? Certes Git n’est pas fait pour effectuer des sauvegardes, je l’ai bien compris.

Mais à la base, l’électricité n’était pas fait pour rouler, Tor n’était pas fait pour vendre des trucs bizarres, etc. :D

Machou

Et les grilles-pains n’étaient pas faits pour faire tourner Linux, et pourtant aujourd’hui on peut installer Linux sur un grille-pain.

C’est merveilleux.

Toujours est-il que je ferais pas tourner une prod sur un grille-pain, pas plus que je ne mélangerais le code et les données d’un site pour les versionner sur un repo Git de 7 Go.

À la rigueur, tu peux toujours utiliser Git LFS pour des gros fichiers binaires, mais ça reste quand même bancal. Je ne vois pas l’intérêt de garder tous les snapshots quotidiens de la BDD depuis sa création notamment, alors que tu pourrais en garder un par jour sur la dernière semaine, un par semaine sur le dernier mois, un par mois sur la dernière année, et un par an avant ça (et encore, à condition qu’il y ait un quelconque intérêt à revenir à un snapshot plus d’un an en arrière). Ne serait-ce que pour ne pas prendre de l’espace pour rien.

+1 -0

Bon, je vois que mon idée n’est pas adaptée alors.

Je comprends, je vais me tourner vers une solution plus viable. :)

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte