Étiquette : backup

Catégories
Open-source Planet-libre raspberry Systeme

Raspberry Pi – Faire un backup de sa carte SD

cartesdCe qu’il y a de bien avec un Raspberry Pi c’est que l’on peut passer d’un système à l’autre en changeant simplement de carte SD et en redémarrant la machine. On peut ainsi avoir une carte avec une distribution classique (Raspbian), une autre avec un média center (OpenELEC ou Raspbmc) ou encore une autre avec un desktop light (ArchLinux). L’idéal étant d’avoir à disposition autant de cartes SD que de systèmes (vu le prix des cartes, ce n’est pas un gros investissement).

Cependant, il est parfois utile, pour des tests ou pour économiser le nombre de ces cartes de sauvegarder puis de restaurer l’image disque sur une machine GNU/Linux classique. C’est ce que nous allons voir dans ce billet.

Sauvegarde intégral d’une carte SD

On commence par insérer la carte SD dans le lecteur du PC GNU/Linux sur lequel on veut faire la sauvegarde.

Pour identifier le périphérique correspondant à la carte SD à sauvegarder sur son système, il suffit de saisir la commande suivante et de regarder le device qui correspond à sa carte SD:

$ sudo fdisk -l
[sudo] password for nicolargo: 

Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 têtes, 63 secteurs/piste, 38913 cylindres, total 625142448 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x000e3a56

Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sda1   *        2048   617170943   308584448   83  Linux
/dev/sda2       617172990   625141759     3984385    5  Étendue
/dev/sda5       617172992   625141759     3984384   82  partition d'échange Linux / Solaris

Disk /dev/sdb: 16.0 GB, 16012804096 bytes
64 têtes, 32 secteurs/piste, 15271 cylindres, total 31275008 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x00014d34

Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sdb1            8192      122879       57344    c  W95 FAT32 (LBA)
/dev/sdb2          122880    31275007    15576064   83  Linux

J’ai donc deux disques détectés sur ma machine:

  • /dev/sda (disque de 320 Go) qui est mon disque dur système sur mon PC portable. Ce n’est pas ce disque que l’on veut sauvegarder.
  • /dev/sdb (disque de 16 Go) qui est ma carte SD que je souhaite sauvegarder.

On lance la sauvegarde avec la commande suivante:

sudo dd if=/dev/sdb | gzip -9 > ./raspberry-20130420-sdb.img.gz

Restauration intégrale d’une carte SD

Après avoir inséré la clé USB sur laquelle on souhaite faire la restauration (attention la clé va être effacée), on commence par identifier l’identifiant du périphérique comme dans le paragraphe précédant (/dev/sdb dans mon cas).

Puis ensuite, il suffit de saisir la ligne de commande:

gunzip ./raspberry-20130420-sdb.img.gz | sudo dd of=/dev/sdb

—

Nous allons ensuite voir comment sauvegarder les carte SD partition par partition, ce qui peut être utile si vous ne voulez que sauvegarder le système et pas une éventuelle partition de données.

Sauvegarde partition par patition d’une carte SD

Comme on peut le voir sur les deux dernières lignes de la commande fdisk du premier paragraphe , la carte SD (point de montage /dev/sdb dans mon cas) comporte deux partitions (mais il peut y en avoir plus selon la configuration de votre Raspberry Pi).

Il faut sauvegarder toutes les partitions:

sudo dd if=/dev/sdb1 | gzip -9 > ./raspberry-20130420-sdb1.img.gz
sudo dd if=/dev/sdb2 | gzip -9 > ./raspberry-20130420-sdb2.img.gz

Ces commandes peuvent prendre plus ou moins de temps selon la taille de votre carte SD. J’ai ainsi mis plus d’une dizaine de minute pour faire la sauvegarde de ma carte SD de 16 Go. On voit ici l’avantage de choisir la taille de ses cartes SD en fonction de ses besoins…

Restauration partition par patition d’une carte SD

Nous allons maintenant restaurer la carte préalablement sauvegardée. La procédure consiste à créer les partitions avec la commande fdisk puis ensuite à y écrire les images avec dd.

On part sur le principe ou la carte est vierge est sans partition (sinon utilisé la commande d pour chacune des partitions puis w pour valider):

$ sudo fdisk /dev/sdb

Commande (m pour l'aide): p

Disk /dev/sdb: 16.0 GB, 16012804096 bytes
64 têtes, 32 secteurs/piste, 15271 cylindres, total 31275008 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x00014d34

Périphérique Amorce  Début        Fin      Blocs     Id  Système

On commence par créer le première partition (sdb1):

Commande (m pour l'aide): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Numéro de partition (1-4, par défaut 1): 
Utilisation de la valeur par défaut 1
Premier secteur (2048-31275007, par défaut 2048): 8192
Dernier secteur, +secteurs or +taille{K,M,G} (8192-31275007, par défaut 31275007): 122879

Commande (m pour l'aide): t
Partition sélectionnée 1
Code Hexa (taper L pour lister les codes): c
Type système de partition modifié de 1 à c (W95 FAT32 (LBA))

puis la seconde (sdb2):

Commande (m pour l'aide): n
Partition type:
   p   primary (1 primary, 0 extended, 3 free)
   e   extended
Select (default p): p
Numéro de partition (1-4, par défaut 2): 
Utilisation de la valeur par défaut 2
Premier secteur (2048-31275007, par défaut 2048): 122880
Dernier secteur, +secteurs or +taille{K,M,G} (122880-31275007, par défaut 31275007):

Commande (m pour l'aide): p

Disk /dev/sdb: 16.0 GB, 16012804096 bytes
64 têtes, 32 secteurs/piste, 15271 cylindres, total 31275008 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x00014d34

Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sdb1   *        8192      122879       57344    c  W95 FAT32 (LBA)
/dev/sdb2          122880    31275007     15576064  83  Linux

On valide les partitions:

Commande (m pour l'aide): w
Synchronisation des disques.

Ensuite on restaure les images:

gunzip ./raspberry-20130420-sdb1.img.gz | sudo dd of=/dev/sdb1
gunzip ./raspberry-20130420-sdb2.img.gz | sudo dd of=/dev/sdb2

Et voilà le travail !

Catégories
Blog Open-source Planet-libre Web

Sauvegarde incrémentale et automatisé de votre compte Gmail

Les prophètes du Web avaient prédit la fin des mails avec l’arrivée des réseaux sociaux. Force est de constater que la messagerie électronique « classique » est toujours bien ancrée dans les moeurs.  Pour une utilisation personnelle, la messagerie GMail de Google fait office de leader sur le marché. J’ai personnellement plus de 3 Go d’archives de mail sur mon compte personnel. Bien que très stable, le service de Google n’est pas à l’abri d’une perte de vos précieux messages. Nous allons donc voir dans ce billet comment conserver une archive locale de votre compte Gmail en utilisant le logiciel libre GetMail. GetMail est distribué sous licence GPL version 2 et il est disponible dans les dépôts des principales distributions GNU/Linux.

La procédure suivante va nous permettre de faire une sauvegarde incrémentale (seul les nouveaux messages sont téléchargés) d’un compte Gmail accessible via le protocole IMAP sur une machine Debian Squeeze (mais la procédure est la même sous Ubuntu).

Installation et configuration initiale de Getmail

On commence par installer le logiciel:

sudo apt-get install getmail4

On créé ensuite les sous-répertoires suivants (à adapter à votre configuration):

  • ~/.getmail: va contenir les fichiers de configuration de Getmail (un fichier par compte)
  • ~/backup/gmail: est le répertoire de destination ou la sauvegarde va être faite

En utilisant les commandes suivantes:

mkdir ~/.getmail
mkdir ~/backup/gmail

On passe ensuite à la création du fichier de configuration (~/.getmail/getmail.gmail) pour notre compte Gmail. Ce dernier doit contenir les lignes suivantes:

[retriever]
type = SimpleIMAPSSLRetriever
server = imap.gmail.com
username = user@gmail.com
password = password
mailboxes = ("inbox",)
port = 993

[destination]
type = Mboxrd
path = ~/backup/gmail/user.mbox

[options]
received = false
delivered_to = false
read_all = false
verbose = 0

Je vous laisse modifier ce fichier avec vos propres informations.

On s’empresse de protéger ce fichier des regards extérieurs:

chmod 700 ~/.getmail/getmail.gmail

Comme vous pouvez le voir dans cette même configuration, j’ai choisi d’utiliser le format Mboxrd qui est un standard reconnu par la plupart des logiciels. Getmail doit disposer d’une archive vide avec les bons droits avant de le lancer pour la première fois. On utilise donc la commande suivante pour le satisfaire:

touch ~/backup/gmail/user.mbox

Lancement initial de Getmail

Je vous conseille de faire le premier lancement de Getmail depuis une console pour voir les éventuels messages d’erreurs.

getmail -r ~/.getmail/getmail.gmail

Il est possible, notamment si vous lancé Getmail depuis un serveur n’ayant jamais fait de connexions clientes IMAP vers GMail, que Google bloque l’accès et que Getmail retourne un message du style:

IMAP error during logout (command CLOSE illegal in state AUTH, only allowed in states SELECTED)

Pour résoudre se problème il faut se connecter sur votre compte Gmail (à partir de n’impote qu’elle machine) puis de cliquer sur le bandeau rouge en haut de l’écran:

Puis de valider votre connexions:

Vous avez alors 10 minutes pour relancer la première commande de ce paragraphe.

Si il n’y a pas d’erreur, alors le téléchargement des fichiers vers votre archive (fichier unique) devrait commencer. vous pouvez aller prendre un café, ou plusieurs, selon la taille de votre compte GMail. Je vous conseille de prévoir un espace disquelégérement supérieur à l’information donnée par Gmail en bas du WebMail (fichier archive de 4 Go pour 3 Go affiché dans Gmail). En effet, l’archivage implique l’ajout d’un « overhead » assez important.

Note: Même depuis mon serveur OVH connecté à 100 Mbps sur Internet, je ne dépasse pas les 1 Mbps lors de l’archivage, surement une limite des serveurs Google et/ou du protocole IMAP.

Automatiser la sauvegarde

« Sauvegarder, c’est bien, automatiser la sauvegarde c’est mieux. » [Nicolargo]

Une petite ligne ajoutée à votre crontab système va permettre d’automatiser la sauvegarde incrémentale de votre compte Gmail. Personnellement, je la déclenche toutes les nuits à 1h du matin.

# crontab -e

0 1 * * * getmail -r ~/.getmail/getmail.gmail

Vous voilà maintenant plus tranquille avec une archive bien à vous de vos (g)mails !

 

Catégories
Open-source Planet-libre Reseau

Mounter son espace de sauvegarde FTP en local sous Debian

Voici une rapide explication pour « mounter » dans un répertoire local un espace de sauvegarde FTP. J’ai utilisé cette procédure pour accéder à mon espace de stockage gratuit de 10 Go sur mon serveur Dedibox DC sous Debian Squeeze.

On commence par récupérer les paramètres de son serveur FTP

On a besoin:

  • du nom de la machine hébergeant le serveur FTP (host)
  • un compte utilisateur (login)
  • un mot de passe (password)

Chez Online.net, ces informations se trouve dans la console d’administration:

Une fois ces informations sous le coude on peut passer à l’étape suivante.

On prépare le terrain

On commence par installer Fuse qui va permettre de faire le montage du répertoire en FTP (toutes les commandes suivantes sont à saisir dans une console root):

[cc lang= »bash »]

apt-get install curlftpfs

[/cc]

Ensuite on créer le répertoire local (/mnt/backup dans mon cas) à partir duquel le répertoire FTP distant sera visible.

[cc lang= »bash »]

mkdir /mnt/backup

[/cc]

On teste que tout fonctionne en ligne de commande:

[cc lang= »bash »]

curlftpfs login:password@host /mnt/backup/

[/cc]

Vous devriez pouvoir lire, écrire et effacer des fichiers dans le répertoire /mnt/backup/.

On démounte le répertoire avec la commande suivante:

[cc lang= »bash »]

umount /mnt/backup

[/cc]

On automatise le tout

On lieu d’avoir à saisir à la main ou dans un script de démarrage la commande curlftpfs, le plus simple et transparent est d’utiliser le fichier /etc/fstab qui va mounter automatiquement l’espace FTP au démarrage de votre machine.

Pour cela, il faut d’abord créer un fichier /root/.netrc contenant les informations sur votre serveur FTP, donc après un « vi /root/.netrc », il faut ajouter la section suivante:

[cc lang= »bash »]

machine host

login login

password password

[/cc]

Puis une petite sécurité sur ce fichier:

[cc lang= »bash »]

chmod 600 /root/.netrc

[/cc]

Ensuite on édite le fichier /etc/fstab et on y ajoute la ligne suivante:

[cc lang= »bash »]

curlftpfs#host /mnt/backup fuse _netdev,allow_other,uid=1000,gid=1000,umask=0022 0 0

[/cc]

Note: il faut remplacer uid=1000,gid=1000 par les valeurs données par le résultat de la commande « id ».

Un petit…

[cc lang= »bash »]

mount -a

[/cc]

… plus tard et votre répertoire FTP distant devrait être accèssible depuis votre répertoire local /etc/backup !

Source: Linux Config

Catégories
Blog Open-source Planet-libre Reseau Systeme Web

Sécuriser son blog WordPress #4

Nous voici donc dans le dernier volet de notre saga sur la sécurisation d’un serveur Web hébergeant un blog WordPress. Si vous avez suivi les recommandations des billets précédant vous devriez  avoir un serveur avec un niveau de sécurité acceptable…

La perfection n’existant pas, du moins en sécurité informatique, il est nécessaire d’avoir sous la main les moyens de remonter rapidement votre serveur en cas de piratage.

Je vous rappelle que cet article est découpé en plusieurs billets (vous êtes en train de lire le #4):

Cette série de billets a été co-écrite avec Jérémie Marguerie étudiant à EPITA (un dernier grand merci à lui :)).

Sauvegardes régulières

En effet, quelque soit les moyens que vous aller mettre en oeuvre, votre serveur ne sera jamais protégé à 100%. Il est donc essentiel d’avoir une sauvegarde récente de l’ensemble de votre blog, c’est à dire:

  • vos fichiers statiques (images, videos, fichiers de données…)
  • votre base de donnée SQL
  • une procédure (ou encore mieux un script comme celui-ci) à jour de réinstallation de votre serveur

Voici donc le détail de ces actions.

Sauvegarde des fichiers statiques

J’effectue cette sauvegarde en deux étapes.

1) La première est un backup de l’ensemble de mon répertoire Web (contenant WordPress et les fichiers statiques) sur un deuxième disque qui est attaché à mon serveur virtuel (VPS). Ainsi en cas de crash disque, les données seront disponibles localement. Attention de bien vérifier auprès de votre hébergeur que ce deuxième disque virtuel est bien sur un disque physique différent de celui sur lequel est hébergé votre blog !

J’utilise le logiciel RSnapShot pour effectuer cette tache. J’ai rédigé un billet sur le sujet que vous pouvez consulter ici.

2) La seconde étape est de copier de manière régulière (et si possible automatique) ces sauvegardes sur une autre machine. En effet, si un méchant hackeur pirate votre serveur, il y a de fortes chances qu’il s’en prenne également à vos sauvegardes locales.

Pour cela, j’utilise le service « in the cloud » Dropbox (en attendant un service équivalent basée sur des clients libres). Pour installer et utiliser Dropbox sur un serveur sans interface graphique, vous pouvez suivre cette procédure. J’archive avec une commande tar l’ensemble du répertoire WordPress puis je le copie dans un sous répertoire de ma Dropbox.

Sauvegarde de la base de donnée SQL

J’utilise le plugin WordPress WP-DBManager qui, en plus d’optimiser automatiquement ma base de donnée,  sauvegarde et envoi une archive directement sur mon adresse mail (la fréquence des expéditions est configurable).

Il est également possible d’automatiser une commande mysqldump dans votre crontab systeme et comme les fichiers statiques copier l’archive dans une copie locale et dans votre Dropbox.

Re-installation rapide de son serveur « from scratch »

Ce point est souvent négligé, à tort !

Quoi de plus long que de ré-installer et re-configurer un serveur en production sous la pression du temps… Avoir un script qui reproduit ces étapes de configuration est plus qu’utile en cas de problème : piratage ou bien panne matérielle. En cas de piratage, il faudra évidemment chercher la cause du problème et la résoudre avant de remettre son serveur en ligne et bien entendu modifier tous les mots de passes (système, WordPress, base de donnée SQL…).

Maintenance et supervision

Dans la première partie de cette série de billets, nous avons installé le logiciel cron-apt qui envoie automatiquement un mail quand des mises à jour son disponible pour votre serveur. Il faut bien sûr prendre le temps de lire ces mails et de les traiter le cas échéant.

On peut également installer le logiciel log-watch qui surveiller pour vous les fichiers de log et envoyer automatiquement un rapport par mail. J’ai personnellement laissé tombé ce type de logiciel sur mon serveur personnel car la quantité des informations remontées nécessitait trop de temps pour être interprétée . Dans le même ordre d’idée il y a également logcheck qui permet de recevoir un rapport toutes les heures sur les lignes « anormales » trouvées dans les logs.

aptitude install logcheck

Le fichier de configuration se trouve dans /etc/logcheck/logcheck.conf. La liste des fichiers de log à surveiller dans /etc/logcheck/logcheck.logfiles.

Il faut également surveiller les rootkit (petit programme permettant d’obtenir les droits d’administration de votre serveur en se basant sur des failles connues). Pour cela il faut installer un détecteur de rootkit comme  chkrootkit:

sudo aptitude install chkrootkit

Puis le lancer régulièrement (le plus simple est de le faire par crontab et d’envoyer le résultat par mail).

sudo chkrootkit

A noter que dans la version actuelle de chkrootkit (0.49). Un faux positif est détecté sous Ubuntu 10.04 LTS dans le fichier /etc/init:

Searching for Suckit rootkit… Warning: /sbin/init INFECTED

Le message est donc à ignorer jusqu’à la prochaine mise à jour.

Pour conclure ce chapitre quelques logiciels que l’on peut installer:

  • tmpreaper : vider le /tmp régulièrement
  • vérifier l’intégrité des fichiers systèmes avec Samhain (disponible dans les dépots Ubuntu).

Conclusion

Vous l’aurez compris, sécurisé son système prend du temps, consomme des performances non négligeables et demande des connaissances approfondies. C’est néanmoins une étape fondamentale pour se protéger des pirates et autres scripts automatisés qui se feront une joie de rentrer dans votre site web ou pire, votre serveur.

Les applications présentées devraient néanmoins vous permettre de limiter la casse, mais gardez à l’esprit que la plupart des attaques se faisant via votre site web, le protéger correctement reste une des meilleurs solutions existantes.

/etc/logcheck/logcheck.conf
Catégories
Open-source Planet-libre Reseau Systeme

Sauvegarde journalisée de votre machine avec RSnapShot

Suite à un commentaire de Xavier sur un de mes billets, je me suis penché sur l’utilisation de RSnapshot. Ce logiciel libre permet d’automatiser une sauvegarde journalisée de vos machines et ceci localement comme à distance.

RSnapShot est disponible dans la plupart des dépôts des distributions GNU/Linux et *BSD. Nous allons illustrer cet article avec une installation et une configuration de RSnapShot sur un serveur Gandi sous Ubuntu 10.04 LTS.

Installation de RSnapShot

On utilise la version disponible dans les dépôts officiel:

sudo aptitude install rsnapshot

Configuration de RSnapShot

L’ensemble de la configuration est centralisé dans le fichier /etc/rsnapshot.conf.

sudo vi /etc/rsnapshot.conf

Attention à la syntaxe dans ce fichier, RSnapShot est assez pointilleux. Il veut que tout les répertoires finissent par un / et des tabulations entre chaque variables.

Les variables importantes à configurer sont les suivantes:

snapshot_root   /.snapshots/

La variable snapshot_root permet de configurer le répertoire racine ou les sauvegardes seront stockées. Ce répertoire peut être sur le même disque que le disque système (c’est le cas de la configuration par défaut avec l’utilisation du répertoire /.snapshots/).

Je vous conseille pour ma part d’utiliser si possible un répertoire stocké sur un deuxième disque physique. Par exemple sur mon serveur Gandi, j’ai un deuxième disque qui est monté sur le répertoire /srv/backup. Je vais donc configurer la variable à /srv/backup/snapshots/ (noter le / à la fin du répertoire !).

Exemple: snapshot_root /srv/backup/snapshots/

cmd_ssh /path/to/ssh

Si vous voulez utiliser les fonctions de sauvegarde de serveur distant (en utilisant le protocole SSH), il faut dé-commenter la ligne précédente. Si vous avez besoin de passer des arguments spécifique à SSH, il faudra compléter la ligne ssh_args.

Exemple: cmd_ssh /usr/bin/ssh

interval monthly 3

Activation de la sauvegarde mensuelle (désactivé par défaut).

On passe ensuite aux variables permettant de configurer ce que l’on veut sauvegarder.

Sauvegardes locales

On parle ici d’une sauvegarde journalisée de répertoires de la machine ou RSnapShot est installé.

backup /home/ localhost/

Le répertoire /home/ sera sauvegardé dans le sous répertoire $snapshot_root/localhost/.

Exemple:

backup /home/ localhost/

backup /etc/ localhost/

backup /var/svn/ localhost/

Sauvegardes distantes

On peut également sauvegarder des répertoires de machines distantes. On utilise pour cela la configuration suivante:

backup root@example.com:/etc/  example.com/    +rsync_long_args=–bwlimit=1024,exclude=core

On va ainsi sauvegarder le répertoire /etc/ de la machine exemple.com en utilisant une connexion SSH avec l’utilisateur root (il faut bien sur que la connexion SSH entre votre machine exécutant RSnapShot et example.com soit automatisée). En bonus on demande à RSnapShot de ne pas sauvergarder les fichiers core (exclude=core) et de limiter la bande passante à 1 Mbps (–bwlimit=1024).

Sauvegardes en utilisant des scripts

Une autre fonctions intéressantes de RSnapShot est la possibilité d’utiliser des script shell pour automatiser des sauvegardes un peu plus complexes.

Par exemple imaginons que l’on veuillent sauvegarder les données de son serveur SVN. On commence par créer le script shell /usr/local/bin/backup-svn.sh:

#!/bin/sh

# Backup SVN


svnrepo= »/var/svn/ »

for i in `ls $svnrepo`

do

svnadmin -q dump $svnrepo/$i > $i.svndump

gzip -f $i.svndump

rm $i.svndump

done

Puis on le rend exécutable:

sudo chmod a+x  /usr/local/bin/backup-svn.sh

Enfin on configure RSnapShot:

backup_script /usr/local/bin/backup-svn.sh localhost/svn/

Le script backup-svn.sh va être lancé à partir du répertoire localhost/svn/

Il est bien sur possible de faire des scripts pour d’autres besoins: sauvegarde de bases de données MySQL par exemple.

Utilisation de RSnapShot

On commence par valider le fichier de configuration:

sudo rsnapshot configtest

Syntax OK

Simulation d’une sauvegarde journalière (cela va afficher ce que RSnapShot va faire mais sans le faire…):

sudo rsnapshot -t hourly

echo 3531 > /var/run/rsnapshot.pid

mkdir -m 0700 -p /srv/backup/snapshots/

mkdir -m 0755 -p /srv/backup/snapshots/hourly.0/

/usr/bin/rsync -a –delete –numeric-ids –relative –delete-excluded /home \

/srv/backup/snapshots/hourly.0/localhost/

mkdir -m 0755 -p /srv/backup/snapshots/hourly.0/

/usr/bin/rsync -a –delete –numeric-ids –relative –delete-excluded /etc \

/srv/backup/snapshots/hourly.0/localhost/

mkdir -m 0755 -p /srv/backup/snapshots/hourly.0/localhost/

mkdir -m 0755 -p /srv/backup/snapshots/tmp/

cd /srv/backup/snapshots/tmp/

/home/nicolargo/bin/backup-svn.sh

cd /home/nicolargo/

sync_if_different(« /srv/backup/snapshots/tmp/ », \

« /srv/backup/snapshots/hourly.0/localhost/svn/ »)

mkdir -m 0755 -p /srv/backup/snapshots/hourly.0/

/usr/bin/rsync -a –delete –numeric-ids –relative –delete-excluded \

–exclude=core –bwlimit=1024 –rsh=/usr/bin/ssh \

nicolargo@exemple.com:/home /srv/backup/snapshots/hourly.0/sam/

mkdir -m 0755 -p /srv/backup/snapshots/hourly.0/

/usr/bin/rsync -a –delete –numeric-ids –relative –delete-excluded \

–exclude=core –bwlimit=1024 –rsh=/usr/bin/ssh \

nicolargo@exemple.com:/etc /srv/backup/snapshots/hourly.0/sam/

touch /srv/backup/snapshots/hourly.0/

Test en ligne de commande:

sudo rsnapshot hourly

Le répertoire contenant la première sauvegarde devrait être créé sous /srv/backup/snapshots/hourly.0.

Enfin on automatise le lancement en éditant la crontab système (root):

sudo crontab -e -u root

0 */4 * * * /usr/bin/rsnapshot hourly

30 23 * * * /usr/bin/rsnapshot daily

0 23 * * 0 /usr/bin/rsnapshot weekly

30 22 28 * * /usr/bin/rsnapshot monthly

Pour une liste exhaustive des fonctions proposées par RSnapShot, je vous conseille la lecture de la documentation officielle (en Anglais).

Et voili, merci encore à Xavier pour cette belle découverte.

Catégories
Developpement Open-source Systeme

Sauvegarde automatique de son serveur SVN

Dans la série « sauvegarde tes données sinon tu le regretteras un jour ou l’autre », je voudrais le serveur SVN.

J’utilise un serveur SVN (pas encore eu le temps ni le courage de passer à GIT) pour gérer en version mes configurations, mes scripts shell et mes petits développements personnels. Une erreur de manipulation étant vite arrivée, j’ai automatisé l’archivage journalier (avec une mémoire d’une semaine) de la base de donnée utilisée par SVN.

Sauvegarde

J’utilise pour cela la commande svnadmin qui permet à l’aide de l’option dump de copier dans un simple fichier le contenu de la base de donnée.

Par exemple pour sauvegarder le projet dont la racine SVN se trouve dans le répertoire /var/svn/monbeauprojet, il faut saisir la commande suivante:

svnadmin -q dump /var/svn/monbeauprojet > /backup/svn/monbeauprojet.svndump

Il est bien sûr conseillé d’avoir une sauvegarde sur un disque différent de celui montée par /var/svn ou encore mieux d’uploader la sauvegarde sur un autre serveur.

Script pour sauvegarder l’ensemble des projets

Si votre serveur SVN comporte plusieurs projets, il faut passer par un shell script:

# Backup SVN (local)

day=`LANG=C date +%A | tr A-Z a-z`

svnrepo= »/var/svn/ »

backupdir= »/backup/svn »

for i in `ls $svnrepo`

do

svnadmin -q dump $svnrepo/$i > $backupdir/$i-$day.svndump

gzip $backupdir/$i-$day.svndump

rm $backupdir/$i-$day.svndump

done

Ce script va produire dans le sous répertoire /backup/svn une liste de fichiers compressés (format gzip). Chaque projet aura 7 sauvegardes correspondant aux 7 derniers jours. Par exemple, le fichier nommé monbeauprojet-sunday.svndump.gz sera la sauvegarde de la base de données SVN de dimanche dernier.

Pour lancer automatiquement la sauvegarde il suffit d’ajouter ce script dans la crontab système.

Restauration

En cas de problème sur un projet, il suffit de saisir les commandes suivantes pour restaurer la base de données. On utilise également la commande svnadmin mais cette fois ci avec l’option load:

gzip -d /backup/svn/monbeauprojet-sunday.svndump.gz

svnadmin load /var/svn/monbeauprojet < /backup/svn/monbeauprojet-sunday.svndump

Il faut bien vérifier que les droits des sous répertoires sont bons (svn:svn pour mon Ubuntu Server).

Si la restauration se fait sur un nouveau serveur SVN, il faut penser à créer le répertoire avec la commande:

svnadmin create /var/svn/monbeauprojet

Conclusion

Il y a surement d’autres solutions techniques (par exemple faire une copie sur un deuxième serveur SVN avec la commande svnadmin hotcopy) mais je trouve cette solution plutôt simple et flexible.


Catégories
Blog Open-source Systeme

Sauvegarde automatique de son site Internet

A moins d’être très joueur (ou fou), la sauvegarde de son site Internet doit être pensée et mise en œuvre dès le début d’un projet. Voici une solution basée sur une solution libre (lftp) qui sera très facile de caser dans une crontab pour automatiser cette tache ingrate.

L’architecture est la suivante:

Il faut disposer:

  • d’un serveur Web avec un accès FTP (ce qui est le plus standard chez les hébergeurs)
  • d’un PC de backup connecté en permanence à Internet (histoire d’automatiser le backup)

Préparation du PC de backup

Pas grand chose à installer mis à part l’indispensable client FTP lftp qui va nous permettre de faire un backup incrémental (seul les nouveaux fichiers seront téléchargés).

Exemple d’installation de lftp sous Ubuntu (à adapter à votre OS…):

[shell]sudo aptitude install lftp[/shell]

On créé ensuite un répertoire dans lequel le site Web/blo  sera sauvegardé.

[shell]mkdir ~/backup[/shell]

Configuration de la sauvegarde

On édite le fichier ~/monsite.lftp avec les informations suivantes (à adapter à vos besoins):

[shell]

set ftp:list-options -a
set cmd:fail-exit true
set ftp:ssl-allow false
set ftp:passive-mode on
set net:timeout 10
set net:max-retries 2
set net:reconnect-interval-base 5
set net:reconnect-interval-multiplier 1

open -p 21 login:password@monsite.com
lcd ~/backup
mirror -e -x dossier-a-exclure/

quit

[/shell]

On teste la sauvegarde:

[shell]

lftp -f ~/monsite.lftp

[/shell]

Et voilà, le répertoire ~/backup devrait contenir une image exacte de votre site Internet !

Il ne reste plus qu’à automatiser le backup toutes les nuits (crontab -e):

[shell]

0 1 * * * lftp ~/monsite.lftp

[/shell]

Et si je veux sauver ma base de données WordPress ?

Bonne question Michel… Personnellement j’utilise le plugin WP-DatabaseManager qui me permet de:

  • sauvegarder ma base de donnée dans un des répertoire de mon site Web (donc le backup se fera automatiquement avec la procédure décrite ci-dessus)
  • optimiser ma base de donnée
  • restaurer si besoin ma base de donnée

Et vous, comment faite vous la sauvegarde de votre site ?

Catégories
Open-source Web

Spideroak, un sérieux concurrent à Dropbox

Spideroak est un service en ligne de sauvegarde, synchronisation et partage de données. La fonction qui m’intéresse particulièrement est de pouvoir synchroniser des répertoires entres plusieurs machines.

Spideroak fonctionne sur le principe suivant: on commence par installer le client Spideroak sur une machine (GNU/Linux, Mac OS X ou Windows). Au premier lancement, le client va créer un compte utilisateur auquel sera associé une clé de chiffrement permettant de s’assurer que vous serez le seul à pouvoir accéder à vos données (même la société Spideroak…). Il va ensuite vous demander le nom de votre machine (je vous conseille de choisir un nom facile à reconnaitre, surtout si vous avez plusieurs machines) et la liste des répertoires à sauvegarder. On se retrouve donc avec, sur le serveur,  une association « Nom de machine / Répertoire de données ». A partir du moment ou le client est installé sur au moins deux machines, on peut passer à l’étape de la configuration de la synchronisation.  Il suffit de choisir une source (« Nom de machine 1 / Répertoire de données X ») et une destination (« Nom de machine 2 / Répertoire de données Y »). A partir de ce moment là, toute modification (ajout, modification, suppression) d’un fichier dans le répertoire local Y de la machine 2 sera répercutée sur le répertoire X de la machine 1 (et vice et versa).

On voit ici la flexibilité de Spideroak par rapport à Dropbox. En effet, Dropbox ne permet que de synchroniser un seul répertoire (appelé Dropbox par défaut). Tandis qu’avec Spideroak, il est possible de synchroniser autant de répertoire que nécessaire, Par exemple, un répertoire « Documents » d’un PC sous Linux avec un répertoire « Mes Documents » d’un pauvre PC sous Windows. Dans le même ordre d’idée il est possible de sélectionner les répertoires à synchroniser sur un PC donnée: il n’est par exemple pas indispensable de stocker sa collection de photos sur son PC du boulot mais il peut être utile de l’avoir sur son PC portable perso…

Voici pour mieux comprendre un petit screencast ou je partage un répertoire « test » entre mes PC Desktop et Laptop:

Source du screencast au format H.264 (720p).
D’autres screencast proposées par Spideroak.

Tout comme avec DropBox, il est également possible d’accéder en lecture à ses données à partir d’un simple navigateur Web ou à partir d’une application iPhone.

Spideroak propose gratuitement 2 Go de stockage (comme Dropbox), par contre l’offre payante est plus compétitive car on a 100 Go pour $10 par mois (ou $100 à l’année). Il faut ensuite compter $10 par tranche de 100 Go supplémentaire.

La société Spideroak ne distribue pas son client sous licence libre (ce qui est bien dommage mais il y a des chances que cela change dans le futur). Par contre elle met a disposition, sous licence GPLv3, une liste de logiciels développés autour de ce projet.

Cliquer ici pour installer et tester Spideroak sur votre machine.

J’attends vos retours !

Catégories
Blog Open-source

Backup complet de votre blog WordPress

J’imagine que vous faites des sauvegardes régulières de votre blog… Si ce n’est pas le cas, voici la méthode que j’utilise pour sauvegarder mon bébé.

Un blog WordPress est composé d’une base de donnée (SQL) et d’un ensemble de fichiers stockés sur un serveur (HTTP/FTP). Il faut donc penser à sauvegarder ces deux éléments.

Sauvegarde de la base de donnée

Le plus simple est d’utiliser le plugins WordPress DB Backup disponible ici. Il suffit ensuite de selectionner les tables à sauvegarder (le plus simple est de toutes les sélectionner) et de programmer backup automatique (toutes les heures, jours ou semaines). Le backup peut être stocké directement sur votre serveur (un peu risqué si celui-ci plante) ou envoyé sous la forme
d’une archive Sql.Gz sur une adresse mail.

Sauvegarde des fichiers

J’utilise un méthode automatique pour effectuer cette sauvegarde (sur ma machine Linux Ubuntu).

Après avoir installé l’utilitaire lftp (le meilleur client FTP en ligne de commande):

sudo apt-get install lftp

J’utilise la commande suivante:

lftp -f blog.lftp

Avec comme fichier blog.lftp:

[shell]

set ftp:list-options -a
set cmd:fail-exit true
set ftp:ssl-allow false
set ftp:passive-mode on
set net:timeout 10
set net:max-retries 2
set net:reconnect-interval-base 5
set net:reconnect-interval-multiplier 1

open -p 21 logindublog:passworddublog@ftpdublog.com
lcd ~/backup/blog/
mirror -e -x public_html/blog/avatars/

quit

[/shell]

Cette commande va:

  1. Ouvrir une connection FTP vers mon serveur ftpdublog.com en utilisant le login logindublog et le mot de passe passworddublog
  2. Faire un mirroir du répertoire /blog de mon serveur vers le répertoire local ~/backup/blog/ (à créer)
  3. Lors du mirroir, on supprime du répertoire local les fichiers qui n’existent plus sur le serveur
  4. On ne backup pas les avatars qui sont dans le répertoire public_html/blog/avatars/

La première sauvegarde risque de prendre un bon bout de temps (surtout si votre blog date un peu). Mais en suite, comme seul le différentiel entre votre serveur et votre répertoire local sera transféré cela ira beaucoup plus vite.

Pour automatiser le lancement de cette commande tout les jours à 1 heure du matin:

# crontab -e

1 0 * * * /usr/bin/lftp -f blog.lftp > /dev/null 2>&1

Et voila, vous pouvez attendre le crach de votre serveur hébergé de manière plus sereine…