Il existe une méthode de sauvegarde générique dans backup manager qui te permet d'implémenter a peu près tout ce qui n'est pas prévu. Il te suffit de donner une commande qui produira des données sur stdout et le tour est joué.
J'oubliait également, tu pourrais aussi utiliser la fonctionnalité de "précommande" et de "postcommande".
Il s'agit de variable du fichier de conf qui pointe vers un script à exécuter. La précommande est exécutée (si définie) avant le démarrage du scénario d'archivage, la postcommande une fois le scénario terminé.
Voila pour l'exemple de configuration et la page de man :
http://www.backup-manager.org/documentation/
Dès que le guide de l'utilisateur sera terminé, il sera disponible en ligne (patience ! :)
Pour te répondre Olivier, je pense que tu peux réussir à implémenter ta stratégie d'archivage avec backup-manager, en combinant les fonctionnalités suivantes :
- le système d'upload intégré (qui passe soit par SSH soit par FTP)
- la fonctionnalité d'archivage générique (tu lui donne une commande qui sort des données sur stdout)
- la fonctionnalité de gravure automatique, avec le media "DVD"
Je t'invite à jeter un oeil à la dernière version, la 0.5.5 car elle intègre quelques nouveautés que tu as suggéré ici : la blacklist et le déréférencement de liens symboliques.
Tout d'abord merci beaucoup pour cette note très instructive :)
Je vais tâcher de répondre à tes questions une par une mais avant tout, je t'invite à t'inscrire sur la liste récemment créée, tes remarques y seraient les bienvenues ;) Pour t'inscrire, envoie un mail à backup-manager@sukria.net?subject=subscribe, la liste en elle même est backup-manager-users@sukria.net.
Autre point important : le système de gravure automatique est jugé éxpérimental pendant toute la série de 0.5.x, lorsque 0.6.0 sortira, cela voudra dire que le système est convenable pour la majorité des utilisateurs.
Place à tes questions/remarques maintenant :
> Je ne comprend pas trop cette histoire de gravure sur CD et de durée
L'idée est de tenter de graver sur CD le contenu du répertoire de backup. Si la quantité à graver est trop grande, bm essaie de ne graver que les archives du jour.
C'est très pratique avec un CDRW, tu le laisse dans ton graveur et le matin, une fois que bm est passé, tu as les archives du jour dans ton CD.
Ceci dit, ta remarque met le doigt sur le problème principal de cette stratégie : que faut-il graver ? à quelle fréquence ? Ce sont clairement les questions importantes auxquelles il faudra trouver la meilleure réponse.
Ta suggestion de paramétrer la fréquence de la gravure est bonne, je pense que je vais l'intégrer à la prochaine version. Je pense également trouver un moyen de dire explicitement à bm ce que l'on veut graver...
> si jamais le répertoir contenant les backups est un enfant du répertoire à backuper, ne pas l'archiver. J'y ai pensé au dernier moment juste avant de faire l'archive.
C'est une bonne idée. Je note.
> une option pour suivre ou non les symlinks, une blacklist"
Suivre ou non les liens symboliques est également quelque chose qui manque. Pour la blacklist, j'ai également pensé à faire une liste de répertoire à exclure.
> Faire des archives d'une taille fixée, plusieurs si besoin est (pour pouvoir graver sur CD par après). Faire directement l'iso serait génial.
L'idée de faire des archives de taille fixe est bonne, reste à voir comment on pourrait automatiser le choix des fichiers à graver en cas de place manquante.
Par contre pour l'iso, c'est techniquement très simple à faire (la première aproche adoptée était de générer l'iso puis de la graver) mais présente un inconvénient pour les utilisateurs actuels : elle nécessite de la place physique équivalente à celle occupée par les backups. Désormais bm utilise un pipe pour directement graver à la volée l'image ISO.
Dans l'idée, on voudrait adapter cela aux graveurs de DVD, imagine si backup-manager te pond une ISO de plusieurs giga tous les soirs... Ca va vite devenir encombrant ! :) Ceci dit, ça pourrait être une option également. A débattre.
Enfin, pour toutes tes remarques baptisée "confort" je pense que l'heure n'est pas encore au GUI. Je serai ravi si quelqu'un entrepenait l'écriture d'une telle surcouche mais je préfère pour l'instant me concentrer à 100% sur l'outil en tant que tel. Réussir à respecter les attentes du plus grand nombre en gardant un logiciel simple d'accès est ma priorité.
Encore merci pour ta note et n'hésite pas à venir poster (en anglais) sur la liste ! :)
Le lien ne pointe plus dans les choux.
Le howto est peut-être un peu gros pour figurer ici... en tout cas la personne qui a posté cette astuce ne m'en avais même pas parlé (en tant qu'auteur du dirty howto ça m'aurais évtier de laisser le 404 se propager)...
petite correction par rapport à ma mention conernant la correction du bug principal : un usage abusif des ressources CPU, il semblerait que ce bug apparait encore dans certains cas relativement fréquents (notamment sur des systèmes ayant un Athlon)...
Les notes de changelog sont donc un peu optimistes ;)
[^] # Re: Attention !!!!
Posté par Sukrieh Alexis . En réponse à la dépêche Première version stable de Backup Manager. Évalué à 1.
La version dans debian est obsolète : dans sarge on a la 0.5.7 (très vieille) dans sid 0.5.9b.
Je vais faire un paquet très bientot de la 0.6 (qui sera installable sur sarge sans problème de dépendances d'ailleurs).
[^] # Re: Dommage ...
Posté par Sukrieh Alexis . En réponse à la dépêche Première version stable de Backup Manager. Évalué à 4.
http://www.backup-manager.org/documentation/user-guide/ch-co(...)
[^] # Re: Et pourquoi pas en page principale ?
Posté par Sukrieh Alexis . En réponse à la dépêche Le Libr'East 2006 a besoin de toi !. Évalué à 2.
Dommage, c'est une noble cause pourtant.
[^] # Re: En vrac:
Posté par Sukrieh Alexis . En réponse au journal Backup Manager 0.5.9b. Évalué à 1.
Il s'agit de variable du fichier de conf qui pointe vers un script à exécuter. La précommande est exécutée (si définie) avant le démarrage du scénario d'archivage, la postcommande une fois le scénario terminé.
[^] # Re: En vrac:
Posté par Sukrieh Alexis . En réponse au journal Backup Manager 0.5.9b. Évalué à 1.
http://www.backup-manager.org/documentation/
Dès que le guide de l'utilisateur sera terminé, il sera disponible en ligne (patience ! :)
Pour te répondre Olivier, je pense que tu peux réussir à implémenter ta stratégie d'archivage avec backup-manager, en combinant les fonctionnalités suivantes :
- le système d'upload intégré (qui passe soit par SSH soit par FTP)
- la fonctionnalité d'archivage générique (tu lui donne une commande qui sort des données sur stdout)
- la fonctionnalité de gravure automatique, avec le media "DVD"
[^] # Re: cool..
Posté par Sukrieh Alexis . En réponse au journal backup-manager 0.5.4 est sorti. Évalué à 1.
[^] # Re: cool..
Posté par Sukrieh Alexis . En réponse au journal backup-manager 0.5.4 est sorti. Évalué à 5.
Je vais tâcher de répondre à tes questions une par une mais avant tout, je t'invite à t'inscrire sur la liste récemment créée, tes remarques y seraient les bienvenues ;) Pour t'inscrire, envoie un mail à backup-manager@sukria.net?subject=subscribe, la liste en elle même est backup-manager-users@sukria.net.
Autre point important : le système de gravure automatique est jugé éxpérimental pendant toute la série de 0.5.x, lorsque 0.6.0 sortira, cela voudra dire que le système est convenable pour la majorité des utilisateurs.
Place à tes questions/remarques maintenant :
> Je ne comprend pas trop cette histoire de gravure sur CD et de durée
L'idée est de tenter de graver sur CD le contenu du répertoire de backup. Si la quantité à graver est trop grande, bm essaie de ne graver que les archives du jour.
C'est très pratique avec un CDRW, tu le laisse dans ton graveur et le matin, une fois que bm est passé, tu as les archives du jour dans ton CD.
Ceci dit, ta remarque met le doigt sur le problème principal de cette stratégie : que faut-il graver ? à quelle fréquence ? Ce sont clairement les questions importantes auxquelles il faudra trouver la meilleure réponse.
Ta suggestion de paramétrer la fréquence de la gravure est bonne, je pense que je vais l'intégrer à la prochaine version. Je pense également trouver un moyen de dire explicitement à bm ce que l'on veut graver...
> si jamais le répertoir contenant les backups est un enfant du répertoire à backuper, ne pas l'archiver. J'y ai pensé au dernier moment juste avant de faire l'archive.
C'est une bonne idée. Je note.
> une option pour suivre ou non les symlinks, une blacklist"
Suivre ou non les liens symboliques est également quelque chose qui manque. Pour la blacklist, j'ai également pensé à faire une liste de répertoire à exclure.
> Faire des archives d'une taille fixée, plusieurs si besoin est (pour pouvoir graver sur CD par après). Faire directement l'iso serait génial.
L'idée de faire des archives de taille fixe est bonne, reste à voir comment on pourrait automatiser le choix des fichiers à graver en cas de place manquante.
Par contre pour l'iso, c'est techniquement très simple à faire (la première aproche adoptée était de générer l'iso puis de la graver) mais présente un inconvénient pour les utilisateurs actuels : elle nécessite de la place physique équivalente à celle occupée par les backups. Désormais bm utilise un pipe pour directement graver à la volée l'image ISO.
Dans l'idée, on voudrait adapter cela aux graveurs de DVD, imagine si backup-manager te pond une ISO de plusieurs giga tous les soirs... Ca va vite devenir encombrant ! :) Ceci dit, ça pourrait être une option également. A débattre.
Enfin, pour toutes tes remarques baptisée "confort" je pense que l'heure n'est pas encore au GUI. Je serai ravi si quelqu'un entrepenait l'écriture d'une telle surcouche mais je préfère pour l'instant me concentrer à 100% sur l'outil en tant que tel. Réussir à respecter les attentes du plus grand nombre en gardant un logiciel simple d'accès est ma priorité.
Encore merci pour ta note et n'hésite pas à venir poster (en anglais) sur la liste ! :)
[^] # Re: *Est-ce que le schmibiliibilbiilbiblck*
Posté par Sukrieh Alexis . En réponse au journal backup-manager, un outilsimple pour votre Linux. Évalué à 2.
L'idée est d'installer l'outil sur le site distant et de le configurer pour qu'il upload les archives générées ailleurs.
Le but est d'utiliser les infrastructures existantes (ftp, ssh) pour faciliter la mise en place rapide.
[^] # Re: *Est-ce que le schmibiliibilbiilbiblck*
Posté par Sukrieh Alexis . En réponse au journal backup-manager, un outilsimple pour votre Linux. Évalué à 1.
C'est un logiceil encore beta mais la plupart des fonctionnalités proposées sont parfaitement opérationnelles.
Cependant, le backup incrémental est prévu :) de même que le support de gravure de DVD...
[^] # Re: Utiliser Mozilla à travers un tunnel SSH
Posté par Sukrieh Alexis . En réponse au message [Terminal] Utiliser Mozilla à travers un tunnel SSH. Évalué à 1.
Le howto est peut-être un peu gros pour figurer ici... en tout cas la personne qui a posté cette astuce ne m'en avais même pas parlé (en tant qu'auteur du dirty howto ça m'aurais évtier de laisser le 404 se propager)...
a bon entendeur
[^] # Re: Debian
Posté par Sukrieh Alexis . En réponse à la dépêche GNOME 2.4 est disponible. Évalué à 1.
ajouter la ligne
deb http:// people.debian.org/ ~fpeters/gnome2.4/
dans /etc/apt/sources.list
puis :
apt-get update
apt-get upgrade
éventuellement faire un dpkg -i --force-overwrite lorsque ça merde et le tour est joué :)
# Re: Lmule est mort, vive Xmule !
Posté par Sukrieh Alexis . En réponse à la dépêche Lmule est mort, vive Xmule !. Évalué à 5.
Les notes de changelog sont donc un peu optimistes ;)
[^] # Et MyDynaWeb !!!
Posté par Sukrieh Alexis . En réponse à la dépêche Création de PHP-Nuke Club. Évalué à 2.
Voila :)
[^] # Re: Et les applets/epplets/trucs du genre?
Posté par Sukrieh Alexis . En réponse à la dépêche Split d'E17. Évalué à 1.
[^] # Re: Etrange coincidence
Posté par Sukrieh Alexis . En réponse à la dépêche Split d'E17. Évalué à -2.
D'accord la discussion est intéressante, mais je suis quand même véxé !