Logo Khaganat
Traductions de cette page?:

Les informations sur cette page ne sont plus à jour. Cela vous aidera peut-être, mais usez de votre discernement et adaptez.

Processus de sauvegarde sur un serveur

Il peut arriver plein de choses à un ordinateur, d'autant plus s'il est en ligne, donc : sauvegardez, sauvegardez !

Cet article aurait besoin d'être dépoussiéré, certaines de ses informations, sans être fausses, ne sont pas forcément des plus pertinentes. Utilisez votre esprit critique si vous l'utilisez pour vos besoins, et participez à son amélioration.

Pour que les sauvegardes servent à quelque chose, il faut qu'elles soient fonctionnelles, régulières, et placés en divers lieux physiques, mais aussi il faut tester régulièrement une récupération des données : un backup qui ne fonctionne pas, ça n'intéresse personne. Au minimum, envoyez les sauvegardes de votre serveur sur votre propre ordinateur ; dans l'absolu, c'est plus pratique d'avoir un second serveur en ligne dédié à la sauvegarde + un ordinateur personnel qui duplique les données. Trois endroits où avoir les données, ce n'est pas trop.

Pensez que votre serveur peut être piraté… mais aussi que le disque dur peut lâcher brusquement ou disparaître dans un incendie. Dans ce cas, comment remettrez-vous les données en ligne ?

Nous vous présentons ici une façon de faire : il en existe d'autres.

Complétez cet article avec vos connaissances !

Sauvegarde des bases mysql via un script

Un certain nombre de CMS passent par des bases de données type mysql. Vous pouvez sauvegarder toutes ces bases en un script, lancé à intervalle régulier via cron.

Cette partie est probablement en partie obsolète. Ne copiez pas bêtement, lisez tout soigneusement, utilisez vos connaissances, testez, puis mettez cette partie à jour.

backupmysql.sh se charge de sauvegarder, de façon séparée, chacune des tables utiles, tout en incrémentant le nom du fichier de sauvegarde avec la date du jour. En bonus, la sauvegarde d'un annuaire LDAP (adaptez à vos besoins !). Puis il supprime les plus anciennes sauvegardes, sinon ça devient le bazar et ça prend de la place :

backupmysql.sh
#!/bin/bash
# Variable pour avoir la date du jour 
TODAY=$(date +%Y-%m-%d)
 
# Sauvegarde des tables
/usr/bin/mysqldump -u root -p$(cat /home/user/.password) --opt etherpad > /home/user/mysqlbackup/$TODAY-etherpad-mysqldump.sql
/usr/bin/mysqldump -u root -p$(cat /home/user/.password) --opt smf > /home/user/mysqlbackup/$TODAY-smf-mysqldump.sql
/usr/bin/mysqldump -u root -p$(cat /home/user/.password) --opt teampass > /home/user/mysqlbackup/$TODAY-teampass-mysqldump.sql
/usr/bin/ldapsearch -xLLL -D "cn=admin,dc=monserveur,dc=net" -w $(cat /home/user/.ldapassword) > /home/user/mysqlbackup/$TODAY-exportKLDAP.ldif
 
# Nettoie le dossier "Backup" régulièrement, afin qu'il ne prenne pas trop de place.
 
# On se fait une jolie variable qui imite le nom des fichiers de sauvegarde, avec leur chemin complet, pour éviter d'effacer n'importe quoi
mysqldump='/home/user/backup/*mysqldump.sql*'
 
# On efface celles ayant plus de 15 jours
find $mysqldump -type f -mtime +15 -exec /bin/rm -f {} \;

S'assurer que les fichiers /home/user/.password et /home/user/.ldapassword contiennent bien le mot de passe de root (mysql et ldap)… et que les droits sont donnés, en lecture, uniquement à l'utilisateur qui va lancer le script.

Avant de lancer le script, vérifier que les dossiers existent, l'user est le bon, puis testez, avant de mettre le cron en place.

Exemple de cron : le script se lance tous les jours à 00H301) :

30 0 * * * /home/user/backup/backupmysql.sh

Le fonctionnement de Mariadb a changé, et il semblerait qu'il faille changer le script de la façon suivante, en le lançant en root :

/usr/bin/mysqldump --opt smf | gzip -2 > /home/khaganat/mybackup/$TODAY-smf-mysqldump.sql.gz

Crontab associé (depuis l'user root, donc) :

# Sauvegarde des tables
00 1 * * * /home/user/mybackup/backup.sh

Vérifier soigneusement avant de faire confiance…

Rsync sur les données vers un serveur distant

Copie des données distantes

Sur le serveur de sauvegarde, un script (script.sh) se charge de faire un rsync sur les données utiles.

bash
#!/bin/bash
 
for var in $(cat /home/user/sav/backup); do  rsync -av --delete-after utilisateur@monserveur.net:$var /home/user/sav/vps; done > /home/user/sav/vps$(date +%Y-%m-%d)-svg.log 2> /home/user/sav/vps$(date +%Y-%m-%d)-err.log

Adapter /home/user/sav/ à votre propre chemin sur votre serveur.

Le fichier backup (dans le même dossier que script.sh) liste les dossiers à sauvegarder, par exemple :

/home/user/backup
/home/etherpad
/home/user/supybot
/var/www
  • backup est notre dossier avec les sauvegarde mysql, cité plus haut
  • etherpad et supybot sont des exemples de dossiers situés dans des endroits spécifiques
  • /var/www devrait sauvegarder toutes vos données accessibles via le net.

Deux fichiers de log sont générés, l'un avec les possibles erreurs, l'autre avec ce qui a été synchronisé. Lancez le script une première fois et vérifiez les erreurs : ce serait dommage que vos sauvegardes ne fonctionnent pas, parce que vous avez oubliez de configurer les droits sur vos fichiers !

Faire tourner les sauvegardes

Afin d'avoir des sauvegardes à différents moments, afin de pouvoir remonter dans le temps en cas de souci, un script copie régulièrement les dossiers, puis les effacent après 100 jours :

#!/bin/bash
# Sauvegardes tournantes web : pour garder une version plus ancienne en cas de souci. 
# Chaque version a 5 jours de décalage ; au bout de 3 mois on vire.

# On récupère les variables du jour 
day=$(date +'%d')
year=$(date '+%Y')
m=$(date -d "today" '+%m')
#On se fait une jolie variable avec la date du jour
sav=save_$year-$m-$day
# On copie le dossier actuel du site web dans un autre répertoire
cp -R /home/user/sav/vpsweb/ /home/user/sav/oldsave/$sav
# Dossiers à effacer lorsqu'ils sont trop vieux, avec chemin complet
savdel='/home/user/sav/oldsave/*'
# On supprime celui qui date d'il y a plus de 100 jours. 
find $savdel -type f -mtime +100 -exec /bin/rm -R {} \;
# cron à mettre en place
# 15 3 5,10,15,20,30 *  * user /home/user/sav/sav_tournante.sh

Adapter user et le chemin des dossiers. Dans l'exemple, un dossier “oldsave” a été créé dans /home/user/sav afin de stocker les dossiers sauvegardés.

Cron

Enfin, un cron sur le serveur lance la sauvegarde régulièrement (ici, à 2H00 le 1er, 3e, 5 et 7e jour de la semaine), ainsi que le script pour garder des images plus vieilles (à 3H15 le 5, le 10, le 15, le 20, le 25 et le 30 de chaque mois) :

0 2 * * 1,3,5,7 /home/user/sav/script.sh
15 3 5,10,15,20,30 *  * user /home/user/sav/sav_tournante.sh

Pour que ces scripts fonctionnent, il faut avoir donné le droit à votre serveur de sauvegarde de se connecter au serveur à sauvegarder sans mot de passe ; voir se_connecter_sans_mot_de_passe_methode_non_securisee

À la main de temps en temps ?

Cela change rarement, mais ça peut faire gagner du temps :

Sauver les fichiers dans /etc/apache2/sites-available de temps en temps, après les modifications.

Sauver le contenu de /etc/openvpn en cas de changement, si vous avez mis en place un VPN.

Sauvegarder l'état du pare-feu :

iptables-saves > 2016-02-17-iptables-saves

Pouvoir récupérer des données sur un autre serveur

Lors d'une réinstallation, il faut aller chercher ce qu'on a sauvé. Après avoir préparé les éléments de base du serveur, générez une clé rsa depuis votre utilisateur lambda (pas en root), sans mot de passe2).

ssh-keygen -t rsa

Puis copier cette clé sur le serveur qui a les sauvegardes, sur le bon utilisateur

ssh-copy-id -i ~/.ssh/id_rsa.pub moncomptedesauvegarde@serveursauvegarde.com

Comme ça peut durer un moment ces trucs, protéger un peu l'accès sur le serveur de sauvegarde :

nano .ssh/authorized_keys

S'assurer au passage que l'utilisateur moncomptedesauvegarde a bien les droits sur le dossier qu'on va récupérer.

Et ajouter l'ip devant la clé de “lambda”

from="ip du nouveau serveur" ssh-rsa XXXYYYZZZ(clé) lambda@nouveauserveur.net

Ensuite, on fait un cd pour se placer là où on veut récupérer les données sauvées, puis un rsync :

cd /var/www/oldsave
rsync -av moncomptedesauvegarde@serveursauvegarde.com:/repertoire . 2>&1 > rsynctrace.txt
  • -av signifie
    • -a ou –archive : raccourci pour la récursivité et préserver les droits etc.
    • -v : verbose, avec des détails.
    • moncomptedesauvegarde@serveursauvegarde.com : à adapter pour se connecter au serveur de sauvegarde
    • :/répertoire : le chemin, depuis la racine, du répertoire qu'on veut copier.
    • . : à copier dans le dossier courant
    • 2>&1 > rsynctrace.txt : va faire un fichier de “log” avec ce que fait rsync, c'est plus facile à consulter qu'en console et on garde trace de tout souci rencontré.

Dans le sens inverse

Je garde la démarche ci-dessous “au cas où” mais ça va bien plus vite de récupérer depuis un serveur de sauvegarde en ligne. Je laisse l'aspect “notes”, flemme de trop corriger.

J'ai eu un souci pour faire rsync vers mon serveur perso, ce dernier ayant un port non standard pour ssh.

Du coup, j'envoie depuis mon serveur vers le nouveau serveur

ssh-copy-id -i ~/.ssh/id_rsa.pub lambda@vpstests.khaganat.net

Pour rsync :

rsync -av ./www/accueil lambda@vpstests.khaganat.net:/var/www/html

Donc : du dossier vers le serveur. Tout simple.

1)
Il vaut mieux lancer les scripts de sauvegarde au moment où vos utilisateurs ont peu de chance d'être en ligne, car ils peuvent consommer pas mal de ressources.
2)
C'est le temps de prendre les infos, ça va pas durer. Cette clé est à détruire ensuite !
CC Attribution-Share Alike 4.0 International Driven by DokuWiki
fr/sauver_serveur.txt · Dernière modification : 2022/04/25 09:20 de zatalyz

Licences Mentions légales Accueil du site Contact