Un domaine doté d'un nombre impressionnant d'outils libres est celui de la sauvegarde. Et pourtant, lorsque l'on fait tourner sa petite toutouille perso, des monstres comme Amanda font l'effet de massues à écraser les mouches. L'objectif de ce billet est donc le même que ça précèdent version : permettre de faire nos sauvegardes en tout simplicité, en mettant en oeuvre des concepts professionnels (synchronisation distante, mirroring, historisation) mais simplement armé des outils basiques que sont rsync et ssh.
avant-propos
Ce type de sauvegarde ne convient qu'au contexte d'une architecture domestique ou approchant (TPME, Indépendant, etc.). Pour tous les autres, il existe des outils tout faits et même dans certains cas plus ergonomiques (typiquement pour la sauvegarde de son seul poste de travail).
Je devance donc un peu certains commentaires : ce n'est pas la peine de me dire qu'il existe des outils faisant tout cela très bien car le but ici est justement de faire le sien aux petits oignons, adapté au plus prés de nos besoins. L'avantage est qu'un outil que l'on connaît est plus facile à mettre au point qu'une usine à Gaz qui change à chaque version. De plus il vous sera possible d'ajouter des petits détails propres à votre installation qu'un système de sauvegarde trop simple ne saura pas gérer.
Principe de l'historisation
Le principe d'historisation est repris de cet article. Je ne reviens donc pas dessus. Cependant la manière d'utiliser ici les hardlinks est un peu différente. L'idée est d'avoir dans notre dossier de stockage, deux sous dossiers current et history. A chaque rotation, le dossier current, qui contient les dernières données sauvegardées est hardlinké de manière récursive dans un sous-dossier de history portant comme nom la date et l'heure de la rotation. Ensuite on ne va garder que les N dossiers les plus récents en détruisant les plus anciens.
Ainsi, si vous lancez une sauvegarde toutes les 15 minutes et que l'on garde, disons 100 rotations, vous disposez de la possibilité de remonter en arrière dans le temps de 50 heures par tranches de 15 minutes.
Dans la précédente version de ce tutoriel, j'avais utilisé rdiff-backup pour effectuer ce travail. L'expérience m'a prouvé qu'utilisé massivement, cet outil n'est juste pas fiable. A deux reprises je me suis retrouvé avec des deltas corrompus et l'impossibilité de revenir en arrière dans le temps. De plus le système par hard-links permet de récupérer très simplement un snapshot en faisant un rsync. Avec rdiff-backup, on doit passer par divers paramètres pour arriver d'une utilisation beaucoup moins évidente, même s'il s'agit là d'une question d'habitude.
Sauvegarder pour quoi faire ?
Le meilleur moment dans la vie pour prendre conscience de l'intérêt d'une sauvegarde est celui où notre disque se met à crépiter tel un joyeux feu de la Beltane. Un tera gavé à bloc des photos et vidéos du petit dernier qui n'est alors plus qu'une brique aussi fumante que votre compagne qui vous interroge de cet air redoutablement inquiet : T'as bien une copie quelque part, dis...
. A ce stade, on se fait généralement la remarque qu'une sauvegarde automatisée aurait été bien utile... Car c'est reconnu par une utilisation quelque peu foireuse de la loi de Murphy : la sauvegarde automatique est réputée pour éloigner le mauvais oeil et allonger la durée de vie des disques durs...
Sauvegarder quoi ?
La bonne réponse est tout !!!
. Du moins tout ce qui n'est pas installable : documents de travail, photos, vidéos, configurations, etc. Mais il est possible de distinguer trois catégories dans ce "tout"
- Les données qui changent régulièrement : documents de travail, configuration de machines, etc...
- Les bases de données au sens large : courriels d'un serveur IMAP, base mySql ou PostgreSQL, gestionnaire de version (CVS, Subversion, etc.).
- Les données lourdes qui changent peu mais qui augmentent en de grandes portions : vidéos, photos, ressources en tout genre.
Les deux derniers cas, s'accommodent généralement assez bien d'une sauvegarde journalière simple, sans historisation. En revanche pour la première catégorie, il nous faut quelque chose de plus régulier avec la possibilité de remonter dans le temps. Cela permet de tordre le cou au cas classique de l'effacement accidentel du dossier BétaDur
que vous étiez sur le point de livrer au client, ou celui de la mise à jour pour laquelle les mainteneurs de la Mandriva ont décidés pour dieu sait quelle raison que la configuration de votre PostFix était toute pourrie et qu'il fallait impérativement vous la pourrir plus encore plus...
L'approche Perl
La précédente version de ce tuto utilisait bash (elle est encore disponible en révision). Le problème de bash c'est que l'on est vite gêné aux entournures, obligé à faire de terribles jonglages à coup de tubes, awk et autres sed. Perl est donc devenu peu à peu mon langage de script favoris. Sa syntaxe permet d'écrire à peu prés aussi rapidement qu'en bash avec plus de rigueur, et donc moins d'effets de bord. Enfin ses librairies sont tellement nombreuses qu'il est rare de ne pas en trouver une qui colle parfaitement à un besoin.
Notre but est donc de fabriquer une librairies Perl très simple que nos scripts de sauvegarde utiliseront. Pour ce faire nous allons utiliser quelques concepts clef qui convient de bien comprendre :
- Utilisation de SSH pour aller chercher les données à sauvegarder sur les autres machines que celle qui fait physiquement la sauvegarde. Pour cela nous "lions" les machines les unes aux autres grâce à des clefs publiques/privées. Notre librairie n'aura donc besoin d'aucun mot de passe car elle sera utilisée par "root". Si le serveur SSH utilise un port non standard, ce qui est conseillé pour une machine accessible du réseau publique, le fichier /etc/ssh_config sera paramétré pour que l'accès se fasse sans avoir à spécifier le port. Si vous ne vous sentez pas à l'aise avec tout cela, allez faire un tout ici
- Le transport des fichiers d'une machine à l'autre utilise rsync selon que l'historisation est nécessaire ou pas. Ces deux outils permettent de synchroniser via SSH deux dossiers (local et distant) en ne faisant circuler sur le réseau que ce qui est différent. Faites un petit coup de man rsync pour avoir plus d'idée sur le sujet.
Maintenant, histoire de savoir où l'on avance, nous allons commencer par la fin, avec ce à quoi ressemblerait un script de sauvegarde "live", c'est à dire celui correspondant à notre première catégorie de choses à sauvegarder : les données qui changent souvent.
#! /usr/bin/perl
# import de notre librairie
unshift(@INC,"/usr/share/tools/libraries/perl");
require "backup.pm";
# définition de la destination des backups
use_storage("/backups");
# définition du serveur (local car c'est aussi lui qui lance les sauvegardes, pas besoin de ssh)
if (check_host(
name=>"serveur_interne",
fs=>"local")) {
# ajout d'un dossier distant à sauvegarder localement, ici /etc en utilisant
# les exclusions de type "etc".
add_folder("/etc", "etc");
}
# définition d'un poste de travail
if (check_host(name=>"poste_travail")) {
add_folder("/etc", "etc");
add_folder("/home", "homes");
}
# définition du serveur publique
if (check_host(name=>"serveur_publique")) {
add_folder("/etc", "etc");
}
# définition d'une machine windows
if (check_host(
name=>"machine_windows",
fs=>"cifs",
root=>"C")) {
add_folder("/Users/gaston", "windows");
}
release_storage();
Pas si compliqué n'est-ce pas ? Voyons un peu comment tout cela se goupille.
La librairie
L'idée n'est pas ici de donner un cours de perl, je ne vais donc pas coller le code de la dizaine de procédure que la librairie contient mais plutôt en expliquer l'utilisation. Les sources sont dans tous les cas disponibles ici.
Préparation et libération du stockage
use_storage("/backups");
...
release_storage();
La fonction use_storage et release_storage ne font rien d'extraordinaire. La première va juste créer du dossier cible et surtout y coller un fichier vide, lock pour éviter que la procédure soit ré-entrante. Ainsi si un autre programme travaille sur notre dossier de stockage, la procédure user_storage va nous bloquer jusqu'à ce que le précédent programme ait terminé. release_storage détruit donc ce lock.
Définition des machines
if (check_host(
name=>"machine_windows",
fs=>"cifs",
root=>"C")) {
...
}
Une fois le stockage définit, l'idée est de vérifier que la machine que l'on cherche à backuper est bien présente sur le réseau. Pour cela nous utilisons la fonction check_host qui exploite la libraire Net::Ping. La seule astuce est de régler le protocole à icmp. En effet par défaut cette librairie fait un ping via tcp, ce qui n'est pas compatible avec une machine ayant un firewall qui restera du coup invisible à la sauvegarde.
L'autre objectif de la fonction check_host est de définir la machine source tout d'abord par son nom usuel (name) puis optionnellement par son adresse IP (address). Si l'adresse IP est mise, c'est le nom de la machine qui est utilisé.
Dans tous les cas un sous-dossier du nom de cette machine va être créé sous celui défini dans use_storage. C'est là que ce feront toutes les sauvegarde. Lorsque la sauvegarde se fera, la structure complète du dossier à sauvegardé sera créé en dessous de se sous-dossier. Le paramètre root permet quant à lui de tronquer une partie du début du chemin en indiquant une racine distante de sauvegarde. Ainsi dans le cas d'une sauvegarde CIFS (windows), la racine indique de ne pas prendre en compte le C mais de commencer directement avec le début du chemin à sauvegarder.
La paramètre fs permet de nuancer la manière dont est vue la machine. Par défaut c'est ssh, signifiant que ssh sera utilisé pour se lier à la machine distante. La méthode local indique quant à elle que nul n'est besoin de SSH, qu'il faut faire une copie local. Enfin nous avons la méthode cifs qui va consister à monter le dossier windows avant de sauvegarder et ftp qui va utiliser wget plutôt que rsync-backup.
Enfin le paramètre method définit l'outil utilisé pour la synchronisation. Il peut s'agir rsync (par défaut).
Synchronisation
...
add_folder("/home", "homes");
...
La définition de la machine faire par la commande check_host permet de simplifier au maximum la syntaxe des dossier à sauvegarder. La librairie sait en effet déjà quelle est l'adresse de la machine, la destination de sauvegarde, le type de système de fichier (local, ssh, ftp ou cifs) et l'outil de synchronisation à utiliser (rsync). Il ne reste plus donc qu'à donner les dossiers à sauvegarder par la commande add_folder.
add_folder prend en premier paramètre le chemin local sur la machine à sauvegarder et en second, optionnellement, un nom de fichier d'exclusions. Ce fichier utilise le format natif de la commande de synchronisation utilisé (rsync) et doit se trouve dans le dossier /etc/backup, dans un fichier nommé nom_exclusion.exclusions. Les exclusions portent ici assez mal leur nom car ces fichiers permettent aussi de force la sauvegarde d'un fichier. Par exemple pour un dossier home, cela donne :
- **/.purple/icons
+ **/.purple
+ **/.evolution/calendar/local/system/calendar.ics
+ **/.evolution/addressbook/local/system/addressbook.db
+ **/.gconf
+ **/.liferea_*/feedlist.opml
- **/etc/backup/homes.exclusion
Mirroring
Comme nous l'avons vu en introduction, nous allons avoir deux types de sauvegardes. Celles effectuées très souvent, contenant les dossiers qui changent régulièrement. Et celles que l'on fait chaque nuits, contenant les bases de données (mail, postgresql, etc.) et les données lourdes (photos, vidéo, etc.).
Chacune de ces deux sauvegardes va donner lieu à un script en perl comme celui montré plus haut. Celui de la sauvegarde régulière va être très simple et demande à peu prés aucune adaptation. Celui de la sauvegarde journalière est un peu différent car nous allons rsync car historiser les changements sur des photos ou des bases de données n'a que peu d'intérêt (à vous de voir ceci dit).
Ensuite la sauvegarde n'est pas faite en local, mais sur
Dernier aspect, cette grosse sauvegarde va comprendre nos bases, nos fichiers lourds mais aussi notre précédent dossier de sauvegarde régulière. Ainsi nos fichiers qui changent souvent sont non seulement historisés en local, mais aussi recopiés sur le disque USB pour plus de sécurité.
#! /usr/bin/perl
use File::Path;
unshift(@INC,"/usr/share/tools/libraries/perl");
require "backup.pm";
# montage du disque de sauvegarde en lecture-écriture
my $mount_point="/mnt/backup";
`mount /dev/disk/by-label/backup $mount_point -o remount,rw`;
# ouverture du stockage pour notre sauvegarde
use_storage("$mount_point/mirroring");
# comme d'habitude, définition de la machine distante, mais cette fois utilisant "rsync"
if (check_host(name=>"serveur_distant", method=>"rsync")) {
# sauvegarde des bases de données (postgresq, subversion, imap, etc)
add_folder("/databases");
# sauvegarde des fichiers "lourds"
add_folder("/videos");
# sauvegarde de nos "sauvegardes régulières"
add_folder("/backups");
}
release_storage();
# remontage du disque en lecture seule
`mount $mount_point -o remount,ro`;script lancé toutes les nuits
CRON
Dernière étape une fois que nos deux scripts sont écrits et testés, les mettre en musique en passant par un planning cron :
# toutes les 15 minutes...
*/15 * * * * root /usr/bin/backup-live
# Tous les matins, à l'heure des voleurs...
4 4 * * * root /usr/bin/backup-daily
Conclusion
La librairie de backup fait en 150 lignes tout ce que je lui demande, sans broncher, et sans prendre plus de ressources que nécessaires avec une adaptation à un besoin particulier très rapide à mettre en oeuvre.
Commentaires
@alexdaums: Si il te manque des packages du CPAN, j'en ai repackagé environ 700, tu trouveras certainement ton bonheur ici : http://apt.catapulse.org/debian
Ajkouter à ton /etc/apt/sources.list :
deb http://apt.catapulse.org/debian stable main
Bonjour,
Dans cette ligne:
A quoi correspond le "windows"?
Merci.
EDIT: C'est apparament un bug pour le positionnement du commentaire. Qui s'appliqiuerait au personne loggées.
Bonjour
les sources de la lib ne sont plus disponibles [erreur 404]. Serait il possible de reparer le pb svp ?
Merci. :)
Ben je suis sous ubuntu 8.04 server à cause de ma solution zimbra pour ma messagerie.
Est ce que tes paquets ne poseront pas de problèmes?
Normalement non, les fichiers sont installés dans /usr/local ... exceptés une petite dizaine
Comment tu as réussi à me percher ton message là haut toi ??? :)
hmmm ... j'en sais rien :( j'étais un peu fiévreux hier, est-ce que ça peux être lié ?
Oups désolé j'ai oublié je suis en 64bits. Et apparemment c'est pas bon.
Ah et ça te retourne quelle erreur ?
Impossible de récupérer http://apt.catapulse.org/debian/dists/stable/main/binary-amd64/Packages.gz 404 Not Found
Voilà.
C'est corrigé :)
Côté sauvegardes, je conseille à tous de regarder du côté de rdiff-backup (qu'on fera passer, comme rsync, au travers de ssh). C'est la puissance de rsync, combinée à un mécanisme qui gère automatiquement l'historique. En gros, côté sauvegarde, on a un miroir correspondant à la dernière sauvegarde et à la racine de ce miroir, un dossier spécial contenant tous les "deltas" permettant de revenir en arrière de x versions. En outre, rdiff-backup ne consigne que les portions de fichiers qui changent, ce qui le rend particulièrement efficace et économe en espace disque.
Quelques exemples d'invocation de la commande rdiff-backup :
Pour interroger le serveur de backup avec rdiff-backup :
Pour restaurer des fichiers
Faire du ménage
Quelques notes encore avec rdiff-backup
- le filesystem côté destination peut ne pas gérer les attributs étendus : ils seront stockés dans des fichiers.
- veillez à utiliser la même version de rdiff-backup sur toutes les machines car autant rsync sait "négocier" avec des versions différentes autant rdiff-backup est intransigeant.
- la version 1.2 sortie récemment a été particulièrement étudiée pour gérer les particularités des filesystems Microsoft et OS/X.
Bonjour,
Juste "bravo", comme - presque - chaque article très intéressant.
Bonne journée ;)
@AP très intéressant cet outil, merci ! Ca va rendre purement et simplement obsolète ma rotation/hardlinks de fichiers ton histoire et grandement raccourcir le script. En plus si seuls les deltas sont sauvegardés, cela va prendre moins d'espace et je dois j'imagine pouvoir utiliser cela sur des bases de données du coup... hum... Je pense que je vais mettre bientôt l'article à jour moi ;-)
@Armetiz merci :-) Pour info, c'est quoi le "presque", j'imagine que tu ne l'as pas collé là pour rien ;-)
Excellente conception, toutefois, je vous recommande également BackupPC (http://backuppc.sourceforge.net/)
http://backuppc.sourceforge.net/faq/BackupPC.html#overview
@Alexandre heureusement que j'ai écrit ceci en intro :
@AP je viens de tester rdiff-backup directement en l'implantant dans ma fonction "synchronize". Déjà ça fonctionne avec un regret cependant, ils auraient pu, vu la proximité des deux outils, ne pas s'amuser à re-syntaxer tous les arguments.
Sinon côté fonctionnalités c'est très sympa, ça marche bien pas de problème. Le soucis vient en revanche de la robustesse. En effet, si je casse la connexion en cours de syncro, chose qui arrivera forcement un jour où l'autre, le dossier de delta devient simplement illisible... Au relancement de la synchro on obtient ceci :
C'est pas génial ça, je perd du coup tout l'historique de sauvegarde. Autre chose qui m'a posé problème, leur protocole est super sensible aux versions. Si ce ne sont pas exactement les mêmes sur les deux machines, ça capote. Ceci dit, ce n'est pas très grave en soit mais ça l'est un peu si on oublie de mettre à jour une machine qui du coup sort du pool de sauvegarde.
Je vais encore regarder pour voir s'il y a moyen de réparer la casse sur une connexion perdu car ce genre de problème est létal pour moi dans la mesure où je sauvegarde aussi des machines mobiles via WIFI, et le WIFI étant ce qu'il est, faut que ce soit robuste.
@Ulhume, tu as probablement raison, mais le fait d'anticiper les commentaires, ne doit pas nous empêcher d'en faire ;) ... merci tout de même d'avoir répondu. Bonne continuation.
@Ulhume: Effectivement, il faut avoir pile poil les mêmes versions de rdiff-backup partout... et il a en effet un peu de mal quand il se prend les pieds dans le tapis. Il faut que la session (vue comme une grosse "transaction" au sens base de données) se passe bien de bout en bout. Si ça cafouille, à l'essai suivant, il annule ce qui est partiellement passé avant de démarrer. Ce point est évoqué dans la FAQ présente sur le site officiel... Pour ma part, il me sert chaque nuit pour mon backup perso vers un PC tiers au travers d'internet (Dyndns power). De même, citons au nombre de ses faiblesses le fait qu'il ne sait pas finement réguler sa consommation de bande passante (le "--bwlimit" de rsync).
Malgré tout, je reste fan de l'outil... :)
Article super intéressant merci beaucoup :-)
De mon coté je cherche à faire des backups régulière de mon système directement sur un serveur nas relié à mon réseau et j'ai encore jamais trouvé :-(
@Sooske c'est quoi comme serveur NAS ?
C'est un synology Ds 207
@AP Ok, j'ai le problème. En fait l'erreur que je t'ai donnée apparaît lorsque le connexion a planté lors de la première session. Du coup le dossier ne contient pas de pointeur current (logique vu qu'il n'y avait rien eu avant) et le résultat est que rien n'est récupérable.
En revanche, si la connexion plante sur les synchro suivantes, on ne perd que la dernière session qui a de toute façon foiré.
Tout cela se teste très bien en killant ssh sur la machine distante.
Bon, en tout cas ça me convient mieux comme cela, et l'idée me plaît beaucoup. Avec l'ancienne méthode je ne pouvais pas me permettre d'historiser les bases de données, avec ton outil, ça semble très réalisable. En revanche je n'ai pas trouvé d'option qui permette de limiter le nombre d'historique. J'imagine que la solution est de systématiquement finir une session par un pure de tout ce qui est plus vieux que N jours ?
@Sooske Tout dépends de ce que tu veux dire par "directement sur un serveur NAS". Si tu veux que ce soit le NAS qui lance la procédure de backup, il faut que tu regardes de ce côté http://www.synology.com/enu/products/features/networkbackup.php
Vu que c'est un zinzin bien windowsien, j'imagine qu'il doit être capable d'aller parler à un partage en CIFS. Donc si tu installes SAMBA sur ton PC et que tu crées des partages sur ce que tu veux sauvegarder, ton NAS devrait pouvoir faire le boulot.
@ Ulhume j'aurai du préciser (honte à moi) je suis sur une mandriva et ne possède aucun Windows chez moi, pour le moment je fais mes backups via rsync vers un pc distant présent sur mon réseau, j'aurai voulu que ma backup parte directement sur le serveur nas et chaque fois j'échoue à l'authentification sur ssh.
Ce serait bien un article sur les Nas un de ces quatres ;-)
@Sooske je ne risque pas de faire un tel article car je n'en possède pas, en revanche mon site t'es ouvert ;-)
Le fait que tu possèdes une mandriva (enfin quelqu'un qui n'a pas ubuntifié assimilé), ne t'empêche pas d'installer un serveur sampa (urpmi samba-server) et ainsi de publier sur ton réseau des partages compatibles Windows (CIFS). Du coup ton NAS ira directement prendre les données sur ton disque.
Tout sauf Ubuntu :-)
Effectivement je n'avais pas songé à samba de cette manière, je vais m'y pencher voir ce qui est faisable ou non.
Merci beaucoup !
@Ulhume,
Le presque parfait est là, surtout car le parfait absolus n'existe pas ;)
Ene ffet, même les articles où tu parles de tes déboires à fabriquer une tour pour y mettre des pc m'ont intéressés ^^
@Armetiz Ouf, j'ai cru que j'avais encore écrit des boulettes :)
@AP ban, ben ça y'est, je suis converti :-)
Juste pour signaler que dans la série "backup incrémental avec historique", il y a http://www.rsnapshot.org/, basé aussi sur rsync et cp -al (les liens durs, c'est bien pour faire plein de snapshots sans prendre trop de place), le paquet existe dans la plupart des distribs (sinon, pas dur à installer, juste un script perl qui parse un fichier de conf).
Il est fourni avec un fichier de conf qui permet de gérer ses backups en spécifiant juste
- les répertoires à sauvegarder (locaux ou distants)
- où les sauvegarder
- le nb de snapshots quotidiens/hebdos/mensuels à garder
On peut aussi préciser un script à exécuter avant/après, et des listes d'exclusions/inclusions.
Par rapport à rdiff, il ne garde pas tout, seulement ce qu'on lui demande (ex j-1, j-2, ... , j-6, semaine-1, ... , mois-1, etc.) et fait des snapshots séparés par date.
Seul bémol, on ne peut pas préciser directement des répertoires différents suivant la fréquence (ce serait pratique de garder 3 mois d'archives pour certains dossiers mais seulement 3j pour d'autres). Pour y parvenir il faut soit effacer certaines parties de vieux snapshots dans un postsnap.sh, soit créer plusieurs fichiers de conf et lancer chaque snapshot avec sa conf et sa fréquence séparément.
Bref, un autre outil du même genre, simple mais adaptable.
@daniel merci pour l'aternative. Pour l'instant je teste rdiff-backup histoire de voir si à terme la solution est fonctionnelle. Des snaps répétés ne prennent pas trop de place ceci dit dans la mesure où les deltas sont vides. Ceci dit je le trouve un chouilla lent et pompant un peu plus de ressources sur la machine cible qu'un rsync.
Oh oui vraiment sympa rdiff-backup.
Il existe de nombreux script qui l'emploie : http://wiki.rdiff-backup.org/wiki/index.php/ContribScripts
Dont un qui m'intéresse plus particulièrement slbackup (pas si puissant que le tient, gère pas les win$)
Sinon as tu mis a disposition les sources de ton script ? Juste une petite observation, ne devrais tu pas tester la présence de rdiff, créer les répertoires ... avant l'éxécution ? Et un autre détail, je ne comprends pas très bien l'option '--tempdir', en effet pendant la synchro pas un octect n'y est écrit ? J'ai vérifié ce point car l'utilisation de /tmp est déconseillé car réservé au système ( si /tmp est sur une partition séparée il y a le risque que celle-ci explose et donc que le système devient instable.)
@Dab Pour les sources, je collerais cela dans subversion sous peu. Pour les tests, ben disons que c'est plus la démarche du "je me consruit mon backup" plus que celle du "je fais un script pour les gens", donc c'est vrai que la démarche "idiots proof" me semble mais obligatoire :-)
Pour le coup de tempdir, cela me vient de rsync. Alors je sais pas si rdiff fait la même chose, mais au cas où... En fait, avec rsync, lorsqu'un gros volume de données était transféré, il prenait de l'espace sur /tmp. Le souçis est que le dossier en question était limité par une partition et mon rsync plantait systématiquement, genre sur une vidéo. Du coup j'ai pris l'habitude de mettre cette option qui chez moi pointe vers une partition de large taille. Maintenant, est-ce que cela sert avec rdiff, no lo se.... Mais s'il a mis l'option ça doit pas être non plus pour des prunes ;-)
J'ai rajouté un chapitre pour les sources
grazie :)
Un petit truc bien pratique avec le cron (du moins sous Debian) est que lorsqu'un script exécuté écrit sur sa sortie standard, un mail d'information contenant cette sortie est transmis à root. Utile par exemple pour prévenir lors d'un echec de synchronisation.
@Dab je crois que c'est un comportement standard du GNU/CRON. J'ai la même chose avec la Driva en tout cas mais j'ai pas trouvé un moyen très malin de l'utiliser dans le script.
Tu pourrai peut être simplement écrire sur la sortie standard qu'en cas de pb lors de l'exécution du script?
En cas de pb, on écrit plutôt sur la sortie d'erreurs ;-)
Car souvent on lance les script cron avec du
ce qui permet de ne recevoir par mail que les erreurs (la sortie standard de l'éxécution "normale" étant évacuée vers /dev/null pour ne pas polluer la boîte mail).
@Daniel la remarque est juste en effet :-)
Tout à fait Daniel, c'est nettement plus propre. Je n'avais pas remarqué que le cron récuperait aussi la sortie d'erreur
Pour la route : Backupnija ( http://riseuplabs.org/backupninja/ ) : Sauvegarde incrémentale via rdiff-backup, sauvegarde des bases Mysql, postgres, de dépot subversion, openldap, gravure sur CD ... bien foutu
Encore une petite piste sur la sauvegarde si je peux me permettre :
http://www.bacula.org/en/
Un outil extrêmement puissant et à mon gout plus simple de misse en œuvre qu'Amanda
@maze je le note en cas de besoin mais pour l'instant mon chtit script convient à mon modeste usage :-)
@Dab noté aussi :-)
Merci pour cet article !
@Ulhume Petite erreur dans rdist-backup ?
. Je pense que le mot juste serait plutôt "historise".
Bonne continuation
@GoZ C'est corrigé, merci :)
s/rdist-backup/rdiff-backup/g
s/c'est en autres/c'est entre autres/g
On peut signaler pour info que rdiff-backup a un cousin nommé "duplicity", développé par la même équipe. Le postulat de base de cet outil est : "faire ses sauvegardes sur un serveur à qui on ne fait pas vraiment confiance en terme de confidentialité". Contrairement à rdiff-backup, la sauvegarde n'est pas un miroir de la version n avec des deltas pour "remonter le temps" mais une copie chiffrée de notre système à sauvegarder à une date donnée, copie tronçonnée en blocs et assortie des deltas qui permettent d'arriver jusqu'à la version actuelle. Sur le papier, cet outil est séduisant. En pratique, si le serveur FTP sur lequel on sauvegarde nos données est capricieux et coupe un transfert en plein milieu, on est bons pour tout recommencer. Avec de petits volumes de données (de l'ordre de quelques centaines de Mo) ça me semble jouable. Avec des volumes plus importants, ça me semble casse-gueule. Quoi qu'il en soit, c'est bon de voir que des développeurs ont pensé aux paranos parmi nous... :)
@AP c'est modifié merci :)
Bonsoir,
merci pour cette belle page, comme beaucoup d'autre d'ailleurs. Je vais avoir besoin de me pencher sur le problème, ce sera un excellent point de départ. (dans 2 ans, si tout va bien, je serai en thèse, et je ne veux rien perdre ;) )
autre chose : une phrase mal rattrapée :
"Ensuite la sauvegarde ne va pas se faire en local, mais sur J'utilise ici la technique du un disque USB externe pour séparer au mieux les deux systèmes. "
@spip merci pour la phrase, un peu plus que "mal rattrapée", complètement stupide m'aurais paru plus juste ;-)
Bonjour,
Tout d'abord bravo pour ce super boulot!
Ensuite je souhaite tester la solution juste avant celle ci avec rdiff-backup en étant conscient de vos remarques à son sujet. J'ai donc créé un répertoire où j'ai mis vos sources et un script pour tester sur une machine winxp.
Le script:
Mais j'ai des erreur que voici:
Déjà vous utilisez la version BASH (l'ancienne) et pas la version PERL (nouvelle)
Ensuite, pour backup.sh, vous avec une dépendances :
http://svn.arnumeral.fr/subversion/public/tools/libraries/bash/traces.sh
Une fois que vous l'avez récupéré, ajouter . $BASE_PATH/traces.sh avant l'inclusion de backup.sh dans votre fichier test, cela devrait mieux marcher.
Maintenant, la version en SH, je ne l'utilise plus depuis belle lurette :)
Merci, voici mon nouveau fichier:
Mais j'ai toujours une erreur.
Merci.
zarb, à la limite remplacez la fonction _trace comme ceci :
Bonjour, et encore merci de la rapidité pour votre aide!
Mais j'ai toujours cette erreur:
J'ai l'impression qu'il y a un soucis avec votre bash, et là je vais avoir du mal à debugger par commentaires :)
Une dernière question.
ma distrib est ubuntu server 8.04 LTS:
Sh pointe t'il vers le bon bash?
hum, sous Mandriva on utilise bash et pas dash, essayer de remplacer #!/bin/sh par #!/bin/bash dans tous les scripts (test.sh backup.sh et traces.sh) pour voir.
Ca marche mieux!
Mais nouvelle erreur pour mon poste winxp:
Voici le script de backup
Pour vous aidez un peut le poste à sauvegarder à comme nom netbios autocad, il y a le D:\ qui s'appelle stockage de partagé dessus et je souhaite sauvegarder le répertoire documents qui se trouve à la racine de D:
Encore merci!
tu n'aurais pas oublié une accolade par hasard ? ;-) regarde bien, juste après "release_cifs_host" :)
Et bien merci celà à l'air de fonctionner maintenant à moi de vérifier.
Par contre rdiff me parrait assez lent....
Je testerais aussi la version perl! Mais je suis assez rétissant car il me faudrait installer les dépendances avec CPAN.
J'en doute, les dépendances PERL s'installent (en tout cas c'est comme cela sous mandriva) en passant par les dépôts standard
Peux tu me les donner?
Je vais voir si c'est dispo dans les depots ubuntu.
Merci
Rdiff-backup me semble très lent plus d'une 1H pour 512Mo en cifs!!
Est ce normal??
EDIT: Problème résolu!
Poster un nouveau commentaire