Script de sauvegarde serveur Debian + IspConfig3

Programmation
#41

Aïe, tu me fais peur. Je vais devoir bientôt faire changer le disque de mon dédié, je devrais le retrouver vide, c’est à dire avec ma distrib Debian + peut-être ISPConfig3 (c’est la configuration que j’ai choisie chez OVH à la commande).
Je pensais pouvoir réutiliser les backups effectués par le script pour :

  • Remettre l’environnement user, groupes… bref /etc/ grâce à etc-xxx.tar.gz
  • Remettre ISP config + sa DB grâce à: ispconfig_software-xxx.tar.gz, dbispconfig-xxx.sql.gz, vmail-xxx.tar.gz et etc-xxx.tar.gz
  • Redéployer les fichiers de chaque site + sa/ses DB(s) associée(s) grâce à : /sites/webXX-xxx.tar.gz et /mysql/cX_DB.xxx.gz
    En tous cas, dans la doc ISPConfig3, la méthode de backup/restore ne concerne que ces items.

Je ne comprends pas ça:

[quote=“lol”]
S’il s’agit de restaurer un serveur à partir de zéro, c’est plus compliqué… J’en ai eu l’expérience récemment lors d’un changement de serveur.
Il faut tout se taper à la main…

  • Créer les utilisateurs, sites et bases dans ISP.[/quote]

Normalement la DB ISPConfig contient toutes ces informations non ?
Et la partie système des users est dans /etc/passwd, /etc/shadow… etc qui sont backupées dans etc-xxx.tar.gz.
Je loupe quelque chose ?

[quote=“lol”]

  • Restaurer les sites et les bases;[/quote]
    Le restore depuis /sites/webXX-xxx.tar.gz et /mysql/cX_DB.xxx.gz ne suffit pas ?

[quote=“lol”]

  • Changer les uid/gid si nécessaire (attention, certains CMS contiennent des chemins dans les bases, il faut penser à vérifier et changer si nécessaire - c’est un peu chiant à faire…).[/quote]
    Encore une fois, la partie système des users dans /etc/passwd, /etc/shadow… etc qui sont backupés dans etc-xxx.tar.gz ne suffit pas lorsqu’on repart de zéro ?
    Le fait d’écraser /etc/passwd et /etc/shadow par les fichiers backupés ne me fait pas retomber sur mes pattes ? (sachant que root, nobody and co auront le même).
#42

Salut,
Tu as parfaitement raison.

En résumer, si la machine (serveur ovh avec ispconfig préinstallé) de destination est identique à la machine d’origine, une simple restauration fonctionnera parfaitement.
En ce qui me concerne je n’ai pas fais ce choix (j’ai pris une Debian de base, suis passé à Debian CUT et ai installé ispconfig moi-même). Les uid/gid étaient différents, donc impossible de restaurer à l’identique (la machine d’origine était une OVH avec ispconfig pré-installé).

#43

Bon, tu me rassures en tous points.
Je vais bientôt devoir tester sans filets le restore, je ferai ça manuellement, et je ferai un retour ici si par hasard il y a un problème lié à la façon dont les fichiers ont été backupés.

Si j’ai un peu de mou, je m’essaierai peut-être à écrire un script de restore; l’idée que j’ai est de rajouter la création d’un fichier plat au script de backup, listant tous les sites et bases, et uploadé sur la FTP qui serait en entrée du script de restore.
Le restore (complet) consisterait à récupérer tous les packages localement depuis le FTP, et déployer dans l’ordre :

  • /etc/*
  • /usr/local/ispconfig/*
  • /var/www/clientX/webY/* [n fois]
  • mysql import [n fois]
#44

Salut,

Excellente idée; Je ne m’y suis pas attelé car je n’en ai pas eu besoin… Je sais, ce n’est pas bien de ne pas prévoir à l’avance! :blush:

J’avais tout de même fais un essai dans une VM et je n’avais pas rencontré de pb particulier.
La VM était une réplique de mon dédié.

#45

Tu ne passe pas par un software pour gérer l’ensemble des tes back-ups ?

Une solution serait sans doute de centraliser une sauvegarde sur une/des machines dédié à ça avec l’aide d’une solution de sauvegarde de ce genre : bacula.org/fr/

Tout en continuant d’utiliser une sauvegarde comme tu le fait en locale avec une rétention moindre que sur la solution dédié.

Ce qui te permettrai d’avoir un minimum de support en cas de souci je pense aussi.

L’avantage de conserver une copie en locale et une copie centralisé sur une machine dédié et de pallier au problème machine et de pouvoir à la volée refaire une machine partie en cacahuète, ou de pouvoir injecter une simple sauvegarde d’un de tes clients.

Il y a aussi la possibilité de mettre une interface web en place et sans doute aussi ça n’existe pas de coupler les sauvegarde avec un trigger zabbix voir même une sonde nagios/shinken pour t’avertir lors de souci de sauvegarde.

Pour savoir tu utilise des rétentions de combien de temps (c’est du confort ou un service payant ?)?

#46

Salut Clochette,
Non, je n’ai pas encore suffisamment de machines à sauvegarder. Mais ça commence, je vais y penser sérieusement.
J’avais déjà tâté Bacula, c’est vrai que c’est un bon choix. je ne savais même pas qu’il y avait une interface d’administration centralisée…
C’est surement une bonne solution. :023

Je garde 15 jours de sauvegardes, c’est juste un plus que j’offre à mes clients (et c’est non payant).
Aucun ne m’a demandé de conserver plus longtemps, ce qui leur importe c’est de retrouver rapidement leurs sites en ligne en cas de problème.

#47

[quote=“lol”]Salut Clochette,
Non, je n’ai pas encore suffisamment de machines à sauvegarder. Mais ça commence, je vais y penser sérieusement.
J’avais déjà tâté Bacula, c’est vrai que c’est un bon choix. je ne savais même pas qu’il y avait une interface d’administration centralisée…
C’est surement une bonne solution. :023

Je garde 15 jours de sauvegardes, c’est juste un plus que j’offre à mes clients (et c’est non payant).
Aucun ne m’a demandé de conserver plus longtemps, ce qui leur importe c’est de retrouver rapidement leurs sites en ligne en cas de problème.[/quote]

Disons que Bacula propose aussi du support (certes payant mais dès fois c’est pratique lorsque l’on se torture sur un problème sans avoir le temps).

Pour ce qui est de la sauvegarde actuelle, c’est une bonne chose de le proposer comme un confort supplémentaire.

Mais attention arrivé à un moment le nombre de sauvegarde sera tel que la gestion de tous ceci devra être payant car cela prendra énormément de temps à vérifier et à débugger.

#48

Re,

Sans compter l’espace et la bande passante…

J’ajoute maintenant à mes sites quelques serveurs mails internalisés…
Jusqu’à présent j’impose à mes clients de me donner un accès dans leur LAN pour faire les sauvegardes; mais ce serait mieux à l’extérieur…
Je vais me pencher sérieusement sur la question, merci d’avoir soulever ce point.

Edit: Y’a une page sur le Wiki sur bacula, c’est le moment de tester… Merci Haludeis! :wink:

#49

MMmm… pour revenir au script, je me demande s’il ne faudrait pas, par défaut, exclure la DB d’ISPConfig de la partie backup mySQL :

…puisque dans la section dédiée au backup d’ISPConfig, on le refait :

mysqldump -u root -p"$PASS" dbispconfig > "$DESTISP"/dbispconfig-$DATE.sql; gzip -f "$DESTISP"/dbispconfig-$DATE.sql log_msg "`date +%X`: dbispconfig-$DATE.sql.gz sauvegarde terminée"
À moins qu’il n’y ait une bonne raison ?
J’ai au passage noté que les tailles des deux zips de la même base sont différentes. C’est dû au user utilisé pour le mysqldump, un coup root, un coup ipsconfig ?

#50

Laurent, attends-toi à une discussion sur 3 ou 4 semaines minimum et après, tu ne reconnaitras plus ton script originel :laughing: :laughing: :laughing:

#51

Si c’est pour l’améliorer, c’est tant mieux non ? :slightly_smiling:

#52

Petite question : pourquoi mysqldump et pas mysqlhotcopy ? (le hotcopy laisse la base accessible en lecture, et la lock au maximum 5 secs pour l’écriture).

#53

Tu es trop “jeune” sur le forum, c’est une galéjade entre MisterFreez et moi :smiley:

#54

Tu es trop “jeune” sur le forum, c’est une galéjade entre MisterFreez et moi :smiley:[/quote]
Je l’avais noté même si je n’ai pas répondu :slightly_smiling: Tu en es bien content de ton script, non ?

#55

[quote=“MisterFreez”]
Je l’avais noté même si je n’ai pas répondu :slightly_smiling: Tu en es bien content de ton script, non ?[/quote]
Bien sûr que j’en suis content et j’ai d’ailleurs beaucoup appris lors de ces échanges :006

#56

Salut,

[quote=“sebdonato”]je me demande s’il ne faudrait pas, par défaut, exclure la DB d’ISPConfig de la partie backup mySQL
…
J’ai au passage noté que les tailles des deux zips de la même base sont différentes. C’est dû au user utilisé pour le mysqldump, un coup root, un coup ipsconfig ?[/quote]

Oui, ça fait double emploi effectivement.
Pour la taille, il y a un .sql et un gz (compressé).

#57

Bonjour,

Il est super ce script… Moi j’ai un soucis, je ne reçoit pas d’email de log en fin de script… Une idée ?

#58

Salut,

Problème avec la commande ?

Problème d’alias ?

#59

Hello,

Ce me suis inspiré de beaucoup de scripts, dont celui-ci, pour faire le mien, donc je le partage avec la communauté zenzla.com/linux/574-script- … l-web.html

Zenzla

#60

Salut,

Merci pour la contribution (je ne sais pas de quand date ton message… mais merci!).