Le but est de sauvegarder un serveur distant sur un pc qui n'a pas vocation à être allumé en permanence. L'autre objectif est aussi de se passer de la location d'un espace ftp pour entreposer des sauvegardes. l'inconvénient est le temps d'upload qui sera beaucoup plus long en cas de restauration.

On va faire mumuse, avec le wake on lan, openssh et backup-manager.

Backup-manager est composé d'un ensemble de scripts qui sous-traitent à des programmes bien communs et rodés (tar, scp, etc... etc...) C'est notamment pour ça que je l'apprécie, pas de mauvaise surprise. Il me sert depuis 2 ou 3 ans pour les serveurs linux du travail et depuis moins de temps pour le serveur qui héberge ce blog.

Petit schéma de l'installation.

Il alourdit la lecture de ce billet, mais ça me fait mal au cœur de l'effacer.

________
|Dedibox|
|débian	|
________|
    |eth 0
    |IP publique:111.111.111.111
    |
    |
    |
    |IP publique:222.222.222.222
 ___|___
/Freebox/
--------
    |
    |IP locale: 192.168.0.254
    |_______________________
    |			    |ip locale 192.168.0.253 	adresse mac: 
    |			____|___________		XX:XX:XX:XX:XX
|-------|		|PC (Fédora13)	|
|PC 1   |		|sauvegardes	|
|	|		|---------------|
---------

• Le serveur à sauvegarder IP notée 111.111.111.111
• L'adresse publique du modem 222.222.222.222
• L'IP locale du PC qui servira aux sauvegardes: 192.168.0.253 adresse mac notée: XX:XX:XX:XX:XX^[1]

Le PC1 est là juste pour faire joli et quelques tests

Backup-manager

L'installer

apt-bet install backup-manager

Configurer backup-manager

Tout se passe dans le fichier /etc/backup-manager.conf. Si la lecture de l'anglais technique fait partie de vos compétences, le paramétrage ne devrait pas vous poser de soucis, car le fichier de configuration est bien documenté.
On va le configurer directement, dans sa version finale. Il faudra paramétrer le wake on lan et le ssh après.

Repository

J'ai tout laissé par défaut. La copie locale sera mise dans /var/archives

export BM_REPOSITORY_ROOT="/var/archives"

Archives

export BM_ARCHIVE_TTL

Indique le "time to live" Soit le nombre de jours dont les archives sont gardées. ^[2].

export BM_ARCHIVE_METHOD="tarball-incremental mysql"

Ce sont les méthodes de sauvegardes que j'ai choisi.

Un petit mot sur les avantages/inconvenants de l'incrémentiel: Dans une stratégie de sauvegardes incrémentielles, Des sauvegardes totales (tous les fichiers) sont effectuées à une périodicité assez éloignée. Entre deux, on effectue des sauvegardes incrémentielles, qui ne prennent que les fichiers qui ont été créés ou modifiés depuis la sauvegarde précédente.

L'avantage de l'incrémentiel est de prendre moins de place, et par effet de cause d'être plus rapide, et donc par exemple (ce n'est pas le cas dans ce tuto) d'aller changer la bande de sauvegarde moins souvent. L'inconvénient c'est que si jamais il y aura besoin de faire une restauration, ça se passera comme ça:
Restauration de la dernière sauvegarde totale puis restauration de toutes les sauvegardes incrémentielles une par une en écrasant les fichiers mois récent. Deux inconvénients:

• S'il y a beaucoup d'incrémentielles, ce sera long.
• Les fichiers qui ont été volontairement supprimés depuis la sauvegarde totale seront restaurés. ça peut paraitre bête, mais lors d'une des rare restaurations, la secrétaire de direction avait la veille passé quelques heures à faire du tri dans ses dossiers et ses fichiers. Elle a halluciné de voir tout revenir.

Encryption

Je ne chiffre pas les sauvegardes, je fais simplement attention à ce qu'elles soient suffisamment protégées et laisse ce chapitre par défaut. C'est un coup à les rendre inutilisables et à perdre du temps précieux lors d'une éventuelle restauration.

Backup method: tarball

Même si on a mis tarball-incremental incrémental ci dessus, cette partie nous intéresse.

Les directives qui m'intéressent dans cette partie sont notamment:

export BM_TARBALL_DIRECTORIES="/etc /home /var"

Ce sont les répertoires à sauver

export BM_TARBALL_BLACKLIST="/var/archives"

Ce sont les répertoires à exclure.

tarball-incremental

ici on définie la périodicité incrémentielles/totales J'ai laissé par défaut

Backup method: MYSQL

export BM_MYSQL_DATABASES="__ALL__"

listez ici les bases à sauver. faites comme ci dessus pour toutes les sauver.

Quand aux paramètres de coonnection, là j'ai eu la négligence de laisser root. mais créer un user nommé backup-manager ayant les droits en lecture seulement (suffisant pour la sauvegarde) sur toutes les tables ça donne:

GRANT SHOW DATABASES,SELECT,LOCK TABLES ON *.* TO 'backupmanager'@'localhost' IDENTIFIED BY 'secret';

Backup method: svn

Non concerné

Backup method: pipe

Non concerné

Section "UPLOAD"

export BM_UPLOAD_METHOD="scp":

La méthode choisie

export BM_UPLOAD_HOSTS="222.222.222.222"

L'ip du serveur qui recevra les sauvegardes

export BM_UPLOAD_DESTINATION="/media/dd2/saves"

Le repertoire de dépot des sauvegardes sur le pc distant. Dans mon cas, c'est un disque dur dédié à ça.

The SSH method

export BM_UPLOAD_SSH_USER="sauveur"

l'user ssh à annoncer. on le créera plus loin

export BM_UPLOAD_SSH_KEY="/root/.ssh/id_dsa"

Il n'arrive pas à prendre la clé par défaut d'apres mes esais, faut lui indiquer. On la créera plus loin dans ce tuto.

export BM_UPLOAD_SSH_HOSTS="222.222.222.222"

L'IP publique de la freebox. Le mappage des ports sur l'interface freebox sera vue plus loin.

export BM_UPLOAD_SSH_PORT="22" export BM_UPLOAD_SSH_DESTINATION="/media/dd2/saves"

dossier destinataire

export BM_UPLOAD_SSH_PURGE="true" export BM_UPLOAD_SSH_TTL="15"

durée de vie des sauvegardes (je mets 15 j là dessus.)

on ne s'occupe pas des méthodes suivantes

Advanced settings, use this with care.

export BM_PRE_BACKUP_COMMAND="wakeonlan -i 222.222.222.22 xx:xx:xx:xx:xx"

On réveille l'ordinateur distant au démarrage de la sauvegarde.. Pas besoin de rajouter un délai. dès qu'il aura lancé la demande de wakeonlan, il compressera les donner à sauvegarder en local, avant de les envoyer. La première étape laisse le temps au pc de s'allumer tranquilou.

export BM_POST_BACKUP_COMMAND="ssh sauveur@222.222.222.222 -i /root/.ssh/id_dsa halt"

Eteindre la machine quand c'est fini. En théorie un simple user linux n'a pas le droit de le faire. On verra plus loin.

Paramétrer la freebox pour le ssh et le wakeonlan

• Cocher le "Proxy wol"
• ajoutez une redirection du port 22 vers l'adresse IP locale du PC qui recevra les sauvegardes.

Comme dans le screen ci dessous (il y a en plus le port 80 là).

Installer wake on lan

Le PC n'a pas vocation à être allumé en permanence, il faudra que le serveur l'allume lorsqu'il souhaite faire sa sauvegarde. Il n'y a pas grand chose à faire pour le wol.

Pour vérifier que le pc est compatible wol

Les cartes mères récentes permettent le wol. pour vérifier, le mieux est d'installer un petit tool:

yum install ethtool

et lancer la commande:

ethtool eth0

Si on lit ce genre de trucs c'est ok:

Supports Wake-on: pumbg
Wake-on: g

Sinon, il faut aller farfouiner dans le bios pour l'activer. Pour utiliser le wakeonlan il nous faut l'adresse mac du PC à allumer. La commande "ifconfig" (en root) vous donnera ce renseignement. Je la note XX:XX:XX:XX:XX.

Test du wol en local

Le pc 1 est un ubuntu. Installer un script qui permet d'envoyer le signal magique wakeonlan

sudo apt-get install wakeonlan

Puis on éteind le pc fedora et on l'allume depuis PC1 en tapant :

wakeonlan XX:XX:XX:XX:XX

Et ça marche (le cas contraire n'est pas évoqué dans ce tuto).

Le wol depuis internet

Depuis la dédibox (en ssh) on tente apres avoir installé le paquet wakeonlan:

wakeonlan -i 222.222.222.222 XX:XX:XX:XX

Et ça marche (le cas contraire n'est pas évoqué dans ce tuto).

A ce niveau là on sait que le serveur pourra allumer le pc distant. Passons maintenant à la mise en place d'un espace de stockage sur ce pc pour y déposer les sauvegardes.

openssh avec clés

Créer un user unix qui sera utilisé pour les sauvegardes (sur le PC qui recevra les sauvegardes)

En tant que root sur le pc qui recevra les sauvegardes:
Je le nomme sauveur

useradd -m -G users -s /bin/bash sauveur 
passwd sauveur

Installation et paramétrage openssh

Sur l'ordinateur qui recevra les sauvegardes

yum install openssh-server

éditer le fichier de configuration

vi /etc/ssh/sshd_config

Temporairement on laisse "yes" à la directive PasswordAuthentication mais "no" pour PermitRootLogin

PasswordAuthentication yes
PermitRootLogin no

Et on ajoute à la fin:

AllowUsers sauveur

Relancer le daemon ssh:

/etc/init.d/sshd restart

Générer des clés ssh pour se connecter au compte sauveur:

Sur le serveur qu'on veut sauvegarder (la dédibox), en root

cd ~
ssh-keygen -t dsa
exit

Laissez les valeurs par défaut quand il demande où enregistrer les fichiers. je ne mets pas de passphrase.

Placer la clé publique générée dans la listes de celles autorisées par "sauveur" sur le PC qui reçoit les sauvegardes. Toujours depuis le serveur à sauvegarder:

ssh-copy-id -i ~/.ssh/id_dsa.pub sauveur@222.222.222.222

Revenir sur le PC qui reçoit les sauvegardes et éditer la configuration de sshd

vi /etc/ssh/sshd_config

et mettre "no" à la directive PasswordAuthentication Relancer le daemon ssh:

/etc/init.d/sshd restart

Permettre au compte "sauveur" d'utiliser la commande halt

J'ai fait un petit appel au secours sur le forum de fedora à ce sujet. Un utilisateur utiisant l'interface graphique (et donc présent localement devant le PC?) aurait plus de droit qu'un utilisateur distant (du moins pour l'extinction).

En root sur le pc qui recevra les sauvegardes:

chmod u+s /sbin/halt

Finaliser

Il reste juste à créer les dossiers qui recevront les sauvegardes et y donner les droits au compte sauveur. Puis il faut tester:

backup-manager

Conclusion

L'écriture de ce billet m'a un peu gonflé en fait. fastidieux, dur à présenter, il faut que je me trouve un plugin dotclear "sommaire" dans un billet.... boaf, allez, plus que l'introduction à refaire, chasser les fautes et publier. :D

Je ne vais pas mentir, j'ai installé ce blog il y a maintenant plus d'un an je crois sous DC, après un premier essai sous spip, plus par défaut, le premier truc que j'ai trouvé qui me paraissait sympathique.. Depuis, a cause d'Emma notamment, j'ai installé aussi des wordpress. Je vais vous raconter mon ressenti. Voyons les fonctionnalités, l'ergonomie puis les performances.

Au niveau des fonctionnalités, il n'y en a pas que je n'ai pas trouvé chez l'un mais pas chez l'autre. Cependant, sur les sites de tiers ayant développé des plugins, on trouve souvent une version wordpress et pas dotclear. J'ai toujours trouvé des adaptations sur le site de dotclear. Match nul pour les fonctionnalités.

Wordpress parait plus user friendly au premier abord. Par défaut sous dotclear le mode de publication est le format "wiki". Il est cependant possible d'utiliser le format xhtml qui est un WYSIWYG Qui équivaut celui de son concurrent. Conclusion, ce n'est qu'au premier abord (et perso je préfère la méthode wiki). Je conçois cependant que le format wiki par défaut puisse rebuter certains utilisateurs. Dotclear plus pour geek?

Regardons du coté des performances à présent.!!!!Serveur Web C'est du ressenti, mais je trouve l'interface de wordpress un peu "molle" comparée à celle de mon cher blog. allons voir de plus prêt: Je lance un top sur le serveur et je refresh la page d'accueil de ce blog:

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 
13798 www-data  20   0  211m  18m 4136 S  4.7  0.9   0:01.76 apache2                                       
13813 www-data  20   0  211m  18m 3904 S  0.7  0.9   0:01.44 apache2                                       
 2069 mysql     20   0  165m  51m 6460 S  0.3  2.6   5:21.07 mysqld   

et je fais la même avec le site des défis d'écriture qui est sous wp:

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 
13579 www-data  20   0  227m  36m 4252 S 33.3  1.8   0:05.22 apache2                                       
13817 www-data  20   0  220m  28m 3764 S 23.3  1.4   0:00.70 apache2                                       
 2069 mysql     20   0  165m  51m 6460 S  0.3  2.6   5:21.17 mysqld  

Ounch, pour le pourcentage de CPU utilisé en instantanné, il n'y a pas photo, DC est beaucoup plus léger.

Voila, ça c'est dit. Pour faire une vrai comparaison, il faudrait fouiner le code. Les templates sont gérés très différemment sur les deux systèmes. conclusion, perso, je continue sous dotclear (et si je change, ce sera pour tinadCMS)