Bonjour,
En suivant votre code et pour éviter tout problèmes, j’arrive a un script (ci joint) qui bloque les tables SQL durant la sauvegarde.
Pouvez vous me dire si il est correct ?
Merci d’avance.
sauvegarde.txt (6.62 KB)
Bonjour,
Les bases sont effectivement verrouillées pendant le “dump”, c’est normal.
J’utilise ce système sur des bases qui ne sont pas importantes et sur des sites à fréquentation “raisonnable”… Une coupure de moins d’une minute est sans incidence.
Je suis en train de réfléchir à une autre procédure: réplication vers un autre serveur et sauvegarde sur celui-ci; Du coup pas de blocage de base sur le serveur “maître”.
Pour ton script, je ne comprend pas la question…
Juste savoir si c’est bien cela, je veux être sur avant de faire une erreur maladroite.
Re
Compris. Il va falloir le “débugger” toi-même…
Pour cela, ajoute des pauses à chaque action, et vérifie que chaque étape se déroule bien…
Bonjour,
Tout d’abord un grand merci pour ce script !
Je l’ai lancé hier avec succès.
J’ai toutefois eu quelques comportements bizarres, visiblement, pour les web_domains déclarés dans ISP Config qui ne sont pas de type vhost, c’est-à-dire dans mon cas 2 alias et 1 subdomain.
Pour les web_domains de type alias, déclarés comme appartenant à client0, est-il vraiment nécessaire de backuper le “site” ? Dans la mesure où concrètement, il n’y a pas de répertoire /var/www/client0/webx, je ne pense pas.
Pour les web_domains de type subdomain, c’est même “pire”, puisqu’il n’y a visiblement ni client au sens ISPConfig, ni document_root.
Je propose - à moins que j’ai dit une sottise précédemment - de changer la requête qui récupère la liste des sites pour ne prendre que les web_domains de type vhost :
###################################################################### BACKUP SITES
[ ! -d $DESTSITES ] && mkdir -p $DESTSITES
# Récupération infos clients et sites
cd "$CHEMIN"
echo "select system_user,system_group from web_domain where type='vhost' " | mysql -u $USER -p$PASS -D $DB > $TEMP
tail -n +2 "$TEMP" > liste
rm "$CHEMIN/$TEMP"(à vérifier les simples quotes dans la requête, je suis un bleu en shell script).
Qu’en pensez-vous ?
Une autre question que je me pose concerne le restore de ces fichiers et databases : j’imagine que ça se fait avec le user root (ou tout autre user de type admin). Qu’en est-il alors au niveau des droits et owners des fichiers, un fois restaurés ? Ils sont tous root:root ou bien avec leurs users webx:clienty respectifs ?
S’ils sont tous root:root avec les droits associés, est-ce que ça n’a pas d’effet de bord sur l’usage ultérieur ?
Autre question, concernant les liens symboliques que fait ISPConfig dans /var/www/ d’un alias de type mondomaine.tld -> /var/www/clients/clientx/weby/
Faut-il les recréer à tout prix ? Si oui, manuellement ou est-ce qu’ISPConfig va le faire de facto en sauvant le site via l’interface ou d’une autre manière ?
Désolé pour ces questions de débutant, c’est ce que je suis… 
Salut,
Merci pour le retour.
Effectivement prendre seulement les vhost est intelligent.
Pour ce qui est des restaurations…
S’il s’agit de restaurer seulement un site:
Les archives contiennent les bon propriétaires; Une restauration ne changera donc par les uid/gid (à moins de forcer root, mais ce ne serait pas malin
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.
- Restaurer les sites et les bases; 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…).
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).
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é).
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]
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! 
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é.
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 ?)?
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. 
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=“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.
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.
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!
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 ?
Laurent, attends-toi à une discussion sur 3 ou 4 semaines minimum et après, tu ne reconnaitras plus ton script originel 
Si c’est pour l’améliorer, c’est tant mieux non ? 
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).
Tu es trop “jeune” sur le forum, c’est une galéjade entre MisterFreez et moi 