Journal bup, solution de backup viable ?

Posté par  . Licence CC By‑SA.
Étiquettes :
3
11
mai
2011

cher journal,

Je suis à la recherche d'avis sur le système de backup bup.

J'aime bien le fait que ça soit basé sur git, que ça utilise un algo de rolling checksome, tout ça évite la redondance des données.

C'est assez récent (octobre 2009), c'est pourquoi je cherchais des retours d'expérience concernant la stabilité et la viabilité des backups (notamment).

  • # Je ne connaissais pas bup…

    Posté par  . Évalué à 2.

    Mais il à l'air de correspondre à mes besoins… Je vais tester ça pour backuper mes données de mes PCs vers mon serveur !

  • # Épidémie

    Posté par  . Évalué à 9.

    Je crois que nous devons alerter les services de santés immédiatement, nous avons très clairement à faire à une épidémie qui se généralise... Les gens ne savent plus cliquer sur "forum"... Ou alors ils confondent les mots "journaux" et "forums" qui il est vrai ont une écriture assez semblable...

    • [^] # Re: Épidémie

      Posté par  . Évalué à 1.

      désolé de l'offence, mais la page http://linuxfr.org/proposer-un-contenu ainsi qu'un coup d'œil aux journaux récents m'ont enduit d'erreur.

      Promis, je referais plus

      • [^] # Re: Épidémie

        Posté par  . Évalué à 8.

        Oh si, refais-le.

        Ce journal était informatif et m'a fait découvrir un nouvel outil

    • [^] # Re: Épidémie

      Posté par  . Évalué à 3.

      Incroyable comme y'a toujours quelqu'un pour dire ça et que malgré tout la discussion se fait à chaque fois (même que parfois, c'est intéressant et utile :o).

      • [^] # Re: Épidémie

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Tu insinues que les forums ne sont pas intéressants ?

        • [^] # Re: Épidémie

          Posté par  . Évalué à 3.

          Ni utile. Yes sir Yes (spa moi qui l'dit, c'est lui).

          "The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln

      • [^] # Re: Épidémie

        Posté par  (site web personnel) . Évalué à 5.

        Je propose une nouvelle fonctionnalité: dans chaque journal, on aurait un bouton qui pourrait directement générer un fil de discussion:

        • ce journal n'aurait-il pas sa place dans les forums?
        • quel rapport avec le libre?
        • c'est lumineux!

        Les contributeurs gagneraient tellement de temps...

    • [^] # Re: Épidémie

      Posté par  (site web personnel) . Évalué à 5.

      Son journal, même si formulé comme une question, m'a permis de découvrir un logiciel libre.

      • [^] # Re: Épidémie

        Posté par  (site web personnel, Mastodon) . Évalué à 0.

        Son journal est une question, cela aurait tout de même été très sympatique de sa part de mettre la question dans le forum puis d'écrire un journal "j'ai découvert machin, on m'en a dit que du bien, ça fait ça c'est trop cool même si c'est un peu jeune"

      • [^] # Re: Épidémie

        Posté par  . Évalué à 3.

        Tu l'aurais tout aussi bien découvert dans les forums, je me trompe ?

        Ou alors tu ne vas pas voir les forums car c'est pourri de gens qui, au lieu de troller, tentent d'agir en aidant un peu les autres.

  • # Pas de suppression des vieux backups

    Posté par  (site web personnel) . Évalué à 4.

    ça a l'air vraiment cool (surtout le poème au début du readme ^^), et git le rends vraiment performant !

    mais

    bup currently has no features that prune away old backups.

    Because of the way the packfile system works, backups become "entangled" in weird ways and it's not actually possible to delete one pack (corresponding approximately to one backup) without risking screwing up other backups.

    git itself has lots of ways of optimizing this sort of thing, but its methods aren't really applicable here; bup packfiles are just too huge. We'll have to do it in a totally different way. There are lots of options. For now: make sure you've got lots of disk space :)

    Oui, il manque la suppression des anciens backups, mais puisque les nouveaux backups ont potentiellement des morceaux en commun, il faudrait trier les morceaux qui sont utilisés plusieurs fois et le reloger, etc, ... et c'est pas implémenté !

    Sinon c'est impressionnant comme projet !

    • [^] # Re: Pas de suppression des vieux backups

      Posté par  . Évalué à 3.

      Je ne vois pas bien les avantages par rapport à backintime (http://backintime.le-web.org/documentation/) par exemple (qui est fondé sur rsync et les hardlinks) ?

      Est-ce que quelqu'un a évalué les deux solutions ?

      • [^] # Re: Pas de suppression des vieux backups

        Posté par  (site web personnel) . Évalué à 2.

        C'est le morceaux de fichiers qui peuvent être partagés entre plusieurs fichier et même plusieurs backup différents.

        Après il faut évaluer dans quelle configuration laquelle est la meilleure.

      • [^] # Re: Pas de suppression des vieux backups

        Posté par  (site web personnel) . Évalué à 0.

        J'utilise moi aussi un script rsync fait maison qui se base sur les hardlinks. C'est très pratique, et très compact niveau espace disque (les sauvegardes sont incrémentales). Le fait d'utiliser les hardlinks permet d'émuler des sauvegardes sous la forme de « snapshot ». Pour libérer de l'espace disque ou supprimer des sauvegardes, c'est trivial, il suffit de supprimer des snapshots.

        La magie des hardlinks ! (Et rsync un peu aussi…)

  • # Let's check some !

    Posté par  . Évalué à 10.

    un algo de rolling checksome, tout ça évite la redondance des données

    Vraiment ?! Si ça check some, c'est qu'il s'agit d'une vérification très partielle, et par conséquent pas très fiable... :-P

  • # A la main c'est mieux

    Posté par  (site web personnel) . Évalué à 1.

    En matière de backup j'utilise toujours des solutions où je contrôle tout du début à la fin donc c'est toujours du dev maison basé sur des outils simples telle que rsync, cp (hardlink), tar, mail et pour gérer tout ce petit monde un petit script.

    J'ai publié mon script backupeur, pour le moment la dernière version publié date mais je finalise une nouvelle dont j'ai pratiquement tout re-écris.

    Born to Kill EndUser !

    • [^] # Re: A la main c'est mieux

      Posté par  . Évalué à 5.

      Sauf que si j'utilise ton script, je ne l'aurai pas fait à la main, moi... (ce qui reviens au même que d'utiliser une autre solution toute faite).

      • [^] # Re: A la main c'est mieux

        Posté par  (site web personnel) . Évalué à 1.

        Effectivement sauf à te plonger dans les petits bout de shell script ce qui est bien plus simple qu'un programme en perl, python ou C.

        Born to Kill EndUser !

        • [^] # Re: A la main c'est mieux

          Posté par  . Évalué à 3.

          shell script ce qui est bien plus simple qu'un programme en perl, python ou C.

          Ça c'est vite dis le shell c'est lourd à en crever ne serais-ce que par le nom typage des variables (dès que tu veut faire une comme de deux entier tu utilise une syntaxe pas agréable).

          Personnellement j'évite tout script shell qui fait plus de quelques dizaines de lignes (et généralement mon choix se porte vers le Perl).

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: A la main c'est mieux

            Posté par  (site web personnel) . Évalué à 3.

            C'est bien connu perl est d'une clarté limpide ;)

            Born to Kill EndUser !

            • [^] # Re: A la main c'est mieux

              Posté par  . Évalué à 4.

              Je préfère écrire :

              my $var = 34 + 8;

              que

              var=$((34 + 8))

              Ensuite le choix de Perl c'est qu'il est bien plus efficace et agréable en tant que langage de glue que python ou ruby et il donne plus de liberté. Après c'est un choix il est toujours possible d'utiliser d'autres langages à sa convenance, mais vraiment le shell (sh, bash et dans une moindre mesure zsh) a vraiment des manque pour écrire un vrai logiciel avec (visibilité des variables, typage des variables, valeur de retour des fonctions,…).

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: A la main c'est mieux

                Posté par  (site web personnel) . Évalué à 3.

                D'un autre côté j'utilise shell uniquement pour interfacer des programmes existant donc rien de bien compliqué. Pour le typage, pas vraiment utile, la gestion des erreurs, je récupère la sortie du programme lancé... Bien sûr dans le cas de mon script.

                Le but de mon script n'est pas de re-inventer rsync (ou autre) en shell mais de rajouter une couche au dessus qui permet de simplifier la configuration, avoir une gestion de log et d'alerte (mail ou console). En fait c'est un peu comme le fait rsnapshot cité plus bas.

                Pour moi shell n'est pas un "créateur de programme" mais une sur-couche qui permet de faire communiquer différent programmes entre-eux.

                Born to Kill EndUser !

                • [^] # Re: A la main c'est mieux

                  Posté par  . Évalué à 3.

                  Pour moi shell n'est pas un "créateur de programme" mais une sur-couche qui permet de faire communiquer différent programmes entre-eux.

                  Autrement dis un langage glue :)

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: A la main c'est mieux

            Posté par  (site web personnel) . Évalué à 3.

            Du coup, c'est exactement ce que je fais rsnapshot.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.